Caliency.
SEO

Does Site Speed Affect SEO? 200 Turkish Sites Measured

Google uses speed in ranking but guarantees nothing. Real-user data from popular .tr sites: only 41 percent pass Core Web Vitals on phones.

C

Caliency

13 min read
In a bright office, a young woman with her face partly turned away holds her phone at eye level next to a laptop; the phone shows a half-loaded page made of grey placeholder blocks with a thin teal progress bar across the top.

Site speed does affect Google rankings, but only to a limited degree. Google states plainly that the three metrics it calls Core Web Vitals are used by its ranking systems. The same document says good scores don't guarantee top rankings, and that Google tries to show the most relevant content even when its page experience is sub-par.

In other words, speed doesn't replace content. Where many helpful results compete for the same query, it can contribute to success.

This post answers three questions: what Google actually says, which data it looks at, and where Türkiye's 200 most popular .tr sites stand on these metrics. For the third, we ran our own measurement on 20 October 2026. What the metrics are and how to fix them is covered separately in our Core Web Vitals guide.

What does Google actually say about site speed?

Short answer: Core Web Vitals are used in ranking, but they don't decide it on their own. Google's page experience documentation spells this out in a few points (Google Search Central, page experience):

  • They are used: Google says Core Web Vitals are used by its ranking systems and recommends that site owners achieve good values.
  • No single signal: There is no single "page experience signal"; the core ranking systems look at a variety of signals that align with page experience.
  • No guarantee: Good results in Search Console or third-party tools don't guarantee that your pages will rank at the top.
  • Relevance comes first: Google tries to show the most relevant content even if the page experience is sub-par. For queries with lots of helpful content, a great page experience can contribute to success.
  • A perfect score is not the goal: Chasing a perfect score purely for SEO reasons may not be the best use of your time.
  • Mostly page by page: Evaluation is generally page-specific, though there are some site-wide assessments.

Our reading: speed won't lift weak content, but it can make a difference where your content is on par with competitors. Anyone promising you ranking gains from a speed project is promising something Google's own documentation doesn't.

The thresholds are fixed. For a good experience, Google says LCP should occur within 2.5 seconds, INP should be under 200 milliseconds and CLS under 0.1 (Google Search Central, Core Web Vitals). web.dev recommends measuring these at the 75th percentile, separately for mobile and desktop (web.dev, Web Vitals).

MetricWhat it measuresGood (75th percentile)
LCPHow long the main content takes to load2.5 seconds or less
INPHow fast the page responds to taps and clicks200 ms or less
CLSHow much content shifts while the page loads0.1 or less

Which speed data does Google use: lab or field?

Short answer: field data, meaning the experience of real users. The Chrome UX Report (CrUX) is a dataset of how real-world Chrome users experience popular destinations on the web. Google's documentation says it is used by Google Search to inform the page experience ranking factor (Chrome for Developers, About CrUX).

The 0–100 score everyone looks at first in PageSpeed Insights is something else. It is a Lighthouse lab test and a weighted average of five metrics. The weights: FCP 10 percent, Speed Index 10 percent, LCP 25 percent, Total Blocking Time 30 percent and CLS 25 percent (Chrome for Developers, Lighthouse performance scoring).

There is a detail in that breakdown most people miss: INP is not in the score at all. web.dev notes that lab tools which only observe page load can't report INP. Total Blocking Time is a reasonable proxy, but it isn't a substitute (web.dev, INP).

Lab (Lighthouse)Field (CrUX)
Who measuresOne test machineReal Chrome users
ConditionsOne device, one network, one locationUsers' real devices and connections
PeriodThe moment of the testLast 28 days, 75th percentile
INPNot measurable; TBT as a proxyMeasured
Good forFinding causesDeciding whether there is a problem

The two can disagree sharply for the same page. According to web.dev, a lab test is limited to one device, one network and one location. Field data reflects the real devices and connections of your users (web.dev, lab and field data differences).

Passing is also judged on field data. According to PageSpeed Insights, a page or origin passes the Core Web Vitals assessment if the 75th percentiles of all three metrics are good. If there isn't enough INP data, good LCP and CLS are enough (PageSpeed Insights documentation).

Do Türkiye's 200 most popular sites pass Core Web Vitals?

Short answer: most don't. Of the 178 popular .tr origins with real-user data, 41.0 percent pass all three metrics on phones (Caliency measurement, 20 October 2026).

Method: We took the 200 most popular .tr domains within the top 100,000 of Tranco list 64VKX (Tranco, list 64VKX). It is the same sample as our earlier studies. We queried each domain in the Chrome UX Report API at origin level for phones.

We tried https://domain first and https://www.domain if there was no data. The collection period is the 28 days from 21 September to 18 October 2026. We applied PageSpeed Insights' pass rule. We ran no lab tests; every number here is real-user data (Chrome for Developers, CrUX API).

Findings (Caliency measurement, 20 October 2026):

  • 178 of the 200 domains (89 percent) have CrUX data.
  • 73 of them, or 41.0 percent, pass all three metrics.
  • Share rated good per metric: LCP 73.6 percent, INP 63.1 percent, CLS 79.8 percent.
  • The median site passes each metric individually: at the 75th percentile, LCP 1.92 seconds, INP 166.5 ms, CLS 0.03.
  • Of the 105 sites that fail, 68 fail on just one metric.

The last two points together paint an interesting picture. The typical site is under the threshold on every metric, yet most sites trip on at least one. The problem isn't general slowness; it is a single weak spot that sits somewhere different on each site.

Share of origins passing Core Web Vitals on mobile200 popular .tr sites (178 with data)41%.com.tr (96)35.4%.gov.tr (49)46.9%.edu.tr (25)52%All Turkish mobile sites (HTTP Archive)57.4%All countries (HTTP Archive)52.8%Share of origins passing all three Core Web Vitals on phones
Sources: Caliency measurement, 20 October 2026 — the 200 most popular .tr domains in Tranco list 64VKX, queried in the Chrome UX Report API at origin level for phones (https:// first, then https://www.), collection period 21 September to 18 October 2026. 178 of 200 origins had data (.com.tr 96, .gov.tr 49, .edu.tr 25). An origin passes if its 75th-percentile LCP is at most 2,500 ms, INP at most 200 ms and CLS at most 0.1; two origins without INP data were assessed on LCP and CLS, as PageSpeed Insights does. Comparison rows: HTTP Archive, Core Web Vitals Technology Report, September 2026 data, all technologies and rank groups, computed from the report's own API; mobile origins tested: Türkiye 220,095, all countries 8,569,446. The two sources use different CrUX snapshots, so the comparison is approximate.

The difference by domain type is clear too. Commercial sites (.com.tr) pass at 35.4 percent, government sites (.gov.tr) at 46.9 percent and universities (.edu.tr) at 52.0 percent (Caliency measurement, 20 October 2026). Their weak spots differ as well. On government sites, only 63.3 percent have a good LCP. On commercial sites, the problem is almost entirely INP.

On an oak desk, a laptop screen shows an abstract performance dashboard: three large circular gauges in teal, amber and soft red with no numbers, and a segmented timeline bar below; a phone beside it shows the same three gauges in miniature.

The biggest problem isn't loading, it's responsiveness

Short answer: the metric popular .tr sites fail most is INP. Of the 176 sites with INP data, 65 are outside the good range. 39 sites fail on INP and nothing else (Caliency measurement, 20 October 2026).

If those 39 sites fixed INP alone, the number passing would rise from 73 to 112, from 41.0 to 62.9 percent. On commercial sites the picture is sharper still. Only 46.9 percent of .com.tr sites have a good INP. The median commercial site's 75th-percentile INP is 204 ms, just over the 200 ms threshold.

For comparison, we looked at HTTP Archive's Core Web Vitals Technology Report. In its September 2026 data, 57.4 percent of 220,095 Turkish mobile origins pass Core Web Vitals. Across all 8,569,446 mobile origins tested worldwide, the figure is 52.8 percent (HTTP Archive, Türkiye; HTTP Archive, all countries).

Popular Turkish sites fall behind on responsiveness200 popular .tr sitesAll Turkish mobile sitesLCP (loading)73.6%69.5%INP (responsiveness)63.1%78.7%CLS (visual stability)79.8%86.7%
Sources: Caliency measurement, 20 October 2026 — Chrome UX Report API, origin level, phones, collection period 21 September to 18 October 2026; LCP and CLS for 178 origins, INP for 176 (two origins had no INP data). Good means a 75th-percentile LCP of at most 2,500 ms, INP of at most 200 ms and CLS of at most 0.1. Comparison: HTTP Archive, Core Web Vitals Technology Report, September 2026 data for Türkiye, all technologies and rank groups, computed from the report's own API; mobile origins tested per metric: LCP 221,703, INP 156,980, CLS 224,180. Different CrUX snapshots, so the comparison is approximate.

So Türkiye's most visited sites fall behind the Turkish average. They are slightly better at loading their main content: 73.6 percent have a good LCP against 69.5 percent. They are clearly worse at responding to taps: 63.1 percent have a good INP against 78.7 percent.

We didn't measure the cause of this gap. web.dev lists JavaScript that keeps the main thread busy, and long tasks, among the main causes of poor INP (web.dev, INP). Popular commercial sites carrying more ad, analytics and tag scripts is a plausible explanation, but it is a hypothesis.

There is a practical lesson here. A team working from the PageSpeed Insights score never sees the metric popular sites fail most, because that score doesn't include INP. The way to see INP is to look at field data.

How do you test your own site speed?

Short answer: look at field data first, then at the lab test. Three tools are enough, and each answers a different question.

  1. PageSpeed Insights (pagespeed.web.dev): Shows real-user data and a Lighthouse lab test in the same report. If the page itself lacks data, it falls back to the whole origin; if the origin has none either, only the lab result is left (PageSpeed Insights documentation).
  2. Search Console's Core Web Vitals report: Shows your indexed pages in groups of similar pages. A group's status is set by its worst metric. Values are the 75th percentile over the last 28 days (Search Console Help, Core Web Vitals report).
  3. Our free SEO checker: The SEO checker we built at Caliency shows the page's CrUX data where it exists, or the whole site's data otherwise. It also runs a mobile lab test and, in the same report, basic SEO checks such as the title tag and indexability.

"No data" is not a failure. To be included in CrUX, a site must be publicly discoverable and have enough visitors for a statistically significant dataset (Chrome for Developers, About CrUX). On a new or low-traffic site the lab test is your only guide, but that doesn't mean you pass.

On a sunny Istanbul street, a hand holds a smartphone showing a simple, fully loaded web page; a tram and blurred pedestrians are visible in the background.

What should you fix first?

Short answer: whichever metric is outside the good range in your field data. Instead of working through all twenty items Lighthouse suggests, check in Search Console which page group fails on which metric.

  • If INP fails: Look for JavaScript that keeps the main thread busy after a tap: long tasks, third-party tags, scripts running for no reason. In our measurement, this is where popular sites trip most often.
  • If LCP fails: Look at why the main image or heading arrives late. Common causes are server response time, a large unoptimised image or scripts that delay the content.
  • If CLS fails: Check images and ad slots without reserved dimensions, and fonts that load late.

We walk through the fix for each in our Core Web Vitals guide. Most of these problems come from decisions made while the site is built; we collected the ones that determine speed in What makes a website SEO-friendly.

When is speed work not a priority?

An answer you might not expect from an SEO agency: if your site already passes on field data, more speed work for SEO's sake will most likely pay off little. Google itself says chasing a perfect score may not be the best use of your time.

Likewise, if your pages aren't getting indexed, or you have no content that answers what people search for, speed isn't the first job. A fast site nobody can find is still a site nobody can find.

We'll state our own limit too: we can't tell you how many positions a speed project will gain you. Nobody can say that honestly, because Google uses speed as one of many signals and doesn't publish its weight. Our SEO services treat speed as part of the technical foundation, not as a ranking tactic. Whatever its effect on rankings, a page visitors can actually use should be part of the build anyway.

What we didn't measure

  • We didn't measure the relationship between speed and ranking. These sites get enough visits to make the list, and 59 percent of them fail at least one metric. That is a reminder that speed doesn't decide things on its own, not proof of it.
  • The measurement is at origin level. Google generally evaluates page by page, so individual pages can differ from the site-wide figure.
  • We only looked at phone data; desktop wasn't measured.
  • CrUX only covers Chrome users who have opted in to sharing data. The experience in Safari and other browsers isn't in this data.
  • 22 of the 200 domains had no data. At least nine of them redirect visitors elsewhere (eight to another domain, one to another subdomain); we didn't repeat the measurement at the redirect targets.
  • The HTTP Archive comparison is approximate. Its data comes from the monthly CrUX dataset for September 2026; ours comes from the API and covers 21 September to 18 October.

Frequently asked questions

Does site speed affect Google rankings?

Yes, to a limited degree. Google says Core Web Vitals are used by its ranking systems. The same document says good scores don't guarantee top rankings, and that Google tries to show the most relevant content even when its page experience is sub-par. Speed doesn't replace content; it can contribute to success where many helpful results compete.

Which speed data does Google use for ranking?

Real-user data. The Chrome UX Report (CrUX) is a dataset of how real Chrome users experience the web. Google's documentation says it is used by Google Search to inform the page experience ranking factor. Search Console's Core Web Vitals report is also based on this field data and shows the 75th percentile over the last 28 days.

Will a low PageSpeed Insights score hurt my rankings?

The 0–100 performance score is not the data Google names for ranking. It is a weighted average of a Lighthouse lab test run on one device and one network, and it doesn't include INP at all. If the real-user data in the same report passes the Core Web Vitals assessment, a low lab score alone is no cause for alarm. It is a diagnostic tool for finding causes.

How do you test your site speed?

Three tools are enough. PageSpeed Insights shows real-user data and a Lighthouse lab test in the same report. Search Console's Core Web Vitals report groups your indexed pages into similar-page groups and rates each by its worst metric. Caliency's free SEO checker also shows the page's or site's CrUX data where available and runs a mobile lab test.

Do popular Turkish websites pass Core Web Vitals?

Most don't. Of the 200 most popular .tr domains in the Tranco list, 178 have real-user data. 41.0 percent of those pass all three metrics on phones (Caliency measurement, 20 October 2026). The metric they fail most is INP: only 63.1 percent are rated good on it. In HTTP Archive's September 2026 data, 57.4 percent of all Turkish mobile origins pass.

In short

Site speed is used in Google's ranking, but relevance comes first and good scores don't guarantee top positions. The data Google looks at is not the 0–100 score in PageSpeed Insights; it is CrUX field data from real Chrome users.

Among Türkiye's 200 most popular .tr sites, 41.0 percent of the 178 with data pass Core Web Vitals, against 57.4 percent of all Turkish mobile origins. The biggest gap is INP: only 63.1 percent of the popular sites are rated good on it (Caliency measurement, 20 October 2026). The problem isn't loading, it's responding to taps, and it doesn't show up in the lab score.

To see where your site stands today, try our free SEO checker. For a site built fast from the start, see our web development service. For the technical foundation of your current site, see our SEO services, or simply get in touch. If you're curious which other basics are missing on the websites of Türkiye's largest listed companies, see our BIST 100 study.

Got a project in mind?

We'll scope it and give you a fixed price on one call.

Start a project →