How to use website performance tools to find what is slow
Use TTFB, compression, caching, HTTP/2 and uptime tools to diagnose a slow site step by step, and know which fix to apply.
"My site is slow" has several different causes, and guessing wastes time. The free tools at /tools let you isolate which layer is slow — the network, the server, or the page itself — before you change anything.
The order to check things
1. Is it up at all? — status & uptime
Start with the website status checker or uptime checker. If the site is intermittently down, that is an availability problem, not a speed one — and the fix is different (see Troubleshoot a down site).
2. How long until the first byte? — TTFB
The TTFB checker measures Time To First Byte: how long the server takes to start responding. This is the single most useful number for "is the server slow."
High TTFB → the server (or database) is the bottleneck. Look at CPU, slow queries, no caching. Fix on the server.
Low TTFB but still slow → the server is fine; the problem is the page (lots of assets, big images) or the network. Fix in the page.
3. Is the response compressed? — compression
The compression checker tells you whether HTML/CSS/JS are sent gzipped/brotli. Uncompressed text is commonly 70% bigger than it needs to be — enabling compression is often the single biggest, cheapest win.
4. Are repeat visits cached? — cache headers
The cache header checker shows what your pages tell browsers and CDNs to cache. If static assets are not marked cacheable, every visit re-downloads them. Combined with a CDN check, this tells you whether a CDN is actually in play.
5. Is HTTP/2 or HTTP/3 in use? — protocol check
The HTTP/2 checker confirms modern protocol support. HTTP/2 multiplexes requests and reduces the "many small files" penalty; it is usually a one-line change at the web server or proxy.
6. What is the server running? — server & CMS detection
The web server checker, server header checker and CMS detector tell you the stack (Nginx/Apache, WordPress etc.). That decides where you apply the fixes — a WordPress caching plugin versus an Nginx directive.
What the numbers mean (rough guide)
| Metric | Good | Needs work |
|---|---|---|
| TTFB (cached HTML) | < 200 ms | > 600 ms |
| TTFB (dynamic) | < 500 ms | > 1 s |
| Compression | gzip/brotli on | off |
| Static asset caching | long max-age | none |
The fix lives at the layer that is slow
High TTFB → server: add page caching, tune the database, resize the VPS. → WordPress performance
Big transfers → enable compression, serve properly-sized images, add a CDN. → What is a CDN?
Repeated downloads → set cache headers.
Many requests → HTTP/2/3.
Run the tools top to bottom, fix the first thing that is clearly wrong, then re-measure. On a HostingSwift VPS or web hosting plan each of these fixes is a small, well-understood change.