Website performance checklist: plan and track your fixes

How to use this tool

1. Choose a representative page or template and save its current performance report.
2. Review the checklist by area: images, JavaScript, CSS, fonts, hosting, caching, rendering, third-party integrations and mobile behavior.
3. Mark an item complete after checking the relevant implementation and its effect. A setting being enabled is not always evidence that the desired behavior occurs.
4. Copy the progress summary when you need a record outside this browser or want to share the work with a colleague.
5. Reset progress when you want to begin a separate review, taking a copy first if you need the existing record.

The checklist saves progress in local browser storage. It is not an account-based project tracker and does not synchronize your work across browsers or devices. Clearing the site's stored data can remove the saved progress.

About the results

The completed-item count describes your checklist state. It is not a performance score, an accessibility certification or proof that Core Web Vitals pass. Different pages can share a template but expose different problems because of their content, media and integrations.

Use the items as prompts for investigation. For example, an LCP image should not be delayed by lazy loading, but that does not mean every image should load eagerly. Long-lived caching is appropriate for versioned static assets, while private pages require different rules. Apply each check to its intended context.

Record evidence beside your project tasks: the tested URL, device category, cache state, affected component and before-and-after recording. The checklist keeps the process visible, while those records establish what was actually verified.

Which section should I start with?

Start with the measured bottleneck. A delayed first byte suggests server and caching checks. A late image request suggests resource discovery. A slow interaction suggests main-thread and rendering work. Unexpected movement suggests missing layout space.

If you do not yet know the cause, use Core Web Vitals for beginners to choose a report, then follow the dedicated metric guide. Checking easy boxes first can feel productive while leaving the main user problem untouched.

Should every item apply to every website?

No. A static publication and a personalized commerce application have different constraints. Some items require a judgment about relevance, platform control or tradeoffs. Keep an external note when an item is not applicable; do not claim a feature was implemented merely to make the progress count complete.

Avoid universal numerical rules where the actual cost depends on the page. DOM complexity, image dimensions and script activity need representative measurements. The JavaScript guide and server-response guide explain how to investigate those dependencies.

Will saved progress survive a browser change?

Not automatically. Local storage belongs to the browser's storage for this site. A different device, private session or cleared browser profile may not contain it. Copy the summary when you need a durable project record. Do not enter private credentials or sensitive operational information into copied material you intend to share.

Revisit the checklist after substantial template, plugin or integration changes. Performance work is easier to maintain when each change has a specific verification step rather than an old completion count.