Performance first checklist for sustainable web development

Teams that treat performance as a core acceptance requirement reduce network transfer, client CPU, and server work, which lowers both user friction and environmental impact. The checklist that follows is organized by development stage and pairs concrete actions with simple test gates you can automate.

How to use this checklist

Run the checklist as part of design reviews, pull request validation, and release gates. Each item includes a clear implementation pattern and an automated or manual verification step. Start with the items that remove whole resource categories such as unused third party scripts and oversized images, then enforce build and runtime guards.

Pre design and product decisions

1. Adopt a performance budget

   Define a small set of limits that map directly to resource use, for example maximum total bytes for the critical path, maximum main thread time, and a limit on third party script weight. Embed these budgets in design briefs so feature teams make trade offs early.

   Verification: store budgets in your repository and run automated checks from CI using tools that fail the build when budgets are exceeded.

2. Design for progressive enhancement and content prioritisation

   Design core flows so they work with minimal clientside JavaScript and without optional assets. Prioritise visible content and defer decorative elements to later in the loading sequence.

   Verification: run a no-JS smoke test and validate that primary tasks are still achievable and that the first meaningful paint contains the core UI.

3. Choose media strategy up front

   Decide which images and videos are necessary, which can be abstracted into CSS or vector formats, and where to rely on responsive variants. Prefer appropriate modern formats where browser support allows and plan for CDN resizing to avoid serving oversized assets.

   Verification: collect representative assets and ensure each has at least one responsive variant that fits common viewport sizes.

Development and build pipeline

1. Enforce treeshaking and remove unused code

   Configure your bundler to eliminate dead code and to produce separate bundles for vendor and app code. Extract runtime that does not need to be executed during initial render.

   Verification: include a CI step that reports bundle sizes per entrypoint and flags increases beyond a small threshold.

2. Implement critical CSS and split styles

   Inline only the minimal CSS required for above the fold content and lazy load the remainder. Keep component CSS scoped so unused styles are not shipped globally.

   Verification: measure the size of styles in the critical path and ensure main thread execution for style recalculation is within your budget.

3. Use resource hints and load prioritisation

   Apply preconnect for origins you will talk to early, preload for fonts and critical images, and defer nonessential scripts. Avoid preloading many resources which can congest the network.

   Verification: run trace-based tests to confirm critical resources are requested and fetched within the expected time window.

4. Optimize fonts

   Limit the number of font families and weights. Use variable fonts when they meaningfully reduce combined file size. Serve fonts with efficient formats and ensure font-display is set to avoid long layout-blocking behavior.

   Verification: confirm only required font files are delivered and that fallback fonts are acceptable during font loading.

Asset delivery and hosting

1. Use a CDN configured for caching and format negotiation

   Serve static assets from a CDN close to users. Configure the CDN to perform format negotiation for images and enable long cache TTLs for immutable assets while using short TTLs for content that changes frequently.

   Verification: inspect cache headers and CDN response behavior for representative requests to ensure hits for common assets.

2. Resize and compress images at the edge or build time

   Generate multiple sizes and prefer modern formats. Avoid clientside resizing of large images. Use lossy compression settings that preserve visual quality while reducing bytes.

   Verification: sample pages across device widths and compare delivered image sizes to the expected responsive variant.

3. Minimise third party and tracking scripts

   Audit all third party dependencies and require justification for each inclusion. Replace heavyweight vendors with lightweight alternatives or server side integrations where feasible.

   Verification: maintain a third party registry and report the aggregate weight and execution time of third party code as part of your release metrics.

Client runtime and interaction

1. Defer and lazy load non critical JS

   Split interactive features into chunks and load them on user interaction or when they enter the viewport. Use progressive hydration patterns for component frameworks to reduce initial main thread work.

   Verification: measure main thread blocking time during load and verify that deferred code is not executed until required.

2. Keep runtime CPU low

   Prefer CSS animations and transitions over JavaScript where possible. Avoid excessive DOM size and frequent layout thrashing caused by synchronous reads and writes.

   Verification: run CPU profiling on representative devices and ensure frame rate and interaction latency meet your target thresholds.

3. Reduce network chatter

   Batch API requests where possible and use caching strategies on the client to avoid repeated requests for unchanged data. Apply conditional requests and ETags for dynamic resources.

   Verification: audit network waterfall for common user journeys to ensure request counts and sizes align with expectations.

CI, testing and release gates

1. Integrate automated performance checks in CI

   Run lab audits with tools such as Lighthouse or WebPageTest to validate critical metrics against your budgets. Fail builds that regress beyond your defined thresholds.

   Verification: each pull request shows the performance report and a pass or fail status based on the budgets.

2. Run real user monitoring and synthetic tests

   Combine synthetic tests for repeatable comparisons with lightweight real user metrics that capture diverse network and device conditions. Use these signals to catch regressions not visible in lab runs.

   Verification: publish and review trend charts and set alerts for sudden metric degradations after releases.

3. Automate bundle and dependency monitoring

   Track changes in bundle composition and large dependency additions. Require a documented review for any new dependency that exceeds a size threshold.

   Verification: CI produces a dependency diff for each change and flags unexpected additions.

Third party governance and privacy

1. Classify and limit script capabilities

   Distinguish between scripts that must run in the critical path and those that can be loaded asynchronously or server side. Prefer server side implementations for analytics and personalization when they preserve privacy and reduce client load.

   Verification: maintain a consented script map and verify that nonessential scripts are gated behind user consent when required.

2. Measure the cost of each external vendor

   Record network bytes and CPU time attributable to each third party to inform decisions about replacement or removal. Use these measurements in vendor selection criteria.

   Verification: periodic audits show per vendor contribution to page weight and execution time.

Monitoring, reporting and continuous improvement

1. Track a compact set of performance indicators

   Select a small number of actionable metrics such as time to interactive, largest contentful paint, total transfer size, and main thread blocking time. Report these with segmentation by device class and network type.

   Verification: publish weekly dashboards and include a short runbook for common regressions.

2. Enforce regression budgeting

   Allow temporary exceptions with documented mitigation plans, but require regressions to be short lived. Make performance debt visible alongside feature debt in planning meetings.

   Verification: review outstanding exceptions during sprint planning and require owners and timelines.

3. Use measurement to prioritise work

   Focus effort where the combination of traffic and per visit resource use yields the largest operational wins. Start with high traffic pages and frequently executed flows.

   Verification: use A B or staged rollouts to confirm expected improvements before a full release.

Sample acceptance criteria you can copy

1. Pull request must not increase critical path bytes by more than 5 percent

   Implement via CI delta checks that compare a baseline build to the PR build.

2. New third party scripts require a documented justification and size audit

   The PR template should include the audit and a plan for lazy loading or server side migration if weight is significant.

3. All images must have responsive variants and a maximum delivered pixel area

   Fail builds when images exceed the size expected for target device classes.

Next steps for teams

Start by selecting two or three checklist items to enforce in the coming sprint and automate the verification steps. Make the performance budget visible in design and review workflows and treat performance regressions as code quality issues. Small, consistent investments in build and runtime controls compound into measurable reductions in resource use and improved user experience.

Example internal link: refer to your performance budgets guide during onboarding and link each PR to the corresponding budget rule for quick context.