This test fails when one or more images on the page are served at dimensions significantly larger than the size at which the browser actually renders them. Fixing this issue means resizing the source files (or serving responsive variants) so the bytes downloaded match the pixels actually displayed. The result is faster page loads, lower data usage, and better Core Web Vitals scores.

Example

<img
  src="/images/hero-800.jpg"
  srcset="/images/hero-400.jpg 400w,
          /images/hero-800.jpg 800w,
          /images/hero-1600.jpg 1600w"
  sizes="(max-width: 640px) 100vw, 800px"
  alt="Marathon runners at sunrise"
  width="800" height="450">

Where to make the change

• Raw HTML: use srcset and sizes to let the browser pick the right variant for the user's viewport. Always include intrinsic width and height attributes.
• WordPress: WordPress generates multiple image sizes automatically. Use the the_post_thumbnail() helper or the block editor's image block, both of which emit responsive srcset markup.
• Shopify: use the image_url Liquid filter with size parameters (for example {{ image | image_url: width: 800 }}) and pair with image_tag to emit a responsive image.
• Wix or Squarespace: both platforms generate responsive variants automatically; this issue is typically caused by uploading a deliberately oversized image.
• Headless or framework sites: use the framework's image component (for example next/image or astro:assets), which generates responsive variants and lazy-loads off-screen images.

Common causes and how to resolve them

• Original camera or stock-photo file uploaded as-is: a 6000-pixel-wide JPEG rendered in a 400-pixel column wastes most of the bytes. Resize the source or generate responsive variants.
• No srcset: the browser has no choice but to use the single source. Add multiple variants so mobile users get smaller files.
• Hero images sized for ultra-wide displays: if your largest layout is 1600 pixels, do not ship a 4000-pixel original.
• Background images set in CSS without responsive sources: use the image-set() CSS function or media queries to swap in different image files at different breakpoints.

Best practices

• Generate variants at common widths: 400, 800, 1200, and 1600 pixels covers most viewports cleanly.
• Always set width and height: intrinsic dimensions let the browser reserve space and avoid layout shift, helping CLS.
• Lazy-load off-screen images: add loading="lazy" to images below the fold so the browser only downloads them when needed.
• Pair with modern formats: resizing alone is good; resizing and serving WebP or AVIF compounds the savings.

This test fails when one or more images are rendered at an aspect ratio meaningfully different from the source file's native ratio, producing stretched or squashed visuals. Fixing this issue means either using width and height attributes that match the file's real dimensions or replacing the source with a correctly proportioned crop.

Example

<!-- Source file is 1600 x 900 (16:9). Set matching attributes: -->
<img src="/images/marathon-1600.jpg"
     alt="Marathon runners at sunrise"
     width="1600" height="900"
     style="max-width: 100%; height: auto;">

Where to make the change

• Raw HTML and CSS: set the width and height attributes to the source file's native dimensions. Use CSS height: auto when scaling responsively so the browser preserves the ratio.
• WordPress: when inserting an image via the block editor, choose the image's intended size rather than overriding dimensions in custom CSS.
• Shopify, Wix, or Squarespace: use the platform's built-in image cropper so the displayed crop matches the source file you upload.
• Headless or framework sites: components like next/image require both width and height, which prevents distortion when the layout scales.

Common causes and how to resolve them

• Hard-coded width and height that do not match the file: recompute them from the source dimensions or remove them and rely on the file's intrinsic ratio.
• Container has a fixed height that crops the image: use CSS object-fit: cover if cropping is intentional, or change the container so the image keeps its natural ratio.
• Wrong source file uploaded: swap in a correctly proportioned crop rather than stretching the wrong file in CSS.

Best practices

• Always set both width and height: the browser uses these to reserve space and avoid layout shift before the image loads, which helps CLS.
• Use object-fit when cropping is intentional: cover fills the container without distortion; contain letterboxes to preserve the full image.
• Standardize on a few aspect ratios: picking one or two ratios per template makes it easier to crop assets consistently and avoid one-off distortions.

A Content Delivery Network serves static assets from edge locations close to the user, reducing latency, improving cache hit rates, and offloading traffic from the origin server. Fixing this issue means routing your images, JavaScript, CSS, and fonts through a CDN so visitors anywhere in the world get fast, consistent delivery.

Where to make the change

• Cloud platforms: Cloudflare, Fastly, AWS CloudFront, Bunny.net, and similar providers offer free or low-cost CDN tiers. Sign up, point your domain through the CDN, and enable caching for static asset paths.
• WordPress: use a CDN integration plugin or sign up directly with Cloudflare and update the site's nameservers.
• Shopify: Shopify serves storefront assets through its own CDN automatically; the failure usually points at custom assets uploaded outside the platform.
• Headless or framework sites: deploying to Vercel, Netlify, or Cloudflare Pages puts the entire site behind a global CDN by default.

Common causes and how to resolve them

• No CDN at all: add one. Even a free Cloudflare account in front of an existing host produces measurable speed gains.
• CDN configured but bypassed for some assets: ensure all img, script, link, and font URLs use the CDN hostname rather than the origin.
• Cache headers prevent caching: long-lived assets need cache-control headers like public, max-age=31536000, immutable. Without them, the CDN cannot cache effectively.
• Origin-only third-party scripts: many vendors already serve their scripts via their own CDN. Use the URL the vendor provides rather than self-hosting.

Best practices

• Use a versioned asset path: filenames like app.a3f9.css let you set far-future cache headers without ever serving stale files. Update the filename when content changes.
• Enable Brotli at the edge: most CDNs can compress responses on the fly, including text formats.
• Pre-warm caches for new launches: after a major release, request key URLs through every region (or use the CDN's purge-and-prefetch tools) so users do not hit cold caches.

Structured data is a standardized way to label the entities and relationships on a page so search engines and AI answer engines can understand them. Adding the right schema helps unlock rich result features in SERPs (star ratings, FAQs, product cards, recipes, events) and gives AI answer engines precise facts to extract when generating responses. Fixing this issue means picking the schema types that match your content and embedding them as JSON-LD inside the page <head>. See the Google Search Central structured data guide for the full type catalog.

Example

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "How to choose marathon running shoes",
  "author": { "@type": "Person", "name": "Jane Doe" },
  "datePublished": "2026-04-15",
  "image": "https://example.com/images/hero.jpg"
}
</script>

Where to make the change

• Raw HTML: embed a JSON-LD block inside the <head>. JSON-LD is Google's preferred format because it does not interleave with visible content.
• WordPress: a dedicated SEO plugin generates JSON-LD for articles, products, breadcrumbs, and FAQ blocks automatically. Customize the templates for non-standard content.
• Shopify: Shopify themes emit Product schema by default. Extend with custom types via theme code edits.
• Wix or Squarespace: built-in blocks for FAQ, recipe, and event content emit schema automatically.
• Headless or framework sites: generate JSON-LD from your content data in the layout component so every page ships consistent schema.

Common causes and how to resolve them

• No structured data at all: add at minimum the @type that matches the page (Article for blog posts, Product for product pages, Organization for the homepage).
• Wrong schema type for the content: using Product schema on an article page misleads search engines. Pick the type that matches what the page actually is.
• Required properties missing: each schema type has required fields. Validate with the Rich Results Test to surface missing properties.
• Markup does not match visible content: Google penalizes structured data that asserts facts the page does not show. Reflect what is actually on the page.
• Multiple conflicting blocks: a theme and an SEO plugin both emit schema for the same entity. Pick one source of truth.

Best practices

• Validate before shipping: Google's Rich Results Test and Schema Markup Validator catch syntax errors and missing required fields.
• Use JSON-LD: easier to maintain than Microdata or RDFa and Google's preferred format.
• Cover the obvious wins: Article, Product, BreadcrumbList, Organization, and FAQPage are the highest-impact types for most sites.
• Keep schema accurate: wrong or exaggerated schema can lead to Google removing rich result eligibility for the entire site.