Make a publication faster without breaking the reading path

Choose a reader task

Performance work begins with what someone came to do. For a publication, that could mean opening a long guide on a phone, finding a topic or completing a newsletter form. MDN’s performance material describes measurement across loading and responsiveness. WCAG 2.2 provides testable accessibility criteria, including keyboard use, reflow and status communication. These are complementary concerns: a quickly rendered page is not successful if the reader cannot use it.

This guide proposes a review method rather than claiming an audit of every page or browser. Select a few representative tasks and write what successful completion looks like. Include a reader using enlarged text and a reader navigating without a pointer. The objective is a usable reading path, not a score produced under one convenient test condition.

Record a reproducible baseline

Choose a device or browser profile and document network conditions. Use the same article and viewport when comparing changes. Record when the main text becomes usable, whether images shift the reading position and how quickly an interaction responds. Distinguish a cold first visit from a repeat visit using cached assets. Both can matter, but they should not be mixed into one unexplained comparison.

Keep browser traces or measurement output alongside a short written observation. If a slow result occurs only sometimes, retain that variation rather than selecting the fastest run. A publication may have a fast homepage while a long article with images performs poorly. Test representative content lengths and layouts instead of assuming one route speaks for the whole site.

Prioritize the content that carries the task

The headline, article body and navigation should not wait for decorative scripts. Give images predictable dimensions so they do not move text after loading. Select appropriate image sizes rather than sending a large desktop asset to every phone. Keep meaningful text in the document so that basic reading is not dependent on a successful sequence of client-side requests.

Treat animation as an enhancement with a reduced-motion path. A transition should not hide a form result or trap focus. If a third-party widget becomes unavailable, the article should remain readable. Decide whether the widget is necessary before optimizing how it loads; removing work that does not serve a reader can be more valuable than making that work slightly faster.

Preserve interaction and accessibility

After each change, navigate with the keyboard through the menu, article links and forms. Confirm that focus remains visible and follows an understandable order. Increase text size and narrow the viewport. Look for horizontal scrolling caused by ordinary prose, clipped controls or overlays covering the active field. Check that submission success and failure are communicated in text, not only by color or an animation.

Automated tools can identify issues such as missing names or some contrast failures. They cannot determine every question of reading order, useful alternative text or understandable error recovery. Use their output to focus manual inspection. A passing scan should be reported as a passing scan, rather than expanded into an unsupported claim of complete accessibility.

Compare one meaningful change

Choose a likely bottleneck and change it narrowly. For example, replace an oversized lead image with responsive variants, then repeat the same task under the same conditions. Inspect visual quality and alternative text as well as transfer size. If the difference is within normal variation, state that instead of claiming a dramatic improvement.

Keep correctness checks proportional to the change. An image adjustment needs image and layout verification; a new client-side rendering path may require broader interaction testing. Preserve a previous artifact or configuration so that a regression can be reversed without reconstructing the old implementation from memory.

Report the result honestly

State what became better, which conditions were checked and what remains outside the assessment. Connect technical evidence to the reader task: less waiting before text appears, a stable reading position or a form that stays usable on a small screen. Avoid promising universal speed or accessibility from one measurement. A good performance review leaves the publication easier to use and gives the next maintainer enough evidence to preserve that improvement.

Sources

• MDN web performance documentation — living documentation; accessed 16 October 2026
• W3C Web Content Accessibility Guidelines 2.2 — 2024-12-12