Performance & Core Web Vitals checklist
Speed affects everything downstream—how long visitors stay, whether forms get completed, and how search engines evaluate the page experience. This checklist covers the fundamentals and Google's Core Web Vitals metrics specifically.
What Core Web Vitals measure
- LCP (Largest Contentful Paint): how long it takes the largest visible element (usually a hero image or heading) to render
- INP (Interaction to Next Paint): how responsive the page feels when a visitor clicks, taps or types
- CLS (Cumulative Layout Shift): how much visible content unexpectedly shifts around while the page loads
Images & media
- Images are compressed and served at a size appropriate to where they're displayed—not a 4000px-wide image shown at 400px
- Modern, efficient image formats are used where supported, with fallbacks for older browsers (see the dedicated image optimization checklist)
- Images and iframes below the fold are lazy-loaded so they don't compete for bandwidth with what's immediately visible
- Every image has explicit width and height (or an aspect-ratio) so the browser reserves space before it loads—this alone prevents most layout shift
- Video is not set to autoplay large files unnecessarily, especially on mobile connections
Code & asset optimization
- CSS and JavaScript are minified for production
- Unused CSS and JavaScript are trimmed rather than shipped on every page regardless of need
- Render-blocking scripts are deferred or loaded asynchronously where possible
- Web fonts are limited in number and variant, and use a strategy that avoids invisible text while loading
- Third-party scripts (widgets, chat tools, ad tags) are audited—each one is a real performance cost, and unused ones should be removed
- Critical above-the-fold CSS is prioritized so the visible part of the page can render without waiting on the entire stylesheet
Server & backend performance
- Time to first byte has been measured specifically, separate from front-end asset loading—a slow server delays everything downstream regardless of how optimized the front end is
- Database queries behind dynamic pages are checked for obvious inefficiency, especially anything that scales badly as content grows
- Server-side or edge caching is used for pages and data that don't need to be regenerated on every single request
- Hosting has adequate capacity for expected traffic—an undersized plan is a common, avoidable cause of slow responses, particularly under any kind of traffic spike
Hosting & caching
- The site uses browser caching so returning visitors don't re-download unchanged assets
- A content delivery network (CDN) is used to serve static assets closer to visitors, if the audience is geographically spread out
- Cache invalidation is handled correctly when content changes—visitors shouldn't see stale content indefinitely, nor should every deploy force a full cold cache
Resource hints & loading priority
- The most critical resource for the page's LCP element (a hero image, a key font) is prioritized to load as early as possible
- Connections to critical third-party origins are established early where the platform supports it, rather than only starting once the browser discovers a reference to them deep in the page
- Resource hints are used selectively for genuinely critical resources—overusing them for everything defeats the purpose and can slow the page down instead
- Fonts are preloaded only when they're used above the fold; preloading fonts used further down the page wastes early bandwidth that the visible content needs first
- Non-critical JavaScript (analytics, chat widgets, below-the-fold interactivity) is deferred so it doesn't compete with the resources the visible page actually needs first
Layout stability
- Ads, embeds and dynamically injected content reserve space in advance rather than pushing the page around when they load
- Web fonts don't cause a visible layout jump when they swap in
- Cookie banners and popups are sized and positioned so they don't shift the content underneath
Testing & tools
- Real-world (field) performance is checked in Google Search Console's Core Web Vitals report, which reflects actual visitor data
- Lab testing tools like Google PageSpeed Insights, Lighthouse (built into Chrome DevTools) or WebPageTest are used to diagnose specific issues
- Performance is tested on a throttled, mid-range mobile connection, not just a fast office connection
- Performance is re-checked after any significant redesign, not just at initial launch
💡 Field data (real visitors, from Search Console) and lab data (a single simulated test run) can disagree—field data reflects reality more closely, but lab tools are far better for diagnosing exactly what's slow.
Monitoring over time
- Core Web Vitals are checked on a recurring schedule, not only once at launch, since third-party scripts and content additions tend to erode performance gradually
- A performance regression after a deploy is treated as seriously as a functional bug, not as an acceptable side effect of shipping features
- Key pages (homepage, top landing pages, checkout) are monitored specifically, since site-wide averages can hide a badly performing high-traffic page
Performance overlaps heavily with technical SEO and with mobile experience—a slow site is disproportionately a slow mobile site. See the image optimization checklist for the single biggest lever most sites have.