Website Speed Checklist: Hosting-Level Fixes First

Fix a slow site from the server outward. Measure first, then check server response, caching, and your CDN. Only then work on images, code, fonts, and third-party scripts.

This order matters because each layer sits on top of the one before it. Smaller images can’t hide a server that takes two seconds to answer.

This guide only puts the work in order. Each step links to the page that explains the fix in depth.

Every fix in the list has its own page among the website performance fixes by layer.

How the checklist works

Every step below has the same four parts, so you can stop at the first one that fails.

• Check: what to look at.
• Tool: a free way to see it.
• Pass/fail: the signal that tells you whether to act.
• If it fails: the page that owns the fix.

Work top to bottom. When a step fails, fix it and measure again before moving on.

For your site, this means: you spend effort where it pays off first, instead of compressing images on a site whose real problem is the server.

Step 1: Measure first

Start with field data from real visitors, then use lab tests to find the cause.

Field data comes from real Chrome users visiting your site. Lab data comes from one simulated visit, such as a Lighthouse test.

Google’s Web Vitals guidance, last updated October 31, 2024, sets these “good” targets, measured at the 75th percentile of page loads on mobile and desktop:

• Check: your Core Web Vitals for real visitors, on mobile and desktop.
• Tool: PageSpeed Insights (the field data section at the top) or the Core Web Vitals report in Google Search Console.
• Pass/fail: pass if all three metrics are “good”. If one fails, note which, because it points to the layer to fix.
• If it fails: the gap between lab scores and what real visitors actually experience explains why a high score can still hide a slow site.

For your site, this means: a failing LCP often starts at the server, so keep going to step 2.

A failing INP or CLS is usually a front-end issue, so you can jump to steps 6 to 9.

How many real sites meet these targets is tracked in the website speed statistics for 2026, a separate roundup of Web Almanac data.

Step 2: Check server response time (TTFB) first

Server response time, measured as TTFB (time to first byte), is the first thing to check, because every other step waits for the server’s first byte.

Google’s TTFB guidance, updated November 18, 2025, gives 0.8 seconds or less as a rough guide for most sites.

• Check: TTFB on a cached public page and on an uncached page, such as a logged-in or cart page.
• Tool: a multi-location TTFB test, or the Network tab in your browser’s developer tools.
• Pass/fail: pass if the cached page meets that guide from cities near your server. Fail if even nearby tests miss it.
• If it fails: work through the hosting-level fixes for TTFB, from page cache to PHP and database settings.

What counts as normal for your setup is answered by the TTFB benchmarks by city and hosting type, measured on four accounts we bought.

Step 3: Confirm page caching is working

Page caching should be your next check, because a cache hit lets the server answer without running PHP or querying the database.

• Check: whether public pages are served from cache.
• Tool: look at the response headers in your browser’s developer tools. Many hosts and cache plugins add a header showing a cache “HIT” or “MISS”.
• Pass/fail: pass if a repeat visit to a public page shows a hit. Fail if every request is a miss.
• If it fails: pick the right layer using which cache layer your site needs, then set up the one your host supports.

For your site, this means: a working page cache often cuts TTFB more than any front-end change you could make.

Step 4: Check object caching for dynamic pages

Object caching keeps the results of repeated database queries in memory, which helps pages that can’t be fully cached.

Stores, membership sites, and anything with logged-in users rely on it most.

• Check: whether uncached pages (cart, account, wp-admin) are still slow after step 3.
• Tool: a query monitor plugin, or your host’s dashboard if it shows database time.
• Pass/fail: pass if the query monitor shows no slow or repeated queries on those pages. Fail if the same queries run again and again, or a few take most of the load time.
• If it fails: set up Redis object caching on your server if your plan allows it.

Step 5: Check your CDN

A CDN (content delivery network) serves copies of your files from servers near each visitor, which helps when your audience is far from your host.

• Check: whether static files, and ideally HTML, come from the CDN.
• Tool: response headers again, or a multi-location speed test.
• Pass/fail: pass if distant visitors load files from a nearby edge with cache hits. Fail if there is no CDN for a global audience, or if pages got slower after turning it on.
• If it fails with no CDN: start with how a CDN delivers cached files.
• If it fails with a CDN on: look for CDN settings that slow pages down, such as cookies that block caching.

For your site, this means: if your visitors are mostly near your server, a CDN helps less, and you can move on.

Step 6: Optimize images

Images are often the largest files on a page and the most common LCP element, so they come first on the front end.

• Check: image file sizes and formats, especially the main image at the top of the page.
• Tool: PageSpeed Insights diagnostics, or sort by size in the browser’s Network tab.
• Pass/fail: pass if no image is much larger than the size it is shown at. Fail if large JPEG or PNG files appear above the fold.
• If it fails: resize, compress, and lazy-load them with image compression and format steps.

Step 7: Reduce CSS and JavaScript

CSS and JavaScript files can block the page from drawing and slow down how fast it reacts to clicks.

• Check: render-blocking and unused CSS and JavaScript.
• Tool: PageSpeed Insights diagnostics, or the Coverage panel in Chrome developer tools.
• Pass/fail: pass if no large file blocks rendering. Fail if diagnostics list render-blocking resources or a lot of unused code.
• If it fails: start by minifying CSS and JavaScript files, then remove what the page doesn’t use.

For your site, this means: this step often fixes a failing INP, which step 1 flagged.

Step 8: Check web fonts

Web fonts are extra files the browser downloads before showing text in that style, and they can cause layout shifts.

• Check: how many font files load and whether text jumps when they swap in.
• Tool: the Network tab filtered to fonts.
• Pass/fail: pass if a few font files load and text doesn’t move. Fail if many weights load or text shifts.
• If it fails: cut unused font weights and styles, and load the main font early.

Step 9: Audit third-party scripts

Third-party scripts are code loaded from other companies’ servers, such as chat widgets, ads, analytics, and embeds.

• Check: which outside scripts load on each page.
• Tool: the Network tab, grouped by domain, or the third-party section in PageSpeed Insights diagnostics.
• Pass/fail: pass if each script has a clear purpose. Fail if a script you don’t use, or a slow one, loads on every page.
• If it fails: remove unused scripts, and load the rest only on pages that need them.

When it’s the host, not the site

If your server stays slow after steps 2 to 4, the problem is likely your plan, not your pages.

Signs it’s the host:

• A cached page still misses Google’s TTFB guide from a city near your server.
• Speed drops at busy times, then recovers on its own.
• Your host’s dashboard shows CPU, memory, or process limits being hit.
• A staging copy with a default theme and no plugins is still slow.

Signs it’s the site:

• Cached pages are fast, but logged-in pages are slow.
• Speed got worse after a new plugin, theme, or script.
• PageSpeed diagnostics point mostly to images, code, or scripts.

If the host signs match, the warning signs of an outgrown plan help confirm it. For WordPress sites, the managed WordPress picks with server specs are a next step.

Copyable website speed checklist

Copy this list into your notes or task tool and tick each item as you go.

1. [ ] Measure: Core Web Vitals field data (LCP 2.5 s or less, INP 200 ms or less, CLS 0.1 or less)
2. [ ] Server response: cached page TTFB in Google’s “good” range from a nearby city
3. [ ] Page cache: repeat visits show a cache HIT
4. [ ] Object cache: logged-in pages close in speed to public pages
5. [ ] CDN: distant visitors get cache hits; nothing slower after enabling it
6. [ ] Images: no oversized or uncompressed images above the fold
7. [ ] CSS and JavaScript: no large render-blocking or unused files
8. [ ] Fonts: few font files; no text shifting
9. [ ] Third-party scripts: only the ones you need, only where needed
10. [ ] Measure again and compare with step 1

Frequently asked questions

How we researched this

The pass/fail signals come from Google’s web.dev Web Vitals and TTFB articles, rechecked on October 4, 2026.

The 28-day field data window comes from the PageSpeed Insights documentation (updated October 21, 2024), read October 4, 2026.

The order of steps follows how a page loads: the server answers first, caching and the CDN decide how fast that answer arrives, and the front end loads last.

The checks match how we test hosting accounts under the speed test rules we follow, which cover server response time, loading speed, and Core Web Vitals.

Each published review of an account we bought reports its TTFB and PageSpeed Insights results.