Frontend Performance Audit Checklist: Core Web Vitals, Images, JavaScript, and Caching

Overview

Performance work should begin with evidence, not a long list of optimizations. Test a representative page on a realistic device and network, record the results, then work from the most visible or expensive problem to the least important one. A homepage, product page, article page, and authenticated application screen may have very different performance profiles.

Use both field and lab perspectives when they are available. Real-user data shows how an experience behaves for actual visitors across devices and connections. A controlled Lighthouse run or browser DevTools session is useful for reproducing a problem and testing a proposed fix. Neither view replaces the other: lab testing helps explain a result, while field data helps determine whether the result matters in practice.

Keep a simple audit record: URL, test conditions, key metrics, suspected cause, change made, and result. This prevents teams from repeating the same investigation and makes regressions easier to spot.

Checklist by scenario

Before changing code

• Choose the page types and user journeys that matter most.
• Test with a clean browser profile or an incognito window where appropriate.
• Run more than one test when results vary, and record the test conditions.
• Compare mobile and desktop layouts instead of assuming the desktop result represents both.
• Use the Performance and Network panels in browser DevTools to find the slowest requests and longest main-thread tasks.
• Run a Lighthouse performance audit as a diagnostic starting point, not as the only definition of quality.

For a broader troubleshooting method, pair this audit with the web application debugging workflow. The same discipline applies: reproduce the issue, isolate a cause, make one focused change, and retest.

When the first paint or main content is slow

• Find the element identified as the main visible content and determine what it depends on.
• Check whether the server response, a redirect, a stylesheet, a font, or an image is delaying it.
• Reduce avoidable work before the main content: excessive redirects, large blocking stylesheets, and nonessential scripts.
• Make sure the most important image is not accidentally lazy-loaded or requested at a very low priority.
• Review the server response time separately from the browser's rendering time.

When images dominate the page

• Compare each image's intrinsic dimensions with its rendered dimensions. Do not send a large source image when a smaller one is sufficient.
• Use responsive image attributes such as srcset and sizes when the same asset appears at different viewport widths.
• Choose an efficient format supported by the project's browser requirements, and use compression appropriate to the image type.
• Lazy-load images below the initial viewport, but keep important above-the-fold content available promptly.
• Set width and height or an equivalent aspect-ratio reservation so images do not push content around as they load.
• Check thumbnails, background images, avatars, and third-party content; the largest problem is not always an image in the main article body.

When JavaScript is the bottleneck

• Inspect the bundle composition and identify dependencies that are loaded on pages that do not use them.
• Apply route-level or component-level code splitting where it reduces initial work.
• Defer nonessential scripts and delay optional features until they are needed.
• Remove duplicate libraries, unused polyfills, development code, and unnecessarily broad imports.
• Look for long tasks in the Performance panel. A small download can still cause a slow page if it performs expensive parsing, rendering, or event processing.
• Confirm that third-party scripts are necessary, measurable, and loaded at an appropriate point in the user journey.

When a fix involves a complicated JavaScript change, test behavior as well as speed. The JavaScript debugging workflow can help separate a performance regression from a functional regression.

When fonts or layout movement are the problem

• Load only the font families, weights, and character ranges the interface actually uses.
• Consider whether a system font or a smaller fallback strategy is suitable for noncritical text.
• Preload a font only when it is genuinely needed for initial rendering; unnecessary preloads compete with more important resources.
• Define stable dimensions for images, embeds, advertisements, and dynamically inserted components.
• Check whether late-running JavaScript changes text, navigation, banners, or controls after the page appears.

When delivery and repeat visits are slow

• Verify that text assets such as HTML, CSS, JavaScript, and SVG are compressed during transfer.
• Use long-lived caching for versioned static assets so repeat visits do not redownload unchanged files.
• Ensure deployed asset URLs change when their content changes; otherwise, a long cache can preserve stale files.
• Review cache behavior for HTML separately from immutable assets. Pages that contain personalized or frequently changing data need different rules.
• Check whether a content delivery layer, connection reuse, or server configuration is adding avoidable latency.

What to double-check

Before declaring the audit complete, verify that the improvement survives realistic conditions. A smaller JavaScript bundle may not improve the initial view if another script still blocks rendering. A compressed image may still be oversized for a small screen. A faster lab score may hide a slower interaction on a low-powered device.

• Metric definitions: Treat Core Web Vitals as measurements with distinct purposes. Loading, visual stability, and responsiveness should be investigated separately rather than reduced to one score.
• Priority: Fix the resource that delays the user-visible result, not necessarily the largest file in the report.
• Build output: Inspect production output, not only source files or local development behavior.
• Responsive behavior: Repeat checks at important breakpoints and on pages with different content lengths.
• Accessibility: Do not remove meaningful text, labels, focus behavior, or motion preferences merely to improve a metric.
• Functionality: Test navigation, forms, authentication, analytics requirements, and error states after optimization.
• Cache invalidation: Confirm that a new deployment serves the intended versions of CSS, JavaScript, fonts, and images.

For projects that use many small developer utilities or generated files, keep the workflow understandable. A JSON formatter, bundle analyzer, or browser audit is valuable when it answers a specific question; adding tools without a clear diagnostic purpose can make the process harder to repeat.

Common mistakes

• Optimizing in the wrong order: Tuning a minor CSS selector while a multi-megabyte image or third-party script delays the page produces little value.
• Chasing a single score: Scores can vary with test conditions. Compare the underlying requests, timings, and user-visible behavior.
• Lazy-loading everything: Deferring the primary content can make the initial experience worse. Lazy-loading belongs on content that is genuinely below the initial view or otherwise nonessential.
• Preloading too much: Preload hints are not free. Too many high-priority requests compete with the document, primary styles, and important content.
• Ignoring third parties: Chat widgets, video embeds, advertising, analytics, and experimentation scripts can add network and main-thread work even when application code is clean.
• Testing only on a fast machine: A page that feels quick during local development may be expensive on a slower phone or constrained connection.
• Making several changes at once: Bundling unrelated changes makes it difficult to know which one helped or caused a regression.
• Stopping after the first improvement: Performance can regress when content, dependencies, design systems, or framework settings change.

When to revisit

Run this frontend performance audit before a major launch, after a redesign, when adding a substantial dependency, and after changing image or font pipelines. It is also worth repeating before seasonal planning cycles or whenever traffic patterns, templates, hosting, browser recommendations, or team workflows change.

Make performance part of the normal delivery process rather than a one-time cleanup. Establish a small set of representative URLs, keep a baseline for each, and retest after meaningful releases. If a result worsens, compare the network waterfall and main-thread activity with the previous baseline before changing code.

Use this closing routine:

1. Pick one important page and one realistic user journey.
2. Capture a baseline under documented conditions.
3. Identify the highest-impact bottleneck.
4. Make one targeted change.
5. Retest loading, stability, responsiveness, functionality, and accessibility.
6. Record the result and add a regression check if the issue is likely to return.

For projects being prepared as portfolio work or deployed through a repeatable local workflow, the related project planning and deployment checklist and Docker local development guide provide useful context. Revisit this page whenever the inputs change, then prioritize the next measurable improvement rather than trying to optimize everything at once.