A fast page is not simply a small page. It is a page that gives the browser a clear path to meaningful content and keeps work predictable on a slow connection or an older device.
Measure the critical path
Start with the first document request, then list the resources that block the first useful render. Check transfer size, response time, compression, and cache headers. Browser waterfalls are more useful than a single score because they show where waiting actually happens.
Spend bytes deliberately
Remove resources that do not change the page. Compress text responses with Brotli or gzip, keep JavaScript close to the interaction that needs it, and cache versioned static files. A cache-busting version parameter lets a long-lived cache coexist with safe updates.
Keep delivery accessible
Performance work should not remove readable text, keyboard navigation, labels, or useful error states. A page that loads quickly but hides its main action behind an inaccessible control is not a better experience.
The best optimization is often a request the browser never had to make.
Separate lab evidence from field evidence
A synthetic audit is a valuable repeatable starting point. It can show a render-blocking stylesheet, an oversized image, a long task, or an absent cache header. It is not a complete picture of how visitors experience a page. Real conditions vary with connection quality, device memory, browser features, third-party services, geography, and whether a person is returning to a page with assets already cached.
Use lab tests to identify likely causes and field measurements to understand whether a change helps people. Keep the page, device class, connection assumptions, test date, and interaction being measured in the record. A team does not need an elaborate dashboard to begin; a consistent before-and-after capture of key flows is enough to prevent arguments based on a single fast development machine.
Prioritise the content a visitor came to see
Start with the page's main heading, lead image when it carries information, and the first action a visitor can take. Give images explicit dimensions so the layout does not move while they load. Use responsive image sizes and a format appropriate to the browser, but do not hide meaningful image content behind a decorative placeholder. Load non-critical media and embeds later only when that does not prevent a reader from reaching them.
Third-party tags need the same scrutiny as first-party code. Analytics, ads, social widgets, consent tools, and embedded video can add network requests and main-thread work. Each may have a legitimate purpose, but the purpose should be recorded with an owner and a review date. Removing an unused tag is often more durable than endlessly tuning its load order.
Make changes easy to reverse
Performance work touches shared files, so a small change can have a broad effect. Version static assets, keep a clear fallback for an optimised image or script, and watch for errors after deployment. A cache policy should allow a browser to reuse stable files while giving the site a reliable path to ship a correction. In this site, for example, a version query on a stylesheet lets a browser fetch a new file when the published reference changes.
Test a representative navigation with a keyboard and on a narrow viewport after changing script loading or layout. A solution that improves one metric while breaking a menu, focus order, or form message has moved the cost to a reader. Performance and reliability are parts of the same delivery standard.
What to capture in a performance note
- The page and visitor flow tested, plus the device and connection assumptions.
- First-render, largest-content, interaction, and layout-stability observations where available.
- The requests or main-thread tasks contributing most to delay.
- Whether repeat visits benefit from caching without preventing updates.
- Accessibility and error checks performed after the change.
A repeatable check
- Record a cold load and a repeat load on the target device.
- Compare compressed and uncompressed transfer sizes.
- Inspect cache headers and make sure updates have a version path.
- Test the same flow with JavaScript disabled where practical.
- Run keyboard and narrow-screen checks before calling the work finished.
Sources and further reading
Use the web.dev performance course, MDN Web Performance documentation, and Chrome Lighthouse documentation as primary references. The Web Content Accessibility Guidelines are a companion reference for checking that optimisations preserve access.