Page weight is not a ranking factor. It is worth getting that out of the way, because a great deal of writing on this subject implies otherwise.
What page weight does is affect three things that genuinely matter: how fast your pages are for people, how efficiently search engines can crawl your site, and how much work a browser has to do before content appears. Those effects are real and measurable, and they are why page weight and SEO keep appearing in the same sentence.
The distinction matters because it changes what you expect. Reducing weight does not buy you positions. It removes obstacles.
Page Weight and SEO: Effects on Speed and Crawling
Crawling: the effect nobody sees
Search engines allocate finite resources to any given site. Heavy pages consume more of that allocation per page fetched.
For a small site this rarely matters, and pretending otherwise is one of the more common exaggerations in SEO writing. If you have forty pages, they will be crawled.
For a large site it becomes significant. Thousands of URLs, heavy templates and slow server responses together mean crawlers reach less of your site per visit, and new or updated pages take longer to be discovered.
The signal to watch is in Search Console: pages discovered but not indexed, or a crawl rate that does not reflect how often you publish.
Core Web Vitals: where weight becomes measurable
These metrics capture what a heavy page feels like to use.
- Largest Contentful Paint measures how long the main content takes to appear, and oversized images are the usual cause of a poor score.
- Interaction to Next Paint measures responsiveness, and JavaScript is almost always the culprit when it is poor.
- Cumulative Layout Shift measures unexpected movement, commonly caused by images without dimensions or fonts swapping late.
These form part of how page experience is assessed, though they sit well below relevance and content quality in importance. A fast page about nothing still ranks nowhere.
Render cost is the underrated part
A hundred kilobytes of image is downloaded and decoded. A hundred kilobytes of JavaScript is downloaded, parsed, compiled and executed.
That difference matters twice over. On a mid-range phone, the processing delay is felt directly. And for search engines, rendering has a cost that affects how thoroughly content assembled in the browser gets processed.
Content available in the initial HTML is unambiguously available. Content that appears only after scripts run depends on rendering completing as expected, and that dependency is worth avoiding where you reasonably can.
This matters more now that AI systems also read your pages, and their rendering capability varies considerably more than search engines’ does.
Where the weight actually is
Open your highest-traffic page in a browser’s network panel, sorted by size. Three things dominate on almost every site.
- Images, usually the largest share. Wrong dimensions, dated formats and eager loading of things nobody scrolls to.
- JavaScript, usually the most expensive per byte. Libraries imported for one function, frameworks carrying features the page never uses.
- Third-party scripts, usually the easiest to remove. Tags for tools abandoned a year ago, analytics running twice because two teams added it independently.
The HTTP Archive page weight report gives you a benchmark to compare against rather than an abstract target.
Fixing it, in order
- Images: correct dimensions, modern formats, lazy loading below the fold. No design compromise and usually the largest single improvement.
- Third-party scripts: list every external domain, find an owner for each, remove the ones nobody can account for.
- Fonts: two families at most, subset to the characters used, with a readable fallback.
- JavaScript last, because it takes the most effort. Audit dependencies and prefer browser-native solutions where they will do the job.
Measure before and after under stated conditions so you know what earned the improvement. Where performance and environmental impact both apply, treat them as the same lever: reducing unnecessary data transfer and processing supports a faster experience while lowering estimated digital carbon, though environmental figures remain modelled rather than directly measured.
Our search engine optimisation work covers technical health and content together, since fixing one without the other rarely moves anything.