All posts
PerformanceCI/CDChecklist

Pre-Deploy Performance Checklist

A practical checklist to run before every production deploy to catch performance regressions before your users do.

debugutils.dev

Performance regressions are far easier to catch before deploy than after. A 5-minute pre-deploy check can prevent a 2-hour incident response when someone notices the site slowed down.

Here’s the checklist we recommend running before pushing to production.

Quick Pre-Deploy Checks (5 minutes)

Run a speed test on staging

Test your staging URL against debugutils.dev before deploying. Compare the results to your last production test. Look for:

  • Performance score drop > 5 points
  • LCP increase > 0.5s
  • New render-blocking resources
  • Significant increase in total page weight
  • New third-party script domains in the waterfall

Verify image optimization

Open the waterfall and filter to images. Check:

  • Hero/LCP image is WebP or AVIF
  • Images have explicit width and height attributes
  • Only above-fold images are eagerly loaded; others use loading="lazy"
  • No images over 200KB in the initial load — see our image optimization guide
  • LCP image has fetchpriority="high"

Check for render-blocking resources

Look at the critical rendering path in the waterfall. Check:

  • No synchronous JavaScript in <head> (must have defer or async)
  • Critical CSS is inlined or preloaded
  • No new stylesheets added to the critical path

Verify caching headers

Check the response headers for static assets:

  • CSS and JS files have long-lived cache headers (e.g., max-age=31536000)
  • Assets use content-hashed filenames for cache busting
  • Fonts have cache headers set
  • Main HTML has appropriate short-TTL headers

Lighthouse Score Thresholds

Use performance budgets to formalize these numbers. Before every production deploy, verify:

MetricMinimum
Performance (mobile)≥ 70
LCP< 2.5s
CLS< 0.1
TBT< 300ms
Accessibility≥ 80

If any threshold fails, investigate before deploying.

New Feature Checklist

When deploying a new feature:

Images and media

  • All new images specify width and height
  • New images use WebP/AVIF format
  • New images are sized appropriately for their display context
  • New video uses preload="none" unless critical

JavaScript

  • New JS dependencies checked with Bundlephobia for size impact
  • New third-party scripts added with async or defer
  • No synchronous API calls blocking the main thread
  • Code splitting applied for new large components

CSS

  • No new layout-affecting animations (use transform instead)
  • No new CSS that sets fixed heights on dynamic content
  • No new external fonts without preload hints

Third-party integrations

  • New tracking scripts, chat widgets, or embeds approved
  • Added with async/defer — never in <head> without a plan
  • Estimated TBT impact reviewed

After Deploying

  • Run debugutils.dev on production immediately after deploy
  • Compare to pre-deploy staging test
  • Check CrUX data in PageSpeed Insights 4 weeks later (field data lags)
  • Update your baseline test results for next comparison

Automating This

Integrate Lighthouse into CI/CD to fail builds that miss thresholds:

# Example: GitHub Actions with lighthouse-ci
- name: Run Lighthouse CI
  run: |
    npm install -g @lhci/cli
    lhci autorun
  env:
    LHCI_GITHUB_APP_TOKEN: ${{ secrets.LHCI_GITHUB_APP_TOKEN }}

Configure .lighthouserc.js with your thresholds. See lighthouse-cicd pipeline guide for a complete setup.

Manual testing on debugutils.dev gives you richer diagnostic data (waterfall, CrUX, video) than Lighthouse CI alone — use both.

All posts