24. Bölüm: Site Neden Yavaş Açılıyor?

Son güncelleme: 1 Kasım 2026.

Bir sitenin yavaş açılması çoğu zaman tek bir nedene bağlı değil. Hosting yavaş olabilir, görseller çok büyük olabilir, JavaScript gereğinden fazla çalışabilir, üçüncü taraf kodlar sayfayı bekletebilir veya kullanıcıya en önemli içerik geç gösteriliyor olabilir.

Bu yüzden “site yavaş” dediğimizde aslında ilk yapmamız gereken şey hız probleminin kaynağını bulmak.

Bence burada en büyük hata doğrudan PageSpeed Insights’a girip sadece puana bakmak.

Site hızı bir puandan ibaret değil. Kullanıcının gerçekten ne yaşadığı daha önemli.

1. Bir site neden yavaş açılır?

En sık karşılaştığımız nedenleri kabaca şöyle sıralayabiliriz:

• Yavaş veya yetersiz hosting
• Sunucunun geç cevap vermesi
• Cache kullanılmaması veya yanlış yapılandırılması
• Çok büyük görseller
• Gereksiz JavaScript
• Fazla CSS
• Üçüncü taraf scriptleri
• Reklam kodları
• Chat araçları
• İzleme kodları
• Harici fontlar
• Çok fazla HTTP isteği
• CDN kullanılmaması
• Veritabanı sorgularının yavaşlığı
• Sayfanın kullanıcıya gereğinden fazla kaynak yüklemesi

Bunların bazıları frontend tarafında, bazıları sunucuda, bazıları da kullanılan altyapıda olabilir. Dolayısıyla “sayfa yavaş” dediğimizde önce problemin nerede olduğunu ayırmamız gerekiyor.

2. Hosting ve sunucu performansı neden önemli?

Kullanıcı bir sayfayı açtığında tarayıcı önce sunucudan cevap bekliyor. Sunucu geç cevap veriyorsa sayfanın geri kalanında yaptığınız optimizasyonların etkisi sınırlı kalabilir.

Burada sık karşılaştığımız metriklerden biri İlk Bayta Kadar Geçen Süre (Time to First Byte – TTFB). Basit olarak kullanıcı isteği gönderdikten sonra sunucudan ilk verinin gelmesine kadar geçen süreyi ifade ediyor.

TTFB’nin kötü olmasının sebebi sadece hosting değildir. Şunlardan da kaynaklanabilir:

• Yavaş veritabanı sorguları
• Ağır uygulama kodu
• Cache eksikliği
• Uzak sunucu lokasyonu
• DNS
• CDN yapılandırması
• Sunucu yoğunluğu

Bu yüzden “TTFB yüksek, hosting değiştirin” demek her zaman doğru teşhis değil. Önce neden yüksek olduğunu bulmak gerekiyor.

3. Cache ne işe yarıyor?

Bir web sayfasını her kullanıcı istediğinde sunucunun aynı işlemleri baştan yapması gerekmeyebilir.

Örneğin bir WordPress sitesinde her ziyaretçide şu işlemleri yapmak yerine daha önce oluşturulan sonucu belirli bir süre saklayabiliriz:

• Veritabanına bağlanmak
• İçeriği çekmek
• Temayı çalıştırmak
• Eklentileri çalıştırmak
• HTML üretmek

Buna önbellekleme (Cache) diyoruz. Doğru kullanıldığında ciddi hız kazandırabilir.

Ama 23. bölümde anlattığımız haber sitesi örneğinde olduğu gibi cache her zaman “ne kadar uzun, o kadar iyi” değildir. Haber sitemap’inin 10 dakika cache’lenmesi sunucuyu rahatlatıyordu ama yeni haberlerin sitemap’e geç eklenmesine neden oluyordu.

Yani performans optimizasyonunda da temel soru şu:

Bu sistem ne için kullanılıyor?

Kurumsal sitenin cache stratejisiyle haber sitesinin cache stratejisi aynı olmak zorunda değil.

4. CDN nedir?

İçerik Dağıtım Ağı (Content Delivery Network – CDN), sitenin bazı kaynaklarını kullanıcıya coğrafi olarak daha yakın sunuculardan sunmaya yardımcı olur.

Örneğin sunucunuz Almanya’da ama ziyaretçiniz Singapur’da. Her görselin ve statik dosyanın Almanya’dan gitmesi yerine CDN üzerinden kullanıcıya daha yakın bir noktadan iletilmesi gecikmeyi azaltabilir.

CDN özellikle şu durumlarda çok faydalı olabilir:

• Uluslararası sitelerde
• Görsel ağırlıklı sitelerde
• Yüksek trafikli projelerde
• Coğrafi olarak dağınık kullanıcı kitlesinde

Ama CDN kullanmak tek başına siteyi hızlı yapmaz. Yavaş çalışan bir uygulamanın önüne CDN koyduğunuzda bütün problemler sihirli şekilde çözülmez.

5. Görseller çoğu sitedeki en büyük yüklerden biri

17. bölümde görsel SEO’yu konuşmuştuk. Site hızı açısından da görseller çok önemli.

Örneğin ürün sayfasında 4000×4000 piksel, birkaç MB büyüklüğünde bir fotoğrafı 600 piksel genişliğinde gösteriyorsanız kullanıcı gereksiz veri indiriyor olabilir.

Yapılabilecekler:

• Gereken boyutta görsel kullanmak
• Sıkıştırmak
• WebP veya AVIF gibi modern formatları değerlendirmek
• Responsive Images kullanmak
• Görsellerin width ve height değerlerini tanımlamak
• Ekranın altında kalan görsellerde Lazy Loading kullanmak

Ama burada benim özellikle önemli gördüğüm bir denge var.

6. Hız uğruna ürün kalitesini bozmayın

Bazen PageSpeed puanını artırmak için görseller aşırı sıkıştırılıyor. Teknik tarafta dosya boyutu küçülüyor. Ama ürün görseli bulanıklaşıyor.

Özellikle e-ticarette bunun mantıklı olduğunu düşünmüyorum. Kullanıcı 10.000 TL’lik bir ürün alacak ama ürün fotoğrafında malzemenin detayını göremiyor.

PageSpeed puanından birkaç puan kazanıp ürün algısını ve dönüşümü bozduysak gerçekten bir şey kazanmış olduk mu? Bence hayır.

Performans optimizasyonunun amacı kullanıcı deneyimini iyileştirmek. Kullanıcı deneyimini bozarak performans puanı yükseltmek değil.

Bu nedenle her zaman dosya boyutu + görüntü kalitesi + kullanıcı ihtiyacı üçlüsünü birlikte düşünmek gerekiyor.

7. Lazy Loading nedir?

Sayfanın çok altında 20 görsel olduğunu düşünelim. Kullanıcı sayfayı açtığında bu 20 görselin tamamını aynı anda yüklemek zorunda değiliz. Ekranda görünmeye yaklaştıklarında yüklenebilirler.

Buna Tembel Yükleme (Lazy Loading) diyoruz. Bu özellikle uzun sayfalarda başlangıç yükünü ciddi biçimde azaltabilir.

Ama burada da yanlış kullanım mümkün. Sayfanın en üstünde kullanıcıya hemen gösterilecek ana görseli Lazy Loading ile geciktirirseniz bu kez LCP değerini kötüleştirebilirsiniz.

Yani her görseli otomatik olarak lazy-load yapmak da doğru değil.

8. JavaScript neden siteyi yavaşlatabilir?

Modern sitelerde JavaScript çok fazla kullanılıyor. Sepete ekleme, filtreleme, slider, popup, analitik, chat, kişiselleştirme ve birçok iş JavaScript ile yapılıyor.

Problem JavaScript kullanılması değil. Problem gereğinden fazla JavaScript çalıştırılması.

Örneğin sayfada şunlar aynı anda çalışıyorsa kullanıcının cihazında ciddi yük oluşturabilir:

• 4 farklı analiz aracı
• 3 reklam scripti
• Chat widget
• Heatmap
• A/B test aracı
• Sosyal medya pixel’leri
• Kullanılmayan tema kodları

Özellikle mobil cihazlarda bu daha belirgin hale gelir. Çünkü herkes son model bilgisayar ve hızlı internet kullanmıyor.

9. Üçüncü taraf scriptleri bazen görünmeyen hız problemi

Site geliştiricisine baktığınızda kendi kodunuz hızlı olabilir. Ama dışarıdan yüklenen kodlar çok yavaş olabilir.

Örneğin şunlar sayfayı ağırlaştırabilir:

• Google Tag Manager üzerinden çalışan onlarca etiket
• Meta Pixel
• Chat araçları
• Reklam servisleri
• Video embedleri
• Harici yorum servisleri
• Kişiselleştirme araçları

Bu nedenle performans analizi yaparken sadece kendi CSS ve JavaScript dosyalarımıza bakmak yeterli değil.

Sayfayı kimlerin yavaşlattığını görmek gerekiyor.

10. Google Tag Manager da kontrol edilmeli

Özellikle yıllardır çalışan projelerde Tag Manager konteynerleri zamanla çöplüğe dönüşebiliyor.

Bir kampanya yapılmış, kod eklenmiş. Kampanya bitmiş ama kod kalmış. Başka ajans gelmiş, yeni pixel eklemiş. Eski pixel kaldırılmamış. Bir süre sonra sayfa açıldığında kullanıcının haberi bile olmayan onlarca kod çalışıyor.

Bu yüzden hız çalışmasında Tag Manager tarafını da kontrol etmek gerekiyor. SEO, Ads, Analytics ve yazılım ekiplerinin burada birlikte çalışması gerekebilir.

11. Fontlar bile performansı etkileyebilir

Web sitesinde farklı fontlar kullanmak tasarım açısından güzel olabilir. Ama şunlar ek yük oluşturabilir:

• Çok fazla font ailesi
• Çok fazla font ağırlığı
• Harici sunucudan gelen fontlar
• Gereksiz karakter setleri

Örneğin sadece Regular ve Bold kullanıyorsanız 100, 200, 300, 400, 500, 600, 700, 800 ve 900 ağırlıklarının tamamını indirmeye gerek olmayabilir.

Küçük optimizasyonlar tek başına çok büyük fark yaratmayabilir ama site genelinde birleştiğinde anlamlı hale gelir.

Core Web Vitals nedir?

Google kullanıcıların sayfa deneyimini ölçebilmek için üç temel Core Web Vitals metriğini kullanıyor:

Google’ın güncel belgelerine göre Core Web Vitals, sıralama sistemlerinde kullanılan sayfa deneyimi sinyalleri arasında yer alıyor. Ancak Google aynı zamanda iyi Core Web Vitals sonuçlarının yüksek sıralama garantisi olmadığını ve sayfa deneyiminin tek bir sinyalden oluşmadığını özellikle belirtiyor (Google for Developers).

Bence SEO açısından doğru yaklaşım da bu:

Önemli ama SEO’nun tamamı değil.

12. Largest Contentful Paint (LCP)

LCP, kullanıcının ekranında görünen en büyük ana içerik öğesinin ne kadar sürede görüntülendiğini ölçüyor. Bu büyük bir ürün fotoğrafı, hero görseli, büyük bir başlık veya büyük bir içerik bloğu olabilir.

Google iyi bir kullanıcı deneyimi için LCP’nin 2,5 saniye veya altında olmasını hedefliyor (Chrome for Developers).

Örneğin ana sayfada dev bir banner kullanıyorsunuz. Görsel 4 MB. Sunucu geç cevap veriyor. Görsel de JavaScript ile sonradan çağrılıyor. Muhtemelen LCP kötü çıkacaktır.

Burada sadece resmi sıkıştırmak çözüm olmayabilir. Problemin hangi aşamada olduğunu anlamak gerekir.

LCP süreci kabaca şu bölümlerden oluşabilir:

• Sunucu cevabı
• Kaynağın keşfedilmesi
• Kaynağın indirilmesi
• Ekrana çizilmesi

Chrome’un performans araçları da LCP gecikmesini bu alt aşamalara ayırabiliyor (Chrome for Developers).

13. Interaction to Next Paint (INP)

INP sayfanın kullanıcı etkileşimlerine ne kadar hızlı cevap verdiğini ölçüyor.

Örneğin kullanıcı şunları yapıyor ama ekran uzun süre tepki vermiyorsa kullanıcı siteyi yavaş hisseder:

• Menüye tıklıyor
• Filtre seçiyor
• Sepete ekliyor
• Accordion açıyor
• Bir butona basıyor

Google iyi INP için 200 ms veya altını hedefliyor. 200–500 ms arası iyileştirme gerektiriyor, 500 ms üzeri ise kötü olarak değerlendiriliyor (Chrome for Developers).

INP özellikle ağır JavaScript kullanılan sitelerde önemli. Bir sayfa hızlı açılabilir ama kullanırken çok yavaş olabilir. Bu yüzden “sayfa 2 saniyede açılıyor” tek başına yeterli bir performans ölçüsü değil.

14. Cumulative Layout Shift (CLS)

CLS sayfadaki beklenmedik kaymaları ölçüyor.

Muhtemelen hepimiz yaşamışızdır. Bir haberi okuyorsunuz. Tam bir bağlantıya basacaksınız. Üstten reklam yükleniyor ve içerik aşağı kayıyor. Siz yanlış yere tıklıyorsunuz. Bu kötü bir kullanıcı deneyimi.

Google iyi CLS değeri için 0,1 veya altını öneriyor (Chrome for Developers).

CLS sorunları genellikle şu nedenlerle oluşabiliyor:

• Boyutu belirtilmemiş görseller
• Sonradan gelen reklam alanları
• Embed içerikler
• Font değişimleri
• JavaScript ile sonradan eklenen öğeler

15. PageSpeed Insights’taki 100 puan hedefimiz olmalı mı?

Bence hayır. 100 almak güzel olabilir ama SEO’nun amacı 100 almak değil.

Lighthouse performans puanı laboratuvar koşullarında yapılan ölçümlerden oluşturulan bir puan. Üstelik skor yükseldikçe birkaç puan daha artırmak için gereken efor ciddi şekilde artabiliyor; Lighthouse belgeleri de yüksek puanlarda azalan getiriden bahsediyor (Chrome for Developers).

Bir e-ticaret sitesi düşünün: PageSpeed 93. Dönüşüm oranı iyi. Core Web Vitals iyi. Kullanıcılar sorun yaşamıyor.

Sırf 100 yapmak için haftalarca geliştirme yapmak gerçekten en iyi yatırım mı? Belki. Ama çoğu projede muhtemelen SEO tarafında daha önemli işler vardır.

Teknik SEO’da her problem aynı önemde değil.

16. PageSpeed Insights ile Lighthouse aynı şey mi?

Tam olarak değil. PageSpeed Insights iki farklı veri türünü birlikte gösterebilir.

Birincisi gerçek kullanıcı verisi (Field Data). Bu veri Chrome Kullanıcı Deneyimi Raporu’ndan (Chrome UX Report – CrUX) geliyor ve gerçek Chrome kullanıcılarının deneyimlerinin toplulaştırılmış halini gösteriyor.

İkincisi laboratuvar verisi (Lab Data). Bu da Lighthouse tarafından kontrollü koşullarda yapılan test (Chrome for Developers).

Bu ayrım önemli. Çünkü Lighthouse size “Bu testte ne oldu?” sorusunun cevabını verirken CrUX daha çok “Gerçek kullanıcılar son dönemde ne yaşadı?” sorusuna cevap verir.

17. Lab Data ile Field Data neden farklı çıkıyor?

Çok normal.

Siz İstanbul’da hızlı internetle, güçlü bilgisayarda test yapıyor olabilirsiniz. Gerçek kullanıcı ise şunları kullanıyor olabilir:

• Eski Android telefon
• Yavaş mobil internet
• Farklı ülke
• Farklı cihaz
• Farklı bağlantı kalitesi

Bu nedenle laboratuvarda 95 puan alırken gerçek kullanıcı deneyimi kötü olabilir. Ya da tam tersi. Test anında sunucu geçici olarak yavaşlamıştır ama gerçek kullanıcı verileri gayet iyi olabilir.

Bu yüzden performans analizinde ikisini birlikte okumak gerekiyor.

18. Chrome UX Report (CrUX) neden önemli?

CrUX gerçek Chrome kullanıcılarından toplanan toplulaştırılmış performans verilerini içeriyor.

Core Web Vitals değerlendirmesi genellikle kullanıcıların 75. yüzdelik dilimine göre yapılıyor. Yani sadece ortalamaya bakmıyoruz. Kullanıcıların büyük çoğunluğunun iyi deneyim yaşamasını hedefliyoruz (Chrome for Developers).

Bu önemli. Çünkü ortalama bazen gerçeği gizleyebilir. 100 kullanıcının 80’i hızlı, 20’si inanılmaz yavaş deneyim yaşıyorsa ortalama kabul edilebilir çıkabilir. Ama gerçek kullanıcıların bir kısmı hâlâ ciddi sorun yaşıyordur.

19. Search Console Core Web Vitals raporu ne işe yarıyor?

Search Console, benzer kullanıcı deneyimi gösteren URL’leri gruplandırarak Core Web Vitals problemlerini görmemize yardımcı oluyor (Chrome for Developers).

Bu yüzden sadece ana sayfayı PageSpeed’e yazıp “Site hızlı.” demek doğru değil.

Ana sayfa hızlı olabilir. Ürün sayfaları yavaş olabilir. Blog hızlı olabilir. Kategori sayfalarında filtre sistemi problem çıkarabilir.

Özellikle büyük sitelerde şablon bazında değerlendirme yapmak daha doğru.

20. Mobil ve masaüstü neden farklı sonuç verebilir?

Çünkü kullanıcı koşulları farklı. Masaüstünde şunlar olabilir:

• Daha güçlü işlemci
• Daha iyi internet
• Daha büyük ekran
• Daha fazla kaynak

Mobilde ise JavaScript çalıştırmak daha pahalı hale gelebilir. Ayrıca kullanıcıların büyük kısmı mobildeyse bizim için gerçek iş problemi de mobil tarafta olabilir.

Bu yüzden performans raporunu sadece masaüstünden kontrol etmek yeterli değil.

21. HTTPS ve SSL hız konusu mu?

HTTPS’in asıl amacı hız değil, güvenlik.

Google web sitelerinin HTTPS kullanmasını tavsiye ediyor ve HTTPS sayfa deneyimi açısından önemli bir temel beklenti. Google ayrıca mümkün olduğunda HTTP yerine HTTPS URL’leri canonical olarak tercih ediyor (Google for Developers).

Günümüzde “HTTPS siteyi yavaşlatır mı?” tartışmasına çok takılmanın anlamlı olduğunu düşünmüyorum. Modern web altyapısında siteyi güvenli sunmak standart olmalı.

22. Hız bir sıralama faktörü mü?

Bu soru sık geliyor. Daha doğru ifade şu:

Google, Core Web Vitals’ı sıralama sistemlerinde kullandığını söylüyor. Ancak tek bir “Page Experience Score” veya “PageSpeed puanı” ile sıralama belirlenmiyor. İyi Core Web Vitals değerleri de üst sırada çıkmayı garanti etmiyor (Google for Developers).

Örneğin iki sayfa düşünelim.

Birinci sayfa:

• 100 PageSpeed
• Zayıf içerik
• Kullanıcı niyetine uymuyor

İkinci sayfa:

• 85 PageSpeed
• Çok iyi içerik
• Kullanıcının aradığı cevabı veriyor

“100 aldığı için ilk sayfa kesin daha üstte çıkar” diyemeyiz.

Google’ın sıralama sistemleri yüzlerce farklı sinyal ve sistemi birlikte değerlendiriyor (Google for Developers).

23. Çok hızlı ama kötü bir site mümkün mü?

Kesinlikle.

Boş bir HTML sayfası muhtemelen inanılmaz hızlıdır. Ama kullanıcıya hiçbir şey sunmaz. Bu yüzden teknik optimizasyonun amacı sadece milisaniye kovalamak olamaz.

Bence her optimizasyonda şu soruyu sormak gerekiyor:

Bu değişiklik gerçek kullanıcı deneyimini iyileştiriyor mu?

Örneğin:

• Görseli küçülttük ama ürün görünmüyor.
• Fontu kaldırdık ama marka kimliği bozuldu.
• JavaScript’i kaldırdık ama filtre çalışmıyor.
• Video kaldırdık ama ürün artık yeterince anlatılamıyor.

Teknik skor yükselmiş olabilir. İş sonucu kötüleşebilir.

24. Log analizi burada ne işe yarıyor?

Sunucu Log Analizi (Log Analysis) bize sunucuya gelen isteklerin kaydını inceleme imkânı verir.

Buradan örneğin şu gibi soruların cevabını araştırabiliriz:

• Googlebot hangi URL’leri tarıyor?
• Ne sıklıkta geliyor?
• 5xx hataları görüyor mu?
• Gereksiz URL’lerde çok zaman harcıyor mu?
• Önemli sayfalara yeterince geliyor mu?
• Sunucu cevap süreleri nasıl?

Özellikle büyük sitelerde hız ve tarama problemlerini birlikte anlamak için çok değerli olabilir. Ama 50 sayfalık küçük bir kurumsal sitede ilk iş log analizi yapmak çoğu zaman gerekli değildir.

Yine ölçeğe göre hareket etmek gerekiyor.

25. Site hızını düzeltirken ben hangi sırayla bakıyorum?

Her projede değişir ama genel yaklaşım şöyle olabilir:

• Önce gerçek kullanıcı verisi var mı bakarım.
• Mobil ve masaüstünü ayrı incelerim.
• Core Web Vitals problemini belirlerim.
• Problem hangi sayfa şablonunda yoğunlaşıyor bakarım.
• Sunucu cevabını kontrol ederim.
• Büyük görsellere bakarım.
• JavaScript ve CSS yükünü incelerim.
• Üçüncü taraf scriptleri kontrol ederim.
• Cache ve CDN yapılandırmasına bakarım.
• Değişikliklerden sonra tekrar ölçerim.

Burada önemli olan “PageSpeed bana 37 öneri verdi, hepsini yapalım” yaklaşımından kaçınmak. Önceliklendirmek gerekiyor.

26. 2 MB görselle 20 KB JavaScript aynı problem değil

PageSpeed raporu birçok öneri gösterebilir. Ama hepsinin etkisi aynı değildir.

Örneğin sayfanın LCP görseli 4 MB ise ilk olarak ona bakmak, kullanılmayan 8 KB CSS’i temizlemekten daha anlamlı olabilir. Ya da problem TTFB ise frontend tarafındaki küçük optimizasyonlar yeterli olmayabilir.

Teknik SEO’nun önemli taraflarından biri de burada ortaya çıkıyor:

Problemi bulmak değil, hangi problemin önce çözülmesi gerektiğini belirlemek.

27. Hız çalışması bir defalık iş değil

Siteye yeni özellikler ekleniyor. Yeni reklam araçları geliyor. Yeni tracking kodları ekleniyor. Yeni tasarım yapılıyor. Yeni görseller yükleniyor. Eklentiler değişiyor.

Bu nedenle bugün hızlı olan site altı ay sonra tekrar yavaşlayabilir. Özellikle büyük projelerde performansı dönemsel olarak takip etmek gerekiyor.

Sonuç olarak site hızına nasıl bakıyorum?

Bence üç farklı açıdan:

1. Kullanıcı ne hissediyor?

Sayfa hızlı açılıyor mu, tıklamalara hızlı cevap veriyor mu, içerik kayıyor mu?

2. Teknik olarak sorun nerede?

Sunucu mu, görsel mi, JavaScript mi, üçüncü taraf script mi?

3. İş açısından çözmeye değer mi?

Bu iyileştirmenin kullanıcıya, dönüşüme ve SEO’ya gerçek katkısı olacak mı?

Bence site hızında en büyük hata sadece üçüncü soruyu unutmak değil; ilk soruyu da unutmak.

PageSpeed skorunu iyileştirirken kullanıcıyı kaybetmemek gerekiyor.

Hedef 100 puan değil. Hızlı, stabil, kullanılabilir ve işini yapan bir web sitesi.

Önceki: 23. Bölüm, Google Siteleri Nasıl Tarıyor? · İçindekiler · Sonraki: 25. Bölüm, Google Sayfanızı Daha İyi Nasıl Anlıyor?

Bu bölümün ilk hali X’te yayınlandı (28 Eylül 2026).