Does page speed affect rankings? Yes, and less than you hope
You want to know whether investing in speed will move your rankings or just your scores.
Short answer
Page speed is a confirmed ranking signal and a weak one, used mostly to separate pages that are otherwise similar in relevance. It will not lift a page that does not deserve to rank. It reliably affects conversion, crawl efficiency and bounce, which is why the work is worth doing for reasons that have nothing to do with rankings.
The size of the ranking effect
Small, and repeatedly described that way by Google. Speed acts as a tiebreaker where relevance is comparable. A slow page that answers the query better still beats a fast page that answers it worse, which is the correct outcome and also the reason speed-first strategies disappoint.
Where speed genuinely decides rankings
On competitive queries where several pages are equally good. That is a narrow band, and if your page is not already in it, speed work is not what moves you into it. Diagnose which situation you are in before committing engineering time.
The effect that is not small
People leaving. Every second before a page is usable loses a share of visitors who already chose you from the results. That loss compounds against every acquisition channel simultaneously, and unlike the ranking effect you can measure it on your own site this week.
Crawl efficiency, quietly
A faster server lets a crawler fetch more pages in the same window. This does not matter at small scale and matters increasingly as URL counts grow. It is a real second-order benefit and a poor primary justification.
How to tell if speed is your problem
Look at where you rank. If you are on page three, speed is not why. If you are hovering at the bottom of page one against comparable pages, it is a plausible tiebreaker. If your pages rank fine and convert badly, it is a conversion problem and the ranking question is a distraction.
Speed is not one number
Time to first byte is a server problem. Largest Contentful Paint is usually images and render-blocking resources. Responsiveness is JavaScript on the main thread. These have different causes and different owners, and treating them as one score is why speed projects sprawl.
The order that works
Measure field data. Fix the metric that is worst for real users. Confirm with real users, not a lab test. Then stop, because past a reasonable threshold the returns fall off sharply and the next page you write is worth more.
Questions
- How fast is fast enough?
- Out of the poor range on real-user data, on the metrics that apply to your page. Chasing perfect scores past that point is optimising a number rather than an outcome.
- Is mobile speed weighted more heavily?
- Indexing and evaluation are mobile-first, and mobile hardware is slower, so mobile is where the problem is worse and where the measurement should start.
- Will a CDN fix my speed?
- It fixes the server half: latency and time to first byte. It does nothing about JavaScript on the main thread, which on a modern application is usually the larger half.
Measured, not asserted
ihatepdf.cv reached 100,542 users on static hosting with genuinely mixed performance: an LCP of 2.488s, an INP of 296ms, and a CLS of 0.126. It ranked and grew anyway, because relevance carried it. Where speed cost real money was inside the product, in the 37.16% of sessions containing a dead click.
Free tool for this: SERP Audit. No account, nothing uploaded.
Where this goes deeper
Every number on this page comes from one complete dataset: one product taken from zero to 100K+ users on search alone, with nothing spent on advertising. The full argument is Chapter 11 of the book. Five chapters are free to read.