Speed checklist before you launch a website

Why the launch is the moment

On launch day you have the most control you will ever have. The pages can still change, no visitor is affected by a test, and you know exactly what is on the site. Afterwards the site collects new plugins, tags, images and campaigns, and each one makes it a little slower. See why websites get slower over time. A baseline taken at launch is also the only fair way to see later whether the site has slipped.

Use this list with the website speed checklist, which covers the fixes in detail, and the website migration checklist if you are replacing an existing site. This page is the gate: the things that must be true before the switch.

1. Write the targets into the brief

• Set the pass marks. For mobile visitors: Largest Contentful Paint 2.5 seconds or less, Interaction to Next Paint 200 milliseconds or less, Cumulative Layout Shift 0.1 or less, judged at the 75th percentile. See the Core Web Vitals cheat sheet.
• Set a budget for page weight and for third-party code, with two levels: a warning to act early and an error that blocks the release. See automated testing and budgets.
• Say who signs off, and what evidence they need: a test report on the staging copy for the home page and each type of page.
• Ask for a list of every third-party tool before the build starts, with who asked for it and what it is for. See third-party scripts.
• Choose the platform and the hosting with speed in mind. See choosing hosting for speed.

2. Check the design and the content plan

• Decide what the main image is at the top of each type of page, how big it is, and in what format. Avoid a slider or an auto-playing video as the first thing on the page. See how to fix a slow LCP.
• Count the fonts in the design file: the families and the weights. Each one is a file to download. See web fonts and speed.
• Design the late arrivals in: cookie notices, banners, chat buttons and ad slots, so they have reserved space and do not push the page around. See how to fix CLS.
• Plan the images. Who resizes them, who compresses them, what formats the editors upload, and who writes the alt text. See image optimization.
• Think through the interactions: filters, search, menus, forms and carts. These decide Interaction to Next Paint. See INP.

3. Must-pass checks on the staging copy

Test the home page and one page of each type. Run Lighthouse several times on each and use the median, because one run varies. See why PageSpeed scores change.

• Every row passes on every type of page. A fail on the home page is a fail for the launch.
• Save the reports, with the date and the address of each page.

4. Test like a visitor

• Open the site on a real phone on mobile data, with an empty cache. See testing on real phones.
• Slow the connection in DevTools and watch what appears first. See the Network panel guide.
• Walk through the journeys that earn money, with test entries: contact forms, search, booking, cart, checkout and payment in test mode. Check that the emails from the site arrive.
• Use the keyboard and zoom in. A page that cannot be used without a mouse, or that breaks when zoomed, has a problem a speed test will not show. See accessibility, best practices and SEO scores.
• Try an older or cheaper phone if you can. Slow processors show script problems that a new phone hides.

5. Check the tags and tracking

• Confirm that analytics, ad tags and conversion events fire once, and only once.
• Load the cookie notice without blocking the page, and keep its space reserved.
• Open the tag manager and read what is inside. Remove test tags and anything nobody can explain.
• Compare the speed with and without the tags, so you know what they cost.

6. Make sure search is safe

• Remove the staging block: the password, the setting that discourages indexing, any noindex tag or header, and a robots.txt that disallows everything. See robots.txt and noindex.
• Check the tags in the raw HTML: title, description, canonical link, language links and structured data. See JavaScript and SEO.
• Check that the 404 page returns a 404 status. See redirects and status codes.
• Replacing a site? Work through the redirect map in the website migration checklist.

7. Launch day

• Clear the page cache and the CDN, then load the main pages on the live address.
• Read the headers of the home page and two deep pages with curl -sIL: status, redirects, content type, caching and compression.
• Run the tests again on the live site and compare them with staging. A difference points to a setting that did not move across.
• Switch on monitoring: an uptime check, a scheduled lab test and, if the site matters to the business, real user monitoring.
• Keep the launch-day reports as the baseline.

8. After launch

• Watch the first days for errors, failed forms, slow pages and server load.
• Repeat the lab tests after a week, and fix anything new.
• Check the real-visitor data after about 28 days, in PageSpeed Insights and Search Console. A page with no data usually has too few visits so far. See the Chrome UX Report.
• Keep the budget running, and put a monthly check in the diary.
• Ask the builder for a hand-over: the third-party list and the reason for each, how to upload images, the cache and CDN settings, how to update safely and the test reports.

Mistakes to avoid

• Testing only the home page. Product, article and checkout pages have their own problems.
• Testing only on a fast office connection. Most visitors are not on one.
• Launching with the staging block on.
• Keeping a heavy first screen because it looked good in the mock-up.
• Adding tags after launch without a review.
• Judging the site by one Lighthouse run.
• Treating launch as the end. It is the start of the baseline.

Check your own page

If the staging copy is behind a password, a public tool cannot reach it. On launch day, run the free audit on the live address and compare it with your staging reports. Fix any row of the must-pass table that fails, and run it again.

Sources

• web.dev on the Core Web Vitals and on how the marks were set: the metrics, their thresholds and the 75th percentile rule.
• Performance budgets on MDN: warning and error levels.
• Chrome UX Report methodology: which pages qualify and the rolling 28-day window.
• The guides linked in each row and line above. Each carries its own sources for the setting or figure it covers.