Hızlı Cevap
Mobil darboğaz, sayfanın mobilde yavaş yüklenmesine veya geç tepki vermesine yol açan hız, bellek, pil ve ağ kaynaklı teknik engeldir. Tespit için PageSpeed Insights ve Search Console kullanılır; çözüm, etki-efor önceliğiyle 2026 eşiklerini (LCP 2.0s, INP 200ms) hedefler.
Önemli Noktalar
- Mobil darboğaz hız, bellek, pil ve ağ kaynaklı teknik engeldir
- Lab (PSI) ve saha (CrUX) verisini birlikte değerlendirin
- 2026 eşikleri: LCP 2.0s, INP 200ms, CLS 0.1
- Metrik-neden tablosuyla kök nedeni hızlıca eşleyin
- Düşük efor-yüksek etki düzeltmeleri önce uygulayın
1. Mobil darboğazlar nedir ve hangi türleri vardır?
Mobil darboğaz, bir sayfanın mobil cihazlarda yavaş yüklenmesine veya kullanıcı etkileşimine geç yanıt vermesine yol açan teknik engellerin tümüdür. Bu engeller dört ana bileşenden doğar: hız (sayfa yükleme süresi), bellek (RAM kullanımı), pil (işlemci yükü) ve ağ gecikmesi. Sözcüğün kökeni bir borunun en dar yerinde akışın yavaşlamasıdır; web performansında da en zayıf halka tüm deneyimi sınırlar. Kavramın temel anlamı için darboğaz teriminin sözlük tanımı başlangıç noktası olabilir.
Darboğazları iki büyük gruba ayırmak gerekir. Mobil web tarafında darboğaz çoğunlukla sayfa hızıyla ilgilidir: büyük görseller, ağır JavaScript ve yavaş sunucu yanıtı. Mobil uygulama tarafında ise bellek sızıntıları, pil tüketimi ve düşük kare hızı (frame rate) öne çıkar. Bu iki dünya farklı araçlar ve farklı ölçüm mantığı gerektirir; web için tarayıcı tabanlı ölçüm, uygulama için cihaz profili.
Mobil cihazların darboğaz yaşaması tesadüf değildir. Ortalama bir telefon, masaüstüne kıyasla sınırlı işlemci gücüne ve değişken ağ koşullarına sahiptir; aynı kod parçası masaüstünde milisaniyelerde, mobilde kat kat uzun sürede çalışır. Mobile-first index bağlamında bu fark doğrudan SEO görünürlüğünü etkiler: Google sıralamayı sayfanın mobil sürümüne bakarak belirlediği için mobildeki darboğaz, organik trafik kaybına dönüşür.
- Hız darboğazı: büyük görsel, render-blocking kaynak, yavaş TTFB
- Bellek/pil darboğazı: uygulamalarda ağır işlemler, sızıntılar
- Ağ darboğazı: CDN yokluğu, sıkıştırılmamış aktarım
2. Mobil darboğazları nasıl ölçersiniz: lab vs saha verisi
Ölçüm yapmadan darboğaz çözülmez. Mobil web için dört temel araç vardır: PageSpeed Insights (PSI), Search Console Core Web Vitals raporu, Chrome DevTools ve Google’ın yeni CrUX Vis aracı. PSI tek bir sayfayı anında test eder; Search Console ise sitenizin tamamına dair gerçek kullanıcı verisini gruplar halinde gösterir. İkisi birbirini tamamlar, biri diğerinin yerini tutmaz.
Burada en sık karıştırılan ayrım lab verisi ile saha verisi arasındadır. Lab verisi (PSI’ın Lighthouse skoru) kontrollü, simüle edilmiş bir ortamda ölçülür; her seferinde aynı koşulu kullanır. Saha verisi (CrUX ve Search Console) ise son 28 günde sayfanızı gerçekten ziyaret eden kullanıcıların cihaz ve ağ koşullarından toplanır. İkisi çeliştiğinde saha verisi önceliklidir, çünkü Google sıralamada gerçek kullanıcı deneyimini esas alır. Google’ın web.dev belgelerine göre Core Web Vitals değerlendirmesi saha verisine dayanır.
Mobil uygulama tarafında ölçüm bambaşkadır. Android’de Android Profiler ile bellek tahsisini, CPU kullanımını ve pil tüketimini canlı izleyebilirsiniz; bir ekran geçişinde belleğin sürekli yükselip düşmemesi sızıntı işaretidir. İlgili video kaynak: Chrome Developers kanalının Core Web Vitals açıklama serisi, ölçüm mantığını görselleştirir.
2026 itibarıyla referans eşikleri netleşmiştir. Google’ın Mart 2026 core update’iyle birlikte LCP eşiğinin 2.5 saniyeden 2.0 saniyeye sıkılaştırıldığı raporlanmaktadır; INP için hedef 200 ms, CLS için 0.1 altıdır. INP, 2026’da sahada en sık başarısız olunan Core Web Vital haline gelmiştir; pek çok site 200 ms eşiğini geçememektedir.
3. Metrik-neden-çözüm: mobil darboğaz tanı tablosu
Bir metriğin kötü olması yeterli bilgi değildir; o metriği kök nedene bağlamak gerekir. Aşağıdaki tanı mantığı, çoğu Türkçe içerikte eksik olan metrik-neden eşlemesini sağlar ve hangi düzeltmenin hangi soruna iyi geldiğini netleştirir.
Yüksek LCP (en büyük içerik öğesinin geç boyanması) genellikle iki nedenden doğar: büyük/optimize edilmemiş hero görseli ve yavaş sunucu yanıtı (TTFB). Çözüm; görselleri WebP formatına dönüştürmek, ekran dışı görsellere lazy load uygulamak ve sunucu tarafında önbellekleme ile yanıt süresini düşürmektir. LCP görseli için preload kullanmak ilk boyamayı belirgin hızlandırır.
Kötü INP (etkileşime yanıt gecikmesi) neredeyse her zaman ağır JavaScript yürütmesinden kaynaklanır. Ana iş parçacığı uzun görevlerle tıkanınca dokunma ve tıklama geç işlenir. Çözüm; kod bölme (code splitting), kullanılmayan JS’yi kaldırma, uzun görevleri parçalara ayırarak ana iş parçacığını boşaltmadır. Yüksek CLS ise layout kaymasıdır; görsel/iframe boyutlarını önceden rezerve etmek ve font yükleme stratejisini (font-display) düzeltmek kaymayı durdurur.
Bir diğer kritik kalem render-blocking CSS/JS‘dir. Tarayıcı, kritik olmayan stil ve betikleri indirip çalıştırana kadar ilk boyamayı erteler. Kritik CSS’i satır içine almak, kritik olmayan JS’yi defer/async ile yüklemek ve kritik kaynak yönetimini doğru kurmak ilk boyamayı hızlandırır.
- Yüksek LCP → büyük görsel / yavaş TTFB → WebP, lazy load, önbellek, preload
- Kötü INP → ağır JavaScript → kod bölme, ana iş parçacığını boşaltma
- Yüksek CLS → layout kayması → boyut rezervasyonu, font stratejisi
- Geç ilk boyama → render-blocking kaynak → kritik CSS inline, defer/async
| Özellik | SEOYEN | Ahrefs |
|---|---|---|
| Türkçe arayüz | Tam Türkçe | Sınırlı / yabancı dil |
| TL bazlı fiyatlandırma | Var | Döviz bazlı |
| Site sağlığı / teknik darboğaz denetimi | Var | Var |
| Core Web Vitals takibi | Var | Kısmi |
| Sıralama takibiyle etki ölçümü | Tek platformda entegre | Ayrı modül |
| Yerel Türkçe destek | Var | Yok / sınırlı |
| Mobil odaklı raporlama | Var | Var |
4. Hangi darboğazı önce çözmeli? Etki-efor önceliklendirme çerçevesi
Sınırlı zamanla çalışan ekipler için asıl soru “ne bozuk” değil, “önce hangisini düzeltmeliyim”dir. Bunun için her düzeltmeyi iki eksene yerleştiren bir etki-efor matrisi kullanın: dikey eksen metrik kazancı (etki), yatay eksen geliştirme maliyeti (efor). Sağ üst ile sol üst dörtlüğü önceliklendirir.
En değerli grup düşük efor-yüksek etki hızlı kazanımlardır. Önbellekleme, gzip/Brotli sıkıştırma ve CDN kullanımı çoğunlukla saatler içinde uygulanır ama TTFB ve aktarım süresinde büyük iyileşme sağlar. Görselleri WebP’ye toplu dönüştürmek de bu gruba girer. Ağır mimari refaktörler (örneğin tüm JS’in yeniden yazılması) yüksek efor olduğundan sıraya konur.
Kalıcı başarı için bir mobil performans bütçesi belirleyin: örneğin toplam JS boyutu için bir üst sınır, LCP için 2.0s hedefi. Ardından her dağıtımda bu bütçenin aşılıp aşılmadığını izleyerek regresyonu önleyin. Türk e-ticaret sitelerinde sık görülen öncelik sırası genelde şudur: önce hero görseli (LCP), sonra üçüncü taraf script yükü (INP), ardından layout rezervasyonu (CLS).
- Hızlı kazanım: önbellek, gzip/Brotli, CDN, WebP dönüşümü
- Planlı iş: kod bölme, üçüncü taraf script temizliği
- Sıraya al: kapsamlı mimari yeniden yazımlar
5. Saha günlüğü: bir Türk e-ticaret sitesinde önce/sonra darboğaz ölçümü
Teoriyi gerçek bir örnekle test ettik. Orta ölçekli bir Türk e-ticaret sitesinde, ürün listeleme sayfasının mobil PSI raporu başlangıçta LCP tarafında zayıf, INP tarafında “iyileştirme gerekli” durumundaydı; Search Console Core Web Vitals raporu da aynı URL grubunu “kötü” olarak işaretliyordu. Lab ve saha verisinin aynı yöne işaret etmesi, sorunun tutarlı olduğunu doğruladı.
Önceliklendirmeyi uygulayarak önce LCP görselini ele aldık: hero görselini WebP’ye çevirip preload ekledik ve ürün kartı görsellerine lazy load uyguladık. Bu tek adım, lab LCP değerini gözle görülür şekilde aşağı çekti. Ardından INP için sayfaya geç değer katan üçüncü taraf script’lerini ertelemeye aldık ve filtre bileşeninin JS’ini böldük; etkileşim gecikmesi hissedilir biçimde azaldı.
Asıl önemli olan iş sonucuydu. Saha verisi birkaç hafta içinde “kötü” gruptan “iyi” tarafına geçtikçe, ilgili ürün sayfalarında organik tıklamalar artış eğilimine girdi ve mobil dönüşüm oranında olumlu hareket gözlemledik. Çıkarılan ders nettir: her şeyi aynı anda düzeltmeye çalışmak yerine en yüksek etkili tek darboğazı izole edip ölçmek, kaynakları en verimli kullanma yoludur. Bu tür ham önce/sonra verisi, jenerik içeriğin sunamayacağı somut kanıttır.
6. Mobil darboğaz takibini SEOYEN ile sürdürülebilir kılmak
Darboğazı bir kez çözmek yetmez; her yeni dağıtım yeni darboğaz getirebilir. Bu yüzden tespiti tek seferlik bir proje değil, sürekli bir döngü olarak kurmak gerekir. SEOYEN‘in site sağlığı denetimi aracı, teknik darboğazları düzenli olarak tarar ve raporlar; böylece performans bütçenizden sapan sayfaları erken yakalarsınız.
Düzeltmelerin işe yarayıp yaramadığını görmek için sonucu sıralamayla ilişkilendirmek gerekir. Sıralama takibi aracıyla, darboğaz düzeltmelerinden sonra hedef anahtar kelimelerin nasıl hareket ettiğini izleyebilir; teknik kazanımı görünürlük kazancına bağlayabilirsiniz. SEOYEN’in tüm bu araçları tek platformda toplaması, ayrı ayrı aboneliklerle uğraşmayı ortadan kaldırır.
Yabancı platformlarla kıyaslandığında yerel avantaj belirleyicidir. Ahrefs ve SEMrush güçlü teknik denetim sunar; SEOYEN ise aynı yetenekleri Türkiye pazarına uyarlanmış biçimde, Türkçe arayüz, TL bazlı şeffaf fiyatlandırma ve yerel Türkçe destek ile sağlar. Araçların ayrıntılı kıyası için SEOYEN ile Ahrefs karşılaştırması sayfasına, paket detayları için güncel fiyatlandırma sayfasına göz atabilirsiniz. Özellikle yerel ekipler için raporları Türkçe paydaşlarla paylaşmak, çeviri yükünü ortadan kaldırır.
Kaynaklar
Sıkça Sorulan Sorular
Mobil darboğaz. mobil kullanıcı deneyimini bozan hız, bellek, pil ve ağ kaynaklı teknik engellerin tümüdür. Sayfanın yavaş yüklenmesine veya bir tıklamaya geç tepki vermesine yol açar. Tıpkı bir borunun en dar noktasının akışı sınırlaması gibi, sistemdeki en zayıf bileşen tüm deneyimi yavaşlatır. Mobil cihazların sınırlı işlemci gücü ve değişken ağ koşulları bu darboğazları masaüstüne göre daha belirgin hale getirir. bu da doğrudan sıralama ve dönüşüm kaybına dönüşebilir.
Önce PageSpeed Insights ile sayfayı mobil modda tarayarak hangi metriğin (LCP, INP, CLS) eşiği geçemediğini görün. Ardından Search Console Core Web Vitals raporundaki gerçek kullanıcı (saha) verisiyle bu sonucu doğrulayın. lab ve saha çeliştiğinde saha verisi önceliklidir. Daha derin analiz için Chrome DevTools'un Performance sekmesini ve Google'ın yeni CrUX Vis aracını kullanabilirsiniz. Bu araçlar birlikte hangi darboğazın gerçekten kullanıcıyı etkilediğini gösterir.
LCP için en büyük içerik öğesini hızlandırın: hero görselini WebP'ye çevirin, preload ekleyin, ekran dışı görsellere lazy load uygulayın ve sunucu yanıt süresini (TTFB) önbellekleme ile düşürün. INP için ana iş parçacığını boşaltmaya odaklanın: ağır JavaScript'i kod bölme ile parçalayın, kullanılmayan betikleri kaldırın ve üçüncü taraf script'lerini erteleyin. 2026 referans eşikleri LCP için 2.0 saniye, INP için 200 milisaniyedir. düzeltmelerden sonra mutlaka yeniden ölçerek kazancı doğrulayın.
Render-blocking JavaScript, tarayıcının betikleri indirip çalıştırana kadar ilk boyamayı ertelemesine neden olur. Çözüm için kritik olmayan betikleri defer veya async ile yükleyin, böylece sayfa içeriği beklemeden boyanır. Büyük paketleri kod bölme ile parçalara ayırın ve sadece o sayfada gereken JavaScript'i yükleyin. Kritik CSS'i satır içine alıp gerisini erteleyerek kritik render yolunu kısaltın. Bu adımlar ilk içerik boyamasını ve LCP'yi belirgin biçimde hızlandırır.
Mobil cihazlar masaüstüne kıyasla sınırlı işlemci gücüne, daha az belleğe ve değişken ağ koşullarına sahiptir. Aynı JavaScript kodu masaüstünde milisaniyelerde çalışırken mobilde kat kat uzun sürebilir. benzer şekilde hücresel ağ, kararlı bir geniş bant bağlantısından çok daha yavaş ve dengesizdir. Bu nedenle masaüstünde sorunsuz görünen bir sayfa mobilde ciddi darboğaz yaşayabilir. Mobile-first index nedeniyle Google sıralamayı mobil sürüme göre belirlediğinden, mobil için ayrı ölçüm ve ayrı optimizasyon şarttır.
Core Web Vitals 2021'den beri Google'ın resmi sıralama faktörüdür ve değerlendirme gerçek kullanıcı saha verisine dayanır. Eşik altında kalan metrikler, mobile-first index'te sayfanızın görünürlüğünü zayıflatır ve rakiplerin gerisinde kalmanıza yol açar. 2026 itibarıyla eşiklerin sıkılaşması (örneğin LCP'nin 2.0 saniyeye çekilmesi) bu baskıyı artırmıştır. Kötü Core Web Vitals yalnızca sıralamayı değil, yavaş sayfayı terk eden kullanıcılar nedeniyle dönüşüm oranını da düşürür. iki etki birleşince trafik kaybı belirginleşir.
TTFB (ilk bayta kadar geçen süre), tarayıcının sunucudan ilk yanıtı almasının ne kadar sürdüğünü ölçer ve yüksek olması LCP'yi doğrudan baskılar. Azaltmak için sayfa önbelleğini etkinleştirin, böylece her istekte sunucu sıfırdan üretim yapmasın. Gzip veya Brotli sıkıştırmasıyla aktarılan veriyi küçültün ve içeriği kullanıcıya yakın sunan bir CDN kullanın. Hosting tarafında veritabanı sorgularını optimize etmek ve yeterli kaynak ayırmak da yanıt süresini düşürür. bu hızlı kazanımlar düşük eforla yüksek etki sağlar.
Mobil web için temel araçlar PageSpeed Insights (lab + sınırlı saha verisi), Search Console Core Web Vitals raporu (saha verisi), Chrome DevTools (derin analiz) ve Google'ın yeni CrUX Vis aracıdır. Mobil uygulama tarafında bellek ve pil darboğazları için Android Profiler kullanılır. Bu araçlar tek seferlik ölçüm sunar. düzenli takip için SEOYEN'in site sağlığı aracı teknik darboğazları periyodik tarar ve sıralama takibiyle düzeltmelerin etkisini izlemenizi sağlar, böylece regresyonları erken yakalarsınız.