Every conversation about load time starts in the same place: the home page. It is the default in the tool, it is the page on the screen during the meeting, and it is the only address everyone in the room knows by heart. Some visitors do arrive there. The rest come from a search, from an ad or from a shared link and land on a category page, a product page, an article or a result list. Those pages do not exist individually: they come out of a handful of templates, and measuring one template means measuring hundreds of addresses. This article shows how to group an inventory by template, which representative per template is worth measuring, how the number of entry visits sets the order of work - and why the lighter inner pages are exactly where the next regression is created.
Key takeaways
- The value a field data report shows for an origin is not a home page value: once an origin qualifies, the eligible experiences on all of its pages are aggregated at origin level (Chrome UX Report).
- Inner pages are lighter, but not harmless: a median of 2,710 KB on the home page against 1,866 KB on an inner page, and 5,422 KB against 3,267 KB at the 75th percentile (Web Almanac 2025).
- Inner page weight is growing - by 9.5 percent within a single year (Web Almanac 2025). The place that gets measured less often grows faster.
- The composition flips: 911 KB of images on the home page against 354 KB on an inner page, but 660 KB of JavaScript on the inner page against 632 KB on the home page (Web Almanac 2025, mobile median). On templates it is script execution that hurts, not the picture.
- Group by template, not by address. External reports do the same: URLs there are grouped into pages that share a similar user experience (Search Console Help).
- The order of work comes out of gap times entry visits. A template with a moderate gap and many entry visits outweighs the outlier almost nobody opens.
Why the home page is the wrong thing to measure
The home page is the best maintained address of any site. That is exactly what makes it a weak measurement object: whatever shows up there was fixed long ago. On top of that comes a misunderstanding in the numbers themselves. The value a field data report shows for an origin does not come from the home page - if an origin is determined to be publicly discoverable, eligible user experiences on all of that origin's pages are aggregated at the origin level, regardless of individual page discoverability (Chrome UX Report). The origin value is therefore a blended value across the entire inventory, in which the home page holds exactly one vote. Putting it next to a lab measurement of the home page compares two different things; how field data and your own measurement differ decides how that number should be read.
For an individual inner page, by contrast, the page-level value is often missing entirely. A page is only included once it reaches a minimum number of visitors; pages and origins below that threshold stay out (Chrome UX Report). A catalogue with a few thousand product pages therefore has no page-level field value for nearly any of them, while it does have one for the origin. Exactly one level remains where both can be joined: the template. It is coarse enough to pool enough traffic and fine enough to name a cause. None of this changes the Core Web Vitals themselves - it changes what they are measured on.
What the origin value does not tell you
What the numbers say about inner pages
The assumption that inner pages are the smaller problem does rest on measurable ground. At the 50th percentile, home pages are 2,710 KB and inner pages are 1,866 KB; at the 75th percentile the figures are 5,422 KB against 3,267 KB (Web Almanac 2025). Averaged over time, the home page is close to 45.8 percent larger than an inner page (Web Almanac 2025). So for a single address the conclusion holds. It simply does not carry further: the inventory consists of one home page and hundreds to tens of thousands of addresses coming out of a few templates - and the sum of entry visits sits there, not on the single address.
More important than total weight is the composition, because it decides which technique actually helps. Measured on mobile, images account for 911 KB on home pages and 354 KB on inner pages; on desktop, the median home page used 239 percent the image bytes of similar inner pages (Web Almanac 2025). For scripts the ratio flips: 632 KB on the home page against 660 KB on the inner page (Web Almanac 2025). Anyone who tries image optimization on the home page and extrapolates the gain to the inventory is therefore working with the wrong factor. On templates the lever sits in script execution and in the server response time that is paid again on each of those thousands of addresses.
The following comparison summarizes what shifts between the one address and the many.
| Attribute (source of the figures: Web Almanac 2025, Page Weight chapter) | Home page | Inner page |
|---|---|---|
| Page weight at the median | 2,710 KB | 1,866 KB |
| Weight at the 75th percentile | 5,422 KB | 3,267 KB |
| Images (mobile median) | 911 KB | 354 KB |
| JavaScript (mobile median) | 632 KB | 660 KB |
| Number of addresses in the inventory | one | hundreds to tens of thousands |
| Field value per address | usually available | mostly below the inclusion threshold |
| Check before release | in practice every time | in practice only after a complaint |
Then there is the movement over time, and it points the other way: inner page weight continued to increase, up 9.5 percent year over year (Web Almanac 2025). The place that gets measured less often is the place that grows faster. That is plausible, because every new badge, every rating widget and every recommendation block lands on the template and therefore on thousands of addresses at once, while the home page is curated by hand. A budget in the delivery pipeline only helps against that drift if it covers the templates rather than the single address.
Grouping the inventory by template
Grouping does not start with the address, it starts with the system that renders the response. Shop and content management system know the name of the template a page came from. Writing that name into a response header costs one line and makes every line in the access log groupable - retroactively for everything recorded from then on. Guessing from the URL pattern instead gets the exceptions wrong: the category with its own template, the article in a special layout, the result list that renders two different views depending on the filters. How much time is spent in the backend can be reported per template along the same path - via Server-Timing.
# 1. Let the application name the template instead of guessing it from the URL.
# The system that renders the response already knows the name.
# nginx: log_format templates '$request_uri $sent_http_x_template $request_time $http_referer';
# 2. Entry visits and server time per template, sorted by entry visits.
# Entry visit = request without an internal referrer (first page of the session).
awk '$4 !~ /my-domain\.com/ {
n[$2]++; s[$2] += $3
}
END {
for (t in n) printf "%-24s %8d entries %8.3f s average\n", t, n[t], s[t]/n[t]
}' /var/log/nginx/templates.log | sort -k2 -nr
# 3. Until the response header exists: derive the template from the URL pattern.
# An interim step only - exceptions slip through this net.
sed -E 's#^/product/[^/?]+.*#product-page#;
s#^/category/[^/?]+.*#category-page#;
s#^/search(\?.*)?$#result-list#;
s#^/magazine/[^/?]+.*#article-page#;
s#^/$#home-page#' requests.txt | sort | uniq -c | sort -nr
Once the grouping exists, every template needs a representative - and not the page that looks best. Two per template carry the work: a typical case from the middle of the distribution and a heavy case from the upper end, so the category with several hundred items rather than the one with a handful. The difference between the two is not measurement noise, it is the result: it shows how strongly the template scales with the amount of data. Measure on the target device rather than the test device, otherwise the finding drifts towards the development machine.
Template, not URL pattern
The name comes from the system, not from a rule about the address. Only that way do special layouts and exceptions land in the right group.
Two representatives each
One typical and one heavy case. The spread between them says more about the template than any single value.
Entry visits per template
Requests without an internal referrer are entries into the site. They weight the measurements and decide the order of work.
Normalize parameters
Campaign and session parameters go out, distinguishing parameters stay. Otherwise one template falls apart into a thousand groups holding one value each.
Template name in the header
One line in the application, and every log line carries its group. This is the cheapest part of the whole exercise.
Field first, lab second
The field says which template matters. The lab says what is expensive inside it. The reverse order produces polished numbers in places nobody visits.
The order that has proven itself
Weighting by entry visits
A measurement per template still does not say where to start. That needs the second number: how often a template is the entry into the site. Not page views, but entries - because on entry nothing is preloaded, no script sits in the browser cache, no connection is warm. The same template that feels fast as the second page of a session can be two seconds slower as an entry. The number is in your own access log: requests whose referrer is empty or comes from an external address.
The order then follows from two factors: the template's gap to the target value and its share of entry visits. The gap is the distance to the target, not the distance to the home page: to provide a good user experience, LCP should occur within 2.5 seconds of when the page first starts loading (web.dev). The recommended reading is the 75th percentile of page loads, segmented across mobile and desktop devices (web.dev) - that split applies per template just as it applies to the whole site, and it is the reason two representatives per template are not one too many.
- Count entry visits across a full month rather than a week: season, campaigns and weekdays shift the distribution noticeably.
- Templates with fewer entry visits than the smallest item already on the list wait their turn - they come up once the large groups are done.
- Report the gap in milliseconds, not in points: a score cannot be multiplied by entry visits.
- Use the same network and device profile for every template, otherwise you measure the test conditions instead of the template.
- Keep the result as a list, not as a single finding: the order is the deliverable, not the worst value in it.
The outlier that does not matter
Three traps when measuring per template
The first trap sits in the addresses. In the public field data set, parameters and fragments are stripped from the URL so that all user experiences on the page are aggregated together (Chrome UX Report). That is intended, but it has a downside the same documentation states explicitly: in rare cases this may unexpectedly group experiences for distinct pages together, for example if parameters ?productID=101 and ?productID=102 represent different pages (Chrome UX Report). Anyone who distinguishes variants through parameters sees one page in the report where an entire template actually stands. Your own evaluation has to rebuild the same normalization, only with the opposite decision: strip campaign parameters, keep distinguishing ones.
The second trap is the grouping an external report builds. There, URLs in the report are grouped into pages that have a similar user experience, and it is assumed that these groups have a common framework and that the reasons for any poor behavior of the group will likely be caused by the same underlying reasons (Search Console Help). That is precisely the assumption that template-based work rests on - except the external report builds its groups itself, and they do not have to match the templates in your system. One group can contain two templates, one template can be spread across two groups. The external grouping works as a hint, your own as a working basis. Which report line carries which finding is settled by the route through the Lighthouse report.
The third trap is the state in which you measure. A representative requested ten times in a row sits in the cache from the second run onwards and returns a value no visitor ever sees - and conversely, personalized templates hit the cache less often than their structure suggests; how quickly one cookie wrecks the hit rate is therefore part of template measurement. Measuring several representatives in parallel to save time additionally buys you the session lock: the requests then wait for each other, and that waiting time ends up inside the template's measurement.
{
"percentile": 75,
"separated_by": ["mobile", "desktop"],
"templates": [
{ "name": "home-page", "representatives": ["/"],
"entry_share": 0.08, "lcp_ms_max": 2500, "weight_kb_max": 1800 },
{ "name": "category-page", "representatives": ["/category/small", "/category/large"],
"entry_share": 0.31, "lcp_ms_max": 2500, "weight_kb_max": 1600 },
{ "name": "product-page", "representatives": ["/product/plain", "/product/many-variants"],
"entry_share": 0.34, "lcp_ms_max": 2500, "weight_kb_max": 1600 },
{ "name": "article-page", "representatives": ["/magazine/short", "/magazine/long"],
"entry_share": 0.19, "lcp_ms_max": 2500, "weight_kb_max": 1400 },
{ "name": "result-list", "representatives": ["/search?q=bag"],
"entry_share": 0.08, "lcp_ms_max": 2500, "weight_kb_max": 1400 }
],
"order": "gap_ms * entry_share, descending",
"normalization": { "strip_parameters": ["utm_source", "utm_medium", "sid"],
"keep_parameters": ["productID", "q"] }
}
From measurement to the order of work
What comes out at the end is not a score but an ordered list: which template first, with what gap, for how many entry visits. For an online shop that is usually the category or the product page, for a magazine the article page, for a service provider the service page - and almost never the home page. What to do first inside a template is then answered by a Lighthouse audit on its representative: choosing the measurement object and prioritizing within a report are two separate steps, and taking them in that order avoids the most expensive kind of work, which is work on the wrong page.
- Set template names in the application and write them into the response header and the access log.
- Count entry visits per template across a full month and sort the list by share.
- Define two representatives per template: one typical, one heavy.
- Measure both at the 75th percentile, segmented across mobile and desktop devices, and report the gap to the target value in milliseconds.
- Multiply gap by entry share, sort the list and work on the first item - then measure again before the second one starts.
The most common finding from runs like this is not a spectacularly slow page but a template that sits just above the target value and carries a large share of entry visits. The causes repeat themselves: a component embedded on every address of the template, a list whose node count grows with the inventory, a script that is only loaded on inner pages. The same arithmetic reaches all the way into the checkout, even though the number of entry visits is small there and the value of each single request is high.
The question before any optimization is not how fast this page is, but how many pages use the same template and how many people enter the site there.
The effort for the grouping is small: one response header, one access log evaluation, two representatives per template. The return is an order of work that survives a follow-up question - and a basis for writing speed into acceptance criteria instead of promising it. If you would like to shorten the start: in a performance analysis we group your inventory by template, measure the representatives and set the order of work together with your team.
Related Articles
Speed Behind the Login: Measuring Portals Without Field Data
Behind a login the public field dataset holds nothing. How to measure inside the portal, which metrics carry, and where the limits differ from a home page.
Performance Measurement Without Consent: What Is Allowed
Section 25 TDDDG comes before the GDPR: when a Vitals measurement is device access, how narrow the exemption is and what stays measurable without consent.
Target Device, Not Test Device: Speed on Weak Hardware
Why the developer machine is the wrong yardstick, which reference device matches the 75th percentile and how both turn into a performance budget that holds.