Page Speed and SEO: What Actually Affects Rankings
Page speed advice tends to arrive as a list of techniques with little indication of which ones matter. That is unhelpful, because performance work is expensive and some of it has no measurable search effect at all.
What follows separates the metrics that are used in evaluation from the ones that are merely reported, and covers the fixes that address the former.
The distinction that matters: field data versus lab data
Performance tools report two different things, and confusing them wastes effort.
Lab data comes from a synthetic test run on a controlled connection. It is useful for debugging and reproducible across runs. It is not what search systems use.
Field data comes from real visitors on real devices and connections. This is the basis for the performance signals that are actually collected, and it is why a page that scores well in a lab tool can still perform poorly in the field: your visitors are not on the fast connection the test used.
Optimise against field data for real users, and use lab data to diagnose specific causes.
The metrics worth understanding
- Largest Contentful Paint. How long until the main content element is rendered. Usually the hero image or the largest text block. This is the one teams should focus on first, because it corresponds directly to when the page becomes useful.
- Interaction to Next Paint. How responsive the page is when someone acts on it. Long tasks on the main thread are the usual cause.
- Cumulative Layout Shift. How much the page moves while loading. Content that jumps as images load is the classic cause, and it is the most directly fixable of the three.
Fixes that actually move the needle
Ordered by impact relative to effort.
- Serve correctly sized images. The single most common cause of a poor Largest Contentful Paint is a large hero image downloaded at full resolution and scaled down in CSS. Serve a size appropriate to the display, and use modern formats.
- Reserve space for media. Setting explicit width and height on images and embeds eliminates most layout shift. This is a small change with a large effect.
- Prioritise the largest element. Telling the browser to load the main hero image early, rather than lazy-loading everything, improves the metric it is named after.
- Break up long main-thread tasks. Large JavaScript bundles and heavy third-party scripts delay interaction. Third-party embeds are a frequent culprit and often the easiest to defer.
- Cache and compress text assets. Straightforward, and usually already done, but worth confirming.
Fixes that matter less than they appear to
Some commonly cited optimisations have no meaningful search effect, and pursuing them first is a poor use of time.
- Chasing a perfect synthetic score. The number a lab tool reports is not what is collected from real visitors. A page at 85 in the lab with good field data is not a problem.
- Minifying everything aggressively. Usually already handled by your build tooling; manual effort here rarely changes anything measurable.
- Reducing page weight for its own sake. Weight matters insofar as it affects the metrics above. A large page that renders its main content immediately can outperform a small page that does not.
- Optimising pages nobody visits. Effort is finite. Start where the traffic is.
Where performance sits relative to everything else
Performance is a real but modest factor. Content relevance, the match between the page and the query, page quality and site-level signals all carry more weight. A slow page with the best answer to a query will usually outrank a fast page with a worse one.
The correct framing is that performance is a threshold rather than a differentiator. Being fast does not earn rankings; being slow enough to frustrate users can cost them, and it affects behaviour metrics that do matter.
Measuring without guessing
- Look at field data first, segmented by device type. Mobile and desktop problems are usually different problems.
- Identify which element is the largest contentful element on your key pages. It is often not what you expect.
- Fix the largest contributor, then re-measure after a full data collection period rather than immediately.
- Check whether third-party scripts are causing interaction delays, since these are frequently added for reasons nobody can now justify.
Pricing
All Cresca plans include templates and landing page hosting for your signup flows:
| Plan | Price | Contacts | Emails / month |
|---|---|---|---|
| Free | $0 | 50 | 50 |
| Professional | $29/mo | 5,000 | 5,000 |
| Premium | $49/mo | 25,000 | 25,000 |
| Ultra | $99/mo | 55,000 | 55,000 |
Performance and crawl budget
Speed affects crawling as well as user experience. A server that responds slowly has fewer pages crawled in the same time, and for sites with many pages the effect compounds. This is not usually the primary constraint, but on a site with thousands of URLs and a modest crawl budget, slow responses can mean pages sit undiscovered.
Server response time is the relevant measure here rather than page render time. A page with heavy client-side JavaScript may render slowly for a user while responding quickly to a crawler, and vice versa. Where crawl budget is a real constraint, check server response separately.
How to know whether to work on it at all
Performance work is worth doing when field data shows a problem affecting real users on the pages that carry your traffic. It is not worth doing to raise a lab score.
A practical test: segment your field data by device. If mobile performs substantially worse than desktop, the problem is usually asset sizing or third-party scripts, and both are fixable. If both perform acceptably, performance is not your constraint and effort elsewhere will return more.
The short version
Field data from real visitors is what gets collected; lab scores are a debugging tool. Focus on Largest Contentful Paint first, then layout stability, then interaction responsiveness. Size your images correctly, reserve space for media, prioritise the main element, and break up long JavaScript tasks.
Do not chase perfect synthetic scores or optimise pages you do not have traffic on. Server response time separately affects how much of a large site gets crawled. Performance is a threshold rather than a ranking advantage, and content quality still outweighs it.
Continue learning
Related Cresca resources
External references