Site Hızı ve Core Web Vitals: Ölçüm ve İyileştirme Rehberi

Site hızı, arama sıralamasından çok daha fazlasını etkiler: yavaş açılan bir sayfada kullanıcı, ürünü görmeden geri döner. Bu rehber Core Web Vitals ölçülerinin ne anlama geldiğini, hangi aracın neyi ölçtüğünü, Türkiye’deki mobil şebeke gerçeğinde nelerin önemli olduğunu ve WordPress ile e-ticaret sitelerinde hangi müdahalenin ne kadar kazandırdığını anlatıyor.

Site hızı neden önemli?

Site hızının iki ayrı etkisi vardır ve bunları karıştırmamak gerekir.

Birincisi sıralama etkisi. Google, sayfa deneyimini bir sıralama sinyali olarak kullanır. Ancak bu sinyal, içerik kalitesi ve alaka kadar güçlü değildir. Yavaş ama konuyu en iyi anlatan sayfa, hızlı ama yüzeysel sayfanın önünde kalmaya devam eder. Site hızı, diğer her şey eşitken fark yaratan bir ayırıcıdır.

İkincisi dönüşüm etkisi ve asıl önemli olan budur. Sayfa açılmasını bekleyen kullanıcı geri döner. Reklam bütçesiyle getirdiğiniz her tıklama için para ödersiniz; sayfa geç açıldığında o parayı sayfa açılmadan kaybedersiniz. Yani hız çalışması SEO’dan bağımsız olarak, doğrudan reklam verimliliği kalemidir.

Türkiye’de bu konunun arandığını rakamla görmek gerekirse: “site hız testi” ayda ortalama 1.300, “site hızı” 720, “core web vitals” 320 kez aranıyor (Google Keyword Planner, Ağustos 2026).

Core Web Vitals: üç ölçü

Google, sayfa deneyimini üç ölçüyle takip eder. Her biri kullanıcının hissettiği farklı bir yavaşlığı temsil eder:

• LCP (Largest Contentful Paint): Sayfanın en büyük görsel ögesinin ekranda belirmesi. “Sayfa açıldı mı?” sorusunun cevabı.
• INP (Interaction to Next Paint): Kullanıcı bir şeye dokunduğunda ekranın yanıt vermesi. “Sayfa çalışıyor mu?” sorusunun cevabı.
• CLS (Cumulative Layout Shift): Sayfa yüklenirken içeriğin zıplaması. “Sayfa oturdu mu?” sorusunun cevabı.

Google’ın yayınladığı eşikler şöyle: LCP için 2,5 saniyenin altı iyi, 4 saniyenin üstü kötü. INP için 200 milisaniyenin altı iyi, 500 milisaniyenin üstü kötü. CLS için 0,1’in altı iyi, 0,25’in üstü kötü. Bir sayfanın “iyi” sayılması için kullanıcıların yüzde 75’inde bu eşiklerin altında kalması gerekir.

LCP: en büyük içeriğin yüklenme süresi

LCP, çoğu sitede en çok sorun çıkaran ölçüdür. Ölçülen öge genelde kahraman görseli, ürün fotoğrafı veya büyük bir başlık metnidir.

LCP’yi bozan tipik nedenler

• Devasa görsel dosyaları. 3.000 piksel genişliğinde, 2 MB’lık bir fotoğrafın mobilde 400 piksellik alanda gösterilmesi, en yaygın hatadır.
• Görselin geç keşfedilmesi. Görsel CSS arka planı olarak veya JavaScript ile yükleniyorsa, tarayıcı onu geç fark eder.
• Kahraman görselinde tembel yükleme. `loading=”lazy”` ilk ekranda görünen görsele uygulanırsa LCP’yi doğrudan geciktirir. Tembel yükleme yalnızca ilk ekranın altındaki görsellere uygulanmalıdır.
• Yavaş sunucu yanıtı. Sayfanın ilk baytı geç geliyorsa geri kalan her şey gecikir.
• Render’ı engelleyen kaynaklar. Head bölümünde bekleyen büyük CSS ve senkron JavaScript dosyaları.

Ne yapmalı

• Görselleri modern formatlarda (WebP veya AVIF) ve gerçekten gösterilecek boyutta sunun.
• Duyarlı görsel kullanın: farklı ekran boyutları için farklı dosyalar tanımlayın.
• Kahraman görseline yüksek öncelik verin, tembel yüklemeyi kapatın.
• Kritik CSS’i satır içine alın, geri kalanını ertelemeli yükleyin.
• CDN kullanın; kullanıcıya coğrafi olarak yakın sunucudan servis, gecikmeyi belirgin şekilde azaltır.

INP: etkileşime yanıt süresi

INP, eski FID ölçüsünün yerini aldı ve daha zorlu bir ölçüdür: sayfanın ömrü boyunca yapılan tüm etkileşimlere verilen yanıtın en kötülerini dikkate alır. Yani menüye tıkladığınızda, filtre uyguladığınızda veya sepete eklediğinizde yaşanan takılma buraya yansır.

INP’yi bozan nedenler

• Ana iş parçacığını kilitleyen uzun JavaScript görevleri. Tarayıcı hesap yaparken kullanıcının dokunuşuna cevap veremez.
• Ağır olay dinleyicileri. Her kaydırmada veya her tuşta karmaşık işlem yapan kodlar.
• Aşırı büyük DOM. On binlerce ögesi olan sayfalarda her değişiklik pahalıya mal olur.
• Üçüncü taraf betikleri. Isı haritası, sohbet balonu, reklam betikleri INP’nin en yaygın sebebidir.

Ne yapmalı

• Uzun görevleri parçalayın, gerekmeyen hesaplamayı erteleyin.
• Kullanılmayan JavaScript’i kaldırın. Çoğu sitede yüklenen kodun büyük bölümü hiç çalışmaz.
• Üçüncü taraf betiklerini geciktirin: sohbet balonunu ilk etkileşimden sonra, ısı haritasını yalnızca belirli sayfalarda yükleyin.
• Filtre ve arama gibi ağır etkileşimlerde sunucu tarafı işlemeyi değerlendirin.

CLS: görsel kayma

CLS, kullanıcının okuduğu metnin veya basmak üzere olduğu düğmenin son anda yer değiştirmesidir. Rahatsız edici olduğu kadar iş de kaybettirir: yanlışlıkla başka düğmeye basan kullanıcı geri döner.

Nedenleri ve çözümleri

• Boyutu belirtilmemiş görseller. Genişlik ve yükseklik özniteliklerini yazın; tarayıcı yer ayırır.
• Sonradan yüklenen reklam ve gömülü içerikler. Kapsayıcıya sabit bir yükseklik verin.
• Yazı tipi değişimi. Yedek font ile asıl font arasındaki boyut farkı metni kaydırır. Font yükleme stratejisini ayarlayın.
• Sonradan görünen çerez bandı veya duyuru çubuğu. Sayfanın üstüne itilen bir bant, tüm içeriği aşağı kaydırır. Sabitlenmiş konumda kullanın.
• Animasyonlu içerik. Yükseklik değiştiren geçişler yerine dönüşüm (transform) kullanın.

Saha verisi ve laboratuvar verisi farkı

Hız ölçümünde en çok kafa karıştıran konu budur ve doğru anlaşılmadığında ekipler haftalarca yanlış şeyle uğraşır.

• Saha verisi (gerçek kullanıcı verisi): Sitenizi gerçekten ziyaret eden kullanıcıların cihazlarından toplanır. Google’ın Chrome kullanıcı deneyimi raporu bu veriyi 28 günlük pencerede toplar. Search Console’daki Core Web Vitals raporu ve PageSpeed Insights’ın üst kısmı bunu gösterir. Sıralamada kullanılan veri budur.
• Laboratuvar verisi: Belirli bir cihaz ve bağlantı simülasyonuyla yapılan tek seferlik test. Lighthouse skoru buradan gelir. Tekrarlanabilir ve hata ayıklamak için mükemmeldir, ama gerçek kullanıcıyı temsil etmez.

Pratik sonuç: Lighthouse skoru 100 olan bir sitenin saha verisi kötü olabilir ve bunun tersi de doğrudur. Karar verirken saha verisine, hata ayıklarken laboratuvar verisine bakın. Ayrıca saha verisi 28 günlük pencereyle çalıştığı için, bugün yaptığınız iyileştirme raporda haftalar sonra görünür; hemen sonuç göremediniz diye değişikliği geri almayın.

Hangi araç neyi ölçer?

• PageSpeed Insights: Hem saha hem laboratuvar verisini tek ekranda gösterir. Başlangıç noktası olarak en pratik araçtır.
• Search Console Core Web Vitals raporu: Sitenin tamamını URL grupları halinde gösterir. Hangi şablonun sorunlu olduğunu bulmanın en hızlı yolu budur.
• Lighthouse (Chrome geliştirici araçları): Ayrıntılı laboratuvar analizi ve öneriler.
• WebPageTest: Farklı konum, cihaz ve bağlantı hızlarıyla test. Şelale grafiği, hangi kaynağın neyi beklettiğini gösterir.
• Chrome geliştirici araçları Performance sekmesi: INP sorunlarını bulmak için en güçlü araç.

Test ederken iki kural: mobil profille test edin (Türkiye’de organik trafiğin çoğunluğu mobil) ve aynı sayfayı birkaç kez ölçün, tek ölçüm gürültü içerir.

Görseller: en büyük kazanç kalemi

Çoğu sitede sayfa ağırlığının büyük bölümü görsellerden gelir ve buradaki iyileştirme en hızlı sonucu verir.

• Doğru format: WebP çoğu durumda JPEG’e göre belirgin kazanç sağlar. AVIF daha da iyidir ancak üretim maliyeti yüksektir. Şeffaflık gerekmiyorsa PNG kullanmayın.
• Doğru boyut: Görseli, ekranda kaplayacağı en büyük alandan büyük üretmeyin. Retina ekranlar için iki katı yeterlidir.
• Duyarlı görseller: Mobil kullanıcıya masaüstü görselini göndermeyin.
• Tembel yükleme: İlk ekranın altındaki tüm görsellerde açık, kahraman görselinde kapalı.
• Sıkıştırma: Kalite ayarını körü körüne 100’de bırakmayın; çoğu fotoğrafta 80 civarı gözle ayırt edilemezken dosya boyutunu yarıya indirir.
• Boyut öznitelikleri: Genişlik ve yükseklik her zaman yazılmalı, CLS’i doğrudan önler.

JavaScript ve CSS yükü

Modern siteler, kullanılmayan kodun altında eziliyor. Tipik bir kurumsal WordPress sitesinde onlarca CSS ve JavaScript dosyası yüklenir; bunların önemli bir bölümü o sayfada hiç çalışmaz.

• Kullanılmayan kodu tespit edin. Chrome’un Coverage aracı, hangi dosyanın yüzde kaçının kullanıldığını gösterir.
• Koşullu yükleyin. İletişim formu betiği yalnızca iletişim sayfasında, slider betiği yalnızca slider olan sayfalarda yüklensin.
• Erteleyin. Kritik olmayan betiklerde defer veya async kullanın.
• Birleştirmeye dikkat. HTTP/2 ile dosya birleştirmenin faydası azaldı; bazen bölmek daha iyidir.
• Eklenti sayısını gözden geçirin. WordPress’te her eklenti kendi varlıklarını her sayfaya yükleyebilir.

Yazı tipleri

Web fontları hem LCP hem CLS’i etkiler. Pratik kurallar:

• Font dosyalarını kendi sunucunuzdan servis edin; üçüncü taraf font servisine bağlanmak ek gecikme ekler.
• Yalnızca kullandığınız ağırlıkları yükleyin. Bir sitede dört ağırlık genelde fazlasıyla yeterlidir.
• Türkçe karakterler için latin-extended alt kümesini dahil etmeyi unutmayın; aksi halde ş, ğ, İ gibi karakterler yedek fontla render olur ve görsel bozulma yaşanır.
• `font-display` değerini bilinçli seçin: swap metni hemen gösterir ama kayma riski taşır, optional kaymayı engeller.
• Kritik fontları önden yükleyin.

Sunucu, önbellek ve TTFB

TTFB (ilk bayta kadar geçen süre), sunucunun ne kadar hızlı cevap verdiğini gösterir. Yüksek TTFB, sayfadaki her şeyi geciktirir ve önündeki hiçbir görsel optimizasyonu bunu telafi edemez.

• Sayfa önbelleği: WordPress gibi dinamik sistemlerde her istek veri tabanı sorgusu üretir. Sayfa önbelleği bu maliyeti ortadan kaldırır ve genelde tek başına en büyük kazancı sağlar.
• Nesne önbelleği: Tekrarlanan sorguları hafızada tutar.
• CDN: Statik dosyaları kullanıcıya yakın sunuculardan servis eder.
• Barındırma kalitesi: Paylaşımlı ucuz barındırmada, komşu sitelerin yükü sizin TTFB’nizi etkiler.
• PHP ve veri tabanı sürümü: Güncel sürümler ölçülebilir hız farkı yaratır.
• Yönlendirme zincirleri: Her yönlendirme ek gidiş dönüş demektir. http’den https’e, oradan www’ya giden bir zincir, ilk baytı gecikmeli getirir.

Üçüncü taraf betikleri

Kendi kodunuzu optimize edip üçüncü taraf betiklerini olduğu gibi bırakmak, çoğu sitede yapılan en büyük eksikliktir. Tipik bir e-ticaret sitesinde şunlar aynı anda çalışır: analitik, etiket yöneticisi, reklam pikselleri, canlı destek, ısı haritası, yorum widget’ı, öneri motoru, çerez bandı.

Yaklaşım:

• Envanter çıkarın. Hangi betik ne iş yapıyor, kim istedi, hâlâ kullanılıyor mu? Çoğu sitede yıllar önce eklenmiş ve kimsenin bakmadığı araçlar bulunur.
• Etiket yöneticisinde toplayın. Tek yerden yönetilen betikler denetlenebilir olur; ayrıntısı GA4 ve Tag Manager rehberimizde.
• Koşullandırın. Isı haritası yalnızca ölçüm yaptığınız sayfalarda çalışsın.
• Geciktirin. Sohbet balonunu ilk kaydırma veya ilk dokunuştan sonra yükleyin.
• Sunucu taraflı etiketlemeyi değerlendirin. Tarayıcıdaki yükü sunucuya taşır.

WordPress sitelerinde pratik plan

Aşağıdaki sıra, çoğu WordPress sitesinde en yüksek kazancı en az riskle verir:

1. Sayfa önbelleği kurun. Tek başına en büyük etkiyi genelde bu yapar.
2. Görselleri toplu dönüştürün. WebP’ye çevirip yeniden boyutlandırın.
3. Kullanılmayan eklentileri kaldırın. Devre dışı bırakmak yetmez, silin.
4. Sayfa oluşturucunun ürettiği fazlalığı azaltın. Aşırı iç içe geçmiş bölümler hem DOM’u hem CSS’i şişirir.
5. Fontları yerelleştirin ve azaltın.
6. Betikleri koşullandırın.
7. CDN ekleyin.
8. Ölçün ve karşılaştırın. Her adımdan önce ve sonra aynı sayfayı aynı araçla ölçün, hangi adımın ne kazandırdığını kaydedin.

Son madde en çok atlanan ve en önemli olanıdır: ölçmeden yapılan optimizasyon, işe yarayıp yaramadığı bilinmeyen bir değişiklik yığınına dönüşür.

E-ticaret sitelerinde öncelikler

Ürün sayısı yüksek sitelerde hız çalışması farklı yerlerde yoğunlaşır:

• Kategori sayfaları. Onlarca ürün görseli aynı anda yüklenir. Tembel yükleme ve doğru boyutlandırma burada en kritik.
• Filtreleme. Her filtre değişiminde tüm sayfanın yeniden yüklenmesi hem yavaştır hem INP’yi bozar.
• Ürün sayfası. Yüksek çözünürlüklü ürün fotoğrafları ve yakınlaştırma bileşenleri LCP’yi zorlar.
• Sepet ve ödeme. Buradaki her yavaşlık doğrudan gelir kaybıdır. Ödeme akışında üçüncü taraf betiklerini asgariye indirin.
• Sonsuz kaydırma. Kullanışlı görünür ama DOM’u sürekli büyütür ve INP’yi bozar.

Hızın dönüşüme etkisi nasıl ölçülür?

Hız çalışmasının iş sonucuna etkisini kanıtlamak, bir sonraki bütçeyi almanın da yoludur. Yöntem:

1. Öncesini kaydedin. Değişiklikten önceki 4 haftanın dönüşüm oranını, sayfa başına gelirini ve hemen çıkma davranışını not edin.
2. Tek seferde büyük bir değişiklik yapın. Onlarca küçük değişikliği aynı anda yaparsanız hangisinin etkilediğini asla bilemezsiniz.
3. Aynı dönem uzunluğunda sonrasını ölçün. Mevsimsellik ve kampanya etkisini dışarıda tutun.
4. Cihaz kırılımına bakın. Hız iyileştirmelerinin etkisi mobilde masaüstünden çok daha belirgindir.
5. Bağlantı hızına göre segmentleyin. Yavaş bağlantıdaki kullanıcılarda dönüşüm farkı en çarpıcı şekilde görünür.

Bu analizleri düzenli yapmak için ölçüm altyapınızın sağlam olması gerekir; bu tarafı dönüşüm optimizasyonu ve ileri analitik çalışmalarında ele alıyoruz.

Sayfa hızı ve reklam performansı

Hız konuşulurken hep SEO tarafı öne çıkar, oysa ücretli reklam tarafındaki etkisi çoğu zaman daha büyüktür ve çok daha hızlı ölçülür.

• Kalite puanı: Google Ads’de açılış sayfası deneyimi, kalite puanının üç bileşeninden biridir. Kalite puanı yükseldiğinde aynı sırada daha düşük tıklama maliyetiyle çıkarsınız. Yani hız çalışması, doğrudan tıklama maliyetini düşürebilen az sayıdaki müdahaleden biridir.
• Boşa giden tıklamalar: Reklamı tıklayan kullanıcı sayfa açılmadan geri dönerse, o tıklamanın parasını ödediniz ama hiçbir şey almadınız. Bu kayıp raporlarda “düşük dönüşüm oranı” olarak görünür ve genelde kreatif ya da hedefleme suçlanır; oysa sorun sayfadadır.
• Ölçüm kaybı: Sayfa çok yavaşsa, ölçüm etiketi çalışmadan kullanıcı ayrılabilir. Bu durumda ziyaret hiç kaydedilmez ve reklam platformu eksik sinyalle öğrenir. Yani yavaş sayfa yalnızca dönüşümü değil, algoritmanın öğrenmesini de bozar.
• Mobil kampanyalarda etki daha sert: Masaüstünde fark edilmeyen bir gecikme, mobil trafikte dönüşüm oranını gözle görülür biçimde düşürür.

Bu yüzden hız iyileştirmesini reklam bütçesi optimizasyonunun bir parçası olarak ele almak gerekir; kampanya tarafındaki karşılığını Google’a reklam verme rehberimizde anlattık.

Mobil gerçeği: hangi cihazda test etmelisiniz?

Performans testlerinde en sık yapılan yanlış, geliştiricinin kendi bilgisayarındaki hızlı bağlantıyla test etmesidir. Gerçek kullanıcı tablosu bambaşkadır: orta segment bir telefon, değişken şebeke kalitesi, açık duran onlarca sekme ve pil tasarrufu modu.

• Orta segment cihaz varsayın. Amiral gemisi telefonlar JavaScript’i çok hızlı işler; orta segment cihazlarda aynı kod kat kat yavaş çalışır. INP sorunları neredeyse tamamen bu cihazlarda ortaya çıkar.
• Şebeke değişkenliğini hesaba katın. Kullanıcı metroda, asansörde veya kalabalık bir alanda sayfayı açıyor olabilir. Sayfanın küçük olması, bağlantı kötüleştiğinde en büyük avantajdır.
• Test profilini sabitleyin. Her ölçümü aynı cihaz profili ve aynı ağ kısıtıyla yapın; aksi halde iyileştirme mi yaptınız yoksa şansınız mı yaver gitti anlayamazsınız.
• Gerçek cihazla da deneyin. Simülasyon iyi bir yaklaşımdır ama gerçek bir telefonda sayfayı kaydırmak, hiçbir aracın söylemediği şeyleri gösterir.

Hız bütçesi belirlemek

Performans, bir kez düzeltilip bırakılan bir şey değildir; her yeni özellik biraz daha ağırlık ekler. Bunu engellemenin yolu, sayısal bir sınır koymaktır. Buna hız bütçesi denir.

Pratik bir bütçe şu üç sınırdan oluşur:

• Toplam sayfa ağırlığı: Kritik şablonlar için üst sınır belirleyin. Yeni bir bileşen bu sınırı aşıyorsa, karşılığında bir şeyin çıkarılması gerekir.
• JavaScript miktarı: En pahalı kaynak budur; indirilmesi değil, işlenmesi maliyetlidir.
• İstek sayısı: Özellikle üçüncü taraf alan adlarına yapılan bağlantılar sayılmalıdır.

Bütçe, teknik bir tercih değil bir ekip anlaşmasıdır. Pazarlama yeni bir izleme betiği isterse, bunun bir maliyeti olduğu ve karşılığında başka bir şeyin kaldırılması gerektiği baştan kabul edilmiş olur. Bu anlaşma olmadan, optimize edilen her site birkaç ay içinde eski haline döner.

Ekip süreci: kim neyi sahiplenir?

Hız projelerinin çoğu teknik nedenlerle değil, sahiplik belirsizliği yüzünden yarım kalır. Net bir dağılım işi yürütür:

• Altyapı ve barındırma: Sunucu yanıt süresi, önbellek katmanları, CDN. Genelde yazılım veya sistem ekibinin işi.
• Ön yüz: Görsel formatları, kritik CSS, JavaScript yükü, DOM boyutu.
• İçerik ve pazarlama: Yüklenen görsellerin boyutu, sayfaya eklenen video ve gömülü içerikler, kampanya banner’ları.
• Ölçüm: Etiket yöneticisindeki betikler, hangi aracın hangi sayfada çalıştığı.

Bu dört alanın her birinde bir sorumlu ve aylık tek bir kontrol toplantısı, çoğu sitede performansın kalıcı olmasını sağlar. Sorumlusu olmayan alan, birkaç ay içinde en yavaş nokta haline gelir.

Hangi müdahale ne kadar kazandırır?

Sınırlı zamanla çalışıyorsanız, etki sırasına göre ilerleyin. Sahada tipik olarak gözlenen sıralama şudur:

1. Sayfa önbelleği yoksa kurmak. Dinamik sistemlerde tek başına en büyük sıçramayı verir, çünkü TTFB’yi doğrudan düşürür.
2. Görselleri düzeltmek. Format, boyut ve tembel yükleme üçlüsü sayfa ağırlığını genelde çok belirgin biçimde azaltır.
3. Gereksiz üçüncü taraf betiklerini kaldırmak. Hem LCP hem INP tarafında kazandırır.
4. Kritik CSS ve font stratejisi. Görsel olarak “sayfa açıldı” hissini öne çeker.
5. Kod bölme ve tembel bileşen yükleme. Geliştirme maliyeti yüksek, kazancı gerçek ama daha küçük.

Bu sıralama, “her şeyi aynı anda yapalım” yaklaşımından çok daha verimlidir. İlk üç madde genelde birkaç günlük iştir ve toplam kazancın büyük bölümünü sağlar; kalan maddeler ise haftalara yayılan geliştirme gerektirir.

“Hızlı ama boş sayfa” tuzağı

Performans skorunu yükseltmenin en kolay yolu sayfadan içerik çıkarmaktır. Görselleri azaltın, videoyu kaldırın, sosyal kanıt bölümünü silin: skor yükselir, satış düşer. Bu, hız projelerinin en sinsi yan etkisidir.

Doğru çerçeve şudur: amaç en hafif sayfa değil, ikna eden içeriği en hızlı sunan sayfadır. Ürün fotoğrafı satın alma kararının merkezindeyse, onu kaldırmak değil doğru formatta ve doğru boyutta sunmak gerekir. Müşteri yorumları dönüşümü artırıyorsa, bileşeni silmek değil ilk ekranın altında tembel yüklemek gerekir.

Pratik ayrım için şu soruyu sorun: Bu ögeyi kaldırırsam sayfa daha hızlı olur mu, yoksa sadece skor mu yükselir? İkinci durumda kayıp gerçek, kazanç kağıt üzerindedir. Bu yüzden her hız değişikliğinin ardından yalnızca performans ölçülerine değil, dönüşüm oranına da bakılmalıdır. İkisini birlikte izlemeyen ekipler, birkaç ay sonra “site hızlandı ama satışlar düştü” tablosuyla karşılaşır ve nedenini bulamaz.

Bir de tersi vardır: sayfayı hafifletmek için kaldırılan izleme kodları. Ölçüm etiketlerini performans gerekçesiyle kaldırmak, kısa vadede birkaç yüz milisaniye kazandırır ama reklam algoritmalarının öğrenmesini bozarak çok daha pahalıya mal olur. Etiketleri kaldırmak yerine tek bir kapsayıcıda toplayıp koşullandırmak doğru yaklaşımdır.

Sık yapılan 10 hata

Aşağıdaki liste, sahada en sık karşılaştığımız ve çoğu birkaç saat içinde düzeltilebilen hataları içeriyor.

1. Lighthouse skorunu kovalamak. Skor bir araçtır, hedef değildir.
2. Saha verisi yerine laboratuvar verisine göre karar vermek.
3. Kahraman görselinde tembel yükleme kullanmak.
4. Görsel boyutlarını HTML’de belirtmemek.
5. Üçüncü taraf betiklerine hiç dokunmamak.
6. Önbelleği kurup e-ticaret sepet sayfasını hariç tutmayı unutmak.
7. Tek ölçümle karar vermek.
8. Masaüstünde test edip mobili görmezden gelmek.
9. Optimizasyon eklentisinin agresif ayarlarını denemeden açmak. Site görsel olarak bozulabilir.
10. Öncesi ve sonrasını ölçmemek.

Bir sayfa ne kadar hızlı olmalı?

Rakamsal bir hedef isteyenler için pratik bir çerçeve: mobilde kahraman içeriğin 2,5 saniyenin altında görünmesi, kullanıcı dokunuşlarına 200 milisaniyenin altında yanıt verilmesi ve sayfa yerleşiminin yüklenme sırasında gözle görülür biçimde kaymaması. Bu üç şart sağlandığında kullanıcı, sayfayı “hızlı” olarak algılar.

Ancak asıl hedef rakam değil, karşılaştırmadır: aynı sorguda sizinle yarışan sitelerden daha hızlı olmak. Sektörünüzdeki üç rakibi aynı araçla ölçün ve kendinizi o aralıkta konumlandırın. Herkesin yavaş olduğu bir kategoride ortalamanın üstüne çıkmak, mutlak bir hedefi kovalamaktan hem daha ucuz hem daha etkilidir.

Terimler sözlüğü

Hız konuşmalarında herkesin aynı terimi aynı anlamda kullanması, ekipler arası yanlış anlamaları büyük ölçüde bitirir. Aşağıdaki kısa liste, raporlarda ve araç ekranlarında en sık karşınıza çıkacak kavramları kapsıyor.

• LCP: En büyük içerik ögesinin görünme süresi.
• INP: Etkileşimden görsel yanıta geçen süre.
• CLS: Sayfa yüklenirken oluşan görsel kayma miktarı.
• TTFB: Sunucudan ilk baytın gelme süresi.
• Saha verisi: Gerçek kullanıcılardan toplanan performans verisi.
• Laboratuvar verisi: Simüle edilmiş koşullarda yapılan test.
• CDN: İçeriği kullanıcıya yakın sunuculardan dağıtan ağ.
• Kritik CSS: İlk ekranın görüntülenmesi için gereken asgari stil.
• Tembel yükleme: Görüntü alanına girene kadar kaynağı yüklememe.
• Render engelleyen kaynak: Sayfanın çizilmesini bekleten dosya.

Özet

Bir cümlede: hız, kullanıcıyı beklettiğiniz her saniyenin faturasını size dönüşüm oranı olarak kesen bir maliyet kalemidir. Sıralamadaki etkisi tartışılabilir, kasadaki etkisi tartışılmaz.

Hız çalışmasına başlarken üç soruyu sırayla cevaplayın: Sunucu yeterince hızlı cevap veriyor mu? Görseller doğru format ve boyutta mı? Sayfada gerçekten gerekmeyen kaç betik çalışıyor? Bu üç sorunun cevabı, çoğu sitede toplam kazancın büyük bölümünü verir. Geri kalan ince ayarlar, ancak bu üçü halledildikten sonra fark yaratır.

Ve en önemlisi: hızı bir defalık proje değil, süreklilik gerektiren bir bakım işi olarak kurgulayın. Yeni eklenen her araç, her banner, her üçüncü taraf betiği kazandığınız süreyi geri alır. Aylık ölçüm rutini olmayan sitelerde performans, birkaç ay içinde başladığı noktaya döner.

İlgili içerikler: Google Search Console rehberi, Teknik SEO kontrol listesi, Dönüşüm oranı optimizasyonu.