Key takeaways
- Field data beats lab scores. A perfect test result means nothing if real users on real connections are having a slow experience.
- Fix LCP first — it is usually the failing metric and usually has one identifiable cause.
- Speed is a threshold, not a race. Once you are in the good band, further optimisation buys conversion, not rankings.
- Most sites lose their performance to images and third-party scripts, and both are fixable without a rebuild.
Performance work attracts a particular kind of waste: weeks spent moving a score from 78 to 94 on a page nobody visits, while the category page that generates the revenue takes six seconds to become usable on a phone. The score went up, the business did not notice, and everyone concluded that speed does not matter.
This article is about doing performance work that pays, using the Semalt platform to see which templates are actually slow for actual users: how to read the two kinds of data, which metric to fix first, and how to know when to stop.
Lab and field: the distinction that decides everything
Two kinds of measurement exist and they answer different questions. Confusing them is the source of most bad decisions in this area.
| Lab data | Field data | |
|---|---|---|
| What it is | One simulated load, controlled conditions | Real users, over a rolling window |
| Good for | Debugging, comparing before and after a change | Knowing whether you have a problem at all |
| Weakness | Nothing like a real session: no cart, no session, cold or warm cache by chance | Slow to move; tells you what, not why |
| When they disagree | Field wins. It is the population that generates revenue. | |
The practical consequence: use field data to decide whether to act and where, and lab data to diagnose and to verify a fix. Teams that work the other way round optimise pages nobody visits, on conditions nobody experiences.
Working parameters from the approach described below.
Which metric to fix first
Three metrics matter, and they are not equally likely to be your problem.
- Largest Contentful Paint — start here
How long until the main content is visible. It fails on most sites, and it usually has one dominant cause: an unoptimised hero image, a render-blocking font or stylesheet, or a slow server response on uncached pages. Identify which of the three and you have identified the fix.
- Cumulative Layout Shift — second, and usually easy
Content jumping while the page loads. Almost always ad slots, embeds or images without declared dimensions. The fix is reserving the space in CSS, which is cheap and rarely controversial.
- Interaction responsiveness — last, and hardest
How quickly the page responds to a tap or click. This means JavaScript, which means a real engineering conversation about what is running and whether it needs to. Leave it until the first two are resolved.
Group by template, not by URL. The useful statement is never "the site is slow". It is "the category template has an LCP problem on mobile". Sorting the crawl results by template turns a list of thousands of slow URLs into three or four actual problems, each with one place to fix it.
See also: Internal Links: The Free Lever Almost Every Site Leaves Unused.
Images: the single largest cause
On the majority of sites we audit, images account for more of the problem than everything else combined, and the fixes are well understood and boring.
What to do
- Serve modern formats — WebP or AVIF — with a fallback
- Size images to their display size, not the original upload
- Set explicit width and height so nothing shifts
- Lazy-load everything below the fold, never the hero
What causes the problem
- A 4000px photograph displayed at 600px
- Forty full-resolution thumbnails on a category grid
- Lazy-loading the hero image, which delays LCP directly
- Background images in CSS that the browser discovers late
The third item on the right is a classic own goal. Lazy-loading is applied to every image indiscriminately, including the one at the top of the page, which is precisely the element the LCP measurement is waiting for. The result is a site that scores worse after an optimisation pass than before it.
Third-party scripts
The second major cause, and the one that requires a business conversation rather than a technical one. Every analytics tool, chat widget, review embed, heatmap, consent banner and remarketing tag adds weight, and each was added by someone who reasonably believed it was harmless.
The exercise that works is an annual inventory: list every third-party script, name the person who wants it, and ask what would break if it were removed. In our experience a third of the list has no current owner, and removing those items produces a measurable improvement with no downside at all.
For what remains, loading strategy matters. Nothing that is not needed for the initial render should block it — defer, load on interaction, or load after the main content. A chat widget that appears two seconds later loses nothing; a chat widget that delays the page hurts every visitor.
Before the browser: server response and caching
Front-end optimisation gets the attention, but a substantial share of slow sites are slow before a single byte of HTML reaches the browser. If the server takes most of a second to start responding, everything downstream inherits that delay and no amount of image work recovers it.
We cover this in detail in Images and Video.
Three causes account for most of it on the sites we see. Uncached dynamic pages, where every visit rebuilds the same output from the database — the fix is page caching, and on a content site it is close to free. Database queries that grew as the site did, particularly on category and listing pages where an innocent query becomes expensive at ten thousand rows. And shared hosting that is simply oversubscribed, which is not a technical problem at all but a purchasing one.
The diagnostic is quick. Measure the time to first byte on a page that is definitely not cached, then measure it again on a page that should be. If both are slow, look at hosting. If only the uncached one is slow, look at caching and queries. If both are fast and users still report slowness, the problem is in the browser and the earlier sections apply.
One caution about caching plugins: they frequently create their own problems, particularly with combined and minified assets that break layout intermittently or serve stale content after updates. When a site develops mysterious visual bugs that appear for some visitors and not others, the caching layer is the first place to look, not the last.
One more thing worth checking while you are in there: whether the same template performs differently for logged-in and anonymous visitors. On sites with accounts, caching often applies only to anonymous traffic, which means the experience your own team sees while logged in bears no relation to what search engines and first-time visitors get. It is a common reason for a team to insist the site is fast while the field data disagrees.
There is a full walkthrough in Structured Data in Practice.
Speed is a threshold, not a competition
This is where most performance budgets are wasted. Being faster than the good threshold does not rank you above a competitor who is also above it — the metric stops differentiating once you are past it.
What continues to improve beyond that point is conversion, which is a genuine reason to keep going but a different justification with a different owner. Be explicit about which one you are arguing for. "This will improve rankings" stops being true once you are in the good band; "this will improve checkout completion" may still be true and is measurable.
Beware optimising the wrong page. The homepage is the most tested and least representative page on most sites. Test the templates that receive search traffic and generate revenue — usually a category or service page, and on mobile, since that is where both the traffic and the problems concentrate.
Measuring the effect honestly
Performance work has an awkward property: it takes weeks to appear in field data, by which time other things have changed. Two habits keep the attribution clean.
Ship performance changes as a distinct batch, separate from content or design releases, with the date recorded. If speed work, a redesign and a content update all land in the same fortnight, nobody can say what caused what.
And record the lab measurement immediately before and after, on the same templates, as evidence that the change did what it was supposed to. Field data confirms it four weeks later; the lab measurement is what tells you the deployment actually worked in the meantime.
A note on the local reality
Two observations specific to sites serving Portugal. Mobile connection quality varies considerably outside the main urban corridors, which means testing on a fast connection in central Lisbon systematically understates the problem for a meaningful share of the audience. Where field data shows a wide spread between the median and the slower percentiles, that spread is usually geography rather than devices.
The second is about hosting. A large number of Portuguese business sites run on shared hosting with slow server response, and no amount of front-end optimisation compensates for a server that takes 800 milliseconds to begin responding. Check the server response time first: if it is poor, the cheapest performance improvement available is often changing hosting rather than optimising anything.
A realistic sequence
Check the field data by template and identify which templates are actually failing for real users. Fix the LCP cause on the worst commercial template — usually images or a render-blocking resource. Reserve space for anything that shifts. Then audit the third-party scripts and remove what has no owner.
That sequence resolves most real-world performance problems and it rarely requires a rebuild. What it does require is choosing the pages by revenue rather than by which one is easiest to test.
If you have never separated your performance data by template, that is the first useful step. Open the dashboard, run a crawl, and look at which template group carries the worst numbers on mobile.
Frequently asked questions
Do Core Web Vitals affect rankings?
They are a factor, but a threshold one rather than a competitive one. Being in the good band matters; being twice as fast as another site already in the good band does not rank you above it. Relevance and content quality outweigh speed comfortably. Beyond the threshold, further work should be justified by conversion rather than by rankings.
My test score is 95 but the site feels slow. Why?
Because the test ran under conditions no real visitor experiences: no session, no cart, no consent banner, no third-party scripts firing, on a fast connection. Field data reflects what actual users experienced over a rolling window, including everyone on an old device during your busiest hour. When lab and field disagree, field is the one that describes your customers.
Which metric should we fix first?
LCP, in almost every case. It is the metric that fails most often and it usually has a single identifiable cause: an unoptimised hero image, a render-blocking font or stylesheet, or a slow server response. Layout shift comes second and is usually cheap to fix. Interaction responsiveness comes last because it means JavaScript work.
Should we lazy-load all images?
Everything below the fold, yes. The hero image, never — lazy-loading the element that LCP is measuring delays exactly the thing being measured, and sites regularly score worse after applying lazy-loading indiscriminately. Combine it with correct sizing, modern formats and explicit dimensions, which together do more than lazy-loading alone.
Open your Semalt dashboard
Audits, rank tracking, competitor data and reporting in one place. Sign in and you will be looking at real numbers for your own domain within minutes.
Sign in to SemaltOr browse the service overview at semalt.com.
