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.
| What it counts | KB transferred per resource type per page audit, broken down across images, scripts, stylesheets, fonts, media, documents, other. Includes only what’s actually downloaded by the browser; cached or unused-but-not-downloaded resources are excluded. |
| Sample type | Lab data from per-page Lighthouse network capture. |
| Why decomposition matters | ”Page is 5MB” is a single number that doesn’t tell you what to fix. “Images are 3.2MB, JS is 1.1MB, fonts are 400KB, CSS is 200KB” is a fix list. Each resource type has different remediation patterns: image conversion + lazy-load for images, dead-code elimination for JS, subset + woff2 for fonts. |
| Reading the decomposition | (1) Identify the largest resource bucket. (2) Compare against ecommerce typical: images dominate fashion, JS dominates app-style storefronts, fonts dominate brand-heavy stores. (3) Cross-reference with sibling cards (psi_image_optimisation, psi_unused_js, psi_unused_css) for the type-specific opportunity list. |
| Currency | KB (kilobytes transferred over network). |
| Time window | T/7D (per-audit). |
| Alert trigger | images > 4MB OR scripts > 2MB OR total > 6MB (page weight in critical zone for one of the dominant types). |
| Sentiment key | lower-is-better per type bucket. |
| Roles | owner, operations |
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.| Resource type | Weight (KB) | Share | Typical ecommerce range | Status |
|---|---|---|---|---|
| Images | 3,240 | 60% | 1,500-2,500 | High, fix first |
| Scripts | 1,150 | 21% | 600-1,200 | High end |
| Stylesheets | 240 | 4% | 100-300 | Healthy |
| Fonts | 420 | 8% | 100-300 | High |
| Media (video) | 180 | 3% | 0-500 | Healthy |
| Documents (HTML) | 80 | 2% | 50-150 | Healthy |
| Other | 90 | 2% | 50-200 | Healthy |
| Total | 5,400 | 100% | 2,500-4,500 | Above ecommerce typical |
- 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.
| Time horizon | Action |
|---|---|
| First 1 hour | Identify dominant bucket. Read the type-specific opportunity card. |
| First week | Apply highest-leverage fix to dominant bucket. |
| Day 14 | Address second-largest bucket. |
| Re-audit | Confirm decomposition rebalanced. |
Sibling cards merchants should reference together
| Card | Why merchants reach for it |
|---|---|
psi_total_weight | Total page weight; this card decomposes by type. |
psi_request_count | Number of requests; complements weight per type. |
psi_image_optimisation | Image-specific opportunities; leverage when images dominate. |
psi_unused_js | JS-specific opportunities; leverage when scripts dominate. |
psi_unused_css | CSS-specific opportunities; leverage when stylesheets are heavy. |
psi_top_opportunities_bytes | Bytes-savings ranking; complements decomposition. |
psi_third_party_cost | Third-party JS/font/script cost. |
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.
| Reason | Direction | What to do |
|---|---|---|
| Browser cache. Manual checks with a warm cache show a smaller decomposition. Vortex IQ audits with a cold cache. | Vortex IQ higher | Use cold-cache (Ctrl+F5 + Disable Cache) when reconciling. |
Resource type classification. Some resources can be classified differently (a font loaded via JS may show as Other or Font depending on detection). | Variable | Spot-check borderline resources. |
| Above-the-fold only vs. full page. Vortex IQ captures the full page transfer; manual checks may stop scrolling early and miss lazy-loaded resources. | Vortex IQ higher | Scroll to bottom in DevTools to load all lazy-loaded resources. |
| Run-to-run variance. Lazy-loaded images may not all fire on a single audit run. | Either direction | Use 7-day rolling. |
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.