Website speed checklist: from first test to last fix

Pass marks

TBT and FCP are lab numbers that point to causes. The three Core Web Vitals decide whether a page passes. See the Core Web Vitals cheat sheet.

1. Measure first

• Choose the pages that matter. Your home page, the page that earns the most, the page people reach from ads or search, and the contact or checkout page. Test these, not every page. See what to fix first.
• Read the real-visitor numbers on mobile. Note which of LCP, INP and CLS fails and by how much. If there is no real-visitor data, the site has too little traffic for it, and the lab numbers will have to do. See lab data and field data.
• Write down the lab numbers: LCP, TBT, CLS, FCP, the server response time, the page weight and the number of requests. Date the page.
• Find the LCP element in the report. It is an image on about three pages in four. See LCP.
• Open the page on a real phone on mobile data, with the cache empty. See testing on real phones.
• Take a backup, and work on a copy of the site when you can. See how to test speed changes safely.

2. Server and delivery

• Check the first byte. TTFB should be 0.8 seconds or less, and Lighthouse flags a server that takes over 600 milliseconds to start answering. If it is slow on every page, fix this group before touching images. See TTFB and server response time.
• Turn on a page cache for pages that are the same for everyone, and exclude carts, checkouts and account pages. See caching explained.
• Make sure the hosting fits the site. A busy store or a membership site needs more than the cheapest shared plan. See choosing hosting for speed.
• Put a CDN in front if visitors are far from the server. See what is a CDN.
• Use HTTPS with no detours. Links should point to the final https address. Where a redirect remains, make it a single step on the same host. See TLS and HTTPS speed and redirects.
• Enable HTTP/2 or HTTP/3. On a CDN it is usually a switch, and a host can enable it if it is not on. See HTTP/2 and HTTP/3.
• Compress text files. Brotli, with gzip as the fallback, for HTML, CSS, JavaScript, JSON and SVG, and not for images or video. Check the content-encoding header in the Network panel. See text compression.
• Set caching headers. Files with a version or hash in their name get a one-year lifetime marked immutable. HTML pages get no-cache with an ETag. See the Cache-Control cheat sheet.
• Keep the number of other hosts small. Each new host costs a lookup and a connection. Warm up only the few that matter. See resource hints.

3. Images

• Treat the main image first. If the LCP element is an image, it should be a real img in the HTML, not a CSS background and not added by a script. Give it fetchpriority="high" and never loading="lazy". See how to fix a slow LCP and the image attributes cheat sheet.
• Send each image at the size it is shown, with srcset and sizes where the width changes. See responsive images.
• Choose the format. AVIF or WebP with a JPEG fallback for photos, SVG for logos and icons, and video in place of animated GIFs. See image formats, SVG and GIFs vs video.
• Compress every file and strip what is not needed. See image optimization.
• Add `width` and `height` to every image, so space is reserved. See image width and height.
• Lazy-load images below the first screen, and only those. See lazy loading.
• Write alt text and plain file names. It helps readers who cannot see the image, and search. See image SEO and speed.
• Look at video. Self-hosted video needs a poster and a size, and an embed needs a facade. See video and speed.

4. Fonts

• Count the font files. Aim for as few families and weights as the design needs. System fonts cost nothing. See web fonts and speed.
• Serve WOFF2. It is compressed and supported by all modern browsers.
• Choose `font-display`. swap or optional, depending on how much you mind a swap.
• Preload only the one or two fonts the top of the page needs.
• Match the fallback font's size to the web font, so the swap does not move the text. See fixing font layout shift.

5. CSS and JavaScript

• Look for render-blocking files in the head. Scripts should have defer or async unless there is a reason. See defer, async and modules and critical CSS and render-blocking.
• Remove code that is not used. The coverage tool in DevTools shows how much of each file runs. See reduce unused code.
• Check the size of the JavaScript and split it by page where a build tool allows. See bundle size and code splitting.
• Ask whether jQuery and old plugins are still needed. See remove jQuery.
• List every third-party script and write down who needs it. Remove the rest, load the heavy ones late and put a facade in front of players and chat. See third-party scripts.
• Record the page load in the Performance panel and look for long tasks of 50 milliseconds or more. See Chrome DevTools Performance panel and reduce main-thread work.
• Move heavy work off the main thread when it can run elsewhere. See web workers.

6. Layout stability

• Reserve space for everything that arrives late: ads, embeds, banners, cookie notices and images. See how to fix CLS.
• Insert new content below what is already on screen, not above it.
• Animate `transform` and `opacity`, not properties that move other content.
• Watch for shifts after the page has loaded, such as a sticky bar that appears when you scroll. A lab test can miss them.

7. Interactions

• Use the page like a visitor on a phone: open the menu, use a filter, add to the basket, send the form. Note anything that lags. See INP.
• For the slow ones, find which part is slow: the wait to start, your code or the redraw. See how to fix INP.
• Keep click handlers short and split long work into pieces. See break up long tasks.
• Test with and without the third-party tags, to see what they cost.
• Check the framework cost if the site is a single-page app. See hydration.

8. Make sure search is safe

• Check that no `noindex` tag or `robots.txt` rule is blocking pages you want found. See robots.txt and noindex.
• Keep the important content in the raw HTML, not only in what a script builds. See JavaScript and SEO.
• Keep the viewport tag and the phone version complete. See mobile-first indexing.
• Check that redirects and canonical links still point to the right place after any change of address. See canonical tags.

9. Keep it fast

• Test again after each change, with the same pages and settings as the first time. See why PageSpeed scores change.
• Compare real-visitor numbers after 28 days, since the Chrome UX Report covers a rolling 28-day window. See the Chrome UX Report.
• Set a budget for page weight, scripts or a metric, and test it automatically. See automated testing and budgets.
• Measure real visitors with a monitoring script if the site matters to the business. See real user monitoring.
• Review each new plugin, script and large image before it goes live. See why websites get slower over time.
• Put a date in the diary for a monthly check of your top pages.

Mistakes to avoid

• Starting with images when the server is slow. Nothing can be faster than the first byte.
• Tuning for the lab score. Pass the Core Web Vitals for real visitors, and stop there.
• Changing many things at once, so that nobody knows which one helped.
• Delaying scripts without testing the first tap, the payment button and the form.
• Skipping the backup.
• Ticking a line because the setting is on. Check the result in the report or the Network panel.

Check your own page

Run the free audit on your most important page and copy the numbers into group one. Then work down the list, and stop at the first group where a result fails its pass mark.

Sources

• Web Vitals and Defining the Core Web Vitals metric thresholds on web.dev: the three metrics, the marks and the 75th percentile.
• Chrome UX Report methodology: real visits and the rolling 28-day window.
• The guides linked from each line, which carry the sources for every setting and number on this page.