Siteniz neden yavaş açılıyor? Sekiz neden, nasıl anlaşılır.

Bir sitenin yavaş açılmasının en sık nedenleri sunucunun geç yanıt vermesi, adresin birkaç kez yönlenmesi, büyük görseller, sayfayı bekleten stil ve betik dosyaları, fazla JavaScript, üçüncü taraf kodlar, yazı tipleri ve telefonun işlemcisidir. Hangisinin sizin sitenizde geçerli olduğu tahminle değil, ücretsiz üç araçla anlaşılır: PageSpeed Insights, Search Console ve tarayıcının ağ sekmesi.

«Site yavaş» tek bir şikâyet gibi duyulur ama ziyaretçi üç ayrı şeyi yavaşlık diye yaşar: ekranın uzun süre boş kalması, sayfa gelse bile tıklamaya geç cevap vermesi ve içeriğin yüklenirken yerinden zıplaması. Google bu üçünü Core Web Vitals adıyla ayrı ayrı ölçer: ana içeriğin görünme süresi (LCP), etkileşime cevap süresi (INP) ve düzen kayması (CLS). web.dev’in tanımına göre iyi sayılan sınırlar sırasıyla 2,5 saniye, 200 milisaniye ve 0,1’dir; ölçü, ziyaretlerin yüzde 75’inde bu sınırın tutup tutmadığına bakar.

Bu yazı siteyi yaptıran tarafın sorusuyla yazıldı: yavaşlığın nedenini ben nasıl anlarım, web ekibime ne sorarım? Her neden için kendi başınıza yapabileceğiniz bir kontrol var. Teknik ayrıntı web performansı rehberinde; ölçümü ve düzeltmeyi bizim yapmamızı isterseniz site hızı optimizasyonu sayfası yöntemi anlatıyor.

Yavaşlığa hangi araçlarla bakılır?

Üç ücretsiz araç yeter ve her biri farklı bir soruya cevap verir. Birincisi PageSpeed Insights: sayfanın adresini yazarsınız; üst bölüm gerçek Chrome kullanıcılarından toplanmış son 28 günün verisini, alt bölüm tek bir benzetilmiş telefonda yapılan laboratuvar testini gösterir. Alt bölümdeki 0–100 arası puan her koşumda biraz değişir; nedenini site hızı nasıl ölçülür yazısında anlattık.

İkincisi Search Console’un Core Web Vitals raporu. Tek bir sayfaya değil bütün siteye bakar: adresleri benzer sayfa grupları hâlinde kötü, iyileştirme gereken ve iyi diye ayırır, mobil ve masaüstünü ayrı raporlar. Hangi sayfa ailesinin sorunlu olduğunu buradan görürsünüz. Üçüncüsü tarayıcının kendi geliştirici araçlarındaki Ağ (Network) sekmesi: Chrome’da F12 ile açılır, «Disable cache» (önbelleği kapat) kutusu işaretlenip sayfa yenilendiğinde inen her dosya tek satır olarak listelenir; en alttaki özet satırı toplam istek sayısını, aktarılan veriyi ve yükleme süresini verir.

1 · Sunucu mu geç yanıt veriyor?

Tarayıcı adresi istedikten sonra sunucudan ilk baytın gelmesine kadar geçen süreye ilk bayt süresi (TTFB) denir ve sayfanın geri kalanı bu sürenin üstüne biner. web.dev çoğu sitenin 0,8 saniye ya da altını hedeflemesini önerir. Uzun sürmesinin tipik nedenleri kalabalık bir paylaşımlı sunucu, her istekte sayfayı veritabanından yeniden üreten bir yapı ve ziyaretçiye uzak bir sunucudur.

Nasıl anlaşılır: Ağ sekmesinde listenin en üstündeki satır sayfanın kendisidir. Üstüne tıklayıp Timing (zamanlama) bölümüne geçtiğinizde «Waiting for server response» satırı bu süreyi gösterir. Birkaç yenilemede sürekli uzunsa sorun tasarımda değil sunucu tarafındadır. Ayrıntı: TTFB ve sunucu yanıtı.

2 · Adres kaç kez yönleniyor?

Ziyaretçi «http://firmaniz.com» yazdığında tarayıcı önce https’e, sonra www’li adrese, sonra sonunda eğik çizgi olan adrese yönlenebilir. Her yönlendirme ayrı bir gidiş dönüştür ve sayfa henüz istenmemiştir bile. Eski kampanya bağlantıları ve önceki sitenin adresleri bu zinciri uzatır.

Nasıl anlaşılır: Ağ sekmesinde «Preserve log» (günlüğü koru) kutusunu işaretleyin ve adresi en uzun hâliyle, http ve www’siz yazın. Durum sütununda 301, 302, 307 gibi satırlar yönlendirmelerdir; sayfanın kendisine ulaşmadan önce birden fazla varsa zincir var demektir. Bu sitede 22 Ağustos 2026’da Google 93 adres biliyordu, oysa sitede 58 sayfa vardı: aradaki fark www’siz, http, sonu eğik çizgisiz ve «/index.html» ile biten aynı sayfalardı. Hepsi kalıcı yönlendirmeyle tek adrese toplandı.

3 · Görseller gereğinden büyük mü?

Telefon ekranında birkaç yüz piksel genişlikte görünen bir fotoğraf, fotoğraf makinesinden çıktığı boyutta yüklenmişse ziyaretçi görmediği pikselleri indirir. Sayfanın en büyük görseli çoğu zaman aynı zamanda LCP öğesidir; o geç gelirse sayfa geç açılmış sayılır.

Nasıl anlaşılır: PageSpeed Insights’ın teşhis bölümü LCP öğesinin hangisi olduğunu gösterir. Ağ sekmesinde Img (görsel) süzgecini seçip Size (boyut) sütununa göre sıralarsanız en ağır dosyalar en üste çıkar. Tek bir görsel sayfanın geri kalanının toplamından ağırsa ilk bakılacak yer orasıdır.

4 · Sayfa bir dosyayı bekliyor mu?

Tarayıcı, sayfanın başında çağrılan stil dosyalarını ve bazı betikleri indirip işlemeden ekrana hiçbir şey çizmez. Bunlara render engelleyen kaynaklar denir. Sayısı arttıkça ve her biri başka bir sunucudan geldikçe boş ekran uzar.

Nasıl anlaşılır: PageSpeed Insights bu dosyaları teşhis bölümünde ayrıca listeler. Ağ sekmesinin sağındaki Waterfall (şelale) sütununda, sayfanın ilk çizilmesinden önce kaç stil ve betik dosyasının indiğini görürsünüz; uzun bir merdiven, bekleyen bir sayfa demektir.

5 · Sayfada fazla JavaScript mi var?

JavaScript’in maliyeti yalnız indirilmesi değildir: telefon onu ayrıştırır, derler ve çalıştırır; bu sırada sayfa tıklamalara cevap veremez. Kullanıcının «tıkladım ama bir şey olmadı» hissi çoğu zaman buradan gelir ve INP ölçüsünde görünür. Slayt gösterileri, animasyon kütüphaneleri ve sayfa oluşturucular JavaScript yükünü büyüten tipik kalemlerdir.

Nasıl anlaşılır: Ağ sekmesinde JS süzgeciyle toplam betik boyutunu görürsünüz. Geliştirici araçlarındaki Coverage (kapsam) paneli, inen kodun ne kadarının o sayfada hiç kullanılmadığını gösterir. PageSpeed’in laboratuvar bölümündeki toplam engelleme süresi (Total Blocking Time) de bu yükün laboratuvardaki karşılığıdır. Bir üst sınır koymanın yolu: JavaScript bütçesi.

6 · Üçüncü taraf kodlar ne kadar yük getiriyor?

Canlı sohbet balonu, reklam ve ölçüm etiketleri, gömülü harita ve video, sosyal medya akışı: bunların hepsi başka bir firmanın sunucusundan gelir ve hızını siz belirlemezsiniz. Her biri tek başına küçük görünse de birlikte sayfanın en ağır kısmı olabilirler.

Nasıl anlaşılır: Ağ sekmesinde sütun başlığına sağ tıklayıp Domain (alan adı) sütununu açın. Kendi alan adınız dışındaki satırlar üçüncü taraf kodlardır; kaç tane olduklarını ve ne kadar veri indirdiklerini buradan sayarsınız. Sorulacak soru teknik değil ticaridir: her biri bir iş karşılığı veriyor mu, her sayfada mı gerekli?

7 · Yazı tipleri mi bekletiyor?

Markaya özel yazı tipleri güzeldir ama her aile ve her kalınlık ayrı bir dosyadır. Dosya gelene kadar metin ya hiç görünmez ya da yedek bir yazı tipiyle çizilip sonradan değişir; ikinci durumda satırlar kayar.

Nasıl anlaşılır: Ağ sekmesinde Font süzgecini seçin ve dosya sayısına bakın. Sayfayı yavaş bağlantıda açtığınızda metnin önce görünmeyip sonra belirdiğini ya da yazı tipi değişirken satırların oynadığını görüyorsanız neden budur.

8 · Masaüstünde hızlı, telefonda neden yavaş?

Aynı sayfa telefonda çoğu zaman daha yavaştır ve bunun asıl nedeni ağ değil işlemcidir: orta sınıf bir telefon aynı JavaScript’i bir dizüstü bilgisayardan çok daha uzun sürede çalıştırır. Masaüstünde ölçüp «hızlıyız» demek bu yüzden yanıltıcıdır.

Nasıl anlaşılır: PageSpeed Insights sonucu açıldığında mobil sekmesinde gelir; masaüstü sekmesiyle karşılaştırın. Search Console da mobil ve masaüstünü ayrı raporlar. Fark büyükse yukarıdaki beşinci ve altıncı nedenlere öncelik verin.

Sayfa hızlı açılıyor ama zıplıyorsa?

Bu yavaşlık değil düzen kaymasıdır, ama ziyaretçi onu da kötü bir deneyim olarak yaşar: okuduğu satır kayar, tıklamak istediği düğmenin yerine başka bir şeye basar. En sık nedeni boyutu bildirilmemiş görseller ve sonradan yerleşen bantlardır. Sayfanızın bir bölümünün kaynak kodunu düzen kayması riski denetçisine yapıştırırsanız araç yeri önceden ayrılmamış görsel, video ve çerçeveleri tek tek listeler.

Neden tahmin değil ölçüm?

Çünkü yavaşlığın nedeni çoğu zaman ilk bakılan yerde değildir. Bu sitede bir turun ardından ana sayfanın engelleme süresi birden arttı; ilk şüpheli, o turda eklenen JavaScript’ti. Tarayıcı izi başka bir şey söyledi: toplam engelleme süresinin yaklaşık yüzde 70’i tek bir CSS seçicisinden geliyordu ve o seçici o sayfada hiçbir şeyi boyamıyordu. Hikâyenin tamamı bir :has() seçicisinin engelleme süresine etkisi yazısında.

Aynı dersi başka bir yönden de gördük: sitede kaydırmayı yöneten iki kütüphane kaldırıldığında sıkıştırılmış JavaScript 51,1 kilobayttan 33,5 kilobayta indi, çünkü o işi tarayıcının kendisi yapabiliyordu. Bugün bu sitede laboratuvar performans puanının ortancası 99, toplam engelleme süresinin ortancası 21 milisaniye, laboratuvar düzen kayması 0; gerçek bir Chrome tarayıcısıyla canlı adresten ölçülen en kötü LCP 420 milisaniye. Kendimize koyduğumuz sınır 0,8 saniye ve her yayından önce ölçülüyor.

Yavaşlığın nedeni tahmin edilmez; izde görünür.

Nedeni bulduktan sonra ne yapmalı?

Sıra önemli. Önce Search Console’da hangi ölçünün, hangi sayfa grubunda ve mobilde mi masaüstünde mi kırık olduğuna bakın. Sonra o gruptan bir sayfayı PageSpeed Insights’ta açın ve teşhis bölümünü okuyun. En son Ağ sekmesiyle yukarıdaki sekiz nedenden hangisinin öne çıktığını doğrulayın. Siteniz WordPress’le kuruluysa eklenti, tema ve sunucu payını ayırmanın yöntemi ayrı bir yazıda: WordPress site yavaş açılıyor.

Web ekibinizle ya da dışarıdan bir uzmanla konuşurken şu sorular işe yarar:

• Hangi ölçü kırık — LCP mi, INP mi, CLS mi — ve bu saha verisinden mi, laboratuvar testinden mi geliyor?
• Sorun hangi sayfa grubunda ve mobilde mi, masaüstünde mi?
• Nedeni neye dayanarak söylüyorsunuz — bir tarayıcı izine mi, bir tahmine mi?
• Düzeltmeden sonra aynı ölçüm aynı koşullarda tekrarlanacak mı?
• Yeni bir eklenti ya da görsel eklendiğinde hızın yeniden bozulmasını ne engelleyecek?

Son soru en çok atlanandır. Hız bir kez düzeltilip bırakılırsa her yeni eklenti, her yeni kampanya görseli onu biraz geri alır. Kalıcı çözüm, sitenin aşamayacağı sınırları yazmak ve her yayında ölçmektir.