New format
Webpage size: how to check weight and speed up loading
Page weight is how many bytes the browser downloads to show the document: HTML, CSS, JS, images, fonts, third-party widgets. The larger the volume and the worse the compression, the longer people wait on a weak connection.
Below: why to measure weight, how to see it in a minute, and what usually gives the fastest win. This is speed hygiene — not “page one thanks to fewer KB.”
Why know page size
Large volume on slow LTE/3G = long LCP, blank screen, leave before content. On hosting and CDN extra traffic costs money. For SEO, field speed metrics and whether people finish the page matter.
Weight is a simple “where’s the fat” signal: compare a competitor URL to yours, spot a spike after a widget, control a release.
When measuring is mandatory:
- after a redesign / new template
- before ad spend on a landing
- if mobile bounce grows
- when someone says “the site is slow”
How to see weight in DevTools
Open the page → F12 / DevTools → Network tab. Enable Disable cache, refresh. At the bottom you’ll see request count and transferred bytes. Sorting by Size shows the heaviest eaters.
Look separately at transferred (over the network) and resource size. Cache distorts the picture — for an audit a cold load matters more.
Mini ritual:
- incognito + disable cache
- mobile user-agent / throttling
- lock top-10 resources by Size
- repeat on a key landing and product page
Online tools and what they show
PageSpeed Insights, WebPageTest, GTmetrix and similar give weight estimates, request chains, and recommendations. Tool numbers diverge due to location and cache — compare relative before/after on one tool.
Don’t chase a “100 score” for a screenshot. The goal is cut extra megabytes and improve perceived speed.
In the report look for:
- total page weight
- images without compression/modern formats
- unused CSS/JS
- blocking scripts in head
- extra redirects
What usually bloats a page
Unoptimized photos and backgrounds, autoplay video, too many fonts, heavy sliders, “just in case” analytics and chats, duplicate libraries, a full-home map without lazy load.
On a CMS — plugins, each with its own CSS/JS. A plugin audit often saves more than tweaking JPEG quality by 5%.
Typical top offenders:
- images > 200–300 KB without a real need
- hero as PNG instead of WebP/AVIF
- all of jQuery UI for one button
- social widgets and live chat
- unminified bundles
How to speed up: work order
First cut the heaviest Network contribution. Images: compression, modern formats, srcset, lazy-load below the fold. Text: Brotli/Gzip. JS/CSS: remove unused, defer/async, code-split.
Browser cache and CDN — after files are light. Otherwise you just deliver the same fat faster.
Sprint checklist:
- compress hero and product cards
- enable server compression
- defer non-critical JS
- remove 1–2 extra widgets
- remeasure DevTools before/after
Production control
Set a weight budget for templates (home, category, article). In CI or the release checklist — a Network snapshot. Watch field CWV in webmaster panels.
After major releases compare not only Lighthouse scores but real transfer size of key URLs.
Playbook:
- reference URLs and their limits
- an owner for assets
- ban uploading a 5MB photo into content without compression
- quarterly re-audit
FAQ
Is page weight the HTML file size?
No. Look at total transfer size of all document resources (and cache vs network). HTML is often tiny next to images and JS.
What’s a normal page weight?
Depends on type. For a landing on 3G, aim for reasonable hundreds of KB–a couple of MB — not tens of megabytes without a real need. LCP/INP and field data matter more than one number.
Where to look in the browser?
DevTools → Network: Size column, total at the bottom. Disable cache for a cold load. Performance/Lighthouse — extra diagnostics.
Does weight affect SEO directly?
Through speed and behavior: a heavy page hurts Core Web Vitals and bounce. Search doesn’t rank by KB, but slow UX hits visibility indirectly.
Is compressing images enough?
Often yes as a first step, but heavy JS/CSS and extra widgets matter too. Cut by Network contribution.
Are Gzip/Brotli required?
Yes for text resources in production. Without compression HTML/CSS/JS balloon several times.
Does a CDN reduce weight?
Not file weight — delivery latency. Weight is cut by asset optimization; CDN is proximity and cache.
Are mobile and desktop the same?
Often not: different images, menu, scripts. Measure both profiles and real devices/throttling.
Landing feels slow — and Network shows a 4MB hero plus chat widgets?
We’ll cut transfer size by contribution — images and JS first, then cache and CDN.
Discuss the task
