Page Weight: a beginner's guide
Analyze page size and resource breakdown
Page weight: the total cost of loading a single page
Page weight is the total number of bytes a browser has to download to fully render a single page — every HTML document, every CSS file, every JavaScript bundle, every image, every font, every video, every analytics beacon. It is one of the simplest possible measures of performance: just add up the sizes. And it correlates surprisingly well with how a page actually feels. Heavy pages are slow on poor connections, slow on old devices, and expensive on metered data plans. Light pages are fast for everyone, everywhere.
You should care because the average web page in 2025 is around 2-3 MB on desktop and 2 MB on mobile, according to the HTTP Archive's Web Almanac. That is enormous — twenty years ago, the average page was under 100 KB. Almost all of the growth has come from JavaScript, images, and third-party scripts (analytics, ads, A/B testing, customer support widgets). The fastest pages on the web today, by deliberate choice, weigh under 200 KB total. The difference in user experience between a 200 KB page and a 5 MB page is enormous on any connection that isn't a wired desktop in a major city.
The five things every page-weight audit looks at:
Total weight. The simple sum, in kilobytes or megabytes.
Weight by type. How much is HTML, CSS, JavaScript, images, fonts, video, and "other"? The breakdown reveals where the bloat lives.
Number of requests. How many separate files make up the page? Each request has its own latency cost.
Third-party weight. How much of the page is your own code vs. external scripts you've embedded? Third-party content is often the biggest source of bloat.
Compressed vs uncompressed sizes. A 200 KB compressed page can decompress to 600 KB in memory; the compressed size is what travels the network, but the uncompressed size matters for parsing time.
Three questions a page-weight audit answers:
How big is my page actually, and how does that compare to the median for my industry?
Where is the weight coming from — my own code, my own images, or third-party scripts I no longer remember adding?
Which single file or third-party script could I remove for the biggest size win?
The cost of ignoring page weight is the slow accumulation of bloat that nobody notices until the page hits 5 MB and customers in slow markets complain. The fix is a periodic audit, ruthless removal of unused dependencies, and a performance budget — a hard limit (say, 1 MB) that engineering treats as a non-negotiable constraint. The most useful public reference for industry benchmarks is the HTTP Archive's Web Almanac, which publishes annual data on page weight trends.
The Page Weight endpoint, in plain language
In one sentence: Analyze page size and resource breakdown
Analyzes total page size and resource breakdown including JavaScript, CSS (Cascading Style Sheets), images, fonts, render-blocking resources, and estimated load times across different network speeds.
Don't worry if some of the words above are still unfamiliar — there's a plain-language glossary at the bottom of this page, and most of the terms link to their own beginner guides if you want to learn more.
What is actually happening when you call it
Here's what's actually happening behind the scenes when you call this endpoint:
Fetches the page and all its resources, measuring the size of each resource type. Breaks down page weight by JavaScript, CSS (Cascading Style Sheets), images, fonts, and other assets. Identifies render-blocking resources, lists the largest resources, and estimates load times for slow 3G, regular 4G, and broadband connections.
If you're using an AI assistant through MCP, you don't need to understand any of the technical details — the assistant calls the tool and translates the result for you.
Why this specific tool matters
Let's skip the marketing fluff and answer the only question that actually matters: why should you, a real human with a real to-do list, care about the Page Weight tool? Here's the plain-English version, written the way you'd hear it from a friend who happens to do this for a living.
Page weight directly impacts load time, data costs, and Core Web Vitals (Google Core Web Vitals). Understanding which resource types contribute most to page weight helps prioritize optimization efforts for the biggest impact.
Picture this in real life. Imagine a frontend developer. Here's the situation they're walking into: Identify the largest resources and resource types contributing to slow page loads. Without the right tool, that person would be stuck copy-pasting between five browser tabs, reading documentation written for engineers, and crossing their fingers that the answer they cobble together is correct. With the Page Weight tool, the same person gets a clear answer in seconds — no spreadsheets, no guessing, no waiting for someone on the infrastructure team to free up.
Three questions this tool answers in plain English. If any of these have ever crossed your mind, the Page Weight tool is built for you:
Why does my website feel slow on real devices, even though it looks fine on mine?
Which specific change would give me the biggest speed boost for the least work?
Am I losing visitors and search rankings because of performance problems I cannot see?
You can either click the tool and get the answer yourself, or ask your AI assistant — connected through MCP (Model Context Protocol) — to ask the question for you and translate the answer into something you can paste into Slack.
Who gets the most out of this. Founders watching their conversion rates, marketers trying to lift landing-page revenue, ecommerce operators chasing every percentage point of speed, and developers tuning Core Web Vitals. If you see yourself in that list, this is one of the EdgeDNS tools you should bookmark today.
What happens if you skip this entirely. Skip it and visitors bounce, conversions drop, and your search ranking quietly slides — all from a problem nobody on the team can see. That's why running this check — even once a month — is one of the cheapest forms of insurance you can give your domain.
Available on the developer plan. The technical details: `GET /v1/domain/page-weight`.
When would I actually use this?
If you're still on the fence about whether the Page Weight tool belongs in your toolbox, this section is for you. Below you'll meet three real people — a frontend developer, a performance engineer, and a mobile developer — facing three real situations where this tool turns a stressful afternoon into a five-minute task. Read whichever story sounds closest to your week.
Story 1: Performance Optimization
Imagine you're a frontend developer. Identify the largest resources and resource types contributing to slow page loads.
Why it matters: Focus optimization on the highest-impact resource types.
Story 2: Budget Monitoring
Imagine you're a performance engineer. Track page weight over time to ensure it stays within performance budgets.
Why it matters: Prevent page bloat from creeping in with new features.
Story 3: Mobile Optimization
Imagine you're a mobile developer. Analyze page weight with estimated load times on 3G/4G to ensure acceptable mobile performance.
Why it matters: Optimize for mobile users on slower connections.
Common situations across teams. Beyond the three stories above, here are the everyday workplace moments when people across the company reach for the Page Weight tool — or one of the tools right next to it in this category. If any of these are on your calendar this month, that's your sign:
Before a high-traffic marketing campaign or product launch.
After a redesign, to make sure performance did not regress.
When your conversion rate drops without an obvious cause.
On a recurring schedule, to enforce a performance budget for your team.
If you can see yourself in even one of those bullets, the Page Weight tool will pay for itself the first time you use it.
Still not sure? Here's the easiest test in the world. Open Claude, ChatGPT, Gemini, or any other AI assistant connected to the EdgeDNS MCP server and ask, in your own words: "Is the Page Weight tool useful for my job?" The assistant will look at the tool, ask you a couple of follow-up questions about what you're trying to accomplish, and give you a straight answer in plain English. No commitment, no signup forms, no jargon.
The easiest way: just ask your AI assistant
If you've connected the EdgeDNS MCP server to Claude, ChatGPT, Gemini, Cursor, or any other AI assistant, you don't need to write any code. Just ask in plain English:
"Use the Page Weight tool to check example.com and explain anything that looks wrong in plain language."
The AI will figure out which tool to call, fill in the right parameters, run it, and then explain the result back to you. No copy-pasting between tabs. No reading raw JSON. No memorizing endpoint names.
MCP (Model Context Protocol) access is free on every plan, including the free tier. One API key works for both REST and AI — you do not have to choose.
The technical way: call it from code
If you're a developer and want to call the endpoint from a script or your own application, here's the simplest possible example. Replace the placeholder API key with the real one from your dashboard.
# Replace edns_live_YOUR_KEY with your real API key from the dashboard
curl -H "Authorization: Bearer edns_live_YOUR_KEY" \
"https://api.edgedns.dev/v1/domain/page-weight?domain=example.com"What you need to provide
There's just one piece of information you need to provide. The table below explains exactly what it is and what a real value looks like.
| Field | Type | Required? | What it means | Example |
|---|---|---|---|---|
domain | string | Yes | The domain to analyze page weight for | example.com |
What you get back
When you call this tool, you'll get back a JSON object with the fields below. If you're talking to it through an AI assistant, the assistant reads these for you and explains them in plain language — you don't need to memorize them.
| Field | Type | What you'll see in it |
|---|---|---|
domain | string | The analyzed domain |
totalSizeBytes | number | Total page size in bytes |
totalSizeFormatted | string | Human-readable total size |
htmlSizeBytes | number | HTML (HyperText Markup Language) document size in bytes |
breakdown | object | Size breakdown by resource type (JS, CSS (Cascading Style Sheets), images, fonts) |
resourcesMeta | object | Resource extraction metadata (extracted, analyzed, failed, truncated) |
requestCount | number | Total number of HTTP (HyperText Transfer Protocol) requests |
renderBlocking | object | Render-blocking resources count and details |
largestResources | array | Top resources by size with URLs |
estimatedLoadTime | object | Estimated load times for 3G, 4G, and broadband |
score | number | Page weight score 0-100 |
grade | string | Letter grade A-F |
breakdown_scores | object | Individual score components with details |
recommendations | array | Optimization suggestions |
Words you might be wondering about
If any words on this page felt like jargon, here's a plain-language version. Click any linked term to read a full beginner-friendly guide.
CSS (Cascading Style Sheets) — The language used to control how a web page looks — colors, fonts, spacing, layout. HTML says what content is on the page; CSS says how it looks.
Core Web Vitals (Google Core Web Vitals) — Google's official measurements of how fast and smooth your web pages feel — how quickly content appears, how long the page takes to become interactive, and how stable the layout is. Used as a search ranking signal.
Need Programmatic Access?
Automate domain intelligence with 100+ API endpoints and a free MCP server for AI integration.