Türk SEM · SEO Tool

Site Speed Metrix: Website Speed Test

We load your page in a real browser three times, starting clean each time. You get the median result, how long every file held things up and what each fix would save you.

Site to test

Device

4G (170 ms latency, 9 Mbps), 2x CPU slowdown, 412×823 screen

Pick a device, enter your address and hit Test Speed. A test takes 30 to 90 seconds.

How It Works

1
Connect your site
Enter the address once. Your server location, HTTP version and compression come from the same scan, so nothing gets measured twice.
2
We load the page three times
Every load uses a fresh Chromium with an empty cache. Mobile runs on 4G with a 2x CPU slowdown, a setting that lands close to what real phone users report for the same sites. Desktop runs without throttling. Tests run from our server in Istanbul.
3
We record every request
For each file we log DNS, connect, TLS, wait and download time, its size and whether it blocks rendering. We also capture the page frame by frame as it loads.
4
You get the median
We report the median of the three runs and the spread between them, so you never make a call based on one lucky or unlucky test.

How the Grade Works

Each metric becomes a 0 to 100 score on a log-normal curve, using the method and thresholds Lighthouse publishes (Chrome for Developers). The weights are ours: Total Blocking Time 30%, Largest Contentful Paint 25%, Cumulative Layout Shift 25%, First Contentful Paint 10% and server response 10%. Server response takes the place of Speed Index because it's what matters most when you pick a host, and we measure it ourselves, unthrottled.

A (90 to 100): The page is fast. There isn't much left to gain.
B and C (70 to 89): Mostly fine, but one or two metrics drag the score down. Start with the top items under Fixes.
D and E (50 to 69): Visitors are waiting. It's usually one big problem: a heavy image, a blocking script or a slow server.
F (below 50): The page struggles to load, especially on phones. Look at server response and the largest element first.

What Counts as Good

These are Google's thresholds for real-user data (web.dev). They look at what 75% of visits experience.

Metric	Good	Needs improvement	Poor
Largest Contentful Paint (LCP)	2.5 s or less	2.5 to 4 s	over 4 s
Interaction to Next Paint (INP)	200 ms or less	200 to 500 ms	over 500 ms
Cumulative Layout Shift (CLS)	0.1 or less	0.1 to 0.25	over 0.25
First Contentful Paint (FCP)	1.8 s or less	1.8 to 3 s	over 3 s
Time to First Byte (TTFB)	0.8 s or less	0.8 to 1.8 s	over 1.8 s

Lab Tests vs. Real Users

Google ranks pages on what real Chrome users experienced over the past 28 days (Chrome UX Report). That data tells you whether there's a problem, not where it is. Site Speed Metrix loads the page under controlled conditions, so it shows you which file is to blame. The results screen puts the two side by side.

Interaction to Next Paint can only come from real users, because someone has to click. In the lab we use Total Blocking Time instead (web.dev). Both point to the same problem: JavaScript keeping the page busy.

For your site's overall SEO health, try our SEO Checker. To follow real-user data week by week, use our PageSpeed portal. All three read the same scan.

Checks PageSpeed Doesn't Run

After the three timed loads, we open the page once more and run the checks below. None of them appear in PageSpeed Insights. On the results screen each one is marked as a Türk SEM check. All of them are lab measurements, not real-user data.

Server response in four parts: We split the server response into DNS, TCP connect, TLS and server wait, and measure it five times without throttling. By subtracting one network round trip from the wait, we also estimate how long the server spends building the page. For comparing hosts, nothing is more telling.
Click response (lab INP): We actually click the menus and buttons on the first screen and time how long the page takes to respond. PageSpeed never clicks, so it can't report INP. While clicking we block any request that would send data to your server, so the test changes nothing on your site.
What locks up the page: Using Chrome's Long Animation Frames data, we find out which script spent how much time in every frame that kept the page busy for over 50 ms. Your own code is kept apart from ad and analytics scripts.
Layout shift while scrolling: We scroll down the page and measure how much late-loading ads and images push the content around. PageSpeed only looks at the initial load.
Second visit: We reopen the page with a primed cache, so you can see how much a returning visitor downloads and how fast the page opens for them.
Back button: We check whether the page opens instantly from the browser's back/forward cache. If it doesn't, we show the reason Chrome itself reports.
Cookie banner and LCP: If the largest element on screen is the cookie banner, LCP measures the banner rather than your page. It's common on European sites, so we flag it separately.

What's in the Deep Dive Tab

We don't squeeze everything we measure into a single score. The Deep Dive tab breaks down why the page loads the way it does. None of it needs an extra page load; it all comes from the same test.

Visual progress: We compare every filmstrip frame with the final one and chart how much of the screen is ready at each moment. That gives you Speed Index plus the points where the screen is 85% and fully complete. Speed Index is shown for reference and doesn't affect the grade.
Unused code: We count, file by file, how much of the JavaScript and CSS downloaded on page load never ran. You'll see which files are worth splitting or deferring, and roughly how much you'd save.
CPU time and page structure: We split the browser's work during load into JavaScript, layout and style recalculation. Next to that you get the number of HTML elements, the nesting depth and the JavaScript heap size.
Connections: For every domain the page connects to, we list DNS, TCP and TLS time and the protocol used. Each third-party script comes with a connection cost, and this is where you see it.
Third-party services: In the Breakdown tab, outside services show up by name instead of by domain: Google Tag Manager, Meta Pixel, Hotjar, live chat widgets and so on. For each one you see its requests, the data it brings in and how long it blocks the page.
Server and security: TLS version, certificate issuer and expiration date, CDN, cache headers and any Server-Timing values the server sends. If the certificate expires in less than three weeks, it shows up as a fix.
Fonts: We list the web fonts the page loads and their font-display setting. Without it, Chrome hides text for up to 3 seconds while the font downloads.
All three runs: The grade comes from the median run, but we show all three runs and the spread between them. A big spread means the server behaves differently from one load to the next.
Carbon estimate: Using the data the page downloads, we estimate carbon emissions per visit with the Sustainable Web Design model (v4). The model uses the global average grid; on a host powered by renewable energy, the real number is lower.

Where the Thresholds Come From

We don't touch Google's Core Web Vitals thresholds, because those are what rankings use. They rest on two things: research on human perception, and whether sites can realistically reach them (web.dev). Research suggests a response within about 100 ms feels instant (Nielsen; Card, Robertson and Mackinlay, 1991; Miller, 1968). Most mobile sites can't get there, though, so Google set the INP limit at 200 ms.

Perception research also shows that no single number tells the whole story. In a study by Kelton and colleagues, the browser's "load" event was on average 6.4 seconds later, or 2.1 seconds earlier, than the moment users felt the page had loaded (NSDI 2017). In the Eyeorg studies, each run with a thousand participants, even the most sophisticated metrics failed to match what people perceived (Varvello et al.). That's why we give you several measurements that complement each other instead of one score.

Server time may look small, but it changes behavior. In a Google experiment, adding 100 to 400 ms of delay to search results cut searches per user by 0.2 to 0.6%, and the effect lasted for weeks after the delay was removed (Google Research).

Frequently Asked Questions

Why is my result different from PageSpeed Insights?

PageSpeed Insights deliberately assumes a very slow connection for its mobile test, so its numbers usually come out worse than ours. We use a 4G connection that sits close to what real users experience, and we load the page three times. The numbers won't match exactly, but they point to the same problems.

Why is mobile so much worse than desktop?

The mobile test mimics a mid-range phone on a 4G connection. Heavy images and long scripts you'd never notice on a laptop add whole seconds here. If most of your visitors are on phones, this is the result to watch.

Which numbers affect Google rankings?

Google reads the Core Web Vitals (LCP, INP and CLS) from real-user data. Our lab test helps you understand why that data looks the way it does. It doesn't feed into rankings itself.

Why do you test three times?

The same page can load differently from one test to the next because of network traffic and server load. We report the median of three runs and show the spread. A big spread usually means your server's response time is unstable.

Where do the tests run from?

From our server in Istanbul, Türkiye. If your server is far away, setting up the connection takes a little longer. That doesn't skew a comparison between sites, since every site is measured over the same route. The results screen also shows where your server is.

How many tests can I run?

Three a day without an account and 20 a day with a free account. Results are kept for 24 hours, and looking at a saved result again doesn't count against your limit.

How do I bring down server response time (TTFB)?

Page caching is the quickest win, since the server stops rebuilding the page on every visit. After that, look at database queries, server resources and distance to your visitors. If your audience is in another country, a CDN cuts this time noticeably.

Is lab INP the same as real INP?

No. Real INP comes from every interaction visitors make during their whole visit, and Google collects it from Chrome users. We click a handful of menus and buttons on the first screen, in a browser on our server. The result tells you whether there's a problem and which element causes it; the number that counts for rankings is still the real-user one.

How do you estimate server processing time?

Setting up the TCP connection takes one round trip to the server, which reflects the network distance. The server wait also contains one round trip. Subtract the TCP connect time from the wait and you get a close estimate of how long the server spent building the page. It is an estimate; if your server sends a Server-Timing header, you can read the exact figure there.

Site Speed Metrix: Website Speed Test

How It Works

Connect your site

We load the page three times

We record every request

You get the median