Hızlı Açılan Bir Web Sitesi İçin Neler Yapmalı?

Puan mı, kullanıcı mı?

PageSpeed Insights’a bir adres yazınca iki bölüm görürsünüz, çoğu kişi ikincisine bakıp geçer. Üstte “Gerçek kullanıcılarınızın deneyimi” yazan kısım, Chrome kullanıcılarından toplanan son 28 günlük veridir (CrUX). Altta ise o an bir test sunucusunun sayfayı yavaş bir telefon ve ağ taklidiyle açtığı laboratuvar testi ve meşhur 0–100 puan.

Google sıralamada gerçek kullanıcı verisine bakıyor, laboratuvar puanına değil. Bunu bilmeyince insanlar 100 puan peşinde günlerini harcıyor. Şöyle bir tablo hiç de nadir değil: 98 puan alan ama gerçek kullanıcı verisinde “başarısız” görünen bir site. Örneğin sebep şu olabilir: test sunucusu Avrupa’dan bağlanıyordu ve önbelleğe alınmış sayfayı görüyordu; Türkiye’deki gerçek ziyaretçiler ise her seferinde önbelleği atlayan bir kampanya parametresiyle geliyordu. Puan güzel, kullanıcı mutsuz.

Tersi de olur: 60 puanlı bir site gerçek kullanıcıda gayet iyi çıkabilir. O yüzden önce üstteki kutuya bakın. Veri yoksa (az ziyaretli sitelerde olur) laboratuvar sonucu fikir verir ama son söz değildir. Search Console’daki Core Web Vitals raporu da aynı gerçek kullanıcı verisini sayfa grupları hâlinde gösteriyor; sitenin geneline bakmak için en iyi yer orası.

Üç ölçüt, üç his

Ölçütlerin adları teknik ama anlattıkları şey çok gündelik.

LCP (Largest Contentful Paint), perde açıldığında sahnedeki başrol oyuncusunun ne zaman göründüğü. Genelde sayfanın en üstündeki büyük görsel ya da başlık. 2,5 saniyenin altı iyi kabul ediliyor. LCP’yi en çok o büyük görselin ağırlığı, geç keşfedilmesi ya da sunucunun geç cevap vermesi bozuyor.

INP (Interaction to Next Paint), bir düğmeye dokunduğunuzda ekranın ne kadar sürede tepki verdiği. Mart 2024’te eski ölçüt FID’in yerini aldı ve daha acımasız: sayfadaki tüm etkileşimlere bakıyor, en kötülerinden birini esas alıyor. 200 milisaniyenin altı iyi. Menü açılmıyor, “Sepete ekle” basılınca bir an donuyor gibi hissediyorsanız INP sorunu var demektir; sebebi neredeyse her zaman ağır JavaScript.

CLS (Cumulative Layout Shift), okurken metnin aşağı kayması, tam bir bağlantıya basacakken üstten bir reklam ya da çerez bandı inip başka bir şeye bastırması. 0,1’in altı iyi. Boyutu belirtilmemiş görseller, sonradan yüklenen yazı tipleri ve geç gelen bantlar en sık suçlular.

Eşiklerin resmi açıklaması Google’ın web.dev sitesinde, arama tarafındaki etkisi de Google Search Central’ın Core Web Vitals sayfasında anlatılıyor.

Yavaşlık nereden geliyor?

Hızlandırma işine başladığımızda ilk yaptığımız şey “nereden” sorusunu cevaplamak. Çünkü sebep bulunmadan yapılan her iyileştirme (önbellek eklentisi kurmak gibi) yarabandı oluyor.

Görseller

Çoğu sitede en büyük kazanç buradan çıkıyor. Telefonla çekilmiş 4000 piksellik, 6 MB’lık bir fotoğrafın olduğu gibi ana sayfaya konduğunu az görmedik. Görseller ekranda görüneceği boyuta küçültülmeli, WebP ya da AVIF formatında sunulmalı, farklı ekranlara farklı boyut gönderilmeli (srcset). Sayfanın altındaki görseller geç yüklenebilir (lazy loading), ama dikkat: en üstteki ana görsele lazy loading koymak LCP’yi bozar. O görsel tam tersine öncelikli yüklenmeli. Görselin genişlik ve yüksekliğini belirtmek de CLS’yi önler. Bu konuyu web sitesinde doğru görsel kullanımı yazısında daha ayrıntılı anlattık.

Eklentiler, takip kodları ve “küçük” eklemeler

Bir sohbet penceresi, bir Instagram akışı, bir ziyaretçi sayacı, iki ayrı analiz kodu, bir de ısı haritası… Her biri “sadece birkaç kilobayt” diye eklenir, toplamı sayfayı kilitler. Üçüncü taraf kodlar sizin sunucunuzda değil başkasının sunucusunda durduğu için onların yavaşlığı sizin yavaşlığınız olur.

Kendi sitemizi yeniden yaparken iletişim sayfasına Google Haritalar gömmedik, örneğin. Yerine işletme profilimize giden bir bağlantı koyduk. Gömülü harita tek başına yüzlerce kilobaytlık kod ve birkaç çerez getiriyor; bağlantı ise neredeyse hiçbir şey. Küçük bir karar ama sayfanın hızını gözle görülür değiştiriyor.

Sunucu ve önbellek

Sunucu ilk baytı geç gönderiyorsa (TTFB) sayfanın geri kalanı ne kadar hafif olursa olsun her şey geç başlıyor. Ucuz, kalabalık paylaşımlı sunucular, eski PHP sürümleri, önbelleği olmayan dinamik sayfalar burada en sık sebepler. Ziyaretçilerinizin çoğu Türkiye’deyse sunucunun da Türkiye’de olması ya da bir CDN arkasında durması fark yaratıyor. Bizim alan adı ve hosting tarafında Türkiye’deki veri merkezlerini ve gerektiğinde Cloudflare’ı tercih etmemizin sebebi de bu.

Yazı tipleri

Google Fonts’tan dört farklı kalınlıkta üç yazı tipi çağırmak hem gecikme hem kayma yaratıyor. Yazı tiplerini kendi sunucunuzdan, yalnız kullandığınız kalınlıklarla ve Türkçe karakterleri içeren alt kümeyle (latin-ext) sunmak daha hızlı ve çerez açısından da daha temiz.

Örnek vaka: 42 eklentili WordPress sitesi

Diyelim ki bir firmanın WordPress sitesi yıllar içinde büyümüş. Her ihtiyaç bir eklentiyle çözülmüş: biri form için, biri slider için, biri sosyal paylaşım için, üçü farklı hız eklentisi (evet, üçü birden, birbirleriyle kavga ediyorlar). Toplam 42 eklenti. Ana sayfa telefonda 7–8 saniyede açılıyor, menüye basınca bir an donuyor.

Böyle bir sitede ilk iş “hangi eklenti gerçekten kullanılıyor” listesini çıkarmak oluyor. Genelde eklentilerin üçte biri hiçbir işe yaramıyor, bir kısmı aynı işi iki kez yapıyor. Slider yerine tek, iyi optimize edilmiş bir görsel; üç hız eklentisi yerine düzgün ayarlanmış bir tane; sosyal paylaşım eklentisi yerine basit bağlantılar… Sunucuda PHP sürümü güncelleniyor, sayfa önbelleği açılıyor. Bu tür bir temizlikten sonra aynı sitenin telefonda 2 saniyenin altına inmesi şaşırtıcı değil. Hiçbir sihir yok; sadece fazlalıkları atmak.

Hız için en köklü çözüm: Daha az şey göndermek

Hızlandırma eklentileri iyidir ama bir sınırı var: zaten ağır olan bir sayfayı sıkıştırıp önbelleğe alırlar, ağırlığı ortadan kaldırmazlar. En hızlı kod, hiç gönderilmeyen koddur.

Biz eforweb.com’u bu yüzden WordPress’ten statik bir yapıya (Astro) taşıdık. Sayfalar önceden hazırlanıp sunuluyor, her ziyarette veritabanına gidilmiyor, sayfada yalnız gerçekten gereken JavaScript çalışıyor. Bu her site için doğru seçim değil; sık güncellenen e-ticaret siteleri ya da müşterinin kendi panelinden her gün içerik girdiği siteler için WordPress gibi bir içerik yönetim sistemi hâlâ çok mantıklı. Ama şunu gösteriyor: hız, işin sonunda eklentiyle eklenen bir şey değil, en başta verilen bir tasarım kararı. Web tasarım projelerinde hızı bu yüzden tasarım aşamasında konuşuyoruz.

Hız, SEO ve yapay zekâ aramaları

Sayfa deneyimi Google’ın sıralama sistemlerinde kullanılan sinyallerden biri; ama Google’ın kendisi de en alakalı içeriğin, sayfa deneyimi zayıf olsa bile öne çıkabileceğini söylüyor. Yani yavaş ama çok faydalı bir sayfa, hızlı ama boş bir sayfanın önüne geçebilir. Hızın asıl etkisi dolaylı: yavaş sayfadan ziyaretçi kaçıyor, form doldurulmuyor, reklama verdiğiniz para boşa gidiyor.

Yapay zekâ aramalarında da durum benzer. Google’ın yapay zekâ özelliklerinde görünmek için önerdiği temel teknik şartlar arasında taranabilir, hızlı ve mobil uyumlu sayfalar var. Bu, ayrı bir “yapay zekâ hızı” değil; bildiğimiz iyi teknik SEO. SEO nedir yazısında bu bütünü, SEO danışmanlığı sayfasında da hız denetimini nasıl yaptığımızı anlattık.

Hızı ölçmek için kullanabileceğiniz araçlar

• PageSpeed Insights: Gerçek kullanıcı verisi ve laboratuvar testi bir arada; başlangıç noktası.
• Google Search Console, Core Web Vitals raporu: Sitenin tamamını sayfa grupları hâlinde gösterir.
• Chrome geliştirici araçları (Lighthouse ve Performans sekmesi): Sorunun hangi dosyadan geldiğini bulmak için.
• WebPageTest: Farklı konum ve bağlantılardan, saniye saniye yüklenme videosuyla test.