bt_bb_section_bottom_section_coverage_image

Website Performance and Mobile Experience for Turkish Users

Website Performance and Mobile Experience for Turkish Users

Website Performance and Mobile Experience for Turkish Users

Turkey is a mobile-first market by infrastructure, not just by behaviour — and that inverts an assumption most foreign web teams are working from.

According to Ookla Speedtest Global Index data compiled for March 2026, Turkey’s median mobile download speed stood at around 110 Mbps, against roughly 80 Mbps for fixed broadband. Mobile is faster than fixed. For context, global medians reported from Ookla data in late 2025 ran at approximately 93 Mbps for mobile and 107 Mbps for fixed — so Turkey sits above the global median on mobile and below it on fixed.

That has a direct consequence. The usual mental model — mobile users are the constrained ones, desktop is where the experience is fast — does not describe Turkey. If your Turkish site feels slow, the cause is much more likely to be your architecture, your third-party scripts and where your content is served from than the user’s connection.

This guide covers the connectivity picture, the technical decisions that actually affect Turkish load times, the Turkish character problem that quietly breaks font loading, and how to measure real Turkish users rather than lab scores from a European test location.

Table of Contents

The connectivity picture

Three things about Turkish connectivity matter for a web build.

Mobile outperforms fixed. The Ookla-derived figures above show median mobile download speeds ahead of fixed broadband. That is unusual among European markets and reflects sustained mobile network investment alongside slower fixed-line upgrade.

Mobile is where the audience is. Turkey’s digital audience is large and heavily mobile — DataReportal’s Digital 2026 report recorded 62.3 million social media user identities, equivalent to close to 71 percent of the population. Traffic to most consumer sites in Turkey arrives predominantly on mobile devices.

Averages hide variance. A median is not a floor. Connectivity differs substantially between İstanbul and smaller cities, between network operators, and between the moment a user is on wifi and the moment they are not. Building only for the median produces a site that works for half your visitors.

Two data cautions. Speed rankings and figures vary between sources and reporting periods, sometimes sharply, so check Ookla’s index directly for the current month rather than relying on a figure quoted in an article, including this one. And median speeds describe bandwidth, not latency — which, as the next sections explain, is often the more relevant constraint.

What Core Web Vitals actually measure

Google’s Core Web Vitals are the standard performance metrics, and they are worth understanding precisely because two of the three are not about download speed at all.

  • Largest Contentful Paint (LCP) measures how quickly the main content of the page renders. This is the one bandwidth and server distance affect most.
  • Interaction to Next Paint (INP) measures responsiveness — how quickly the page reacts when a user taps or clicks. This is primarily a JavaScript and main-thread problem, not a connection problem.
  • Cumulative Layout Shift (CLS) measures visual stability — content jumping as the page loads. This is a layout and asset-sizing problem.

The practical implication for a Turkish site is that a fast connection does not rescue you. A page loaded over a 110 Mbps mobile connection can still feel slow and score poorly if it ships too much JavaScript, runs too many third-party tags, or loads fonts and images without reserving space.

Google’s own measurement uses field data from real users rather than lab tests, which matters for the measurement section below: your Turkish visitors’ experience is what counts, not a score generated from a test server in Frankfurt.

Where your server and CDN sit

This is the single most common structural cause of slow Turkish sites, and it is usually inherited rather than chosen.

A foreign brand’s Turkish pages typically live on the same infrastructure as the global site — frequently in Western Europe or North America. Every request from a Turkish user crosses that distance, and the effect shows up as latency rather than bandwidth. A user on a fast connection still waits for the round trip.

Three decisions follow:

Use a CDN with Turkish or near-Turkish presence. Content delivery networks with points of presence in or close to Turkey cut the distance for static assets. Confirm with your provider which locations actually serve Turkish traffic rather than assuming regional coverage includes it.

Distinguish static from dynamic. A CDN handles images, scripts and stylesheets well. Dynamic content — personalised pages, cart state, search results — still hits your origin server. For transactional sites, origin location matters more than CDN coverage suggests.

Decide this alongside site architecture. Where your Turkish site sits in your domain structure and where it is hosted are related decisions, and hosting location is one of the signals Google’s documentation lists in determining a page’s target locale. Our guide to SEO in Turkey covers the search side.

Local hosting is not automatically the answer. If your Turkish operation is small and your global platform is well engineered, a CDN with good Turkish coverage usually outperforms a separately hosted local site that nobody maintains. The question to answer is where your dynamic requests are served from, not where the brochure pages sit.

The Turkish character problem

This is a specific, technical issue that foreign web teams almost never anticipate, and it degrades both performance and appearance.

Turkish uses ç, ğ, ı, İ, ö, ş and ü. Web font subsetting — the standard practice of shipping only the characters a page needs to reduce font file size — is frequently configured for a Latin subset that omits these characters. The result is one of two failures: the browser falls back to a system font for the affected characters, producing visibly mismatched text within the same word, or the font loads a larger unsubsetted file, negating the optimisation.

Three practical points:

  • Specify Turkish coverage in your font subset. Most font services offer a Latin Extended or explicitly Turkish subset. Choosing it costs a small amount of file size and prevents the fallback.
  • Test with real Turkish text. Lorem ipsum contains none of the affected characters, so a page can look correct in development and break in production. Test with actual Turkish copy containing all seven characters.
  • The dotted and dotless i affects more than fonts. Turkish distinguishes i/İ from ı/I, and case conversion in a non-Turkish locale can corrupt text outright — a problem that surfaces in search functions, URL generation and form validation as well as display.

This sits in the same family as the broader localisation issues covered in our guide to website localization for Turkey, but it is a build problem rather than a content one, and it needs to be specified to whoever implements the front end.

Image weight and the mobile grid

Images are usually the largest contributor to page weight, and the optimisation is standard rather than Turkey-specific. What is Turkey-specific is how much it matters.

Because Turkish traffic skews heavily mobile, the images that matter are the ones rendered at mobile sizes — and serving desktop-sized assets to mobile devices is the most common waste in a global template. Modern formats, responsive sizing, lazy loading below the fold and explicit dimensions to prevent layout shift are the baseline.

Two commercial points specific to the Turkish context:

Product imagery cannot simply be compressed away. In categories where the image is the product — fashion, beauty, furniture — aggressive compression costs conversion. The resolution is better formats and correct sizing rather than lower quality.

The image is also your search asset. Product images feed marketplace listings, shopping feeds and comparison platforms, so the source asset quality matters beyond your own site.

Third-party tags are the most common cause of poor INP scores, and in Turkey they carry an additional constraint that changes how you should load them.

A typical marketing stack adds analytics, advertising pixels, chat widgets, heatmaps, A/B testing and consent management — each executing JavaScript on the main thread. The cumulative effect on responsiveness is usually larger than anything in your own code.

The Turkish specific: non-essential cookies require consent before being set, and advertising cookies in particular cannot be run on a legitimate interest basis. That means your tags should be gated behind consent anyway — which, handled properly, is also a performance improvement, because nothing non-essential executes until the user has consented. The compliance detail is covered in our guide to cookie consent and tracking compliance in Turkey.

Three disciplines:

  • Audit what actually fires on the Turkish site. Tags added by agencies and contractors accumulate and are rarely removed. Inspect network requests rather than trusting the tag manager inventory.
  • Load the consent platform efficiently. The CMP itself is a script, and a slow one blocks everything behind it including your own content.
  • Defer everything that can be deferred. Chat widgets, review widgets and social embeds rarely need to load before the page is interactive.

Mobile experience beyond speed

Speed is necessary and not sufficient. Several mobile experience factors affect Turkish conversion independently of load time.

Form length. Turkish checkout and enquiry forms inherited from a global template frequently ask for fields that are irrelevant locally or formatted for another country’s address structure. Every unnecessary field on a mobile form costs completions.

Phone number and address input. Turkish phone formats and address conventions differ from European defaults. Validation rules written for another market reject valid Turkish input, which is a silent conversion killer.

Payment step rendering. The 3D Secure authentication step used in Turkish card payments is a redirect, and a flow that breaks on mobile browsers or in in-app webviews loses the order at the final moment. This is worth testing specifically rather than assuming.

In-app browser behaviour. A large share of Turkish traffic arrives from social platforms, which means pages render inside Instagram’s or TikTok’s in-app browser rather than a standard mobile browser. Behaviour differs, and testing only in Chrome or Safari misses failures that affect a substantial share of your visitors.

Tap target sizing and thumb reach. Standard mobile design practice, but frequently degraded when a desktop-first template is adapted rather than designed mobile-first.

The conversion consequences of these are covered in our guide to conversion rate optimization for e-commerce in Turkey.

Measuring real Turkish users

This is where most foreign teams get a false picture, and the fix is straightforward.

Lab tests from the wrong location mislead in both directions. A performance test run from a European data centre tells you very little about a user in İzmir. Run tests from Turkish locations where your tooling allows it.

Field data beats lab data. Google’s Core Web Vitals assessment uses real user measurement, and Search Console reports it. That is the number that reflects your actual Turkish visitors.

Segment by country. A global performance dashboard averages Turkey into markets with different infrastructure and different audience device mixes. If Turkey is not segmented, its problems are invisible until they show up as conversion gaps. Getting Turkish analytics configured correctly is a common failure point covered in our GA4 and marketing analytics setup guide for Turkey.

Segment by device and connection type. Given that Turkish mobile connections outperform fixed, the device split tells you something different here than it does elsewhere. Do not assume mobile users are the slow cohort.

Watch the metrics that move money. Performance work justifies itself through conversion rate, bounce rate and revenue per session for Turkish traffic — not through a score.

Platform realities

What you can change depends heavily on how your site is built, and it is worth being realistic about that before committing to a performance programme.

Hosted e-commerce platforms limit how much of the underlying stack you control. The available levers are usually app and script reduction, theme quality, image handling and CDN configuration — and app bloat is typically the largest single problem.

Enterprise platforms and custom builds offer more control and correspondingly more ways to get it wrong. Here the common issues are oversized JavaScript bundles, render-blocking resources and server response time.

Headless architectures can deliver excellent performance and frequently do not, because the front end ships more JavaScript than the pages need.

Whatever the platform, the highest-return work is usually the same: remove what is not needed, defer what is not urgent, serve assets from close to the user, and size images correctly. Exotic optimisation rarely beats deleting three scripts nobody remembers adding.

This is web development work with marketing consequences, which is why it tends to fall between teams. It sits within web design and software capability of the kind agencies such as Medyae provide alongside the marketing side — the practical point being that a performance problem caused by marketing tags cannot be solved by the marketing team alone, and a developer without visibility of why those tags exist will remove the wrong ones.

What this costs commercially

Performance work competes for budget against campaigns, and the argument that wins is usually the one that connects it to acquisition cost.

Three framings that hold up:

Slow pages raise your effective media cost. Every paid click that abandons before the page renders is money spent for nothing. In a market where you are already buying traffic, a percentage improvement in landing page performance is equivalent to a percentage reduction in cost per acquisition.

Mobile is where your paid traffic lands. Turkish paid social and search traffic is heavily mobile, so mobile performance is not a segment of the problem — it is the problem.

Search visibility depends on it. Core Web Vitals are part of Google’s page experience signals, and a site that underperforms on real Turkish user data is competing at a disadvantage against Turkish sites built for Turkish users.

The honest counterpoint is worth stating too: performance is a hygiene factor, not a growth strategy. A fast site with the wrong content, the wrong pricing or no local trust signals will still fail. Fix performance because it removes a constraint, not because it creates demand.

Common mistakes

Assuming Turkish mobile users are bandwidth-constrained. Median mobile speeds exceed fixed broadband; your architecture is the more likely bottleneck.

Testing from European locations. Lab results from Frankfurt describe a user in Frankfurt.

Serving Turkey from a distant origin with no CDN coverage. Latency, not bandwidth, is the constraint you are hitting.

Subsetting fonts without Turkish characters. Produces visible fallback mismatch or negates the optimisation entirely.

Testing with Lorem ipsum. It contains none of the seven Turkish characters that break.

Case-converting Turkish text in a non-Turkish locale. Corrupts terms silently, in search and validation as well as display.

Letting marketing tags accumulate unaudited. Third-party scripts are the usual cause of poor responsiveness.

Not testing in social in-app browsers. A large share of Turkish traffic never sees a standard mobile browser.

A 90-day plan

Weeks 1–4: measure properly. Segment Core Web Vitals field data for Turkish traffic specifically, by device. Run lab tests from Turkish locations. Audit every third-party tag actually firing on Turkish pages. Test your key flows in Instagram and TikTok in-app browsers and on a Turkish mobile connection. Check font subsetting against real Turkish text.

Weeks 5–8: fix the structural items. Confirm CDN coverage for Turkish traffic and where dynamic requests are served from. Remove or defer non-essential scripts, gating marketing tags behind consent. Correct font subsets. Resize and reformat images for mobile rendering. Fix form validation for Turkish phone and address formats.

Weeks 9–12: verify commercially. Re-measure field data rather than lab scores. Read the change in Turkish conversion rate, bounce rate and revenue per session, not the performance score. Decide whether remaining gaps justify platform-level work or whether the cheap wins were the whole opportunity.

Frequently asked questions

How fast is internet in Turkey?

Ookla Speedtest Global Index data compiled for March 2026 put Turkey’s median mobile download speed at around 110 Mbps and fixed broadband at around 80 Mbps — mobile ahead of fixed, which is unusual. Global medians reported from Ookla data in late 2025 were approximately 93 Mbps mobile and 107 Mbps fixed. Figures vary by source and reporting period, so check Ookla’s index directly for current data.

Do I need to host my website in Turkey?

Not necessarily. What matters is where requests are served from and the latency to your users. A CDN with genuine Turkish or near-Turkish presence usually resolves static asset delivery, but dynamic content still reaches your origin server, so for transactional sites origin location matters more than CDN coverage suggests. Confirm with your provider which locations actually serve Turkish traffic.

Why does Turkish text break my fonts?

Because font subsetting configured for a basic Latin set omits ç, ğ, ı, İ, ö, ş and ü. The browser then falls back to a system font for those characters, producing mismatched text within words, or loads a larger file that negates the optimisation. Specify Turkish or Latin Extended coverage in your subset and test with real Turkish copy rather than Lorem ipsum, which contains none of the affected characters.

Which Core Web Vital matters most for Turkish sites?

It depends on the cause. LCP is most affected by bandwidth and server distance, so it responds to CDN and hosting decisions. INP is a JavaScript and main-thread problem, usually caused by third-party marketing tags rather than connection speed — which, given Turkey’s mobile speeds, is often the more relevant constraint. CLS is a layout and asset-sizing issue.

Does consent gating help or hurt performance?

Handled properly, it helps. Turkish rules require consent before non-essential cookies are set, and advertising cookies in particular cannot rely on legitimate interest. Gating tags behind consent means nothing non-essential executes until the user consents, which reduces main-thread work. The risk is a slow consent platform itself blocking the page.

How should I test my site’s performance for Turkish users?

Prioritise field data over lab scores. Google’s Core Web Vitals assessment uses real user measurement and is reported in Search Console — segment it for Turkish traffic and by device. Run lab tests from Turkish locations where your tooling allows, and test key flows inside social in-app browsers, since a large share of Turkish traffic arrives that way.

Conclusion

The most useful thing to know about web performance in Turkey is that the constraint is probably not the network. Median mobile speeds run ahead of fixed broadband and above the global mobile median, which means a Turkish site that feels slow is usually slow because of where it is served from, how much JavaScript it ships, and how many marketing tags nobody has audited.

The work divides cleanly. Structural items — CDN coverage, origin location, font subsetting, image sizing — are one-off fixes with durable returns. Third-party scripts are an ongoing discipline, and one that overlaps neatly with the consent requirements you have to meet anyway. Mobile experience beyond speed, particularly forms, validation and the payment step, is where the remaining conversion sits.

Measure Turkish users rather than test servers, segment the data so Turkey is visible, and judge the work by conversion rather than by score. Performance will not create demand, but in a market where you are paying for every visit, it stops you losing the demand you already bought.