Mobil Hız Optimizasyonu

Sitenizi masaüstünde açtığınızda bir saniyede yükleniyor, telefonda ise yedi saniye sürüyor olabilir; üstelik ikisi de aynı sunucudan, aynı dosyalarla geliyordur. Bu fark bir hata değildir — mobil cihazın işlemcisi daha yavaş, ağı daha değişken, RAM'i daha kısıtlıdır ve tarayıcı arka planda pil tasarrufu yapmaktadır. Mobil hız optimizasyonu, aynı sayfayı bu üç kısıtın altında da hızlı tutma işidir.

Bu iş neden bu kadar önemli? Çünkü Türkiye'de çoğu sitenin trafiğinin yarıdan fazlası mobilden gelir ve Google sıralama sinyallerini mobil sürüm üzerinden hesaplar. Yani masaüstünde ne kadar hızlı olduğunuzun arama sonuçlarına neredeyse hiç etkisi yoktur. Bu rehberde mobil yavaşlığın gerçek sebeplerini, ölçümü doğru yapmayı, görsel-JavaScript-yazı tipi üçlüsünde en büyük kazancı nereden alacağınızı ve mobile özgü klasik tuzakları anlatacağım.

Mobil Neden Masaüstünden Yavaş#

Üç ayrı sebep aynı anda çalışır ve hangisinin baskın olduğunu bilmeden yapacağınız optimizasyon büyük olasılıkla yanlış yere gider.

CPU farkı. Orta segment bir Android telefonun tek çekirdek performansı, ortalama bir dizüstü bilgisayarın kabaca dörtte biri ile altıda biri arasındadır. Bu, JavaScript ayrıştırma ve çalıştırma süresinin doğrudan 4-6 katına çıkması demektir. Masaüstünde 200 ms'de çalışan bir paket, telefonda bir saniyeyi aşabilir ve bu süre boyunca sayfa dokunmalara cevap vermez.

Ağ farkı. Mobil bağlantı sadece daha yavaş değil, daha değişkendir. Gecikme (latency) hücresel ağda 50-150 ms bandındadır ve her yeni TCP+TLS el sıkışması bu gecikmeyi yeniden ödetir. Bu yüzden mobilde "kaç bayt indirdiğim" kadar "kaç ayrı bağlantı açtığım" da önemlidir.

Bellek ve termal kısıtlar. Telefon ısındığında işlemci hızını düşürür. Ağır bir sayfa açıldıktan sonraki kaydırma takılmalarının bir kısmı budur. Ayrıca tarayıcı, bellek baskısı altında arka plan sekmelerini boşaltır; kullanıcı geri döndüğünde sayfa baştan yüklenir.

Bu tablodan çıkan tek cümlelik strateji şudur: mobil için optimizasyon, öncelikle JavaScript'i azaltmak ve doğru boyutta görsel göndermektir. Diğer her şey ikinci sıradadır.

Gerçek Cihazda ve Gerçek Ağda Ölçmek#

Kendi telefonunuzda, ofis Wi-Fi'ında, sayfa tarayıcı önbelleğindeyken yaptığınız test size hiçbir şey söylemez. Doğru ölçüm için üç yöntem vardır ve üçünü birlikte kullanmalısınız.

Chrome DevTools ile kısıtlama. Masaüstü tarayıcıda mobil koşulları benzetin: DevTools açın, Performance sekmesinde CPU'yu 4x slowdown ya da 6x slowdown yapın, Network kısmında Slow 4G seçin ve sayfayı önbelleksiz yenileyin. Bu, gerçeğe en yakın hızlı benzetimdir.

Gerçek cihazda uzaktan hata ayıklama. Android telefonu USB ile bağlayıp geliştirici seçeneklerinden USB hata ayıklamayı açın, masaüstü Chrome'da chrome://inspect adresine gidin. Artık telefonda açtığınız sayfayı bilgisayardaki DevTools ile inceleyebilirsiniz. Benzetim değil, gerçek ölçümdür ve aradaki fark genellikle şaşırtıcıdır.

Saha verisi (RUM). Gerçek ziyaretçilerinizin gerçek cihazlarından toplanan veridir; sıralamaya giren de budur. Google Search Console'daki Core Web Vitals raporu bunu ücretsiz sunar. Kendi ölçümünüzü tarayıcıya gömmek isterseniz basit bir başlangıç:

<script type="module">
  // Tarayıcının yerel LCP ölçümünü kendi uç noktanıza gönder
  new PerformanceObserver((liste) => {
    const girdiler = liste.getEntries();
    const sonuncu = girdiler[girdiler.length - 1];
    navigator.sendBeacon('/olcum', JSON.stringify({
      metrik: 'LCP',
      deger: Math.round(sonuncu.startTime),
      yol: location.pathname,
      baglanti: navigator.connection ? navigator.connection.effectiveType : 'bilinmiyor'
    }));
  }).observe({ type: 'largest-contentful-paint', buffered: true });
</script>

navigator.connection.effectiveType değerini kaydetmek çok işe yarar: LCP'nizin kötü olduğu kullanıcıların hepsi 3g bağlantıdaysa sorun sunucunuzda değil, gönderdiğiniz bayt miktarındadır.

Ölçümü tekrarlanabilir kılmak için bir de komut satırından hızlı bir mobil raporu alın:

# Lighthouse varsayılan olarak mobil benzetimi yapar
lighthouse https://firmaniz.com/ --only-categories=performance --view

# Yalnızca sunucu tarafını (TTFB) mobil bağımsız ölçmek için
curl -s -o /dev/null -w "ttfb: %{time_starttransfer}s | toplam: %{time_total}s\n" https://firmaniz.com/

TTFB'niz zaten 800 ms ise mobil optimizasyonun ön yüz kısmıyla uğraşmadan önce sunucu tarafını çözmelisiniz; bu, LCP iyileştirme yazısında ayrıntılı ele aldığım bir konu.

Görseller: En Büyük ve En Kolay Kazanç#

Mobil sayfalarda indirilen baytın çoğunluğu görsellerdir ve bunun büyük bölümü israftır. 360 piksel genişliğindeki bir ekrana 1920 piksel genişliğinde bir görsel göndermek, kullanıcının o baytların yaklaşık %96'sını hiç görmemesi demektir.

Çözüm duyarlı görsel (responsive image) sözdizimidir. Tarayıcıya birkaç boyut sunarsınız, o kendi ekran genişliğine ve piksel yoğunluğuna göre en uygunu seçer:

<img
  src="/gorsel/urun-800.webp"
  srcset="/gorsel/urun-400.webp 400w,
          /gorsel/urun-800.webp 800w,
          /gorsel/urun-1600.webp 1600w"
  sizes="(max-width: 640px) 100vw, 50vw"
  width="800" height="600"
  alt="Ürün görseli"
  loading="lazy" decoding="async">

Üç ayrıntı burada kritiktir. sizes özniteliği tarayıcıya görselin sayfada ne kadar yer kaplayacağını söyler; yazmazsanız tarayıcı en büyük dosyayı indirir ve tüm çabanız boşa gider. width ve height öznitelikleri yer ayırarak düzen kaymasını önler — bu konuyu CLS düzen kayması yazısında ayrıntılandırdım. loading="lazy" ise ilk ekranın dışındaki görselleri erteler; ilk ekrandaki LCP görseline asla eklemeyin, çünkü onu geciktirmiş olursunuz.

Formata gelince: modern formatlar aynı görsel kalitesinde ciddi tasarruf sağlar.

Dönüştürme işini sunucuda toplu yapabilirsiniz:

# Toplu WebP dönüşümü (kalite 82 çoğu fotoğraf için yeterli)
find ./gorseller -name "*.jpg" -exec cwebp -q 82 {} -o {}.webp \;

# Duyarlı boyutları üretmek
for boyut in 400 800 1600; do
  convert kaynak.jpg -resize ${boyut}x -quality 82 urun-${boyut}.webp
done

En sık atlanan nokta: LCP görselini önceden bildirmek. İlk ekranda büyük bir görsel varsa tarayıcının onu keşfetmek için CSS'i beklemesini engelleyin:

<link rel="preload" as="image" href="/gorsel/hero-800.webp"
      imagesrcset="/gorsel/hero-400.webp 400w, /gorsel/hero-800.webp 800w" imagesizes="100vw">

JavaScript ve Ana İş Parçacığı#

Mobilde en pahalı kaynak baytlar değil, CPU saniyeleridir. İndirilen JavaScript ayrıştırılır, derlenir ve çalıştırılır; bu süre boyunca ana iş parçacığı meşguldür ve kullanıcının dokunuşları yanıtsız kalır. 300 KB JavaScript orta segment bir telefonda kolayca bir saniyelik kilitlenme üretir.

Üç adımlı bir yaklaşım en iyi sonucu verir. Birincisi kaldırmak: kullanılmayan kütüphaneleri çıkarın, jQuery gibi bağımlılıkları modern tarayıcı API'leriyle değiştirin, aynı işi yapan iki eklentiden birini silin. İkincisi bölmek: sayfa başına yalnızca o sayfanın ihtiyacı olan kodu gönderin. Üçüncüsü ertelemek: kritik olmayan her betiği ilk yükleme yarışının dışına çıkarın.

<script src="/js/uygulama.js" defer></script>
<script src="https://analitik.example.com/kod.js" async></script>

Birinci satırdaki defer, kendi kodunuz gibi sıraya bağımlı betikler içindir; ikinci satırdaki async ise sırası önemsiz, tamamen bağımsız üçüncü parti takip kodları içindir.

defer ile async arasındaki fark önemlidir: defer betikleri belge sırasına göre, HTML ayrıştırıldıktan sonra çalıştırır; async ise indiği anda, sırasız çalıştırır. Birbirine bağlı betiklerde defer, tamamen bağımsız takip kodlarında async doğru tercihtir. Hiçbiri yoksa betik ayrıştırmayı durdurur ve mobilde en pahalı hatayı yapmış olursunuz.

Üçüncü parti betikler mobil performansın en büyük tek düşmanıdır çünkü hem CPU tüketirler hem de kontrol edemediğiniz sunuculardan gelirler. Her birini şu üç soruyla sınayın: bu betik olmadan site çalışır mı, ilk ekranda gerçekten gerekli mi, aynı işi yapan daha hafif bir alternatifi var mı. Sınırları kalıcı kılmak için performans bütçesi belirleme yazısındaki yöntemi kullanın.

Yazı Tipleri, Kritik CSS ve Ağ Katmanı#

Web yazı tipleri mobilde iki ayrı soruna yol açar: indirme süresi ve metnin görünmez kaldığı boşluk. Çözüm birkaç satırlık bir disiplindir.

@font-face {
  font-family: 'GovdeYazisi';
  src: url('/font/govde.woff2') format('woff2');
  font-weight: 400;
  font-display: swap;      /* metin hemen görünsün, tipi sonra değişsin */
  unicode-range: U+0000-00FF, U+0100-017F;  /* Türkçe karakterleri kapsa */
}

font-display: swap olmadan tarayıcı yazı tipi inene kadar metni gizler ve kullanıcı boş bir sayfaya bakar. unicode-range ile alt küme (subset) kullanmak dosya boyutunu ciddi biçimde düşürür — Türkçe için Latin ve Latin Extended-A aralıkları yeterlidir, Kiril veya Yunan karakter setlerini taşımanıza gerek yoktur. Ayrıca kural olarak en fazla iki aile ve aile başına en fazla iki ağırlık kullanın; her ek ağırlık ayrı bir dosya indirmesidir.

CSS tarafında hedef, ilk ekranı çizmek için gereken kuralları HTML içine gömmek ve gerisini ertelemektir. Ağ tarafında ise şu üç ayar mobilde belirgin fark yaratır:

# HTTP/2 ile çoklu istek tek bağlantıda taşınır (mobil gecikmeyi gizler)
listen 443 ssl;
http2 on;

# Brotli varsa metin dosyalarında gzip'ten daha iyi sıkıştırır
brotli on;
brotli_comp_level 5;
brotli_types text/plain text/css application/javascript application/json image/svg+xml;

# Statik varlıklar uzun süre önbelleklensin (dosya adı hash'li olmalı)
location ~* \.(css|js|woff2|webp|avif|jpg|png|svg)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
}

Ziyaretçileriniz coğrafi olarak dağınıksa bir CDN katmanı gecikmeyi doğrudan düşürür; CDN'in ne zaman gerçekten fark yarattığını CDN mi daha iyi hosting mi yazısında karşılaştırdım. Statik dosya önbelleği ve sıkıştırmayı paylaşımlı hostingde yapılandırmak için htaccess önbellek ve sıkıştırma yazısındaki kurallar doğrudan kullanılabilir.

Mobile Özgü Tuzaklar ve Sık Yapılan Hatalar#

Ayrı mobil site (m.firmaniz.com) tutmak. Bir zamanlar standarttı, bugün bakım yükü ve SEO karmaşası getiren bir yaklaşımdır. Duyarlı (responsive) tek bir site, iki ayrı kod tabanından hem daha hızlı hem daha ucuzdur.

Masaüstü HTML'ini gönderip CSS ile gizlemek. display: none ile gizlenen bir bölüm indirilmemiş olmaz; içindeki görseller ve betikler yine yüklenir. Mobilde göstermeyeceğiniz ağır bileşenleri sunucu tarafında hiç üretmeyin ya da JavaScript ile koşullu yükleyin.

Viewport meta etiketini unutmak. Bu etiket olmadan mobil tarayıcı sayfayı 980 piksel genişliğinde varsayar ve küçültür; kullanıcı yakınlaştırmak zorunda kalır.

<meta name="viewport" content="width=device-width, initial-scale=1">

maximum-scale=1 ya da user-scalable=no eklemeyin: yakınlaştırmayı engellemek erişilebilirliği bozar ve çoğu tarayıcı zaten bunu yok sayar.

Dokunma hedeflerini küçük bırakmak. Bu bir hız sorunu gibi görünmez ama kullanıcı yanlış düğmeye basıp geri dönerse, ölçtüğünüz hızın hiçbir anlamı kalmaz. Dokunulabilir öğeler en az 44×44 piksel olmalı ve aralarında boşluk bulunmalıdır.

Kaydırmayı engelleyen katmanlar. Sayfa yüklendikten hemen sonra açılan tam ekran bülten formları ve çerez katmanları mobilde ekranın tamamını kaplar. Google bunları "araya giren geçiş reklamı" olarak değerlendirir; ayrıca genellikle geç yüklendikleri için düzen kaymasına da yol açarlar.

Otomatik oynatılan videolar. Mobil veride pahalı, CPU'da pahalı, pilde pahalıdır. Gerekiyorsa preload="none" ve bir poster görseliyle kullanın, kullanıcı isterse oynasın.

Yalnızca ana sayfayı optimize etmek. Mobil ziyaretçilerin çoğu arama sonucundan doğrudan bir iç sayfaya girer. En çok giriş alan beş sayfayı ayrı ayrı ölçün; ana sayfanız hızlı olsa bile ürün detay sayfanız üç kat ağır olabilir.

Sıkça Sorulan Sorular#

Mobil hız testini hangi araçla yapmalıyım#

Tek bir araca güvenmeyin, üçünü birlikte kullanın. PageSpeed Insights hem laboratuvar hem saha verisini bir arada gösterdiği için başlangıç noktası olarak en iyisidir. Chrome DevTools'un CPU ve ağ kısıtlaması, değişikliklerinizi hızlıca denemenizi sağlar. Gerçek bir Android telefonu USB ile bağlayıp uzaktan hata ayıklama yapmak ise benzetimin gizlediği sorunları ortaya çıkarır. Karar verirken Search Console'daki saha verisine öncelik verin; sıralamaya giren odur.

Mobilde hangi metrik en önemli#

Çoğu site için LCP, yani en büyük içerik öğesinin ne kadar sürede göründüğü. Kullanıcının "site yüklendi mi" algısını doğrudan bu belirler ve mobilde en çok bozulan metrik de budur. Hemen ardından INP (etkileşim gecikmesi) gelir; mobilde CPU zayıf olduğu için ağır JavaScript en çok burada acıtır. CLS ise genellikle en kolay düzeltilenidir: görsellere ve reklam alanlarına boyut vermek çoğu vakayı çözer.

Görselleri WebP'ye çevirmek gerçekten fark yaratır mı#

Evet ve genellikle tek başına en büyük kazançtır. Aynı görsel kalitesinde WebP, JPEG'e göre kabaca dörtte bir ila üçte bir daha küçük dosya üretir; AVIF daha da ileri gider. Ama asıl kazanç formatta değil, doğru boyutta servis etmektedir: 360 piksellik ekrana 1600 piksellik görsel göndermeyi bırakmak, format değişiminden daha fazla bayt kazandırır. İkisini birlikte yapın.

AMP kullanmam gerekir mi#

Bugün için hayır. AMP'in bir zamanlar sağladığı arama sonuçlarındaki ayrıcalıklı konum kaldırıldı ve iyi optimize edilmiş normal bir sayfa aynı hız sonuçlarına ulaşabiliyor. Ayrı bir AMP sürümü bakımı iki katına çıkarır ve tasarım özgürlüğünü kısıtlar. Konuyu ayrıntılı değerlendirmek isterseniz AMP hâlâ gerekli mi yazısına bakın.

Sunucumun mobil hıza etkisi ne kadar#

Doğrudan ve sınırlı bir etkisi vardır: sunucu, ilk bayt süresini (TTFB) belirler ve bu süre LCP'nin içine dahildir. TTFB'niz 200 ms ise sunucunuz sorun değildir ve kazancı ön yüzde aramalısınız. 800 ms üstündeyse hiçbir görsel optimizasyonu 2.5 saniyelik LCP hedefini kurtaramaz; önce sunucu tarafını, tam sayfa önbelleğini ve veritabanı sorgularını çözün. Kabaca kural: TTFB toplam LCP bütçenizin dörtte birini geçmemeli.

Eklentileri silmek sitemi gerçekten hızlandırır mı#

Genellikle evet, ama silme kararını sayıya göre değil etkiye göre verin. Bir eklentinin sayfaya kaç KB CSS/JS eklediğini DevTools'un Coverage sekmesinden ya da ağ isteklerini kaynak alan adına göre gruplayarak görebilirsiniz. On hafif eklenti, sayfaya 200 KB JavaScript enjekte eden tek bir sayfa oluşturucudan daha zararsızdır. Önce en ağır üçünü ölçün, alternatiflerini değerlendirin; toptan silmek yerine tek tek ölçüp karar vermek daha az risklidir.

Kapanış#

Mobil hız optimizasyonu, aslında az sayıda kararın disiplinli biçimde uygulanmasıdır. Aklınızda kalacak dört alışkanlık: gerçek cihazda ve kısıtlı ağda ölçün, ekrana uygun boyutta ve modern formatta görsel gönderin, JavaScript'i kaldırın-bölün-erteleyin ve ilk ekranı çizmek için gereken her şeyi diğer her şeyin önüne alın. Değişikliklerinizi tek tek yapıp her seferinde yeniden ölçün; toplu değişiklik hangisinin işe yaradığını gizler.

Ön yüz tarafını toparladıktan sonra sıra sunucuya gelir; TTFB'yi düşük tutmak mobil LCP hedefinizin yarısıdır. NVMe diskli web hosting ve WordPress hosting paketlerimiz hazır önbellek yapılandırmasıyla gelir, daha fazla kontrol isterseniz VDS üzerinde Brotli, HTTP/2 ve tam sayfa önbelleğini kendi ölçülerinize göre kurabilirsiniz. Ölçüm ve ayar tarafını bize bırakmak isterseniz sunucu yönetimi hizmetimiz bu işi üstlenir.