Why does 63% of your page weight slow down your SEO?

Why does Google place so much emphasis on image weight?

Dominik Heyberg points out a shocking figure that still surprises many professionals: 63% of a page's total weight comes from images. This massive proportion turns every poorly optimized visual into a burden for your loading time. Google’s bots scan your pages with particular attention to speed metrics, and a heavy image can severely impact First Contentful Paint (FCP) and Largest Contentful Paint (LCP).

The problem isn’t limited to mobile. On desktop, users also leave a page if the loading time exceeds three seconds. Google translates these drop-offs into negative signals for your ranking. A 2 MB uncompressed image can slow a page down by several seconds, which is enough to cost you positions on competitive queries.

What are the three techniques mentioned by Google?

Heyberg lists three distinct strategies: compression, quality reduction, and deferred loading. Compression (via WebP, AVIF, or tools like TinyPNG) reduces file size without altering dimensions. Quality reduction means lowering the JPEG or PNG compression rate, knowing that a JPEG at 85% remains imperceptible to the human eye compared to 100%.

Deferred loading (lazy loading) delays the download of off-screen images until the user scrolls. This technique avoids loading 10 MB of images at the bottom of a page when the user may have only seen the header. Native lazy loading in HTML (loading="lazy") is now supported by all modern browsers, making implementation much simpler without additional JavaScript.

How do these optimizations concretely affect crawling and indexing?

A slow site exhausts Googlebot's crawl budget. If your pages take three seconds to respond due to oversized images, the bot will crawl fewer URLs per session. On a site with 50,000 pages, this translates to entire sections being ignored for weeks. Optimized images speed up server responses and allow Google to discover more content in the same time frame.

Mobile-first indexing amplifies this phenomenon. Googlebot simulates a 4G network, not fiber. A 3 MB image that loads in one second on your desktop can block a page for 15 seconds under real mobile conditions. Google interprets this delay as a signal of poor technical quality and adjusts rankings accordingly.

• 63% of the average weight of a page comes from images, making it the primary optimization lever.
• Compression, quality reduction, and lazy loading are the three priority techniques according to Google.
• Native lazy loading (loading="lazy") simplifies implementation without custom JavaScript.
• A slow site reduces the crawl budget and penalizes the indexing of large hierarchies.
• Mobile-first indexing multiplies the impact of heavy images on LCP and rankings.

Does this statement align Google with field observations?

Heyberg doesn’t say anything new, but he officially confirms what performance audits have revealed for years. Tools like GTmetrix or WebPageTest regularly show that unoptimized images are the number one factor slowing down loading times. What matters here is Google’s public validation: image optimization isn’t just a developer fad, it’s a ranking criterion via Core Web Vitals.

However, the figure of 63% deserves nuance. This is an average. Minimalist blogs hover around 40%, while e-commerce sites with 20 product photos per page exceed 75%. A site with lots of text and few visuals will benefit less from optimizing its images than a media-heavy site. Effort must be proportionate to context.

What limits should you be aware of before over-compressing?

Reducing JPEG quality from 100% to 50% saves weight, but be cautious: on certain visuals (portraits, fine textures), degradation becomes visible to the naked eye below 75%. A luxury e-commerce site displaying watches with an overly compressed JPEG loses credibility. Google doesn’t directly measure visual quality, but users do, and a high bounce rate impacts ranking.

Lazy loading also presents a trap: if you apply it to the LCP image (the largest image visible without scrolling), you artificially delay the LCP and degrade your score. Google explicitly recommends never lazy loading above-the-fold images. This is a common mistake in pre-configured WordPress themes.

Should you prioritize WebP or AVIF?

Heyberg doesn’t mention the formats, but it’s the logical extension. WebP reduces weight by 25-35% compared to JPEG without noticeable quality loss, and it is supported by 97% of browsers. AVIF goes even further with gains of 40-50%, but browser support remains incomplete (especially Safari iOS before version 16).

In practice, serve AVIF with a WebP fallback, then JPEG. The <picture> tag allows this cascade without JavaScript. However, keep in mind: AVIF encoding is slower on the server side, which can create issues on sites with heavy user uploads (marketplaces, UGC). [To be verified] on your stack before large-scale deployment.

What should you do to optimize your images concretely?

Start with an audit of your pages' actual weight using PageSpeed Insights or Lighthouse. Identify images that exceed 200 KB and compress them using tools like Squoosh, TinyPNG, or ImageOptim. If your CMS is WordPress, Imagify or ShortPixel automate the process in the backend. For custom sites, integrate an image CDN like Cloudinary or Imgix that compresses and resizes on the fly.

Define explicit dimensions in HTML (width and height) to avoid Cumulative Layout Shift (CLS). If you load an image at 1200x800 but CSS resizes it to 600x400, you are wasting bandwidth. Serve the exact expected size, ideally in several formats via <picture> and srcset.

What mistakes should you absolutely avoid?

Never lazy-load the hero image or logo. Google explicitly penalizes this practice because it delays the LCP. Reserve lazy loading for images below the fold. On mobile, this often starts as early as the second section of the page.

Avoid exotic formats without fallbacks. Serving only AVIF without WebP or JPEG backup makes your images invisible on old browsers. A user on Safari iOS 15 will see empty frames if you don’t provide a fallback. The <picture> tag neatly solves this problem.

How can you check if your optimizations are working?

Run a Lighthouse test in mobile mode and target an LCP of less than 2.5 seconds. If your images are the blocking factor, Lighthouse will list problematic files with their current weight and optimal weight. Compare before and after to measure actual gains.

Also, monitor the crawl budget in Google Search Console. If the number of pages crawled per day increases after optimization, it means Googlebot is benefiting from your reduced response times. On a large site, this metric is a key indicator of technical health.

• Compress all images over 200 KB using WebP or AVIF + fallback JPEG.
• Add loading="lazy" to images outside the initial viewport, never on the LCP.
• Define explicit width and height to avoid CLS.
• Use <picture> and srcset to serve the exact size based on the device.
• Test mobile LCP with Lighthouse aiming for less than 2.5 seconds.
• Monitor the crawl budget in Search Console after optimization.