At a glance
Total page weight (KB) decomposed by resource type, images, JavaScript, CSS, fonts, video, HTML, other. Reveals where the bytes actually live, not how heavy the page is overall (that’s psi_total_weight’s job). Image-heavy fashion stores look very different from JS-heavy SaaS-style storefronts: 4.5MB of images on the homepage is a different fix than 4.5MB of unused JavaScript. The decomposition tells the merchant which resource bucket to attack first to lose the most weight per hour of engineering effort.
Calculation
Calculated automatically from your Website Performance (PageSpeed + CrUX) data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.Worked example
A UK-based BigCommerce fashion store, mobile homepage audit, Wednesday 15 May 26.
What the decomposition is telling us:
- Image weight dominates at 60% of total page weight. 3.2MB of images on a single homepage view exceeds the ecommerce typical range of 1.5-2.5MB. Images are unambiguously the highest-leverage fix bucket, even a 50% reduction (achievable via WebP/AVIF + responsive variants) would drop the page from 5.4MB to 3.8MB and land it within the typical range.
-
Why image weight is high: likely four hero PNGs at 800-900KB each (no format conversion), plus product thumbnails on the homepage carousel served at 2x resolution but displayed at 1x. The fix is mechanical: bulk image conversion + responsive
srcsetdeclarations. -
Script weight is at the high end of the typical range (1.15MB). Not critical but worth attention. Cross-reference with
psi_unused_jsto see which bytes are unused and could be code-split or removed. Common culprits: third-party widgets (review platforms, chat widgets, GTM container with unused tags), legacy framework polyfills, jQuery on a non-jQuery codebase. - Font weight is high at 420KB. Three custom fonts × multiple weights × multiple subsets is excessive for a fashion store. The typical fix: subset to Latin only, woff2 only (not woff), preload only the critical weight (regular for body, bold for headings), drop the rest to system fallback. Can typically halve font weight.
- Stylesheets, video, HTML, other are all healthy. No work needed in those buckets.
-
Recommended ship sequence:
- Week 1 (highest leverage): Image bulk conversion to WebP/AVIF + responsive
srcsetacross the entire image library. Saves an estimated 1.5MB on the homepage and similar on PDP/collection. - Week 2: Font subsetting and woff2-only, saves an estimated 200KB site-wide.
- Week 3: Script audit, identify dead code, code-split, defer non-critical third parties, saves an estimated 300-500KB.
- Result after 3 weeks: total page weight drops from 5.4MB to approximately 3.0-3.4MB. Score uplift, LCP improvement, mobile conversion lift.
- Week 1 (highest leverage): Image bulk conversion to WebP/AVIF + responsive
-
Why this card outperforms
psi_total_weightfor fix planning. The total weight card tells you the page is heavy. The decomposition tells you exactly which bucket to attack and what the remediation pattern is. Engineering needs the decomposition to plan a sprint; the total weight tells the executive whether the sprint mattered.
- Identify the largest resource bucket. Almost always images for fashion, JS for app-style storefronts.
- Cross-reference with type-specific opportunity cards for the prioritised remediation list.
- Plan the ship sequence by leverage, not by alphabetical bucket order.
- Re-audit after each ship to confirm the bucket shrinks.
Sibling cards merchants should reference together
Reconciling against the vendor’s own dashboard
Where to look:- Chrome DevTools → Network panel → Filter by type, shows requests grouped by
Img,JS,CSS,Font,Doc,Media,Otherwith weight per group. The single most direct vendor reconciliation source. - WebPageTest → Content Breakdown, pie chart by type with KB and request count per type.
- Lighthouse audit JSON →
network-requestsaudit lists every resource withresourceTypeandtransferSize.
Cross-connector reconciliation: primarily internal (with
psi_total_weight, psi_request_count, type-specific opportunity cards).
Quick rule for support tickets: when a merchant disputes the decomposition, capture a fresh DevTools network panel with cold cache and full scroll, group by type, and compare bucket-by-bucket. Disagreements typically resolve at the per-resource level.
Known limitations / merchant FAQs
Q: Our images bucket is 3.2MB. Is that bad? For a single page view on mobile, yes, 3.2MB of images means typical mobile shoppers wait 5-8 seconds on 4G to see the page. Ecommerce typical for image weight is 1.5-2.5MB. Anything above 3MB is in the “fix-this-quarter” zone. The fix is mechanical: WebP/AVIF conversion plus responsivesrcset declarations across the image library.
Q: Why is the script bucket so heavy when our codebase is small?
Almost always third-party scripts. Open psi_third_party_cost to see the per-domain breakdown. Common culprits: GTM container with 30+ tags, review platforms (Yotpo, Trustpilot), chat widgets (Intercom, Drift), heatmap tools (Hotjar, FullStory), retargeting pixels (Meta, TikTok). Each adds 50-200KB; six of them adds up to 600KB-1.2MB.
Q: Should we worry about the fonts bucket?
Only if it’s above 300KB or you have more than two custom font families. Most fashion stores can drop fonts by 50% via Latin-only subsetting + woff2-only + preloading the critical weight. The default Shopify/BigCommerce theme often loads 4-6 weights of a custom font when 2 weights would render every text style on the page.
Q: Our HTML document weight is 200KB. Is that high?
Yes, that’s significantly above the 50-150KB ecommerce typical. Causes are usually inline scripts/styles bloating the document, server-rendered product data being repeated for every product on collection pages, or CSS-in-JS shipping unminified to the client. Investigate via DevTools → view the document source.
Q: We see media (video) at zero. Is that right?
Probably. Most ecommerce stores don’t use embedded video on landing pages. If you have a video hero (fashion lookbook, brand story), media weight should be 1-3MB and is a primary candidate for either lazy-load with poster image or replacement with an animated WebP/AVIF.
Q: How does this card differ from psi_total_weight?
psi_total_weight is the headline number, total KB of the page. This card decomposes that number by resource type. Engineering uses the decomposition to plan a sprint; the executive uses the total to track outcomes. Both cards should appear in any performance review pack.
Q: We fixed images and the bucket dropped from 3.2MB to 1.6MB. Why didn’t the score improve more?
Because total page weight is one input among many to the Lighthouse Performance Score. LCP (largest contentful paint) is more sensitive to which image loads first and how it’s prioritised than to total image weight. Check psi_lab_lcp and psi_image_optimisation to confirm the LCP-critical image is now optimised, not just the long tail of below-the-fold images.
Q: Why is “other” sometimes 200KB+?
The “other” bucket catches resources that don’t fit the standard types: WebSockets, manifest files, source maps shipped to production by mistake, XHR/fetch JSON payloads, prefetch hints. Investigate via DevTools network panel filtered to “Other”, common findings include 100KB+ source maps that should not ship to production.