This web performance optimization checklist gives you a repeatable way to measure Core Web Vitals, identify the largest sources of delay or layout movement, and track improvements after each release. Use it before launches, during monthly reviews, and after changes to templates, scripts, hosting, or content.
Overview
Website speed optimization is not a one-time task. A page that performs well today can become slower after a new analytics script, unoptimized image, framework upgrade, advertising integration, or hosting change. A practical process therefore combines controlled testing with real-user monitoring.
Start by separating performance into three Core Web Vitals:
- LCP: how quickly the main content becomes visible. LCP optimization usually involves the primary image or heading, server response time, render-blocking resources, and above-the-fold content.
- INP: how responsive a page feels when users interact with it. INP work often focuses on long JavaScript tasks, excessive event handlers, third-party code, and expensive rendering.
- CLS: how much visible content shifts unexpectedly. CLS fixes typically involve reserving space for images, embeds, ads, and dynamic components, as well as managing font swaps.
Use tools such as Lighthouse, PageSpeed Insights, browser DevTools, your hosting logs, and a real-user monitoring system where available. Lab tests help reproduce a problem under controlled conditions; field data shows how the site behaves across real devices, networks, locations, and interaction patterns. Neither view should be treated as a complete substitute for the other.
For related deployment checks, see How to Deploy a Web App: A Production Checklist for Hosting, APIs, and Monitoring. If your site uses client-side rendering, also review the technical SEO checklist for JavaScript websites.
What to track
1. Record a consistent baseline
Choose a small set of representative URLs rather than testing only the homepage. Include a landing page, an article or documentation page, a search or listing page, and a key conversion or application screen. Record the template, device type, connection profile, test location, date, and release version. Consistency makes future comparisons more useful.
For every test, save the LCP, INP, and CLS results along with total page weight, request count, JavaScript transfer size, image transfer size, and the name of the largest resources. Also note whether the result came from a lab test or field data. A simple record can use these columns:
- Date and release or commit
- URL and page template
- Device and network conditions
- LCP, INP, and CLS observations
- Largest image, font, script, or API request
- Change made and expected impact
- Result after deployment
2. Check the page delivery path
Measure time to the first response and inspect whether pages are served from a nearby cache or CDN location. Confirm that compression is enabled, cache headers match the content type, and static assets have stable versioned URLs. A CDN can reduce network distance, but it will not correct slow database queries, oversized HTML, or inefficient application code at the origin.
Review backend timing separately from browser rendering. If the initial document is slow, investigate server-side rendering, database calls, API dependencies, cold starts, and cache misses before changing front-end code.
3. Audit images, fonts, and JavaScript
For images, identify the likely LCP element and make sure it is appropriately sized for its display area. Use modern formats where they fit the content, compress without damaging important detail, and avoid lazy-loading the image that users need immediately. Defer below-the-fold images instead. The image optimization guide provides a deeper workflow.
For fonts, limit unnecessary families and weights, preload only a genuinely critical font, and define fallback behavior so text remains usable while fonts load. For JavaScript, remove unused packages, split code by route or feature, defer nonessential scripts, and investigate long tasks in the Performance panel. Third-party tools should be reviewed like first-party code: measure their cost and remove integrations that no longer serve a clear purpose.
4. Look for layout movement
Reserve dimensions for images, video, embeds, and asynchronous components. Avoid inserting banners above existing content after the page has rendered. Check whether web fonts change text dimensions and whether client-side hydration replaces server-rendered markup. A CLS problem is often caused by a sequence of small shifts, so inspect the layout-shift records rather than relying only on visual impressions.
Cadence and checkpoints
Use a three-level schedule so performance remains part of normal development rather than a late emergency.
- Every pull request or feature release: run focused lab tests on changed templates, compare bundles, and check for new images, fonts, scripts, or API calls.
- After deployment: retest the production URL, verify CDN and cache behavior, and compare the result with the pre-release baseline. Test at least one page on each important template.
- Monthly: review field data, the slowest page groups, error logs, third-party scripts, and hosting resource usage. Assign one or two high-impact fixes rather than creating an unprioritized backlog.
- Quarterly: repeat the full audit. Review framework and dependency changes, image policies, caching rules, font usage, redirect chains, and the performance impact of new product features.
When tracking results, compare like with like. A mobile test on a throttled connection should not be compared directly with a desktop test on a fast connection. Keep a short change log so a regression can be connected to a release instead of guessed from memory.
How to interpret changes
Prioritize issues by user impact, frequency, and effort. A problem affecting the main landing-page image across many devices usually deserves attention before a minor issue on an infrequently visited administrative screen. Likewise, a small improvement to a shared template may be more valuable than a large improvement to one isolated page.
When LCP worsens, first inspect the server response, the LCP resource's discovery and download timing, image dimensions, render-blocking CSS, and font behavior. When INP worsens, identify the interaction with the slowest processing time, then inspect long tasks, event handlers, layout recalculation, and client-side rendering. When CLS worsens, use browser diagnostics to identify which element moved and whether space was reserved before the content arrived.
Do not treat one unusually high or low test as proof of a lasting change. Re-run lab tests, check multiple representative URLs, and wait for field data to reflect a meaningful period of traffic. If lab and field results disagree, investigate differences in device mix, cache state, interaction patterns, and page selection.
Record before-and-after evidence for every optimization. For example: “Removed unused widget script from the article template; JavaScript transfer decreased; interaction test repeated after deployment.” This makes successful work auditable and prevents the same investigation from being repeated later.
When to revisit
Revisit this checklist after any change that can affect delivery, rendering, or interaction. That includes a framework migration, CMS redesign, new analytics or advertising integration, image-library change, hosting move, CDN configuration change, major dependency update, or addition of a client-side feature. A site that publishes frequently should use release-level checks; a stable site can use monthly monitoring and a more complete quarterly review.
Make the next review actionable by choosing one page group and one measurable question. Examples include: “Did the new hero image improve LCP without increasing transfer size?” or “Which interaction causes the longest task on the product page?” Run the relevant test, save the result, apply the smallest effective change, and test again in production.
Keep the checklist with your deployment documentation and link each finding to an issue or release. For broader developer utilities that support debugging and inspection, see the online developer tools toolkit. For a deeper version of this workflow, revisit Web Performance Optimization Checklist: How to Improve Core Web Vitals whenever your monitoring data, templates, or infrastructure changes.
