Kısa cevap: Yavaş açılan bir siteyi hızlandırmanın yolu sırayla ilerlemekten geçer. Önce yavaşlığın gerçek nedenini ölçerek bulun, sonra büyük görseller ve gereksiz scriptler gibi hızlı kazanımları toplayın, ardından hosting ile sunucu tarafını iyileştirin. Son adımda ise değişikliklerin işe yarayıp yaramadığını gerçek kullanıcı verisiyle doğrulayın. Bu rehber bu beş adımı, tahmin yerine ölçüme dayanarak anlatıyor.
Sitenizi Yavaşlatan Asıl Nedenler
Bir sayfa açılırken arka planda çok sayıda işlem gerçekleşir ve bunların her biri gecikme ekleyebilir. Çoğu yavaş sitede sorun tek bir yerde değil, birkaç küçük gecikmenin üst üste binmesindedir. En sık karşılaşılan nedenleri tanımak, nereye bakacağınızı bilmenizi sağlar.
- Yüksek TTFB ve zayıf hosting: Sunucu, tarayıcının ilk isteğine geç yanıt verirse her şey gecikerek başlar. Bu, çoğu durumda paylaşımlı veya yetersiz bir barındırma altyapısının işaretidir.
- Optimize edilmemiş büyük görseller: Yüksek çözünürlüklü, sıkıştırılmamış görseller bir sayfanın en ağır parçası olabilir ve ilk ekranın boyanmasını geciktirir.
- Render engelleyen CSS ve JavaScript: Tarayıcı, ekranı çizmeden önce belirli stil ve script dosyalarını indirip işlemek zorunda kalırsa kullanıcı boş bir ekrana bakar.
- Fazla HTTP isteği: Çok sayıda ayrı dosya, font ve üçüncü taraf bağlantısı, her biri ayrı bir tur gerektirdiği için toplam süreyi şişirir.
- Eksik önbellek (cache): Önbellek devrede değilse tekrar ziyaretlerde bile her dosya yeniden indirilir.
Bu nedenlerin ortak noktası şudur: hiçbiri tek başına felaket değildir, ama bir araya geldiklerinde toplam süre hızla büyür. Örneğin yarım saniyelik bir sunucu gecikmesi, sıkıştırılmamış birkaç görselle ve render engelleyen bir scriptle birleştiğinde, kullanıcının ilk içeriği görmesi saniyeler alabilir. Bu yüzden tek bir suçlu aramak yerine, gecikmenin nerelerde biriktiğini bütün olarak görmeniz gerekir.
Bu nedenleri ezbere düzeltmeye çalışmak yerine, önce hangisinin sizin sitenizde baskın olduğunu ölçmek gerekir. Aksi halde en kolay düzeltebildiğiniz şeye odaklanır, ama asıl darboğazı atlarsınız. İşte bu noktada Core Web Vitals devreye girer.
Core Web Vitals ile Doğru Teşhis
Bir siteyi hızlandırmadan önce neyin yavaş olduğunu sayılarla görmeniz gerekir. Google, kullanıcı deneyimini ölçmek için Core Web Vitals adı verilen bir metrik seti kullanır. Google'ın web.dev kaynağına göre üç temel metrik vardır: yüklemeyi ölçen LCP, etkileşime yanıt hızını ölçen INP ve görsel kararlılığı ölçen CLS. INP, 2024 yılında stabil metrik olarak FID'in yerini almıştır.
Bu metriklerin önerilen iyi eşikleri de bellidir. web.dev Web Vitals rehberine göre iyi sayılan değerler LCP için 2,5 saniye ve altı, INP için 200 milisaniye ve altı, CLS için 0,1 ve altıdır. LCP özelinde ise web.dev LCP belgesi, 2,5 saniyelik hedefin kullanıcıların yüzde 75'i, yani 75. yüzdelik için sağlanması gerektiğini belirtir. Yani tek bir hızlı ölçüm değil, ziyaretçilerin büyük çoğunluğunun deneyimi önemlidir.
Lab Verisi mi, Saha Verisi mi?
PageSpeed Insights gibi araçlar iki farklı veri türü gösterir ve bu ayrım çoğu rehberde atlanır. Lab verisi, kontrollü bir ortamda yapılan tek seferlik bir simülasyondur ve TTI, Speed Index, TBT gibi metrikleri içerir. Tekrarlanabilir olduğu için sorun ayıklamaya çok uygundur. Saha verisi ise gerçek kullanıcıların tarayıcılarından toplanan gerçek deneyimdir. Karar verirken saha verisini esas alın; lab verisini ise neyi düzeltmeniz gerektiğini anlamak için kullanın. İkisini karıştırmak, laboratuvarda mükemmel görünen ama gerçek kullanıcılar için yavaş kalan bir siteye yol açabilir.
Hızı tahmin etmeyin, ölçün. Önce hangi metriğin eşiği aştığını görün, optimizasyonu o metriğe yönlendirin.
Hızlı Kazanımlar: En Çok Etki Eden İlk Adımlar
Teşhis bittiyse, görece az emekle büyük fark yaratan değişikliklerle başlamak en mantıklısıdır. Çoğu sitede en büyük kazanç görsellerden gelir, çünkü genellikle sayfanın en ağır parçası onlardır.
- Görselleri sıkıştırın ve modern formata geçin: JPEG ve PNG yerine WebP veya AVIF kullanmak, görünür kalite kaybı olmadan dosya boyutunu önemli ölçüde düşürür. Görsellerin gösterileceği boyutta sunulduğundan da emin olun.
- Lazy load uygulayın: Ekranın altındaki görsel ve videoların yalnızca kullanıcı oraya kaydırdığında yüklenmesi, ilk açılışı belirgin biçimde hızlandırır.
- CSS ve JS dosyalarını küçültün (minify): Gereksiz boşluk ve yorumların temizlenmesi indirilecek veriyi azaltır.
- Gereksiz scriptleri kaldırın: Artık kullanmadığınız analiz, sohbet veya pazarlama scriptlerini sökün. Her üçüncü taraf script, kendi yükünü ve gecikmesini beraberinde getirir.
- Önbelleği açın: Tarayıcı önbelleği sayesinde tekrar gelen ziyaretçiler aynı dosyaları yeniden indirmek zorunda kalmaz.
Bir önceliklendirme ipucu: ilk ekranda görünen, yani kullanıcının kaydırmadan gördüğü alandaki görsel ve içeriklere odaklanın. LCP genellikle bu alandaki en büyük öğenin ne kadar hızlı boyandığıyla ilgilidir, dolayısıyla oradaki bir görseli optimize etmek alttaki onlarca küçük öğeyi düzeltmekten daha çok işe yarar. İlk ekranın altındaki her şeyi ise rahatça ertelenmiş (lazy) yükleyebilirsiniz.
Bu adımlar çoğu durumda LCP ve toplam yükleme süresini hissedilir derecede iyileştirir. Ama bir sınır vardır: eğer sunucu yanıtı zaten yavaşsa, ön tarafta yaptığınız her iyileştirmenin etkisi sınırlı kalır. Çünkü tarayıcı, ilk baytı alana kadar zaten bekliyordur ve siz ne kadar optimize ederseniz edin o bekleme süresini ön tarafta gideremezsiniz.
Hosting ve Sunucu Tarafının Etkisi
Hız hikayesi tarayıcıda değil, sunucuda başlar. Tarayıcı ilk baytı alana kadar geçen süreye TTFB denir ve bu süre büyük ölçüde hosting kalitenize bağlıdır. web.dev TTFB belgesine göre çoğu site TTFB'yi 0,8 saniye, yani 800 milisaniye ve altında tutmayı hedeflemelidir. Aynı kaynak, backend işleme süresini ve bağlantı kurulum gecikmesini azaltmanın TTFB'yi düşürdüğünü belirtir; bu da doğrudan hosting ve sunucu yapılandırmasıyla ilgilidir.
Sunucu tarafında etki yaratan başlıca iyileştirmeler şunlardır:
- Daha iyi bir barındırma planı: Kaynakları zorlanan paylaşımlı bir sunucudan daha yetkin bir altyapıya geçmek, çoğu durumda TTFB'yi tek başına düşürür.
- CDN kullanımı: İçerik dağıtım ağı, dosyaları ziyaretçiye coğrafi olarak yakın sunuculardan sunarak mesafe kaynaklı gecikmeyi azaltır.
- HTTP/2 veya HTTP/3: Modern protokoller, çok sayıda dosyanın daha verimli aktarılmasını sağlar.
- Gzip veya Brotli sıkıştırma: Metin tabanlı dosyaların sunucuda sıkıştırılarak gönderilmesi, transfer boyutunu küçültür.
Hosting tarafı çoğu rehberin yarısında bile geçmez, oysa yavaş bir sunucu üzerinde yapılan tüm ön optimizasyonlar tavan yapar. Önce zemini sağlamlaştırın.
Eklenti ve Script Temizliği
Zamanla her sitede biriken bir yük vardır: artık gerekmeyen eklentiler, eski kampanyalardan kalan etiketler, denenip bırakılmış üçüncü taraf araçlar. Her biri ek dosya, ek istek ve çoğu zaman render engelleyen kod demektir. Sitenizde yüklü olan her eklenti ve harici scripti tek tek gözden geçirin ve şu soruyu sorun: bu hâlâ bir işe yarıyor mu?
Pratik bir temizlik için:
- Kullanılmayan eklentileri yalnızca pasifleştirmekle kalmayın, tamamen kaldırın.
- Aynı işi yapan birden fazla araç varsa birinde karar kılın.
- Üçüncü taraf scriptleri mümkünse sayfanın kritik render yolundan çıkarın, geç yüklenecek şekilde yapılandırın.
- Her temizlik sonrası ölçüm yapın; bazen bir eklenti beklenenden çok daha fazla yük getirdiğini ancak kaldırıldığında belli eder.
Bu temizlik özellikle INP gibi etkileşim metriklerinde fark yaratır, çünkü ana iş parçacığını meşgul eden ağır scriptler kullanıcının tıklamalarına yanıtı geciktirir. Kullanıcı bir butona bastığında tarayıcı o anda başka bir scripti işliyorsa, yanıt gecikir ve site donmuş gibi hissettirir. Üçüncü taraf araçları azaltmak bu donma hissini doğrudan hafifletir. Tek seferde hepsini kaldırmak yerine birer birer ilerleyin; böylece hangi değişikliğin ne kadar fark yarattığını net görürsünüz.
Değişiklikleri Doğrulama ve Sürekli İzleme
Optimizasyonun en çok atlanan adımı doğrulamadır. Tek bir araçta tek seferlik bir test yapıp "hallettik" demek yanıltıcıdır, çünkü o ölçüm sadece o anın ve o cihazın deneyimini gösterir. Asıl ölçmeniz gereken şey, gerçek kullanıcılarınızın deneyimidir.
Bu yüzden değişiklik sonrası saha verisini takip edin. LCP eşiğinin 75. yüzdelik için, yani kullanıcıların yüzde 75'i için sağlanması gerektiğini hatırlayın; bu da ölçümü tek bir kullanıcıya göre değil, ziyaretçi kitlenizin geneline göre değerlendirmeniz gerektiği anlamına gelir. Sizin hızlı cihazınızda ve hızlı bağlantınızda site uçuyor olabilir, ama mobil veriyle ve eski bir telefonla bağlanan ziyaretçinizin deneyimi tamamen farklı olabilir. Saha verisi tam da bu farkı görünür kılar.
PageSpeed Insights'ın saha bölümü ve gerçek kullanıcı verisi, değişikliklerin işe yarayıp yaramadığını zaman içinde gösterir. Saha verisinin güncellenmesi belli bir süre alır, dolayısıyla bir iyileştirmenin etkisini hemen değil, birkaç hafta içinde değerlendirin. Hızı tek bir gün değil, düzenli aralıklarla izleyerek bir alışkanlık hâline getirin; böylece site büyüdükçe yeniden yavaşladığında erkenden fark edersiniz.
Modern Stack Notu: Framework ve Kod Bölme
Site modern bir JavaScript framework'ü üzerine kuruluysa hız denklemi biraz değişir. Bu sitelerde gereğinden fazla JavaScript göndermek, INP ve etkileşim hızını doğrudan etkiler. Burada iki yaklaşım öne çıkar: içeriği sunucu tarafında üretmek (SSR), böylece kullanıcı ilk anlamlı içeriği daha erken görür; ve kodu parçalara ayırmak (code-splitting), böylece her sayfa yalnızca ihtiyaç duyduğu JavaScript'i indirir. Bu iki teknik, ağır bir uygulamada bile ilk yükleme yükünü önemli ölçüde azaltabilir. Bu konu rakip içeriklerin neredeyse hiçbirinde geçmez, ama modern siteler için belirleyici olabilir.
3 Saniye Kuralı ve Yavaşlığın İş Etkisi
Sektörde sık tekrarlanan bir kural vardır: kullanıcılar genellikle birkaç saniye içinde açılmayan sayfalardan ayrılma eğilimindedir. Bu sezgiyi kesin bir rakama indirgemek doğru olmaz, ama yön nettir; sayfa yavaşladıkça hemen çıkma eğilimi artar ve dönüşüm zarar görür. Hız aynı zamanda bir sıralama faktörüdür. Google Search Central sayfa deneyimi belgesinde Core Web Vitals'ın sıralama sistemlerinde kullanıldığını açıkça belirtir. Burada önemli bir nüans var: hız tek başına belirleyici değildir, ancak benzer alaka düzeyine sahip sonuçlar arasında fark yaratabilir. Yani hızlandırma, hem kullanıcıyı hem de görünürlüğü aynı anda destekleyen az sayıdaki yatırımdan biridir.
Özet: Sırayla İlerleyin
Yavaş bir siteyi hızlandırmanın bütünü aslında basit bir döngüdür: ölç, düzelt, tekrar ölç. Önce Core Web Vitals ile teşhis koyun, sonra görsel ve script tarafındaki hızlı kazanımları toplayın, hosting zeminini sağlamlaştırın, gereksiz eklentileri temizleyin ve en sonunda saha verisiyle doğrulayın. Tahmine değil ölçüme dayandığınız sürece, attığınız her adımın gerçekten işe yarayıp yaramadığını görürsünüz.
VixSEO ile: Sitenizin teknik SEO ve hız tarafını düzenli takip etmek istiyorsanız, araçlarımıza göz atabilir veya hizmetlerimizi inceleyebilirsiniz. Wix, Ikas ve özel sitelerde ölçüm ve iyileştirme sürecini tek panelden yürütmenize yardımcı oluyoruz.