Website Performance Checker
Enter any page and get a scored performance audit: how fast the server answers, how heavy the page is, which files block rendering, whether images and scripts are compressed and cached, and what to fix first.
- Scored report with a fix list
- Measures real files on the server
- Server, weight, images and caching
For real-user speed data, use the Core Web Vitals Checker. To go further on pictures, try the Image SEO Checker.
Five areas that decide how fast a page feels
Each area gets its own score, so you can see where the time and the bytes are going.
Server and delivery
How long the server takes to start answering, whether the HTML is compressed, how many redirects come first, and whether the page is served over https.
Render blocking
Scripts and stylesheets in the head that stop the page from painting, CSS @import chains, and web fonts that hide text while they load.
Page weight
How many files the page pulls in, how many bytes they add up to, how big the DOM is, and how many third-party sites are involved.
Images
Pictures with no width and height, a lazy-loaded hero image, images that are far too large, and JPEGs and PNGs that should be WebP or AVIF.
Caching and compression
Whether CSS, JavaScript, fonts and images are compressed and cached for a long time, so returning visitors don't download them again.
Overall score
The five areas are combined into one score and a grade from A to F, with a prioritised list of what to fix.
Performance targets to aim for
These are widely used guidelines. The tool rates your page against them.
| Measure | Good | Needs work | Why it matters |
|---|---|---|---|
| Server response (TTFB) | Under 200 ms | Over 800 ms | Nothing can paint until the server answers. |
| Total page weight | Under 1 MB | Over 3 MB | Heavy pages are slow on mobile data. |
| JavaScript | Under 300 KB | Over 1 MB | Scripts must be parsed and run, not only downloaded. |
| Single image | Under 200 KB | Over 500 KB | Images are usually the largest files. |
| DOM elements | Under 1,500 | Over 3,000 | Big pages slow rendering and every interaction. |
| Render-blocking files | 0 scripts | 3 or more | Each one delays the first paint. |
| Cache lifetime for assets | 30 days or more | None | Repeat visits should not re-download files. |
How to check website performance
Three steps from a URL to a fix list.
Enter a URL
Paste any public page. Leave file measuring on to include sizes, compression and caching.
Read the score
Start with the lowest area score, then the errors in the list. Each finding says how to fix it.
Fix and test again
Work from the errors down, deploy, and run the check again to see the score rise.
The fixes that usually matter most
On most sites, a handful of changes make most of the difference.
Compress and resize images
Resize pictures to the size shown, save them as WebP or AVIF, and lazy-load those below the first screen.
Defer scripts
Add defer to head scripts and load analytics and chat widgets after the page is usable.
Use a CDN and caching
Serve the page and its files from a CDN with long cache lifetimes on versioned files.
Turn on Brotli or gzip
Compressing text files typically cuts them by 70 percent or more.
Remove what you don't use
Delete unused plugins, fonts, libraries and tracking tags. The fastest file is the one you don't send.
Load fonts well
Add font-display: swap, preload the main font and limit the number of weights.
What a website performance checker does and why page speed matters
Website performance is how quickly a page is delivered and shown, and how much it costs the visitor to load. It starts on the server, where the first byte of the response has to be produced and sent. It continues in the browser, which downloads the HTML, then the stylesheets, scripts, fonts and images the HTML points to. Anything that makes that chain longer or heavier slows the page.
A website performance checker looks at that chain and points to the links that are weak. This one does not run the page in a browser. It reads the server's response and the files the HTML references, so it can name exact causes: a slow first response, HTML sent uncompressed, scripts in the head that block the HTML parser, images far larger than they are shown, and static files with no cache lifetime.
Speed matters for people first: slow pages lose visitors and enquiries. For search, Google's measurements of real-user experience are the Core Web Vitals, and this tool is the diagnostic step behind them. A slow server response, for example, is not a Core Web Vital, but it takes time away from your Largest Contentful Paint. Use the Core Web Vitals Checker to see what real visitors experience and this tool to see what is causing it.
When to run a website performance check
Run it whenever the server, the theme or the files a page loads have changed.
Before a site goes live
Test the staging or pre-launch URL for uncompressed files, missing cache headers, large images and blocking scripts. These are cheap to fix before launch and awkward to fix later.
When comparing hosting or a CDN
Check the same page before and after a move. The server response time is measured from Cloudflare's network, so use it to compare setups, not as a stopwatch for your own visitors.
After adding a plugin or tag
A new slider, chat widget or tracking tag adds files and requests. Run the check again and see whether weight, third-party hosts or blocking files went up.
When LCP is slow in the field
A poor Largest Contentful Paint often comes from a slow server, a blocking stylesheet or a heavy hero image. This report shows which of the three is the bigger problem.
During an image clean-up
See which images are far larger than needed, which lack width and height, and which are still JPEG or PNG when a modern format would be smaller.
In a technical audit or competitor study
Compare your page with a competitor's on weight, files and caching. The fix list gives a developer a place to start without opening the browser tools.
Page speed mistakes and how to fix them
The same few causes slow most sites, and most are configuration problems rather than code problems.
No page caching on a CMS
What goes wrong: Every visit makes the CMS (WordPress, for example, runs PHP and database queries) build the same page again, so the server takes a long time to send the first byte, which then delays everything else.
The fix: Turn on full-page caching at the host, in a caching plugin or at the CDN. On WordPress, page caching is a common first fix for a slow server response.
Scripts that block the first paint
What goes wrong: Scripts in the head without defer or async stop the browser from reading further until each one has downloaded and run. Stylesheets also block rendering, so a large stylesheet delays the first paint too.
The fix: Add defer to scripts that need the page parsed first, or async to independent ones. Keep the CSS needed for the first screen small, and load the rest later.
Short cache lifetimes on static files
What goes wrong: CSS, JavaScript, fonts and images served with no cache lifetime are downloaded again on every visit, which makes returning visitors wait for files they already have.
The fix: Give versioned files a long Cache-Control: max-age, for example a year, and change the file name when the content changes. Keep HTML on no-cache so it stays fresh.
Compression missing or misapplied
What goes wrong: HTML, CSS and JavaScript sent as plain text are bigger than they need to be. The opposite mistake is compressing images that are already compressed, which wastes server time for no gain.
The fix: Enable Brotli or gzip for text files at the server or CDN, and leave JPEG, PNG, WebP and AVIF files alone. Check the Content-Encoding header to confirm it works.
Oversized and wrongly loaded images
What goes wrong: A 3000-pixel photo shown at 600 pixels wide, or a hero image set to lazy-load, makes the largest element on the page slow to appear.
The fix: Resize images to the largest size they are displayed at, use WebP or AVIF, give every image a width and height, and load only the images below the first screen lazily.
Too many fonts, plugins and third-party tags
What goes wrong: Each extra font weight, plugin asset and external script adds requests and weight, and third-party hosts add their own connection delays that you cannot speed up.
The fix: Remove what you do not use. Limit font families and weights, preload the main font, and load analytics, chat and ad tags after the page is usable.
Website performance terms explained
- TTFB (Time to First Byte)
- The time from the request until the first byte of the response arrives. It covers server work and network travel. Google's web.dev guide treats 0.8 seconds or less as a rough good target.
- Render-blocking resource
- A stylesheet, or a script without
deferorasyncin thehead, that the browser must handle before it can paint the page. Deferring scripts and trimming critical CSS reduces the delay. deferandasync- Attributes on a script tag. Both download the file without pausing the parser.
deferruns scripts in order after parsing, whileasyncruns each one as soon as it arrives. - Page weight
- The total bytes a page downloads, across HTML, CSS, JavaScript, fonts and images. Heavy pages cost more time and mobile data, and images are usually the largest share.
- Content-Encoding
- A response header naming the compression applied to the body, such as
gziporbr(Brotli). Text files compress well. Images that are already compressed usually do not. - Cache-Control
- A header that tells browsers and CDNs how long they may reuse a response.
max-agesets freshness,no-cacheforces revalidation before reuse, andno-storeforbids storing it at all. - DOM size
- The number of HTML elements on a page. A very large DOM takes longer to style and lay out, and it can make later interactions slower.
- CDN (content delivery network)
- A network of servers that keeps copies of your files close to visitors. It shortens travel distance, can cache pages and static files, and often handles compression too.
Related tools, guides and services
Speed is one layer of a page. These cover what real users see and the rest of the technical picture.
Core Web Vitals Checker
See the real-user LCP, INP and CLS that this report's findings feed into.
ToolImage SEO Checker
Go deeper on image size, format, dimensions, alt text and lazy loading.
ToolHTTP Header Viewer
Inspect the cache and compression headers behind the caching findings.
GuideSEO for Nepali ecommerce
Read how speed and Core Web Vitals affect online stores that rely on mobile traffic in Nepal.
ServiceTechnical SEO service
Get speed, crawling and rendering problems found and fixed by a specialist.
Built by
Madhav Kushwaha
SEO, AEO, GEO & Digital Marketing Consultant in Kathmandu, Nepal, and trainer at ODcrU Academy and TechAxis Institute. Most speed reports give a score and little else. I built this checker to show the causes behind it: the exact files that block rendering, the images that are too heavy, and the headers that are missing, so the fix list is something a developer can start on at once.
Website Performance Checker: Frequently Asked Questions
More free SEO tools
Speed, status codes, markup and links all shape how search engines and visitors see a page. Check them one by one.