Web Design Lab Guide

Lazy loading defers image downloads until they enter the viewport, cutting initial page weight by 50-70% without sacrificing user experience. Native browser support via the loading="lazy" attribute requires zero JavaScript, while Intersection Observer API provides custom control for advanced implementations like placeholder transitions and load timing adjustments.

Critical Implementation Requirements: Native loading="lazy" attribute for browsers supporting the feature (Chrome 77+, Firefox 75+, Safari 15.4+, Edge 79+), Intersection Observer API fallback for custom thresholds, explicit image dimensions with aspect-ratio to prevent layout shift, above-the-fold exclusions with fetchpriority="high" for LCP images, and decoding="async" for non-blocking rendering on remaining images.

Five Rules for Proper Implementation:

• Never apply lazy loading to above-the-fold images; instead use fetchpriority="high" and consider <link rel="preload"> for LCP images to prioritize critical rendering path
• Set explicit width and height attributes or aspect-ratio CSS on all lazy-loaded images to reserve layout space and prevent Cumulative Layout Shift during load
• Use decoding="async" on lazy-loaded images and fetchpriority="low" on below-the-fold content to deprioritize non-critical resources in browser’s fetch queue
• Include sizes attribute with responsive srcset to prevent incorrect source selection; browser calculates based on viewport width and DPR without proper sizing hints
• Implement Intersection Observer fallback with appropriate rootMargin (browser-dependent, typically 500-1000px) for older browsers without native lazy loading support

Performance Benefits Beyond Page Weight: Reduced server bandwidth consumption for images users never view (saves 2-4MB per page load based on HTTP Archive median), faster First Contentful Paint on mobile devices with limited processing power (improvement varies by device CPU), lower data costs for users on metered connections, improved Time to Interactive by deferring non-critical resource parsing, and better perceived performance through strategic placeholder use during image transitions.

Implementation Path: Start with native loading="lazy" attribute for immediate page weight reduction, add fetchpriority="high" to LCP image and fetchpriority="low" to below-fold images, implement decoding="async" on all lazy-loaded images, add Intersection Observer with browser-appropriate rootMargin for custom loading thresholds, implement dominant color or LQIP placeholders with prefers-reduced-motion support, set aspect ratios using modern aspect-ratio CSS property, and validate with Lighthouse audits targeting LCP under 2.5 seconds and CLS under 0.1.

---

Native Lazy Loading Implementation

Modern browsers support lazy loading through a single HTML attribute. No JavaScript required for basic functionality.

Add loading="lazy" with proper attributes:

<img 
  src="product.jpg" 
  loading="lazy" 
  decoding="async"
  fetchpriority="low"
  width="800"
  height="600"
  alt="Product image"
>

Attribute Breakdown:

• loading="lazy": Defers loading until image approaches viewport
• decoding="async": Prevents blocking main thread during image decode
• fetchpriority="low": Deprioritizes this image in browser fetch queue
• width/height: Reserves layout space to prevent CLS

The browser handles everything. Images download only when approaching the viewport. Default threshold varies by browser and connection speed (Chrome uses approximately 1250px on fast connections, increases to 2500px on slow 2G). The browser adjusts this distance dynamically based on effective connection type.

Note: Exact thresholds are browser-dependent and change between versions. Chrome, Firefox, and Safari use different algorithms. Test on actual devices rather than assuming fixed distances.

Browser support covers approximately 95% of users as of November 2025 (data from caniuse.com). Chrome 77 (August 2019), Edge 79 (January 2020), Firefox 75 (April 2020), Safari 15.4 (March 2022), and Opera 64 all support native lazy loading.

Older browsers ignore the loading attribute and load images normally. No JavaScript errors. No broken images. Graceful degradation without additional code.

Native lazy loading works best for blog content below the fold, product galleries on e-commerce sites, image-heavy portfolios, and news article lists. The browser’s automatic behavior handles 90% of common use cases without custom configuration.

---

Critical Exclusions From Lazy Loading

Never lazy load images users see immediately. This rule prevents performance penalties from delayed content rendering.

Hero images must load with high priority:

<img 
  src="hero.jpg" 
  fetchpriority="high"
  decoding="sync"
  width="1200"
  height="600"
  alt="Hero section"
>

Critical image attributes:

• fetchpriority="high": Tells browser to prioritize this image over other resources
• decoding="sync": Ensures image decodes before render (prevents flash of unstyled content)
• Explicit dimensions: Prevents CLS when image loads

For LCP images requiring preload:

<link rel="preload" as="image" href="hero.jpg" fetchpriority="high">
<img src="hero.jpg" fetchpriority="high" width="1200" height="600" alt="Hero">

Use rel="preload" only when the LCP image isn’t discoverable early in HTML (e.g., CSS background images or JavaScript-injected images). Overuse harms performance by blocking other critical resources.

The first 3-5 images should never lazy load. These appear in the initial viewport on most devices. Apply standard eager loading:

<!-- First 3 products load immediately with priority hints -->
<img src="product1.jpg" fetchpriority="high" decoding="async" width="400" height="400" alt="Product 1">
<img src="product2.jpg" fetchpriority="auto" decoding="async" width="400" height="400" alt="Product 2">
<img src="product3.jpg" fetchpriority="auto" decoding="async" width="400" height="400" alt="Product 3">

<!-- Remaining products lazy load with low priority -->
<img src="product4.jpg" loading="lazy" fetchpriority="low" decoding="async" width="400" height="400" alt="Product 4">
<img src="product5.jpg" loading="lazy" fetchpriority="low" decoding="async" width="400" height="400" alt="Product 5">

Priority Strategy:

• First image: fetchpriority="high" (likely LCP candidate)
• Images 2-3: fetchpriority="auto" (default priority)
• Images 4+: loading="lazy" + fetchpriority="low"

Never lazy load logos, navigation icons, UI button images, or background images in hero sections. These elements constitute critical UI that users expect instantly.

---

Responsive Images With Lazy Loading

Responsive images require srcset and sizes for proper source selection. Omitting sizes causes incorrect downloads.

Incorrect implementation (missing sizes):

<!-- Browser can't calculate which source to use -->
<img 
  srcset="image-400.jpg 400w, image-800.jpg 800w, image-1200.jpg 1200w"
  src="image-800.jpg"
  loading="lazy"
  alt="Image"
>

Correct implementation with sizes:

<img 
  srcset="image-400.jpg 400w, image-800.jpg 800w, image-1200.jpg 1200w"
  sizes="(max-width: 600px) 100vw, (max-width: 1200px) 50vw, 800px"
  src="image-800.jpg"
  loading="lazy"
  decoding="async"
  fetchpriority="low"
  width="800"
  height="600"
  alt="Responsive lazy image"
>

How sizes works:

• (max-width: 600px) 100vw: On screens ≤600px, image takes full viewport width
• (max-width: 1200px) 50vw: On screens 601-1200px, image takes 50% viewport width
• 800px: On screens >1200px, image is fixed 800px width

Browser calculates: (viewport width × DPR × size percentage) = required pixel width, then selects closest source from srcset.

Without sizes, browser assumes 100vw, potentially downloading unnecessarily large images.

Intersection Observer with responsive images:

const imageObserver = new IntersectionObserver((entries, observer) => {
  entries.forEach(entry => {
    if (entry.isIntersecting) {
      const img = entry.target;
      
      if (img.dataset.srcset) {
        img.srcset = img.dataset.srcset;
      }
      
      if (img.dataset.sizes) {
        img.sizes = img.dataset.sizes;
      }
      
      if (img.dataset.src) {
        img.src = img.dataset.src;
      }
      
      observer.unobserve(img);
    }
  });
}, {
  rootMargin: '500px 0px' // Load 500px early on vertical axis only
});

HTML structure:

<img 
  data-srcset="image-400.jpg 400w, image-800.jpg 800w, image-1200.jpg 1200w"
  data-sizes="(max-width: 600px) 100vw, (max-width: 1200px) 50vw, 800px"
  data-src="image-800.jpg"
  src="data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 800 600'%3E%3C/svg%3E"
  width="800"
  height="600"
  alt="Responsive lazy image"
>

---

Modern Image Formats With Lazy Loading

Modern formats (AVIF, WebP) reduce file size by 30-50% compared to JPEG while maintaining visual quality.

Using <picture> for format fallback:

<picture>
  <source 
    type="image/avif" 
    srcset="image-400.avif 400w, image-800.avif 800w, image-1200.avif 1200w"
    sizes="(max-width: 600px) 100vw, (max-width: 1200px) 50vw, 800px"
  >
  <source 
    type="image/webp" 
    srcset="image-400.webp 400w, image-800.webp 800w, image-1200.webp 1200w"
    sizes="(max-width: 600px) 100vw, (max-width: 1200px) 50vw, 800px"
  >
  <img 
    srcset="image-400.jpg 400w, image-800.jpg 800w, image-1200.jpg 1200w"
    sizes="(max-width: 600px) 100vw, (max-width: 1200px) 50vw, 800px"
    src="image-800.jpg"
    loading="lazy"
    decoding="async"
    fetchpriority="low"
    width="800"
    height="600"
    alt="Image with format fallback"
  >
</picture>

Browser selection order:

1. Checks AVIF support → uses if available (smallest file)
2. Checks WebP support → uses if available (medium file)
3. Falls back to JPEG → universal support (largest file)

Format comparison (800×600 image, 80% quality):

• JPEG: 120KB
• WebP: 65KB (46% smaller)
• AVIF: 45KB (62% smaller)

Note: These numbers vary based on image content. Photographic images compress better than text/graphics.

Generate formats using ImageMagick:

# Convert to WebP
convert original.jpg -quality 80 image.webp

# Convert to AVIF
convert original.jpg -quality 80 image.avif

Or use image CDNs (Cloudinary, ImageKit, Imgix) for automatic format conversion based on browser support.

---

Placeholder Strategies For Visual Continuity

Blank spaces during image load create poor user experience. Placeholders maintain layout and provide visual feedback.

Dominant color with blur transition (respecting motion preferences):

<img 
  src="data:image/jpeg;base64,/9j/4AAQSkZJRg..." 
  data-src="full-quality.jpg"
  class="lazy blur"
  style="background-color: #8B7355;"
  width="800"
  height="600"
  alt="Image"
>

CSS with motion sensitivity:

img.lazy.blur {
  filter: blur(20px);
}

/* Smooth transition for users without motion sensitivity */
@media (prefers-reduced-motion: no-preference) {
  img.lazy.blur {
    transition: filter 0.3s ease-out;
  }
}

/* Instant transition for users with motion sensitivity */
@media (prefers-reduced-motion: reduce) {
  img.lazy.blur {
    transition: none;
  }
}

img.lazy.loaded {
  filter: blur(0);
}

JavaScript with motion-aware loading:

const prefersReducedMotion = window.matchMedia('(prefers-reduced-motion: reduce)').matches;

const imageObserver = new IntersectionObserver((entries, observer) => {
  entries.forEach(entry => {
    if (entry.isIntersecting) {
      const img = entry.target;
      const fullImg = new Image();
      
      fullImg.onload = () => {
        img.src = fullImg.src;
        img.classList.add('loaded');
      };
      
      fullImg.src = img.dataset.src;
      observer.unobserve(img);
    }
  });
}, {
  rootMargin: prefersReducedMotion ? '200px 0px' : '500px 0px'
});

Users with motion sensitivity get:

• Instant filter transition (no animation)
• Smaller rootMargin (reduces unexpected content changes)

---

SEO Considerations For Lazy Loading

Google renders JavaScript but not always perfectly. Proper implementation ensures search engines index lazy-loaded images.

Safe noscript pattern (prevents double download):

<!-- JavaScript-enabled browsers -->
<img 
  data-src="image.jpg" 
  src="data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 800 600'%3E%3C/svg%3E"
  class="lazy" 
  loading="lazy"
  width="800"
  height="600"
  alt="Product"
>

<!-- JavaScript-disabled browsers and crawlers -->
<noscript>
  <img src="image.jpg" width="800" height="600" alt="Product">
</noscript>

Why this pattern works:

• JavaScript-enabled: Loads placeholder SVG immediately, swaps to real image when in viewport
• JavaScript-disabled: Ignores data-src, shows noscript image
• No double download: JavaScript browsers never request both versions

Incorrect pattern (causes double download):

<!-- BAD: Both src and data-src present -->
<img src="image.jpg" data-src="image.jpg" loading="lazy" alt="Product">
<noscript>
  <img src="image.jpg" alt="Product">
</noscript>

This downloads the image twice in JavaScript-enabled browsers.

Native loading="lazy" requires no special SEO handling:

<img src="image.jpg" loading="lazy" alt="Product">

Google understands this attribute and treats images normally for indexing purposes.

Structured data with multiple images:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "image": [
    "https://example.com/product-main.jpg",
    "https://example.com/product-angle1.jpg",
    "https://example.com/product-angle2.jpg"
  ],
  "name": "Product Name"
}
</script>

Include all product images in structured data array. Google discovers images through schema even when lazy loaded.

---

Performance Measurement Methods

Testing validates lazy loading improvements and identifies implementation problems. Use real-world data rather than assuming fixed percentages.

Chrome DevTools measurement:

1. Open DevTools (F12)
2. Navigate to Network tab
3. Check “Disable cache”
4. Select “Slow 3G” or “Fast 3G” throttling
5. Reload page
6. Note “Transferred” value at bottom
7. Scroll to bottom and note final transferred value

Example results (based on actual test):

• Before lazy loading: 4.2MB transferred on load
• After lazy loading: 850KB transferred on load (80% reduction)
• After scrolling to bottom: 3.8MB transferred (some images never viewed)

Lighthouse CLI with before/after comparison:

# Before implementation
lighthouse https://example.com --output=json --output-path=./before.json

# After implementation
lighthouse https://example.com --output=json --output-path=./after.json

# Compare LCP, CLS, FCP scores

Example Lighthouse improvements:

• LCP: 4.2s → 2.1s (50% improvement)
• FCP: 2.8s → 1.4s (50% improvement)
• CLS: 0.15 → 0.02 (87% improvement with proper dimensions)
• Performance Score: 68 → 94

Note: Your results will vary based on image count, sizes, hosting infrastructure, and user connection speeds. Always measure your specific implementation.

Real user monitoring tracks actual performance:

const imageObserver = new IntersectionObserver((entries, observer) => {
  entries.forEach(entry => {
    if (entry.isIntersecting) {
      const img = entry.target;
      const startTime = performance.now();
      
      img.onload = () => {
        const loadTime = performance.now() - startTime;
        
        // Send to analytics
        if (typeof gtag !== 'undefined') {
          gtag('event', 'lazy_image_load', {
            'image_src': img.src,
            'load_time': Math.round(loadTime),
            'connection_type': navigator.connection?.effectiveType || 'unknown'
          });
        }
      };
      
      img.onerror = () => {
        // Track failed loads
        if (typeof gtag !== 'undefined') {
          gtag('event', 'lazy_image_error', {
            'image_src': img.dataset.src
          });
        }
      };
      
      img.src = img.dataset.src;
      observer.unobserve(img);
    }
  });
});

This tracks load time per image and connection type, revealing performance bottlenecks in production.

---

WordPress Lazy Loading

WordPress 5.5 (August 2020) includes native lazy loading by default. No plugin required for basic functionality.

WordPress automatically adds loading="lazy" to content images inserted through the block editor or wp_get_attachment_image() function.

Disable lazy loading for specific images:

// For hero/LCP images, disable lazy loading per-image
add_filter('wp_get_attachment_image_attributes', function($attr, $attachment, $size) {
  // Check if this is a hero image (example: featured image on single posts)
  if (is_single() && $attachment->ID === get_post_thumbnail_id()) {
    $attr['loading'] = 'eager';
    $attr['fetchpriority'] = 'high';
    $attr['decoding'] = 'sync';
  }
  
  return $attr;
}, 10, 3);

This approach targets specific images without globally disabling lazy loading.

Add fetchpriority and decoding to lazy images:

add_filter('wp_get_attachment_image_attributes', function($attr, $attachment, $size) {
  // If image is lazy loaded, add performance hints
  if (isset($attr['loading']) && $attr['loading'] === 'lazy') {
    $attr['fetchpriority'] = 'low';
    $attr['decoding'] = 'async';
  }
  
  return $attr;
}, 10, 3);

This adds modern attributes WordPress doesn’t include by default.

WordPress plugins for advanced control:

• Lazy Load by WP Rocket: Excludes specific images, handles YouTube embeds, supports background images
• Smush Pro: Combines format conversion (WebP/AVIF), lazy loading, and CDN integration
• Perfmatters: Granular control over lazy loading with exclusion rules

Modern block themes (FSE themes) often handle responsive images and sizes attributes automatically. Classic themes may need manual sizes implementation in image output functions.

---

Browser Compatibility Reference

Feature	Chrome	Firefox	Safari	Edge	Support %
Native lazy loading	77+	75+	15.4+	79+	~95%
Intersection Observer	51+	55+	12.1+	15+	~97%
Aspect ratio CSS	88+	89+	15+	88+	~94%
fetchpriority	101+	126+	17.2+	101+	~89%
decoding	65+	63+	11.1+	79+	~96%
AVIF	85+	93+	16.1+	85+	~91%
WebP	32+	65+	14+	18+	~97%

Support percentages based on caniuse.com data as of November 2025.

Native lazy loading covers the vast majority of users. Sites targeting older browsers (Internet Explorer 11, Safari 14 and below) need JavaScript fallbacks.

---

Implementation Checklist

• [ ] Add loading="lazy" to all below-the-fold images
• [ ] Add decoding="async" to all lazy-loaded images
• [ ] Add fetchpriority="high" to LCP image
• [ ] Add fetchpriority="low" to below-fold lazy images
• [ ] Include sizes attribute with all responsive srcset images
• [ ] Set explicit width and height or aspect-ratio on all images
• [ ] Exclude hero images, logos, and first 3-5 visible images from lazy loading
• [ ] Implement <picture> with AVIF/WebP for modern browsers
• [ ] Add dominant color or LQIP placeholders
• [ ] Implement prefers-reduced-motion support in transitions
• [ ] Use safe noscript pattern (placeholder SVG in src, real image in noscript)
• [ ] Test on throttled connections (Slow 3G, Fast 3G)
• [ ] Run Lighthouse audit (LCP <2.5s, CLS <0.1, defer offscreen images passing)
• [ ] Verify no double downloads in Network panel
• [ ] Check that LCP element loads with fetchpriority="high"
• [ ] Measure before/after page weight (expect 50-70% reduction, varies by site)
• [ ] Add error handling for failed image loads
• [ ] Implement RUM tracking for lazy load performance
• [ ] For WordPress: Add per-image loading="eager" filter for hero images
• [ ] For WordPress: Add fetchpriority and decoding attributes via filter

---

Frequently Asked Questions

Does lazy loading hurt SEO rankings?

No, when implemented correctly. Google’s crawler renders JavaScript and understands native loading="lazy" attributes. Using the safe noscript pattern (placeholder in src, real image in <noscript>) ensures images remain accessible to crawlers without JavaScript execution. Main product images and featured images should load with fetchpriority="high" rather than lazy loading.

Should I use fetchpriority=”high” on multiple images?

No. Use fetchpriority="high" only on the LCP element (typically the hero image). Using it on multiple images defeats the purpose because the browser can’t prioritize everything. Images 2-3 should use default priority (fetchpriority="auto" or omit attribute), and images 4+ should use fetchpriority="low" with lazy loading.

What’s the difference between decoding=”async” and decoding=”sync”?

decoding="async" allows the browser to decode the image off the main thread, preventing blocking during decode. Use this for all lazy-loaded and non-critical images. decoding="sync" forces synchronous decode, ensuring the image is ready before render. Use this only for LCP images to prevent flash of unstyled content.

How do I know which image is my LCP element?

Run Lighthouse or use Chrome DevTools Performance panel. Record a page load, then look for the “LCP” marker in the timeline. Click it to see which element was identified as LCP. This is your fetchpriority="high" candidate.

Why do I need sizes attribute with srcset?

Without sizes, browsers assume images take 100% viewport width (100vw), causing unnecessarily large downloads. On a 1920px screen with DPR 2, browser requests the 3840px image even if the image only displays at 400px. sizes tells the browser actual display size so it can select the appropriate source.

Can I use lazy loading with background images?

Yes, but requires JavaScript. CSS background-image doesn’t support the loading attribute. Use Intersection Observer to add a class that applies background-image when the element enters viewport. For high-DPR screens, use image-set() in CSS or data attributes with JavaScript to provide multiple resolutions.

Does WordPress automatically add sizes to images?

Yes, WordPress generates sizes attribute automatically for images inserted through the block editor or wp_get_attachment_image(). However, the generated sizes may not match your actual layout. For precise control, use wp_calculate_image_sizes and wp_calculate_image_srcset filters to customize based on your theme’s layout.

How do I test if lazy loading works correctly?

Open Chrome DevTools Network panel, enable “Disable cache”, reload the page, and note which images load immediately. Scroll slowly and watch new images appear in the Network panel as they enter viewport. The initial “Transferred” count should be 50-70% less than total page weight. Use Lighthouse to verify “defer offscreen images” passes and LCP is under 2.5 seconds.