Website Page Size Checker: Measure Page Weight and Make Pages Load Faster
A website page size checker tells you how heavy a page is and why: how big the HTML is, how much JavaScript, CSS and imagery the browser has to download, whether files are compressed and how quickly the server responds. Our free page size checker loads any URL from our server, measures the HTML and every script, stylesheet and image it references (up to 120 files), and shows the total weight broken down by type, with the largest files first. Then it tells you, in order of impact, what to fix to make the page faster.
This guide explains what page size is, how it affects Core Web Vitals and SEO, how to read the report and the practical fixes that cut page weight the most.
Key takeaways
- Aim for a server response under 0.8 seconds; everything else waits for it.
- Images are usually the biggest part of page weight and the easiest to shrink.
- JavaScript is the most expensive resource: it must be downloaded, parsed and run.
- Turn on Gzip or Brotli compression for HTML, CSS and JavaScript.
What is page size?
Page size, or page weight, is the total amount of data a browser downloads to display a page: the HTML document plus every stylesheet, script, image, font and other resource it requests. It’s measured in kilobytes (KB) or megabytes (MB). A lighter page generally loads faster, uses less mobile data and is easier for low-powered phones to process.
Page size vs load time
Page weight is only part of speed. Server response time, the number of requests, render-blocking resources and how JavaScript runs all matter too. A 3 MB page with optimised images that load lazily can feel faster than a 1 MB page blocked by heavy scripts. That’s why our checker reports response time, compression and render-blocking scripts alongside the weight.
What a healthy page looks like
There’s no official limit, but as a working guide, our checker treats pages under about 1.5 MB as lightweight and pages over about 3 MB as heavy. Most business pages can comfortably sit under 2 MB without losing any visual quality.
Why page size matters for SEO
Core Web Vitals
Google uses Core Web Vitals as part of its page experience signals: Largest Contentful Paint (LCP) for loading, Interaction to Next Paint (INP) for responsiveness and Cumulative Layout Shift (CLS) for visual stability. Heavy images slow LCP, heavy JavaScript hurts INP, and images without dimensions cause layout shift. Read Google’s overview of Core Web Vitals and Search and the detailed metrics on web.dev.
Conversions
Slow pages lose visitors before they see your offer, especially on mobile networks. Faster pages typically see lower bounce rates and higher conversion rates, so speed work pays off even beyond rankings.
Crawling
Fast responses let search engines crawl more of your site in the same time, which helps large sites get new and updated pages indexed sooner.
How to use our website page size checker
- Enter the page URL and click Measure page.
- Wait while files are measured. The progress bar shows how many have been checked.
- Read the tiles: server response time, total page weight, number of files, HTML size and DOM elements.
- Look at weight by type to see whether HTML, JavaScript, CSS or images dominate.
- Review the checks for compression, large images, uncompressed files, render-blocking scripts and failed files.
- Open “All files, largest first” to find the specific files to optimise.
- Follow “How to fix it”, then measure again.
How we measure
Sizes are what each server reports, which means compressed sizes where the server compresses. When a server doesn’t report a size, we download the file and label the measurement “uncompressed”. Files loaded later by JavaScript, web fonts and CSS background images aren’t included, so treat the total as a solid minimum. For full lab data, run the page through PageSpeed Insights as well.
Understanding your page size report
Server response time
This is how long our server waited for your page’s HTML, sometimes called time to first byte. Under 0.8 seconds is good; 0.8–1.8 seconds needs attention; above 1.8 seconds is slow. Our server is in the United States, so sites hosted far away will show some extra network time.
Page weight
The sum of the HTML and every measured file. The bar chart shows each type’s share, so you can see at a glance where the bytes go.
Number of files
Each file is a separate request. Modern HTTP/2 and HTTP/3 make many small files less of a problem than they used to be, but dozens of third-party scripts still add DNS lookups, connections and main-thread work.
HTML size and DOM elements
Very large HTML, often caused by page builders, inline SVGs or duplicated mobile and desktop sections, slows the first render. A DOM of more than about 1,500 elements makes styling and interaction slower.
Compression
Text files (HTML, CSS, JavaScript, SVG) should be served with Gzip or Brotli. The checker flags any text file over 10 KB sent uncompressed.
Render-blocking scripts
Scripts in the head without defer or async stop the browser from showing the page until they’ve downloaded and run.
Failed files
Scripts, stylesheets or images that return errors still cost a request and may break parts of the page. Remove the reference or restore the file.
How to reduce page size, biggest wins first
1. Optimise images
Images are usually the heaviest part of a page.
Resize to the displayed size
A 4000-pixel photo shown in an 800-pixel box wastes most of its bytes. Export images at the largest size they’re actually displayed, and use responsive srcset images so phones get smaller versions. WordPress creates these sizes automatically for images in the media library.
Use modern formats
WebP and AVIF are typically much smaller than JPEG and PNG at similar quality. LiteSpeed Cache, ShortPixel, Imagify and most CDNs can convert images automatically.
Lazy-load below the fold, not the hero
Add loading="lazy" to images further down the page, but never to the main hero image, which is often your LCP element. Give the hero fetchpriority="high" instead.
Example
<img src="hero.webp" width="1200" height="630" fetchpriority="high" alt="Team reviewing an SEO report">
<img src="photo.webp" width="800" height="600" loading="lazy" alt="Office exterior">Google’s guide to image SEO best practices covers formats, alt text and responsive images.
2. Cut and defer JavaScript
- Remove plugins, widgets and tracking tags you no longer use.
- Load scripts only on the pages that need them; tools like Perfmatters or Asset CleanUp help on WordPress.
- Add
deferto scripts that aren’t needed for the first view. - Delay chat widgets, heatmaps and social embeds until the visitor interacts.
3. Turn on compression
Enable Brotli or Gzip in your host’s control panel, your CDN or your caching plugin. On Apache or LiteSpeed you can add:
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/css application/javascript application/json image/svg+xml
</IfModule>4. Speed up the server response
- Enable full-page caching so pages are served as static HTML.
- Use a CDN to serve pages and files from locations near your visitors.
- Run a supported PHP version and remove slow plugins.
- Upgrade hosting if your plan is consistently overloaded.
5. Trim CSS
Page builders and themes often load large stylesheets on every page. Generate critical CSS and remove unused CSS with your optimisation plugin, and avoid loading entire icon libraries for a handful of icons.
6. Reduce third-party requests
Audit every tag manager, pixel, chat tool and embed. Each third-party script brings its own requests and processing that you can’t control.
Page size by website platform
WordPress and Elementor
Use a caching plugin, enable Elementor’s performance features (optimised DOM output and improved asset loading), compress images and limit plugins. Our step-by-step guide on how to speed up an Elementor website covers each setting.
Shopify
Apps are the main source of extra JavaScript. Remove unused apps and leftover code from uninstalled ones, and choose a lightweight theme.
Wix and Squarespace
You can’t control the platform’s core code, so focus on image sizes, the number of sections and embedded third-party widgets.
Page size checker vs PageSpeed Insights
The two tools answer different questions. Our website page size checker shows what a page downloads and which files are heaviest, fast and without waiting for a full browser test. PageSpeed Insights runs a simulated browser (Lighthouse) and, when there’s enough traffic, shows real-user Core Web Vitals from the Chrome UX Report.
| Website page size checker | PageSpeed Insights | |
|---|---|---|
| Main question | What does the page download? | How fast does it feel to users? |
| Largest files list | Yes, every measured file | Top opportunities only |
| Server response time | Yes | Yes |
| Core Web Vitals field data | No | Yes, when available |
| Speed | Seconds | About a minute |
Use both: find heavy files here, then confirm the impact on LCP, INP and CLS in PageSpeed Insights and the Core Web Vitals report in Search Console.
Reading a real page size report: a worked example
Here’s how to turn a report into an action plan. Imagine the checker shows a page weight of 4.2 MB, a 1.4-second server response, 96 files and four images over 200 KB.
Step 1: Find the biggest category
The weight-by-type chart shows images at 70% of the total. That’s the first target: four oversized JPEGs make up most of it.
Step 2: Fix the largest files
Open “All files, largest first”. Resizing the hero from 3,800 to 1,600 pixels wide and converting it to WebP often cuts it from over a megabyte to a couple of hundred kilobytes. Repeat for the other large images.
Step 3: Address the server response
A 1.4-second response suggests pages aren’t cached. Turning on full-page caching usually brings this well under a second for repeat requests.
Step 4: Review the request count
Of the 96 files, 30 come from third-party domains: two analytics tools doing the same job, an unused chat widget and several social embeds. Removing what you don’t need cuts requests and JavaScript.
Step 5: Measure again
Re-run the website page size checker. A realistic result is a page under 1.5 MB with a sub-second response, then confirm the improvement in PageSpeed Insights.
How often to check page size
- After installing a plugin, app or tracking tag.
- After a redesign or new template.
- When adding large images, videos or sliders.
- Monthly for your most important landing pages.
Page weight tends to creep up over time as tools and content are added. Regular checks catch it before it hurts rankings or conversions.
Record the results each time you check, including total size, number of requests and the largest files. A simple log makes it easy to see when a new plugin, tracking script or hero video adds weight, so you can fix it before it affects your Core Web Vitals.
Page speed checklist
- Server response under 0.8 seconds.
- Brotli or Gzip compression on all text files.
- No image over about 200 KB without a good reason; modern formats used.
- The hero image isn’t lazy-loaded and has
fetchpriority="high". - All images have width and height attributes.
- Unused plugins, apps and third-party tags removed.
- Non-critical JavaScript deferred or delayed.
- No failed file requests.
- Total page weight ideally under 2 MB.
Related free SEO tools
- Free SEO checker: speed signals plus 30 on-page checks.
- 301 redirect checker: remove redirect hops that delay loading.
- Broken link checker online: find broken links and missing files.
- Who is hosting this website: check your server, CDN and HTTP/3 support.
- H1 checker: tidy structure as you simplify heavy page builder layouts.
Ready to see what’s slowing your page down? Run the website page size checker above.