Sayfa Hızı ve Core Web Vitals ile Google Sıralamasını Artırma

“Ofisteki bilgisayarımda saniyede açılıyor, Google neden sitemi yavaş buluyor?” sorusuyla çok sık karşılaşıyoruz. Google sıralamasında belirleyici olan sentetik test puanı değil; gerçek mobil kullanıcıların LCP (en fazla 2,5 saniye), INP (en fazla 200 milisaniye) ve CLS (en fazla 0,1) eşikleridir. Sayfa hızını ve Core Web Vitals metriklerini bu standartlara çekmek, benzer içeriğe sahip rakiplerin önüne geçerek arama motorlarında üst sıralara kalıcı biçimde yerleşmeyi sağlar.

Denizli’de son 10 yılda incelediğimiz onlarca yerel ve kurumsal web sitesinde aynı tabloyu gördük: Sahipleri sitenin masaüstünde kendi ofis internetleriyle hızlı açıldığını düşünüyor, oysa Merkezefendi ya da Pamukkale sokaklarında 4G bağlantıyla gezinen gerçek müşteriler beyaz bir ekrana bakıp sayfayı kapatıyor. Hız konusu bir yazılım gösterisi değil, doğrudan ciro ve sıralama meselesidir.

Ziyaretçiyi sayfada tutamayan hiçbir işletme dijitalde büyüyemez.

Bu teknik darboğazı aşmak için rastgele hız eklentileri kurup şansa güvenmek yerine, 90 güne yayılan disiplinli bir optimizasyon takvimini hayata geçirmek gerekir.

Core Web Vitals metrikleri gerçekte neyi ölçer?

Core Web Vitals, tarayıcının sayfayı indirmesinden kullanıcının sayfayla etkileşime girdiği ana kadar geçen süreci üç farklı aşamada denetler. Google bu verileri sentetik test araçlarından değil, Chrome kullanıcılarının son 28 günlük gezinme deneyimini içeren CrUX (Chrome User Experience Report) veri tabanından çeker.

LCP, kullanıcının sayfayı gerçekten yüklendi olarak algıladığı ilk anı temsil eder. Çoğu sitede bu öğe manşet görseli ya da ana H1 başlığıdır. INP metriği, 2024 Mart ayında FID (First Input Delay) metriğinin yerine geçmiş olup menüye basıldığında ya da bir filtre tıklandığında sayfanın donma süresini inceler. CLS ise tam butona tıklayacakken üstten yüklenen bir reklam veya görsel yüzünden sayfanın aşağı fırlaması durumudur.

Google sıralaması sentetik test puanına değil gerçek alan verilerine dayanır

İlk 30 günde yapılacak sunucu ve görsel optimizasyonları

Çalışmanın ilk ayı, altyapıdaki en hantal yükleri ayıklama dönemidir. Bu evrede yapılacak doğru müdahaleler, sitenin açılış hızını gün içinde hissedilir derecede değiştirir.

Yeni başladığımız projelerde ilk işimiz Google Search Console panelindeki Sayfalar ve Temel Web Verileri raporunu açmaktır. Burada kırmızı renkle işaretlenen URL grupları tespit edilir. Eğer sorunların tamamında LCP süresi 4 saniyenin üzerinde görünüyorsa, mesele genellikle sunucunun yanıt verme süresiyle (TTFB) ilgilidir.

İlk 30 günde tamamlanması gereken adımlar şunlardır:

1. Sunucu Yanıt Süresini (TTFB) Düşürmek: Paylaşımlı hosting paketlerinde onlarca sitenin aynı işlemciyi tüketmesi TTFB değerini 1.000 milisaniyenin üzerine çıkarır. Güçlü bir barındırma altyapısına geçmek ve LiteSpeed, Nginx FastCGI gibi sunucu seviyesinde önbellekleme kullanmak ilk zorunluluktur. İhtiyacınıza uygun sunucu yapılandırması için kaynakları paylaşımsız kurumsal sunucu çözümlerimizi inceleyebilirsiniz.
2. Görsel Formatlarını ve Boyutlarını Düzenlemek: Sahada en sık karşılaştığımız hata, fotoğraf makinesinden çıktığı gibi yüklenmiş 4 MB boyutundaki JPEG dosyalardır. Tüm görseller WebP veya AVIF formatına çevrilmeli, ekranda kaplayacağı maksimum piksel genişliğine göre yeniden boyutlandırılmalıdır.
3. Hero Görseline Öncelik Vermek: Sayfanın en üstündeki banner görseline kesinlikle loading="lazy" etiketi eklenmemelidir. Bunun yerine görsel koduna fetchpriority="high" niteliği eklenerek tarayıcının bu kaynağı ilk sıraya alması sağlanır.
4. CSS ve Font Blokajını Çözmek: Harici Google Fonts kütüphanesinden 7-8 farklı yazı tipi ağırlığı çağırmak yerine font dosyaları sitenin kendi sunucusunda barındırılmalı (self-host) ve font-display: swap kuralı uygulanmalıdır.

Bu düzenlemeler tamamlandıktan sonra PageSpeed Insights üzerinde laboratuvar testleri tekrarlanır. İlk ayın sonunda TTFB değerinin 600 milisaniye altına indiği, LCP süresinin ise test ortamında 2,8 saniye seviyelerine gerilediği görülmelidir.

30 ile 90 gün arasında JavaScript yükü ve düzen kayması çözümleri

İkinci ve üçüncü aylar, işin daha derin kod mimarisine inildiği ve teknik müdahalelerin yapıldığı dönemdir. Siteniz hızlanmış görünse bile kullanıcı bir butona bastığında arayüz birkaç yüz milisaniye takılıyorsa INP metriği kırmızı kalır.

Özellikle e-ticaret altyapılarında veya karmaşık temalarda ana işlemci iş parçacığı (main thread) gereksiz JavaScript betikleriyle kilitlenir. Canlı destek pencereleri, harita eklentileri, sosyal medya paylaşım butonları ve analiz pencereleri tarayıcıyı yorar.

Bu aşamada uyguladığımız çalışma planı şöyledir:

• Üçüncü Taraf Betikleri Geciktirmek: Google Tag Manager, Meta Pixel veya canlı sohbet pencereleri sayfanın ilk açılışında değil, kullanıcı sayfayı kaydırdığında veya fareyi hareket ettirdiğinde devreye girmelidir.
• Kullanılmayan JavaScript Kodlarını Temizlemek: Tema dosyalarında gelen ve ilgili sayfada hiç kullanılmayan kod blokları defer veya async nitelikleriyle ertelenmeli, mümkünse modüler olarak yalnızca ihtiyaç duyulan sayfalara yüklenmelidir.
• Görsellere ve Çerçevelere Sabit Boyut Tanımlamak: CLS sorunlarının yüzde 80’i genişlik ve yükseklik (width ve height) değerleri yazılmamış görsellerden kaynaklanır. Tarayıcı görselin boyutunu bilmediğinde önce boşluk bırakmaz, görsel indiğinde ise altındaki metni aniden aşağı iter. HTML tarafında her görsele en-boy oranı verilmelidir.
• Dinamik Alanları Sabitlemek: Çerez bildirim çubukları veya kampanya duyuru bantları sonradan sayfanın tepesine bindirilmemeli, CSS ile önceden yeri ayrılmış sabit katmanlar olarak tasarlanmalıdır.

Op. Dr. Emre Erkilet için yürüttüğümüz klinik projesinde, hekimin uzmanlık alanlarını ve tedavi içeriklerini sunarken temiz bir kod mimarisi ve optimize edilmiş mobil açılış altyapısı kurguladık; gereksiz betiklerden arındırılmış sayfalar sayesinde mobil kullanıcılara hızlı ve güven veren bir deneyim sunuldu.

Detaylı bir kod temizliği ve sunucu optimizasyonu için profesyonel teknik SEO analizi ve kod denetimi desteği almak bu sürecin hatasız ilerlemesini sağlar.

Ağır JavaScript blokları ana iş parçacığını kilitleyerek INP değerini bozar

90 gün sonrasında CrUX alan verilerini izleme süreci

Web sitenizde yaptığınız teknik düzeltmeler Search Console paneline ertesi gün yansımaz. Google’ın alan verilerini toplaması ve CrUX raporlarını güncellemesi 28 günlük kayan pencere mantığıyla çalışır.

Yani yaptığınız bir iyileştirmenin gerçek kullanıcılardaki yansımasını ve arama sonuçlarındaki etkisini görmek için en az bir ay beklemek şarttır. 90. güne gelindiğinde Search Console üzerindeki “Temel Web Verileri” raporunda “Zayıf URL” sayısı sıfıra inmeli ve URL’lerin büyük kısmı yeşil renkli “İyi” kategorisine taşınmalıdır.

Performans bir kere yapılıp rafa kaldırılacak bir iş değildir. İçerik ekibi siteye her gün yeni blog yazıları, ürün görselleri veya pazarlama pikselleri eklemeye devam eder. Eğer standart bir yükleme disiplini kurulmazsa, 6 ay sonra site yeniden kırmızı uyarılar vermeye başlar.

Bunu önlemek için 90 gün sonrasında şu denetim rutini işletilmelidir:

• Editörlerin panele yükleyeceği görseller için maksimum 1920 piksel genişlik ve 200 KB boyut sınırı getirilmelidir.
• Sitede yapılacak her yeni eklenti veya betik kurulumu öncesinde bir hazırlık ortamında Lighthouse hız testi yapılmalıdır.
• Search Console panelinde aylık rutin kontrol yapılarak yeni açılan sayfaların düzen kayması üretip üretmediği takip edilmelidir.
• Arama motorlarındaki görünürlüğün genel seyrini anlamak için kapsamlı organik arama danışmanlığı süreçleriyle teknik metrikler birbirine entegre yürütülmelidir.

Sitenizin genel mimarisini düzenli kontrol altında tutmak için teknik SEO denetimi rehberi içeriğimizdeki kontrol listesini de kullanabilirsiniz.

Sık karşılaşılan teknik engeller ve hız optimizasyonunun sınırları

Bunu açıkça söylemek gerekiyor: Her web sitesi sadece hız eklentileriyle Core Web Vitals testlerinden geçemez.

Piyasada 50-60 dolara satılan ve içinde 80 farklı demo barındıran hantal WordPress temaları, satır içi binlerce satır gereksiz CSS ve JavaScript ile gelir. Bu tip altyapılarda eklenti kurarak LCP veya INP değerini yeşile çevirmeye çalışmak, motoru arızalı bir araca sürekli cila çekmeye benzer. Bazen tek doğru çözüm, siteyi temiz kodlanmış hafif bir şablonla veya modern statik teknolojilerle baştan kurgulamaktır; nitekim arayüz sadeliği ve hız odaklı kodlama için satış ve güven kazandıran kurumsal web tasarımı prensiplerini benimsemek uzun vadede en kalıcı sonucu verir.

Bir diğer sınır ise üçüncü taraf reklam ve takip sistemleridir. Sayfanızda Google AdSense, Meta Pixel, Hotjar ve iki farklı analitik aracı aynı anda çalışıyorsa, INP değerini 200 milisaniyenin altında tutmak neredeyse imkansızdır. Burada işletmenin bir tercih yapması gerekir: Ya gerçekten kullanılmayan takip araçları panelden silinecek ya da bu betiklerin kullanıcı deneyiminde yarattığı yavaşlama kabullenilecektir.

Mobil hız ile satış arasındaki doğrudan bağı kavramak isteyenler için mobil uyumlu ve hızlı web sitesinin ciroya etkisi başlıklı yazımız somut veriler sunmaktadır.

Hız iyileştirmesi için haftalık kontrol listesi

Başarıya ulaşmak için teknik müdahaleleri belirli bir sıra dahilinde gerçekleştirmek gerekir. Karmaşık adımlara geçmeden önce temeli sağlamlaştırmak zaman kazandırır.

Sayfa hızı tek seferlik bir puan avcılığı değil, sitenizi ziyaret eden gerçek kişilere gösterdiğiniz saygının teknik karşılığıdır. Düzenli bakım ve doğru altyapıyla hem Google botlarının sitenizi tarama maliyetini düşürür hem de ziyaretçilerin alışveriş sepetini terk etmeden işlemi tamamlamasını sağlarsınız.