How to Speed Up a Slow Website: The 2026 Performance Checklist

Published

Jul 14, 2026

Reading time

9 min read

If your website is slow, start by measuring real user performance and the request path before changing code. The fastest wins usually come from reducing time to first byte, serving fewer and smaller resources, caching safe responses at the edge, and removing work from the main thread. Use this checklist to move from symptoms to a prioritized fix list.

1. Establish a trustworthy baseline

Run a representative set of URLs, not just the home page: a product or service page, a search or listing page, an article, and the main conversion path. Test mobile and desktop, several geographic regions, and both a warm and cold cache. Record the URL, release version, test conditions, and results so that improvements are comparable.

Use field data to understand what real visitors experience. Google recommends evaluating Core Web Vitals at the 75th percentile, segmented by device. PageSpeed Insights combines field data where available with a lab trace. Search Console can show URL groups, while browser DevTools and Lighthouse help reproduce a slow path before release. Lab scores are useful for diagnosis, but they are not a substitute for field data.

2. Fix the request path first

Measure TTFB and its parts

Time to first byte includes the browser's network work, the request's trip to the server, and the time your platform spends producing the first response bytes. Break it down into DNS lookup, connection and TLS negotiation, request transit, queueing, application work, and the response's trip back to the browser. A high TTFB can make every later optimization feel invisible because the browser cannot begin parsing the document sooner.

Shorten the path by using fast, redundant DNS, keeping connections warm, placing a CDN close to users, and caching responses that do not need per-user computation. Optimi's managed DNS and managed CDN pages explain those delivery layers in more detail.

Remove avoidable origin work

Profile the slowest server transactions. Look for uncached database queries, serialized API calls, remote dependencies, cold starts, overloaded application workers, and queues that hold requests. Set a time budget for each dependency and return a useful response without waiting for non-critical work. Move analytics, recommendations, and other secondary calls out of the critical HTML path when they do not affect the first view.

3. Make the first view lighter

The browser cannot render what it has not received or parsed. Identify the largest contentful element and make it arrive early. Compress HTML, CSS, JavaScript, fonts, and images with formats appropriate to each resource. Enable Brotli or another supported content encoding for text, but measure the result rather than compressing already compressed media.

Images are frequent sources of wasted bytes. Serve responsive dimensions, use modern formats where supported, avoid shipping a desktop-sized image to a small screen, and lazy-load images below the fold. Do not lazy-load the likely LCP image. Declare image dimensions or an aspect ratio so the browser reserves space before the asset arrives. Optimi's adaptive image delivery covers the same principle at the delivery layer.

For CSS, remove unused rules and avoid making large stylesheets block every route. For JavaScript, split by route, defer code that is not needed for the first interaction, and remove duplicate libraries. Audit third-party scripts individually: a tag that is small on disk can still create long tasks, layout shifts, network requests, and privacy or reliability dependencies.

4. Improve Core Web Vitals deliberately

The current good targets 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.

• LCP: prioritize the LCP resource, reduce TTFB, avoid late discovery, and do not hide the main content behind client-side JavaScript.
• INP: break up long tasks, reduce JavaScript execution, avoid synchronous layout work, and make event handlers do less before yielding to the browser.
• CLS: reserve space for images, ads, embeds, and injected content; keep fonts from causing large swaps; and avoid inserting UI above content after the page has rendered.

Do not treat a single failing metric as a generic "speed" problem. A slow LCP may be server or image delivery. A poor INP is usually runtime work. CLS is often a layout contract problem. The diagnosis determines the owner and the fix.

5. Configure caching with a content policy

Cache immutable, versioned assets for a long time. Give HTML and frequently changing content shorter freshness windows or require revalidation. Keep personalized pages, account data, checkout responses, and sensitive API responses private or uncacheable. Make the cache key explicit: query parameters, cookies, authorization, language, and device variants can multiply objects or serve the wrong representation if handled carelessly.

For a hashed asset, a generic response might be:

Cache-Control: public, max-age=31536000, immutable

For an HTML document that can be stored but must be checked before reuse:

Cache-Control: public, no-cache
ETag: "release-2026-07-14-a1"

no-cache does not mean no storage. It means a cache must revalidate before reuse. If you need to prevent storage, use no-store, but reserve it for responses that truly must not be retained. Test browser cache behavior and shared-cache behavior separately. A CDN such as Cloudflare or Fastly may also have an edge policy that augments or overrides origin headers, so verify the effective response.

6. Validate every change

After each release or infrastructure change, check:

• Field LCP, INP, and CLS at the 75th percentile by device and key template.
• TTFB and server timing from the same regions and test paths.
• Cache hit, miss, bypass, revalidation, and error rates.
• Response headers, Age, ETag, Vary, cookies, and content encoding.
• LCP resource priority, image dimensions, JavaScript long tasks, and layout shifts.
• Login, cart, checkout, localization, consent, and preview behavior.
• Origin load, database latency, error rate, and saturation during cache misses.

Common mistakes

Do not put a blanket "cache everything" rule in front of an application. Do not add more third-party tools to measure a page without removing redundant work. Do not rely on DNS alone to solve a slow origin. Do not compare a desktop lab run with a mobile field segment. Do not make a year-long asset TTL safe by changing a file in place; version its URL instead.

For the SEO consequences of slow, unstable responses, see technical SEO and GEO. For the cache layer itself, continue with CDN caching explained and How to configure Cache-Control.

Validation checklist

The work is ready to ship when the slowest templates have an identified bottleneck, the fix is measured in field data, cache rules have been tested with anonymous and authenticated requests, and a rollback or purge procedure is documented. Keep the baseline and repeat the test after traffic, content, and dependencies change.

There are only two hard things in Computer Science: cache invalidation and naming things.