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.

This test fails when the browser encounters JavaScript runtime errors as the page loads. Unhandled errors can break interactive features, leave content unrendered, and signal poor code quality, all of which hurt the user experience that search engines factor into rankings. Fixing this issue means identifying the offending script, reproducing the error in DevTools, and shipping a patch that handles the failure cleanly.

Where to make the change

• Open browser DevTools: the Console tab lists every error with the file, line number, and stack trace. Reproduce the issue locally and use sourcemaps to map back to the original code.
• Application code: wrap risky operations in try / catch, validate external data before using it, and provide fallbacks when DOM elements or APIs are missing.
• Third-party scripts: check whether the error originates in an analytics, advertising, or chat-widget script. If yes, contact the vendor or load the script with defer so it does not block the rest of the page.

Common causes and how to resolve them

• Calling a method on null or undefined: guard with optional chaining (?.) or check the value exists before calling.
• Race condition between the DOM and the script: wait for DOMContentLoaded or place the script tag at the end of <body> with defer.
• Missing or 404 script file: a typo in the src attribute or a deleted asset triggers a load error. Fix the path or remove the tag.
• Unsupported syntax in older browsers: if you support legacy browsers, transpile modern JavaScript with a tool such as Babel and serve appropriate polyfills.
• CORS error blocking a fetch: the API must include the correct Access-Control-Allow-Origin header. Either configure the API or proxy the request through your own backend.

Best practices

• Add error monitoring: a service such as Sentry, Bugsnag, or Datadog RUM captures errors from real users and groups them by frequency, so you fix what hurts most first.
• Fail loudly in development, gracefully in production: log unexpected errors but never let them break the rendered page. Show a fallback UI instead of a blank screen.
• Treat errors as bugs in the build: add lint rules and unit tests for the most common error paths so they cannot ship again.
• Defer non-critical scripts: using defer or async on third-party scripts limits the blast radius when one of them throws.

Console errors include any unhandled JavaScript exceptions, network request failures, security warnings, or deprecation notices the browser emits while loading the page. Fixing this issue means resolving the underlying problem each error reports rather than suppressing the message. Even errors that do not visibly break the page can degrade performance, leak data, or trip Core Web Vitals.

Where to make the change

• Open DevTools, Console tab: expand each entry to see the file, line, and stack trace. Right-click an entry to filter, save, or jump to the source.
• Application code: patch the offending script (see js-errors). For network failures, fix the failing endpoint or remove the stale request.
• Third-party tags: if the error originates in an analytics, ad, or widget script, update the snippet, switch to the vendor's current loader, or remove unused tags.

Common causes and how to resolve them

• JavaScript runtime errors: see the JS Error Test fix; the same approach applies.
• Failed network requests (404 or 5xx): remove the dead request or fix the endpoint. Stale tracking pixels and removed assets are common culprits.
• Mixed content warnings: the page is HTTPS but loads an HTTP resource. Update the resource URL to https://.
• CORS or CSP violations: tighten or expand the policy as appropriate. CSP errors usually require allowlisting the offending origin in the response header.
• Deprecation warnings: update the call site to use the recommended API. These do not break the page today but will when the deprecation cycle completes.

Best practices

• Treat the console as a build artifact: a clean console is a sign of a healthy page. Aim for zero errors and zero warnings on production routes.
• Use error monitoring in production: real users hit edge cases your local environment will never reproduce. A monitoring service surfaces them with frequency data.
• Defer or remove unused third-party scripts: every removed script is one fewer source of console noise.

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.

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 external CSS files are not minified. Minification removes whitespace, comments, and unused characters, producing smaller files that download and parse faster. Fixing this issue is a build configuration change.

Where to make the change

• Build pipeline: enable CSS minification in your build tool. Vite, Webpack, esbuild, and Parcel handle this in production mode by default.
• WordPress: a caching or optimization plugin can minify CSS automatically.
• Shopify: Shopify minifies theme CSS automatically when delivered through the asset pipeline.
• CDN-based minification: Cloudflare Auto Minify can compress CSS responses if your build does not.

Common causes and how to resolve them

• Build running in development mode: ensure the production build is the one deployed.
• Minifier disabled in config: re-enable explicitly; it should be on by default in modern bundlers.
• Hand-written CSS shipped without a build step: add a minifier such as cssnano or lightningcss to your pipeline.

Best practices

• Combine with PurgeCSS or similar: stripping unused selectors before minification produces dramatic file-size reductions for utility-class frameworks.
• Inline critical CSS: minification helps for cached files; inlining the above-the-fold styles helps the first paint.
• Pair with compression: Brotli or Gzip on top of minification typically yields the smallest possible payload.

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.