Website Speed Optimization Checklist: How to Improve Core Web Vitals and Page Load Time

Overview

Website performance is rarely improved by changing one setting at random. A slow page may be affected by oversized images, inefficient code, third-party scripts, web fonts, database queries, DNS delays, or slow server response time. The most reliable approach is to measure first, fix the highest-impact issue, and test again under the same conditions.

Core Web Vitals help organize that work around three user-facing experiences:

• Largest Contentful Paint (LCP): how quickly the main content becomes visible.
• Interaction to Next Paint (INP): how quickly the page responds after a user interaction.
• Cumulative Layout Shift (CLS): how much visible content moves unexpectedly while the page loads.

Common performance tools group these metrics into pass, improvement, and poor ranges. As a practical reference, many teams work toward an LCP of 2.5 seconds or less, an INP of 200 milliseconds or less, and a CLS score of 0.1 or less. Treat these as working targets rather than guarantees: test on representative mobile devices, networks, browsers, and page types.

Checklist by scenario

Before diagnosing a slow page

1. Choose representative URLs, including the homepage, a content page, a template with forms or search, and an important conversion page.
2. Test each URL more than once. Record the device type, browser, connection conditions, test location, and whether the test used a fresh or repeat visit.
3. Compare mobile and desktop results. A page that performs well on a desktop connection may still be slow on a mobile device.
4. Record the key metrics, total page size, request count, server response time, and the largest files before making changes.

Use a lab test for repeatable diagnosis and, when available, real-user data to understand how visitors experience the site. Do not treat a single test score as a complete performance report.

When images are the main problem

• Resize each image to the largest display size required by the page. Uploading a very large original and relying on browser scaling still transfers unnecessary data.
• Choose an efficient image format supported by your publishing workflow, and compare visual quality after compression.
• Use responsive image markup or your CMS's image-size features so mobile devices do not download desktop-sized assets.
• Lazy-load images below the initial viewport, but avoid delaying the primary above-the-fold image that contributes to LCP.
• Set width and height attributes or equivalent layout dimensions to reserve space and reduce layout shifts.

When scripts and styles delay rendering

• Identify CSS and JavaScript files that block the first render. Keep critical styles available early and delay nonessential code.
• Remove plugins, libraries, tracking tags, and widgets that are no longer needed.
• Load scripts only on pages that use them. A booking tool, gallery, or form library does not necessarily belong on every URL.
• Use defer or an equivalent loading strategy for scripts that do not need to run before the page is parsed. Test interactive features after changing execution order.
• Review third-party resources separately. They may add connection time, main-thread work, or unpredictable delays outside your server.

When fonts affect page speed or layout

• Limit the number of families, weights, and character subsets loaded on each page.
• Prefer modern, appropriately compressed font files and serve them from a reliable origin.
• Check whether text remains readable while a custom font loads. A suitable fallback can prevent invisible text.
• Preload only a font that is essential to the initial view. Preloading too many files can compete with more important content.

When hosting or server response is suspected

1. Compare the same page with caching enabled and disabled, where your platform allows a safe test.
2. Check whether slow response occurs across many pages or only on one template. Site-wide delays suggest infrastructure, database, DNS, or application issues; isolated delays suggest page-specific assets or code.
3. Review server resource usage, application logs, database queries, cache hit behavior, and background jobs.
4. Confirm that the domain resolves consistently and that TLS negotiation is not failing or repeatedly redirecting.
5. Check whether the hosting plan has enough capacity for current traffic and workload. Shared hosting and cloud hosting can behave differently under resource pressure; compare the trade-offs before migrating.

If a hosting move is being considered, document the current response times and configuration first. The website migration checklist can help you preserve DNS, SSL, redirects, and site data during the change.

What to double-check

Caching: Confirm that full-page, object, browser, and content delivery caching are configured for the platform you use. Purge caches deliberately after changes, then test both the first request and repeat visits.

Redirects: Avoid chains such as HTTP to HTTPS to one hostname and then to another. Choose the canonical version of the site and point links directly to it.

DNS and TLS: DNS is only one part of the initial connection, but incorrect records, unnecessary lookups, or certificate problems can create avoidable delays. For background on records and routing, see the DNS records guide. For certificate configuration, review SSL certificate installation and troubleshooting guidance.

Above-the-fold content: Find the element reported as the LCP element. It may be a hero image, heading, banner, or content block. Optimize that specific resource rather than applying broad changes without measuring the result.

Layout shifts: Look for images without reserved dimensions, late-loading banners, injected consent notices, changing navigation, and embedded media. Fix the source of the movement instead of hiding the symptom.

Mobile behavior: Test with touch interactions, a narrow viewport, and a slower connection. Large tap targets, excessive animation, and heavy client-side rendering can affect usability even when a desktop score looks acceptable.

Common mistakes

• Chasing a perfect score: A higher laboratory score is not automatically a better user experience. Prioritize faster content, reliable interaction, and stable layout on important pages.
• Changing several variables at once: If images, plugins, hosting, and fonts all change together, you may not know which action helped or caused a regression.
• Installing too many optimization tools: Multiple caching, minification, image, or lazy-loading systems can conflict and create broken layouts or duplicated work.
• Optimizing only the homepage: Visitors may enter through articles, product pages, documentation, or campaign landing pages with different templates and assets.
• Ignoring functionality: Deferring scripts can improve an audit while breaking menus, checkout flows, analytics, or forms. Test important tasks after every performance change.
• Confusing DNS speed with overall speed: Changing DNS providers will not fix an oversized page, slow database query, or heavy third-party script. Diagnose the specific phase that is delayed.

When to revisit

Run this checklist before seasonal campaigns, after a hosting change, and whenever you publish a new template or redesign. Recheck it after installing plugins, adding analytics or advertising tools, changing fonts, replacing major images, or introducing embedded video and interactive features. A website migration, domain configuration change, or SSL update is also a useful trigger for a full test.

Keep a simple before-and-after record:

Date:
URLs tested:
Device and connection:
Hosting or CDN changes:
LCP before / after:
INP before / after:
CLS before / after:
Server response before / after:
Largest files or scripts:
Change made:
Follow-up needed:

When a result worsens, roll back or isolate the most recent change, then test again. When it improves, confirm the result across several page types and mobile conditions before treating the change as complete. Repeating this process turns website speed optimization from a one-time score exercise into a maintainable part of publishing, hosting, and site operations.