A practical website performance checklist

Website performance checklist: choose the journeys that matter

A useful website performance checklist starts with pages and actions, not a score. Test the homepage, the most common article or service-page template, and the path that produces a lead, booking, or sale. Add any unusually heavy page, such as a gallery or embedded scheduler. This gives you a small set of representative journeys instead of one homepage result that hides the rest of the site.

Record the device, network setting, test location, page state, and whether the visitor is new or returning. A cold visit exposes transfer and caching problems. A returning visit shows whether the browser can reuse what it already downloaded. Keep those conditions the same when you retest, or a faster connection may look like a successful code change.

• Homepage on a cold mobile visit
• One representative content or service page
• The primary form, booking, or checkout path
• One heavy or unusually interactive template

Use field data to prioritize and lab data to diagnose

Field data comes from real visits across different phones, computers, networks, locations, and user behaviors. If enough traffic is available, it is the best evidence of what people actually experience. Look at the page or template level when possible, because a fast homepage can mask a slow product, article, or lead page.

Lab data runs in controlled conditions and is easier to repeat. Use it to inspect a network waterfall, find the largest element, identify long main-thread tasks, and compare a change before release. Field and lab results can disagree without either one being wrong. Let field evidence set the priority, then use lab tools to reproduce and fix the problem.

Read Core Web Vitals as signals, not a single grade

The current Core Web Vitals are Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift. The recommended good thresholds at the 75th percentile are LCP of 2.5 seconds or less, INP of 200 milliseconds or less, and CLS of 0.1 or less. Segment mobile and desktop results because the devices and constraints are different.

LCP asks how quickly the main visible content appears. INP asks how responsive the page remains when someone clicks, taps, or types. CLS measures unexpected visual movement. A page can pass one and fail another, so work from the failing experience rather than chasing a blended performance score.

Trace LCP from the server to the largest element

Start with the initial HTML response. Redirect chains, slow application work, distant origins, and missing caching can delay every resource that follows. Then identify the LCP element. If it is an image, make sure the browser can discover its URL in the initial markup and that the resource is appropriately sized and compressed. Do not lazy-load the likely LCP image. A high fetch priority can help when used selectively, but it does not repair a late-discovered or oversized resource.

If the LCP element is text, check whether a stylesheet, script, or web font prevents it from rendering. Loading less critical code earlier does not make it critical. Remove unnecessary blocking work, keep the first render simple, and retest the same page under the same conditions.

Fix images, fonts, scripts, and layout shifts

Serve images close to their rendered dimensions, compress them, and use responsive image candidates when the same asset appears at different widths. Lazy-load noncritical images and iframes below the initial viewport. Always reserve space with intrinsic width and height or a reliable aspect ratio so content does not jump when media arrives.

Limit font families and weights to what the design uses. Audit first-party and third-party JavaScript separately. Analytics, chat, consent, video, advertising, and scheduling tools can delay rendering or occupy the main thread even when the site code is small. Remove tags with no active owner, load optional tools later, and confirm that a delayed script still works correctly.

Check delivery, caching, and repeat visits

Compress text responses and cache versioned static assets so returning visitors do not download identical files again. Verify the headers instead of assuming a plugin or CDN applied them. For HTML and personalized responses, choose a policy that matches how often the content changes and whether it can be shared safely between visitors.

Treat a hosting move as a measured response, not the first step. A new server can help when the initial response is consistently slow, resources are constrained, or caching is unreliable. It will not remove an oversized hero, a blocking consent manager, or a long client-side task.

Protect gains with a small release budget

Use the improved pages as the baseline for a performance budget. Set limits for the metrics and assets you can control, such as LCP in a repeatable lab profile, total JavaScript on a template, maximum hero-image size, and the number of third-party origins. The right numbers come from the site and its users, not from a universal page-weight rule.

Run the same checks when a template, plugin, campaign tag, font, or major image changes. A warning can be enough at first; the important part is making regressions visible before they become the new normal.

• First 15 minutes: test the four representative journeys and save the results
• Next 15 minutes: identify the LCP element, blocking resources, and largest transfers
• Next 15 minutes: inventory third-party scripts and layout-shift sources
• Final 15 minutes: choose the top two fixes, an owner, and a retest date