Performance First Checklist for Sustainable Web Development
Who this checklist is for and what it delivers
This checklist is aimed at product managers, engineers, designers and platform teams who want a repeatable, performance driven approach to reduce per visit energy and bandwidth without guessing trade offs. Follow these items to make small changes that compound into measurable reductions in network transfer and device work, while keeping user experience and business goals intact.
How to use the checklist
Apply items in the order shown. Items early in the list tend to give the biggest per visit wins for the least risk. Each checklist entry includes a clear acceptance criterion you can enforce in review or CI and a short set of tools to validate results.
Pre development decisions and design rules
- Adopt a content first template
Design templates and breakpoints that prioritise content over decorative chrome. Acceptance criterion: primary content renders within skeleton layout without additional corporate scripts. Validate by running a mobile Lighthouse snapshot and confirming Largest Contentful Paint is driven by real content elements.
- Specify an image strategy up front
Decide formats, responsive sizes, art direction rules and acceptable quality levels before implementation. Acceptance criterion: responsive image srcset or responsive image CDN rules are defined for each template. Validate by inspecting a representative page and confirming the largest image is delivered in a modern format when supported.
- Limit optional features behind intent signals
Map features such as autoplay video, heavy client personalization, and large downstream widgets to explicit user intent. Acceptance criterion: non essential features are not requested on first render. Validate by tracing network requests on first load and confirming optional resources are lazy loaded.
Development and build time practices
- Enforce minimal critical JavaScript
Ship only the JS required for first meaningful interaction. Acceptance criterion: total JS parsed on the critical path is below team budget. Validate using a development Lighthouse run or a build time bundler report.
- Use tree shaking and code splitting deliberately
Split code by route and by feature so users download only what they need. Acceptance criterion: each entry chunk contains fewer than the agreed number of KBs of non vendor code. Validate by examining build output sizes and verifying no large modules are duplicated.
- Set and test performance budgets in CI
Translate size and timing limits into failing checks in your continuous integration pipeline. Acceptance criterion: PRs that exceed budgets fail CI and include guidance to reduce size. Validate by running Lighthouse or a bundler size check during CI.
- Optimize fonts at build time
Subset and preload only fonts required for initial render. Acceptance criterion: critical font files are subset to required character sets and preloaded sparingly. Validate with build artifacts and by checking font file sizes in network traces.
- Automate image optimization
Configure the build or image pipeline to produce WebP or AVIF derived assets and properly sized variants. Acceptance criterion: every image served on production has at least one optimized modern format variant. Validate by sampling pages and confirming Content Type responses and sizes.
Delivery and infrastructure
- Use a geographically distributed CDN with cache rules
Serve static assets from the edge and set long cache lifetimes for immutable assets. Acceptance criterion: immutable assets use far future cache headers and cache busting is handled by content hashed filenames. Validate via response headers in browser or curl.
- Prefer efficient transport and compression
Enable HTTP version improvements and modern compression. Acceptance criterion: assets are delivered with Brotli or an equivalent and HTTP2 or HTTP3 is available for clients. Validate with network lab tests and server configuration checks.
- Avoid unnecessary server generated markup
Keep server responses concise and avoid repeated wrapper markup that increases bytes for every page. Acceptance criterion: HTML payloads are audited and shrink when common wrappers are removed or made conditional. Validate by comparing HTML transfer sizes between iterations.
- Limit third party scripts
Evaluate each third party for necessity and measurable impact. Acceptance criterion: every third party used is documented with purpose, load model and a performance cost estimate. Validate through a third party inventory and by measuring first load overhead in a controlled test.
Runtime behaviour and progressive delivery
- Lazy load non critical assets
Defer images, iframes and modules that are not required to interact above the fold. Acceptance criterion: non critical assets use native loading or intersection observer patterns. Validate with a first contentful paint and network waterfall check to ensure deferred assets load after core content.
- Prioritise meaningful rendering
Serve critical CSS and avoid large style recalculations on load. Acceptance criterion: critical CSS is under the agreed KB limit and style layout shifts are minimised. Validate via Core Web Vitals metrics and style sheet size inspection.
- Prefer server side rendering for initial view when appropriate
Use server rendering to reduce client CPU work on first load where it improves LCP and reduces JS parsing. Acceptance criterion: server rendered pages show faster LCP in synthetic tests compared to pure client rendering. Validate using Lighthouse snapshots comparing render strategies.
Measurement, CI and release controls
- Automate synthetic checks in pull requests
Run lightweight Lighthouse or WebPageTest checks in PRs with clear thresholds for regressions. Acceptance criterion: PRs must not introduce regressions in critical metrics or bundle sizes. Validate by ensuring CI has failing gates when thresholds are exceeded.
- Instrument real user monitoring for emissions sensitive metrics
Collect Core Web Vitals, transfer sizes and key device CPU metrics in production to detect regressions and to prioritise future work. Acceptance criterion: baseline data exists for 30 days before a major change. Validate by querying your RUM dataset for the baseline period.
- Convert budgets into alerts and rollback rules
When production metrics cross thresholds, trigger an alert and a runbook that can disable non essential features. Acceptance criterion: an automated mitigation path is documented and tested in staging. Validate through a simulated failure and verification of mitigation effectiveness.
- Make sustainability KPIs visible
Publish per visit transfer and device work metrics in dashboards used by product and engineering teams. Acceptance criterion: a dashboard with per visit bytes, LCP and a sustainability signal is updated daily. Validate by viewing the dashboard and confirming data freshness.
Governance and team practices
- Include performance acceptance criteria in stories
Add explicit performance and sustainability acceptance criteria to tickets so work cannot be merged without meeting them. Acceptance criterion: every story affecting client render includes at least one measurable performance criterion. Validate during code review.
- Run periodic audits, not one off fixes
Schedule quarterly audits that review templates, third parties and infra for regressions and new opportunities. Acceptance criterion: audit findings are tracked and assigned. Validate by checking audit backlog and closure rates.
- Train the team on measurement and trade offs
Provide short internal workshops on how to interpret RUM, Lighthouse and how to prioritise fixes by impact per engineering hour. Acceptance criterion: at least two team members can run and interpret core reports. Validate by a practical exercise recorded in retrospective notes.
Practical checks and commands to run
- Local quick audit
Run Lighthouse in the browser or CLI and confirm no regressions in LCP, CLS and Total Blocking Time. Use Lighthouse as a pre merge signal for obvious regressions.
- Build artifact checks
Inspect bundle and asset sizes produced by the build. Tools such as webpack bundle analyzers or build size reporters should be part of CI to enforce limits.
- Production smoke test
Run a headless synthetic test against production endpoints with WebPageTest or Lighthouse CI to confirm performance budgets are met after deploys.
Adopting a performance first checklist ties design decisions to measurable outcomes and makes sustainability a predictable part of delivery. Start small by enforcing one or two CI checks and one recurring audit. As the team gains confidence, raise the bar on budgets and extend measurement to broader user cohorts.