Speed & Core Web Vitals
I fix the cause of a slow site. Not the symptom.
Most speed work is a caching plugin, a minifier and a hopeful re-test. That moves the lab score and leaves the actual problem in place. I profile where the time is genuinely going, fix those things, and give you a before and after you can reproduce on your own machine.
01DemonstrationLive from your browser
This page, measured as you read it.
Anyone selling speed work can show you a screenshot of a good run. These are the numbers your own browser recorded loading this page, against the thresholds Google uses. Open your network tab and check them.
Markup, styles, script and three typefaces — everything needed to paint what you are reading.
The median web page weight recorded by the HTTP Archive.
02DiagnosisWhere the time actually goes
Slow is a symptom. These are the causes.
Almost every slow site I am sent is slow for two or three of the following reasons. The point of the diagnosis is finding out which, because the fix for each is completely different — and buying the wrong fix is how people end up having paid for speed work twice.
The server is thinking too long
A high Time to First Byte means the work happens before a single byte reaches the browser. On WordPress that is usually uncached queries in a template loop, an autoloaded options table that has grown to several megabytes, or a plugin making an external API call during page render. No amount of front-end optimisation touches this.
The largest thing on screen is enormous
A hero image exported at 4000 pixels wide and served as a PNG will fail Largest Contentful Paint on its own. The fix is unglamorous: correct dimensions, modern formats, a srcset so phones do not download the desktop version, explicit width and height, and fetchpriority on the one image that matters.
Scripts are blocking the render
Every synchronous script in the head is a stop sign before the browser can paint. Tag managers, chat widgets, A/B testing tools and font loaders are the usual suspects, and they are frequently loaded on every page for a feature used on one.
The page moves while it loads
Cumulative Layout Shift is caused by things arriving late without reserved space — images without dimensions, web fonts swapping at a different size, cookie banners and ads injected above existing content. It is usually the cheapest of the three to fix and the most annoying to experience.
Interactions feel sticky
Interaction to Next Paint replaced First Input Delay in March 2024, and it is a much harder metric. It measures how long an interaction takes to produce a visible response, across the whole visit — not just the first one. Sites fail it because too much JavaScript is competing for the main thread.
03ProcessGenuinely a sequence
How the work runs.
- 01
Diagnosis, before any quote
- I profile the site and send a written breakdown of where the time goes, ranked by how much it costs you and how hard it is to fix. You keep that document whether or not you hire me.
- 02
Baseline the field data
- Lab scores bounce around between runs. I record the Chrome UX Report field data first, so that at the end we are comparing what real visitors experienced, not two lab runs on different afternoons.
- 03
Fix causes, largest first
- Work happens on staging, one change at a time, each measured on its own. Bundling ten changes together tells you nothing about which one worked, and leaves you unable to reverse the one that hurt.
- 04
Verify, then hand you the method
- You get the before and after, the steps to reproduce both, and a note on what will slowly undo the work — usually the next plugin somebody installs.
04QuestionsAsked often, answered plainly
Things people ask before hiring me.
Will a caching plugin fix my Core Web Vitals?
Partly, at best. Caching improves server response time, which helps Time to First Byte. It does very little for a Largest Contentful Paint caused by an oversized hero image, nothing for layout shift caused by unsized elements, and nothing for Interaction to Next Paint caused by heavy JavaScript. Most sites reach me with a caching plugin already installed and still failing.
Why does my PageSpeed Insights score keep changing?
The big number at the top is a lab test on a simulated slow device, and it varies between runs. The section underneath — field data from the Chrome UX Report — is what Google actually uses, and it is a 28-day rolling average of real visitors. Chase the field data and ignore small movements in the lab score.
How long until the improvement shows up in Google?
Because field data is a 28-day rolling window, expect around four weeks for the change to be fully reflected — longer on lower-traffic sites that take a while to gather enough samples. Anyone promising an instant ranking change is describing the lab score, not the one that counts.
What improvement can you promise?
None, before I have looked — which is why the diagnosis comes first and the quote comes second. A plugin-heavy site with an unoptimised hero has a great deal of easy headroom. A site already lean at the front end but slow in the database is a different job at a different price. I would rather give you a real number after an hour of profiling than an impressive one now.
Do I need to rebuild the site?
Usually not. Most speed problems are a handful of specific causes rather than a fundamental flaw, and fixing them is far cheaper than rebuilding. If I think you have hit the ceiling of what the current build can do I will say so — but that is the exception, and it is not in your interest for me to reach for it first.
What is INP, and did it replace FID?
Interaction to Next Paint replaced First Input Delay as a Core Web Vital in March 2024. FID only measured the delay before the browser started handling your first interaction. INP measures how long the whole interaction took to produce a visible response, across the entire visit. It is considerably harder to pass, and it is usually failed for one reason: too much JavaScript on the main thread.
My site was fine and got slow. What changed?
In my experience, almost always one of three things: a plugin or tracking script added since, a content team uploading full-resolution images straight from a camera, or a database that has quietly grown — post revisions, expired transients, an autoloaded options table. All three are cheap to fix once identified.
Next step
Send me the URL. I will tell you what is wrong with it.
The first thing you get is a written diagnosis you keep either way. If the honest answer is that your site is already fine, that is what the document will say.