Forms passing in staging does not mean the site is fast enough to publish. A short checklist for speed budgets on priority URLs, CI checks, production previews, and what to measure after deploy.
On Thursday the team closed the last functional ticket. Forms submitted, redirects resolved, analytics fired in staging. On Friday someone ran PageSpeed Insights on the production preview URL and mobile INP on checkout was amber while the homepage looked fine.
That sequence is common. Functional QA answers whether the site works. Speed readiness answers whether the build you are about to publish keeps Core Web Vitals inside the budgets you set for the URLs that handle signups, sales, or support traffic. Below is the checklist we use when someone asks how to know a website is ready for deployment, with speed checks listed separately from forms and content review.
Why does passing functional QA not mean the site is ready to deploy?
Functional QA checks behaviour: links resolve, auth flows complete, carts total correctly, CMS entries render, consent banners appear. Speed readiness checks load time and stability on representative page templates under realistic throttling, usually mobile first.
A site can pass the first checklist and still ship a regression. Typical causes include a hero image without dimensions on the homepage template only, a new marketing tag that blocks the main thread on checkout, a font swap that shifts layout on product pages, or a CI job that only audited the marketing homepage while app routes changed in the same release.
Treat them as two separate approvals. Functional QA covers whether things work. Speed readiness covers LCP, INP, and CLS (plus supporting lab metrics such as TBT where INP is noisy) on the URL list you care about after deploy. Both need saved evidence, not a verbal "looks fast."
Pre-deploy performance testing should cover more than one URL and more than one device type. At minimum, run lab audits on:
- Homepage (discovery and first load)
- One high-traffic landing or campaign page
- One conversion route (pricing, signup, contact, or checkout step)
- One content template (blog post, docs page, or help article) if it is built differently
Run each URL on mobile and desktop strategies in PageSpeed Insights or Lighthouse. Record LCP, INP (or TBT on older tooling), CLS, and the Performance score. Compare against your budgets, not only Google's "Good" thresholds if the client SOW is tighter.
Use the environment you will actually ship. A Lighthouse run on localhost misses CDN behaviour, production analytics, and certificate or HSTS differences. A preview URL on the production host (or the live domain before you switch DNS) is the audit you should trust for the publish decision. Staging on a different subdomain is useful for functional QA; it is weaker evidence for speed unless it uses the same tags and caching as production.
Save PDF or JSON exports with timestamps. You will need a baseline to compare against the first production week. Core Web Vitals Monitoring Checklist for Agencies includes onboarding baselines and budget rows you can reuse for a single-site launch.
If your pipeline already runs Lighthouse CI or similar, treat it as a check on the URLs configured in lighthouserc (or equivalent). A green CI build means: this build did not cross the assertions you defined on those routes in a controlled lab run.
It does not prove:
- Every template in the release was in the URL list
- Production third-party tags match preview
- Field data in Chrome User Experience Report will move within days (CrUX lags)
- Mobile traffic mix on the live domain will match the lab profile
CI belongs in the checklist as "pipeline green on configured URLs." It complements pre-deploy manual runs; it does not replace scheduled monitoring after the site is live. How to Set Up Performance Budgets in CI/CD Pipelines walks through assertions and preview hosts if you are adding a check for the first time. A separate note on which checks belong in CI versus ongoing monitoring covers day-to-day ownership for teams that already run pipelines every day.
How do you baseline before ship and compare after deploy?
Before deploy, store a row per URL and strategy: date, environment (preview or production host), LCP, INP, CLS, Performance score, and notes on the LCP element or layout shift source. After deploy, rerun the same URLs at 24 hours and 72 hours on the live domain.
Compare like for like. A mobile lab run before deploy should be compared to mobile lab after deploy, not to desktop field data in Search Console. If scores move, check whether DNS, caching, tag managers, or A/B snippets changed between runs.
If CrUX field data already exists for the domain, record the prior 28-day window but do not expect launch-week fixes to appear immediately. Use lab baselines for the publish decision; use field trends for the first monthly review.
Do third-party and consent scripts still block render on the production URL?
Consent managers, chat widgets, A/B platforms, and analytics often load only on the production domain. A fast staging build can still ship heavy tags on the URL customers hit.
On the production preview (or live domain in quiet hours), open DevTools Performance or Lighthouse and confirm:
- Consent banner does not delay LCP element paint beyond budget
- Chat or support widgets defer until after first interaction or idle
- Tag manager containers match the approved production list, not a staging container
- New pixels added for launch week are documented with an owner
If marketing added "just one script" after the last green Lighthouse run, rerun audits before DNS. That single script is a frequent reason checkout passes functional QA and fails INP on mobile.
When is one green Lighthouse run not enough for deployment?
One green Lighthouse score is not enough when any of these are true:
| Situation | Why one run fails |
|---|
| Only the homepage was tested | Regressions hide on checkout, account, or search results |
| Only desktop was tested | Google uses mobile signals for ranking and most retail traffic is mobile |
| Run happened before final content or tags | Hero media, fonts, or GTM changes after the audit |
| Scores sit just inside budget | Lighthouse variance can flip a borderline INP or LCP on the next run |
| CI and manual runs disagree | Investigate URL list, throttling, or auth differences before ship |
| No baseline file exists | You cannot prove regressions post-launch without a saved before row |
Run at least three consecutive lab runs on critical URLs and compare medians when scores are borderline. For high-stakes launches, keep a short rollback plan and the previous build available.
Website ready for deployment checklist (speed)
Use this table beside your functional QA list. Mark each row pass only with evidence (report link, screenshot, or CI job URL).
| Check | Pass criteria | Evidence to attach |
|---|
| Priority URLs named | Homepage, conversion route, and one secondary template listed | URL list in ticket or runbook |
| Mobile lab budgets | LCP, INP, CLS within agreed limits on each priority URL | PageSpeed Insights or Lighthouse export |
| Desktop lab spot-check | Same URLs on desktop; no desktop-only surprises | Second export per URL |
| Production or preview host | Audits run on the host that will serve customers, not only localhost | URL bar shows production or approved preview |
| CI check (if used) | Pipeline green on configured routes for this commit | CI job link |
| Third-party / consent review | Production tags loaded; no undeclared script after last audit | Tag assistant screenshot or container diff |
| Baseline stored | Before-deploy metrics saved per URL and device type | Sheet or monitoring tool snapshot |
| Post-deploy plan | Reruns scheduled at 24h and 72h; alerts configured | Calendar invite or monitor schedule |
| Rollback named | Person and steps documented if INP or LCP breach after publish | Runbook link |
Functional items (forms, SEO meta, redirects, SSL, accessibility spot checks) still belong in your full launch QA. This table is the speed section for "ready for deployment" when people treat green tickets as proof the site is fast.
FAQ
Is staging enough for a speed check before publish?
Staging is enough for functional QA when behaviour matches production. For speed, prefer the production host or a preview URL that uses production CDN, certificates, and tag containers. If staging omits analytics or consent, run a final audit where those scripts load.
Does a 90+ Lighthouse Performance score mean we are ready?
A high score on one URL is encouraging, not sufficient. Confirm priority routes, mobile tests, and third-party scripts on the live host. Scores also weight metrics differently from field Core Web Vitals; treat Lighthouse as a lab check, not a CrUX guarantee.
Should deployment wait for CrUX to turn green?
No for initial launch. CrUX needs traffic and rolls on a 28-day window. Publish when lab baselines and CI checks pass on the production URL, then watch field data and scheduled monitoring in the first weeks.
What to do the week before you switch DNS
Name your priority URLs in writing. Run mobile and desktop lab audits on the production preview and save baselines. Confirm CI assertions cover at least one non-home template if the release touched app routes. Rerun audits after any late tag or hero media change. Schedule post-deploy reruns before you announce the launch.
Run a free domain PageSpeed check on the URLs in your publish list, or start a trial to keep the same routes on a schedule after deploy.
References
Originally published on Hashnode.