Frontend Performance Checklist: JavaScript, CSS, Images, and Core Web Vitals

Overview

Frontend performance is rarely controlled by one setting. A page can have a small JavaScript bundle but still feel slow because images arrive too late, CSS delays the first render, fonts cause layout shifts, or a client-side interaction blocks the main thread. A useful audit therefore looks at the complete path from navigation to usable interface.

Start with a consistent test process. Record the page or user journey being tested, the device and connection profile, whether the test is cold or repeated, and the build version. Compare like with like. A single local result is useful for finding obvious regressions, but it should not be treated as a complete picture of real-user experience.

For practical investigation, use browser developer tools, a performance trace, the Network panel, and a page-audit tool available in your workflow. The goal is not to maximize a score in isolation. The goal is to identify the slowest meaningful step, make one controlled improvement, and verify that the change helped without damaging accessibility, functionality, or maintainability.

Checklist by scenario

Before a new release

• Test the most important page templates, not only the home page. Include landing pages, listing views, detail pages, forms, and authenticated screens when they are part of the product.
• Compare the production build with the previous build. Check JavaScript, CSS, image, and font transfer sizes as well as the number of requests.
• Confirm that source maps and development-only logging are not being shipped where they are unnecessary.
• Inspect the bundle for duplicated dependencies, oversized libraries, unused feature code, and imports that prevent effective tree shaking.
• Verify that route-level or component-level code splitting still works after the release. A split bundle is not useful if the initial route eagerly imports every feature.
• Run the primary keyboard and screen-reader journeys while measuring performance. A fast interface that removes focus indicators, labels, or usable status messages is not a successful optimization.

When JavaScript feels slow

• Use a performance recording to locate long tasks, repeated rendering, forced layout, and expensive event handlers.
• Defer nonessential work until after the initial interaction or until a feature is needed. Analytics, widgets, editors, and secondary dialogs are common candidates for delayed loading.
• Reduce work performed during startup. Avoid parsing large data sets, initializing hidden components, or attaching unnecessary listeners before the user needs them.
• Review rendering boundaries in the framework or UI architecture. Unnecessary parent updates can cause large portions of the interface to re-render.
• Use web workers for suitable CPU-heavy tasks when moving the work off the main thread is practical, while keeping communication and error handling clear.
• Retest interaction responsiveness after each change. Smaller files do not automatically mean a more responsive interface if execution remains concentrated on the main thread.

For a broader debugging workflow, see How to Debug JavaScript Step by Step. If an error is contributing to repeated retries or broken rendering, the patterns in the JavaScript Error Handling Guide can help isolate it.

When CSS delays rendering or causes visual movement

• Identify render-blocking stylesheets and keep critical styling focused on what is required for the initial view.
• Remove unused CSS where the build process can do so safely. Check dynamic class names, server-rendered states, and user-generated content before deleting selectors.
• Prefer efficient selectors and avoid broad style changes that trigger unnecessary layout or paint work.
• Reserve space for images, embeds, ads, and asynchronous interface regions so content does not jump when those elements arrive.
• Check transitions and animations for layout-heavy properties. Where appropriate, animate transform or opacity instead of repeatedly changing geometry.
• Test responsive breakpoints at realistic viewport sizes. A layout that performs well on a wide screen may become expensive when mobile styles add complex effects or large menus.

When images, fonts, or media dominate the page

• Serve images close to their displayed dimensions and use responsive sources when the same asset appears at multiple sizes.
• Choose an efficient format for the image type, but verify visual quality at the actual display size. Compression is only useful when the result remains readable and appropriate.
• Lazy-load below-the-fold images and media, while prioritizing the visual content required for the initial view.
• Set explicit width and height or an equivalent aspect-ratio rule for media containers.
• Limit font families, weights, and styles to those the interface actually uses. Confirm that fallback fonts do not create a noticeable layout shift.
• Use preloading selectively for resources that are genuinely needed early. Excessive preloading can compete with more important requests.

When Core Web Vitals need investigation

• For loading, inspect the request chain, server response timing, critical resources, image priority, and the amount of JavaScript needed before the main content becomes usable.
• For interaction responsiveness, find long tasks, expensive event handlers, synchronous work, and UI updates that occur during typing, clicking, or scrolling.
• For visual stability, identify late-loading images, fonts, banners, injected notices, and components whose dimensions are not known in advance.
• Separate lab diagnosis from real-user monitoring. Lab tests help reproduce causes; field data can reveal device, network, and usage patterns that a controlled test misses.

What to double-check

Performance improvements should survive ordinary product behavior. Recheck navigation, deep links, browser back and forward behavior, authentication, error states, empty states, and slow API responses. A loading skeleton may improve perceived progress, but it should not hide a request that never resolves or prevent assistive technology from receiving a useful status.

Inspect caching headers and cache invalidation for static assets. Long-lived caching can reduce repeat downloads, but a deployment must still be able to deliver new files reliably. Confirm that asset filenames or another versioning strategy changes when content changes, and check that service-worker behavior does not serve stale application code unexpectedly.

Review third-party scripts separately. Record what each script does, when it loads, and whether the feature is essential to the first interaction. A small number of carefully managed external resources can still create contention, while a locally bundled dependency can also be expensive if it adds unnecessary parsing and execution.

Use the browser Network panel to check request priority, redirects, compression, transfer size, and whether resources are fetched more than once. Use the Performance panel to connect those requests to scripting, layout, painting, and interaction delays. When working with frontend libraries or frameworks, keep the performance model of the chosen stack in view; the framework comparison guide provides context for evaluating those trade-offs.

Common mistakes

• Optimizing the score instead of the journey: An audit score is a diagnostic signal, not a substitute for testing the actions users need to complete.
• Measuring only on a powerful development machine: Local development builds, fast processors, and warm caches can conceal production problems.
• Loading everything early: Preloading every font, image, and script creates competition. Prioritize the resources that support the initial view and first useful interaction.
• Removing accessibility features for speed: Focus management, labels, semantic structure, and announcements are part of a usable interface and should be optimized rather than discarded.
• Applying lazy loading indiscriminately: Deferring content that is immediately visible can make the first view feel slower and may create layout movement.
• Changing too many variables at once: If JavaScript, CSS, images, and hosting settings all change together, it becomes difficult to know which adjustment helped or introduced a regression.
• Ignoring failure paths: Error messages, retries, loading states, and empty results can trigger different rendering work from the happy path. Include them in the audit.

When to revisit

Use this checklist before major releases, after adding a library or third-party integration, when redesigning a component system, and after changing image or font pipelines. It is also worth repeating before seasonal planning cycles when traffic patterns, campaigns, or landing-page content are likely to change.

Create a lightweight performance budget for the pages that matter most. Track bundle size, critical request count, image weight, and the time required for key interactions. The exact limits should reflect the page, audience, and product priorities; the important part is to make regressions visible during review rather than discovering them after launch.

For each review, save the test URL, build identifier, environment, measurements, trace or audit output, and the next action. Fix the highest-impact cause first, then rerun the same scenario. Revisit the process when your framework, build tooling, hosting setup, analytics, or design system changes. A repeatable frontend performance checklist turns optimization from a one-time cleanup into a practical part of shipping reliable interfaces.