What does Google say about SEO? /
Quick SEO Quiz

Test your SEO knowledge in 5 questions

Less than a minute. Find out how much you really know about Google search.

🕒 ~1 min 🎯 5 questions

Official statement

Lazy-loading should not be used for all images because this technique has drawbacks for images immediately visible on screen. It should be applied selectively only to images below the fold line.
🎥 Source video

Extracted from a Google Search Central video

💬 EN 📅 02/07/2024 ✂ 19 statements
Watch on YouTube →
✂ Other statements from this video 18 ▾
  1. □ Are images really slowing down your site's SEO performance?
  2. □ How can you actually boost your website's performance by selecting the right image format?
  3. □ Should you really automate image compression for SEO purposes?
  4. □ Is your website really serving the right image size to each device?
  5. □ Does Google really index all your responsive image variations with picture and srcset?
  6. □ Should you systematically use lazy-loading for all images below the fold?
  7. □ Should you really use the HTML loading attribute to optimize lazy-loading?
  8. □ Are images really the main bottleneck killing your site's performance?
  9. □ Are poorly configured images really harming your SEO through layout shifts?
  10. □ Does image quality really need to adapt by screen size for SEO success?
  11. □ Do you really need picture and srcset to optimize responsive images for SEO?
  12. □ Should you declare alternative image versions using structured data to boost Google's indexing?
  13. □ Should you really enable lazy-loading on every single below-the-fold image?
  14. □ Is lazy-loading all your images actually hurting your SEO performance?
  15. □ Should you really be using the HTML loading attribute for lazy-loading in 2024?
  16. 1:22 Do you really need to migrate your images to WebP and AVIF to boost your SEO?
  17. 1:57 Should you really automate image compression for SEO success?
  18. 1:57 Should you really manually verify automatic image compression results for your website?
📅
Official statement from (2 years ago)
TL;DR

Google recommends against applying lazy-loading to all images on a page. Images that are immediately visible on screen (above the fold) should load normally, otherwise you risk degrading user experience and Core Web Vitals. Lazy-loading should remain targeted: only for content below the initial viewport.

What you need to understand

Why is Google so insistent about this specific point?

Lazy-loading defers image loading until they're about to enter the viewport. Applied to an image visible upon arriving on the page, this introduces an artificial delay: the browser must first parse the HTML, load the JavaScript, then trigger the image download. The result? A blank screen or white space for several hundred milliseconds.

This delay directly degrades the Largest Contentful Paint (LCP), a Core Web Vitals metric that measures the rendering time of the largest visible element. If your hero image is lazy-loaded, you're voluntarily sabotaging your LCP.

What exactly is the fold?

The fold (or "line of sight") refers to the lower limit of the screen upon initial load, before any scrolling. Everything visible immediately must load as a priority — images, text, buttons.

The problem: this line varies depending on the device. A smartphone in portrait mode, a tablet in landscape, a 27-inch desktop screen… the visible height changes dramatically. Modern browsers and frameworks (WordPress, Next.js) attempt to estimate this threshold, but it's never perfect.

What are the concrete consequences of poorly applied lazy-loading?

  • LCP degradation: visible delay in loading main images, direct impact on Core Web Vitals
  • Cumulative Layout Shift (CLS): if space isn't reserved with width/height, lazy-loaded images cause layout shifts
  • Diminished user experience: blank screens, feeling of slowness even on fast connections
  • Potential ranking loss: Core Web Vitals are a confirmed ranking signal since 2021

SEO Expert opinion

Is this recommendation really being applied by CMSs and frameworks?

Let's be honest: the vast majority of mainstream implementations get this wrong. WordPress, with its automatic loading="lazy" attribute since version 5.5, sometimes applies lazy-loading to images above the fold. The CMS attempts to detect the first images, but frequently fails.

JavaScript frameworks (React, Vue, Next.js) perform better with their optimized <Image> components, but developers must use them correctly. I've seen Next.js sites where all images had loading="lazy" hardcoded, including the logo and hero image.

What are the gray areas in this statement?

Google doesn't specify how many images should load normally. One? The first three? Up to what exact height? [To verify]: there's no official threshold in pixels or number of images.

Another unclear point: what about images in a carousel visible on the first screen? Lazy-load the second slide that will display in 5 seconds? The question remains open. My field advice: load the first slide normally, lazy-load the rest.

Warning: some cache or image optimization plugins force lazy-loading on all <img> tags without distinction. Check your WP Rocket, Imagify, ShortPixel settings and similar — they can sabotage your LCP without you knowing.

Does this rule also apply to CSS background images?

Google explicitly mentions <img> tags, but the principle applies to critical background-image properties. If your hero is a div with a CSS background, don't defer it via JavaScript.

That said, browsers load CSS background-image differently — they only trigger the fetch if the element is in the DOM and visible. It's already a form of native lazy-loading, but less penalizing than poorly implemented custom JS.

Practical impact and recommendations

How do you identify which images shouldn't be lazy-loaded?

Use PageSpeed Insights or Lighthouse in mobile and desktop mode. Look at the LCP section: if the detected element is a lazy-loaded image, you have a problem. The report will explicitly tell you if lazy-loading is harming your LCP.

Manually inspect your page with DevTools: open the Network tab, filter by "Img", reload and observe the loading order. The first visible images should appear at the top of the cascade, not after 2 seconds of JS parsing.

What technical mistakes must you absolutely avoid?

Never force loading="lazy" on an image that has fetchpriority="high" or is marked as critical. That's a blatant contradiction that confuses the browser.

Avoid custom JavaScript solutions for lazy-loading if you don't have the technical expertise to properly exclude above-the-fold images. The native loading="lazy" API is sufficient in 90% of cases, provided you don't apply it blindly.

  • Audit your site with Lighthouse/PageSpeed Insights to detect lazy-loaded LCP images
  • Remove the loading="lazy" attribute from the 1-2 first visible images on each page
  • Configure your CMS/plugin to exclude critical images from automatic lazy-loading
  • Add fetchpriority="high" to the LCP image if the browser supports it (Chrome, Edge)
  • Reserve space with width and height to avoid CLS, even on non-lazy-loaded images
  • Test on both mobile AND desktop: the fold changes, so your exclusions must too
  • Verify that your <picture> tags and srcset don't break native lazy-loading behavior
Lazy-loading is a powerful technique, but its application requires discernment. Performance gains only materialize if you apply it to the right images at the right time. The stakes are not negligible: degraded LCP costs you rankings, traffic, conversions. If your technical stack is complex — custom CMS, JS frameworks, CDN with on-the-fly image transformations — fine-tuning optimization can quickly become a headache. It's precisely in these hybrid configurations that an external expert perspective can make the difference, by carefully auditing your loading priorities and adjusting your rules to maximize both perceived speed and actual metrics.

❓ Frequently Asked Questions

L'attribut loading="lazy" natif est-il suffisant ou faut-il du JavaScript custom ?
L'attribut natif est largement suffisant pour 90% des sites. Il est bien supporté (Chrome, Firefox, Safari, Edge) et ne nécessite aucun JS supplémentaire. Réservez les solutions JavaScript uniquement si vous avez des besoins très spécifiques, comme un lazy-loading progressif ou un contrôle pixel-perfect du seuil.
Comment WordPress gère-t-il le lazy-loading automatique ?
Depuis WordPress 5.5, l'attribut loading="lazy" est ajouté automatiquement à toutes les images de contenu (pas au logo ni aux images de thème). Le CMS tente d'exclure les premières images, mais cette détection est imparfaite. Il faut souvent ajuster manuellement ou via plugin.
Que faire si mon plugin d'optimisation force le lazy-loading partout ?
Allez dans les réglages du plugin (WP Rocket, Imagify, etc.) et cherchez l'option d'exclusion. Vous pouvez généralement exclure des images par classe CSS, par URL ou par position. Excluez au minimum la première image de chaque page.
Le lazy-loading impacte-t-il l'indexation des images par Google ?
Non, Googlebot sait interpréter le lazy-loading et indexe correctement les images différées. Le problème du lazy-loading n'est pas le SEO image, mais bien les Core Web Vitals et l'expérience utilisateur.
Faut-il lazy-loader les images en fin d'article long ?
Oui, absolument. Toute image située plusieurs écrans en dessous du viewport initial doit être lazy-loadée. C'est précisément le cas d'usage optimal : économiser de la bande passante et accélérer le chargement initial sans sacrifier l'expérience.
🏷 Related Topics
Domain Age & History Content AI & SEO Images & Videos

🎥 From the same video 18

Other SEO insights extracted from this same Google Search Central video · published on 02/07/2024

🎥 Watch the full video on YouTube →

Related statements

💬 Comments (0)

Be the first to comment.

2000 characters remaining
🔔

Get real-time analysis of the latest Google SEO declarations

Be the first to know every time a new official Google statement drops — with full expert analysis.

No spam. Unsubscribe in one click.