Core Web Vitals before launch: a practical checklist for website owners

Run a Core Web Vitals check before launch, not after visitors report that the new site feels slow. The goal is not to chase a perfect score on every URL. It is to find the pages where performance can affect discovery, trust, or conversion and fix those first.

1. Choose representative pages

Do not test only the homepage. Include:

• the homepage;
• the main campaign or service page;
• a page with a large hero image or video;
• the highest-traffic page; and
• the page where visitors take the most valuable action.

If you are migrating a builder site, test the live source page and the exported or preview version so you can compare the change.

2. Understand the metrics

Keep the first review practical:

• Largest Contentful Paint (LCP) shows how quickly the main content becomes visible;
• Cumulative Layout Shift (CLS) shows whether content jumps while the page loads;
• First Contentful Paint (FCP) shows when the first visible content appears; and
• Time to First Byte (TTFB) shows how quickly the server begins responding.

These metrics describe different parts of the experience. A page can begin rendering quickly and still have a slow main image, or look visually stable while waiting too long for the first response.

3. Find the largest causes before changing everything

For a slow page, check the likely causes in order:

1. oversized hero images, video, or fonts;
2. third-party scripts and embeds;
3. layout elements without reserved dimensions;
4. render-blocking CSS or JavaScript; and
5. hosting or server-response delays.

Make one meaningful change at a time when possible. Otherwise you will not know which improvement helped or whether a visual regression came with it.

4. Protect the page’s job

Performance work should not remove the thing that makes the page convert. Keep the primary headline, proof, navigation, form, and analytics behavior intact while reducing unnecessary weight.

After each change, check the page on a real mobile-sized viewport. Confirm that the first screen still explains the offer, the layout does not shift, and the primary action remains easy to find.

5. Compare before and after launch

Save the baseline for the pages that matter. After the redesign, export, domain change, or hosting move, run the same checks again and compare:

• the metrics;
• the page version and deployment date;
• the visible layout;
• the key interaction; and
• any SEO metadata or URL changes.

A score is only useful when it belongs to a page, a device, and a point in time.

ToStatic’s Performance analysis gives you a focused way to measure a live URL. In the app, Page Performance keeps the review tied to saved sites and repeat checks, while AI-assisted suggestions help turn a weak result into a shorter fix list.

6. Know when to stop

Not every issue deserves a redesign. Stop when the important pages are stable, the user journey works, the largest bottleneck has a credible owner, and the remaining work is lower impact than the launch risk it introduces.

FAQ

What should I fix first for Core Web Vitals?

Start with the slowest high-value page and its largest bottleneck. In many cases that is a hero asset, a third-party script, layout shift, or server delay.

Are Core Web Vitals the same as a performance score?

No. A score summarizes selected signals, while the individual metrics explain where the experience is weak. Use the score to orient yourself and the metrics to choose work.

Should I measure before or after a website migration?

Both. A baseline protects you from shipping a regression, and a post-launch check confirms what visitors actually receive on the final host and domain.

Final takeaway

The best Core Web Vitals workflow is a repeatable comparison: choose the pages that matter, measure the real bottlenecks, protect the user journey, and check the same pages again after launch.