# Performance & Core Web Vitals

Code For Broke audits and fixes website performance problems, using controlled tests and available visitor measurements to guide the work.

---
A slow first screen, a button that hesitates, or a page that shifts while you're reading are different problems. I start with what visitors are trying to do, then trace what is getting in their way.

## Where the time usually goes

The investigation follows the evidence. Common places to look include:

- **Images.** File size, loading order, and whether each screen gets an appropriately sized image.
- **Fonts.** Which fonts load, when text appears, and whether changing fonts moves the layout.
- **Third-party scripts.** The loading and interaction cost of chat widgets, tag managers, and other embeds.
- **Client-side frameworks.** The amount of JavaScript a page needs for the interactions it actually offers.

## What you get

A prioritized explanation of the problems, agreed fixes, and comparable before-and-after tests. Where visitor data is available, I use it to review the live experience too. Business outcomes need their own evaluation; a better score alone is not a revenue result.

## Keeping it fast

A site that was fast at launch doesn't stay fast on its own. Every new plugin, embed, and tracking script costs something, and the decline is gradual enough that nobody notices until it's bad. That's the argument for handling it inside an ongoing arrangement, whether that's [an embedded engagement](/services/embedded-web-development/) or the care plan on [a managed website](/services/managed-static-sites/), rather than as a rescue every couple of years.

---

## Frequently asked questions

### My Lighthouse score is fine. Do I still have a problem?

Possibly. A Lighthouse run tests a controlled scenario, while field data reflects visits from real people on different devices and networks. I use both to understand what's happening. A good lab score alone doesn't tell us that every visitor has a good experience.

### Is this a one-off audit or ongoing?

It can be either. As a one-off you get the audit, the fixes, and before and after numbers. Inside an ongoing engagement it's continuous, which matters because performance regresses quietly every time something new is added.

### What if the site is too slow to fix?

Sometimes the architecture itself is the bottleneck and tuning it is throwing money at the symptom. You'll be told that plainly, with the reasoning, rather than sold a round of optimization that buys a few hundred milliseconds.