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.

Console warnings are non-fatal messages the browser emits about deprecated APIs, security best-practice violations, performance hints, or potential bugs. They do not break the page today, but most warnings indicate something that will eventually become a hard error. Fixing this issue means triaging each warning, resolving the actionable ones, and adding monitoring so new warnings get caught early.

Where to make the change

• Open DevTools, Console tab: filter the panel to Warnings only. Each entry includes a link to the source location and often documentation explaining the recommended replacement.
• Application code: update the call site to use the modern API. Most browser deprecations include a recommended replacement in the warning text.
• Third-party tags: contact the vendor or upgrade to the current loader script. Outdated tags are the most common source of deprecation warnings.

Common causes and how to resolve them

• Deprecated DOM or Web APIs: swap the deprecated method for the modern equivalent. The MDN documentation linked in the warning describes the replacement.
• Performance hints (forced reflow, large layout shifts, long tasks): investigate with the Performance tab. These warnings often map directly to Core Web Vitals failures.
• Insecure features (Permissions-Policy, deprecated headers): update server response headers to use the current syntax.
• Cookie warnings (SameSite, Secure): set explicit SameSite and Secure attributes on every cookie, especially those used in cross-site contexts.

Best practices

• Resolve warnings before they become errors: deprecation cycles usually run six to twelve months. Fix early to avoid emergency patches when the API is removed.
• Keep the console clean on production: a noisy console hides genuine new issues among the chronic ones.
• Pin third-party scripts to maintained versions: outdated vendor scripts are the dominant source of long-running warnings.

This test fails when images are served in legacy formats such as JPEG and PNG instead of modern alternatives like WebP or AVIF. Modern formats compress significantly better at equivalent visual quality, which means smaller transfers, faster page loads, and lower data usage for visitors on metered connections. Fixing this issue means generating modern variants and serving them to browsers that support them.

Example

<picture>
  <source srcset="/images/hero.avif" type="image/avif">
  <source srcset="/images/hero.webp" type="image/webp">
  <img src="/images/hero.jpg" alt="Marathon runners at sunrise" width="1600" height="900">
</picture>

Where to make the change

• Raw HTML: use the <picture> element with multiple <source> entries so the browser picks the best supported format.
• WordPress: WordPress 6.x and later supports WebP natively. Use a media optimization plugin to convert existing JPEGs and PNGs and serve modern formats automatically.
• Shopify: Shopify's image CDN can serve WebP automatically; using the image_url filter with format parameter or the image_tag helper handles negotiation.
• Wix or Squarespace: both platforms convert and serve WebP automatically when supported by the visitor's browser.
• Headless or framework sites: components like next/image and astro:assets generate AVIF and WebP variants at build time and serve the best format per request.

Common causes and how to resolve them

• Only legacy formats published: add a build step or image CDN that generates WebP and AVIF alongside the original.
• Single-format <img> tag: wrap the image in <picture> with <source> entries for AVIF and WebP, falling back to the JPEG.
• Image CDN not negotiating format: enable automatic format conversion or pass a format=auto query parameter (depends on provider).
• SVG used where a raster image would be smaller (or vice versa): illustrations and icons should be SVG; photos should be raster in a modern format. Mixing them up wastes bytes.

Best practices

• AVIF first, WebP fallback, JPEG last: AVIF compresses best, WebP is widely supported, JPEG remains the universal fallback.
• Match quality to use case: hero images can use higher quality settings; thumbnails can drop quality without visible loss.
• Use an image CDN: services like Cloudflare Images, Cloudinary, or Imgix handle resizing, format conversion, and caching in one step.

This test fails when external JavaScript files are not minified. Minification strips whitespace, comments, and shortens identifiers, producing smaller files that are faster to download and parse. Fixing this issue is almost always a build configuration change rather than a code change.

Where to make the change

• Build pipeline: enable minification in your bundler. Webpack, Rollup, Vite, esbuild, and Parcel all minify by default in production mode.
• WordPress: a caching or optimization plugin can minify enqueued scripts on the fly.
• Shopify: Shopify serves theme JavaScript minified automatically when delivered through the platform asset pipeline.
• CDN-based minification: Cloudflare and others offer auto-minify for JavaScript responses if you cannot change the build.

Common causes and how to resolve them

• Build running in development mode: ensure the production build (NODE_ENV=production or equivalent) runs in deploy.
• Minifier disabled in config: a previous config tweak may have turned minification off. Re-enable it explicitly.
• Inline scripts not minified: minifiers usually skip inline scripts. Move large inline scripts to external files so they are processed.

Best practices

• Pair minification with compression: a minified file compresses even better with Brotli or Gzip.
• Ship sourcemaps: upload sourcemaps to your error monitoring tool so production stack traces remain readable.
• Use modern syntax targets: targeting modern browsers in your build produces smaller output than transpiling everything down to ES5.

This test fails when JavaScript or CSS resources block the browser from rendering visible content. Each render-blocking file delays the first paint, and on slower networks the cumulative impact can be severe. Fixing this issue means inlining the truly critical CSS, deferring or asynchronously loading non-essential scripts, and removing unused code.

Example

<head>
  <!-- Inline only above-the-fold critical CSS -->
  <style>/* critical styles here */</style>

  <!-- Load full stylesheet asynchronously -->
  <link rel="preload" href="/styles/main.css" as="style"
        onload="this.onload=null;this.rel='stylesheet'">

  <!-- Defer non-critical scripts -->
  <script src="/scripts/app.js" defer></script>
</head>

Where to make the change

• Application code or templates: identify the CSS and JavaScript needed for the initial render and load only those synchronously. Defer the rest.
• Build pipeline: use a critical CSS extractor (such as critical or penthouse) to generate the above-the-fold styles automatically.
• WordPress: performance plugins offer "delay JS execution" and "load CSS asynchronously" options that handle most of this without code changes.
• Headless or framework sites: use the framework's preload and code-splitting hints to control what blocks rendering.

Common causes and how to resolve them

• Single large stylesheet blocking render: inline critical CSS for the first viewport, load the full stylesheet asynchronously.
• Synchronous third-party scripts in the head: add defer or async, or move them to the end of the body.
• Web fonts blocking text rendering: add font-display: swap in @font-face rules so the fallback font shows immediately.
• Render-blocking @import in CSS: replace with separate <link rel="stylesheet"> tags so the browser can fetch them in parallel.

Best practices

• Use defer for scripts that need the DOM: they execute after parsing but before DOMContentLoaded.
• Use async for fully independent scripts: they execute as soon as they download, in any order.
• Preload the critical request chain: tell the browser early about fonts and key assets with <link rel="preload">.
• Audit with Lighthouse: the Render-blocking resources audit lists every offending file with the estimated time saved by deferring it.

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.