# Template-level fixes: why one change can speed up hundreds of pages

> Most sites are built from a few templates, so most Lighthouse issues repeat across them. Group issues by template, fix once, and re-scan to confirm.

Published: 2026-11-15 · Author: AiroPages

Most websites are built from a handful of templates, so most performance, SEO and accessibility issues repeat on every page that shares one. Fix the template once and every page built from it improves. The work is in grouping issues correctly, and then re-scanning the affected URLs to prove the fix landed everywhere.

## How sites are built from templates

A site with 2,000 URLs rarely has 2,000 designs. It has a few templates and fills them with content.

- **CMS themes** have templates for posts, pages, archives and products. Every post uses the same post template.
- **Frameworks** use routes like `/blog/[slug]`, `/products/[handle]` or `/docs/[...path]`. One route file renders every URL that matches it.
- **Shared components** sit inside those templates: the header, footer, navigation, cookie notice, image component, share buttons and related-content blocks.
- **A global layout** wraps everything and decides which stylesheets, fonts and scripts load on every page.

So a typical marketing site might have a homepage, a landing page template, a blog post template, a blog index and a few one-off pages. A store adds category, product, search and checkout templates.

## Why issues repeat across URL patterns

If a template has a problem, every page that uses it inherits the problem. A blog post template that lazy-loads its featured image gives every post a delayed [LCP](/glossary/lcp). A product template with an image component that omits `width` and `height` gives every product page layout shift. A layout that loads a slider plugin's CSS on every page makes every page pay for it, even the ones without a slider.

This is why testing one page is misleading in both directions. Test the homepage and you miss the template issues on inner pages, which is the point of [Lighthouse only tests one page](/blog/lighthouse-only-tests-one-page). Test one blog post and fix it by hand, and you have fixed one page out of hundreds.

## Three kinds of issues

Not every repeated issue lives in the same place. Before fixing, sort them into three groups.

| Kind | Where it lives | Example | Fix once in |
|---|---|---|---|
| Site-wide | Global layout, header, footer, scripts | Render-blocking font CSS, a tag manager, a missing `lang` attribute | The layout or global config |
| Template | One template or component | Lazy-loaded hero on every post, unsized product images | The template or component |
| Content | One page's content | A 6 MB GIF in one post, a missing alt on one uploaded image | The page, plus a guardrail in the CMS |

Content issues are worth a guardrail even though they affect one page: automatic image resizing or a required alt text field stops the next editor from repeating them.

## How to group issues by template

Grouping by URL alone is a good start but not enough. `/about` and `/contact` may share a template, and `/blog/` might contain two layouts if the site was redesigned and old posts were never migrated.

A more reliable method:

1. **Map URL patterns to templates.** Use path prefixes or route patterns: `/blog/*` to the post template, `/products/*` to the product template. Note pages that do not fit.
2. **Fingerprint each issue.** An issue is "the same" when the same Lighthouse audit fails on the same kind of element or the same resource. For example, the same render-blocking stylesheet URL, or an LCP image with the same CSS class.
3. **Count pages per fingerprint.** An issue on 338 of 340 posts is a template issue. An issue on 1 of 340 is content.
4. **Look for issues that cross patterns.** If the same issue appears on posts, products and landing pages, it lives in the shared layout or a global component.
5. **Rank by pages affected and impact.** A high-impact issue on hundreds of pages comes first. A low-impact issue on one page comes last.

## An illustrative walkthrough

The following example is made up, but it reflects a common pattern. A site has a homepage, 12 landing pages, 340 blog posts and 180 product pages, 533 URLs in total. A full scan on mobile and desktop turns up four groups worth acting on:

1. **LCP image lazy-loaded on 338 blog posts.** The featured image component adds `loading="lazy"` to every image. The two posts without a featured image do not have the issue.
2. **Render-blocking CSS from a slider plugin on all 533 pages.** The plugin enqueues its stylesheet globally, but only the homepage and three landing pages use a slider.
3. **Images without dimensions on all 180 product pages.** The product gallery component outputs `<img>` tags with no `width` or `height`, causing layout shift.
4. **A 5 MB animated GIF in one blog post.** Content, not template.

The fixes:

- Change the featured image component to load eagerly with `fetchpriority="high"`. One file, 338 pages. [How to improve LCP on blog and product pages](/blog/improve-lcp-on-blog-and-product-pages) covers the details.
- Load the slider CSS only on the pages that use the slider. One config change, 529 pages lighter.
- Add `width` and `height` to the gallery component. One file, 180 pages.
- Replace the GIF with a compressed video, and add an upload size limit to the CMS.

Three code changes and one content edit cover every affected page. The same work done page by page would take weeks.

## What makes a good template fix

A good template fix removes the cause for every page, including pages that do not exist yet. A few habits help:

- **Fix the component, not the output.** Changing the image component is better than patching the generated HTML of each post.
- **Make the right choice the default.** If the first image in a post should load eagerly, let the template decide that, instead of relying on editors to tick a box.
- **Keep variants in mind.** A template may render differently with or without a hero image, a video or a sidebar. Test one page of each variant.
- **Write down why.** A short comment in the component explaining why the hero is not lazy-loaded stops the next developer from adding it back.

## How to verify the fix landed everywhere

A template fix is not done until you have checked the pages it was meant to fix.

1. **Deploy and purge caches.** Clear the page cache and CDN, or the scan will test the old HTML.
2. **Re-scan the affected URLs**, not just one example. Use the list of pages from the issue group, on both mobile and desktop.
3. **Check the issue count, not the score.** The question is whether the issue is gone from all 338 pages. Scores move a few points between runs for reasons unrelated to your fix, as explained in [why Lighthouse scores change](/blog/why-lighthouse-scores-change).
4. **Investigate the stragglers.** If 12 pages still fail, they probably use a different layout, have a cached copy, or contain content that triggers the issue in another way.
5. **Watch field data.** The Chrome UX Report and Search Console use a rolling 28-day window, so real-user results catch up over the following weeks. In Search Console's Core Web Vitals report, you can start validation on a fixed issue group.

## Keep it fixed

Templates change. A new plugin, a redesign or a marketing script can undo a fix without anyone noticing. Schedule regular scans, and re-scan after significant deploys, so a regression shows up as a new issue group rather than a slow decline. [Monitoring site speed after every deploy](/blog/monitor-site-speed-after-every-deploy) covers how to set that up.

If you use a coding agent, a template-level issue is also an easy task to hand over: the issue, the affected component and the list of URLs to re-check. The guide to [fixing Lighthouse issues with Claude Code](/guides/fix-lighthouse-issues-with-claude-code) shows that workflow.

## How to do this across your whole site

Manually, you can export Lighthouse JSON for every URL, group failing audits by audit ID and the element or resource involved, and count pages per group in a spreadsheet or script. It works, but it is real effort to build and maintain.

AiroPages does the grouping for you: it runs Lighthouse on every page on mobile and desktop, groups identical issues by page template ("one fix, many pages"), ranks them by pages affected and impact, and gives each a plain-English explanation and a technical fix for your developer. You can copy a fix as a prompt for a coding agent, or connect the agent through the [MCP server](/docs/mcp), which can also trigger re-scans on the Pro and Agency plans.

## One change, every page

The biggest performance wins on most sites are not on individual pages. They are in the handful of templates and components that every page is built from. Group the issues, fix the source, re-scan the pages it touches, and keep scanning so the fix stays in place.