Web Sayfası Hızlandırma: Tahminle Değil Ölçerek Başlayın

Web sayfası hızlandırma çalışmaları çoğu ekipte yanlış yerden başlar. "Site yavaş" şikâyeti, yazılım ekiplerinin en sık duyduğu cümledir ve en sık yanlış çözülen problemdir. Çünkü çözüm genelde tahminle başlar: sunucu yükseltilir, kod sadeleştirilir, önbellek eklenir. Oysa doğru yöntem tek bir sırayla ilerler: önce ölç, sonra en büyük kalemi düzelt, sonra tekrar ölç.

Adım 1: Sorunun katmanını bulun

Toplam süre ikiye ayrılır: sunucunun ilk yanıtı üretme süresi ve tarayıcının sayfayı çizme süresi. Geliştirici araçlarının ağ sekmesinde ilk isteğin bekleme süresine bakın.

• İlk yanıt 800 ms üzerindeyse: Sorun sunucu tarafındadır; veritabanı ve uygulama koduna bakılmalıdır.
• İlk yanıt hızlı ama sayfa geç görünüyorsa: Sorun ön yüzdedir; görseller, betikler ve yazı tipleri incelenmelidir.

Bu ayrımı yapmadan başlanan her optimizasyon, yanlış katmanda harcanan emektir.

Adım 2: Veritabanı — en sık suçlu

Sunucu tarafı yavaşlığının büyük bölümü veritabanından gelir ve genellikle iki nedenden biridir:

N+1 sorgu problemi: Liste çekilir, sonra her satır için ayrı sorgu çalıştırılır. 100 satırlık bir sayfa 101 sorgu üretir. Çözüm, ilişkili veriyi tek sorguda birleştirmek veya toplu olarak önceden yüklemektir. Bu tek düzeltme, çoğu sayfada süreyi yarıya indirir.

Eksik index: Filtreleme ve birleştirme yapılan sütunlarda index yoksa, veritabanı tabloyu baştan sona tarar. Sorgunun başına EXPLAIN yazarak taranan satır sayısını görebilirsiniz.

Bir de sessiz bir üçüncü neden vardır: gereğinden fazla veri çekmek. Listede beş sütun gösterilirken tablodaki otuz sütunun tamamını çekmek, hem ağ hem bellek maliyeti yaratır.

Adım 3: Önbellek — ama doğru yerde

Önbellek, aynı sonucu tekrar tekrar hesaplamayı önler. İyi adaylar: kategori listeleri, ayar değerleri, menü yapıları, ağır rapor sonuçları, dış servislerden gelen ve sık değişmeyen veriler.

Kötü adaylar: kullanıcıya özel anlık veriler, stok ve bakiye gibi doğruluğu kritik bilgiler. Önbellek eklerken en önemli karar, geçersiz kılma stratejisidir: veri değiştiğinde önbellek nasıl temizlenecek? Bu sorunun cevabı yoksa, önbellek eklemeyin.

Sık yapılan hata: Önbelleği çözüm sanmak. Yavaş bir sorguyu önbelleğe almak, sorguyu hızlandırmaz; yalnızca yavaşlığı ilk isteğe erteler.

Adım 4: Görseller

Ön yüz ağırlığının çoğu görsellerden gelir. Uygulanabilir dört adım:

1. Sunucu tarafında boyutlandırın. 300 piksellik alana 3.000 piksellik görsel göndermeyin.
2. Modern biçimler kullanın; aynı görsel WebP ile belirgin biçimde küçülür.
3. Ekranda görünmeyen görselleri tembel yükleyin (loading="lazy").
4. Genişlik ve yükseklik değerlerini belirtin; böylece yükleme sırasında düzen kayması olmaz.

Adım 5: Betikler, stiller ve yazı tipleri

Sayfanın çizimini engelleyen kaynaklar gecikmenin görünür nedenidir. Kritik olmayan betikleri ertelenmiş yükleyin, kullanılmayan kütüphaneleri kaldırın ve yazı tiplerini sınırlayın. Üç farklı yazı tipi ailesinin dört ağırlığını yüklemek, tek başına yüzlerce kilobayt eder.

Ayrıca üçüncü parti betikler (analitik, sohbet, reklam) sayfanın kontrolünüz dışındaki en yavaş parçasıdır. Her birinin gerçekten gerekli olup olmadığını sorgulayın.

Adım 6: Sunucu ve aktarım katmanı

Sıkıştırmanın açık olduğundan, statik dosyalar için tarayıcı önbelleği başlıklarının verildiğinden ve modern HTTP sürümünün kullanıldığından emin olun. Coğrafi olarak dağınık kullanıcı kitlesi varsa içerik dağıtım ağı, ilk bayt süresini gözle görülür biçimde düşürür.

Algılanan hız: gerçek süreden daha önemli

Kullanıcı milisaniye ölçmez; bekleyip beklemediğini hisseder. Bu yüzden bazı iyileştirmeler teknik süreyi değiştirmeden deneyimi belirgin biçimde düzeltir.

Üç teknik özellikle etkilidir. Birincisi, iskelet ekranlar: veri gelmeden sayfanın yapısını göstermek, boş beyaz ekrandan çok daha hızlı hissettirir. İkincisi, iyimser güncelleme: kullanıcı bir kaydı beğendiğinde sunucudan yanıt beklemeden arayüzü güncellemek, hata durumunda geri almak. Üçüncüsü, öncelik sırası: ekranın üst kısmındaki içeriği önce yükleyip alt kısmı ertelemek.

Buna karşılık ters yönde çalışan bir tuzak vardır: yükleniyor animasyonlarını gereğinden uzun göstermek. 200 milisaniyeden kısa işlemlerde animasyon göstermek, işlemi daha yavaş hissettirir.

Gerçek kullanıcı ölçümü

Laboratuvar testleri iyi bir başlangıçtır ama gerçek kullanıcılar farklı cihaz ve bağlantılarla gelir. Sahadan toplanan ölçümlerde ortalamaya değil, yüzdelik dilimlere bakın: kullanıcıların yüzde onu ne kadar bekliyor? Ölçütlerin tanımları için web.dev Core Web Vitals sayfası temel kaynaktır.

Sonuç

Performans çalışması, tahmini ölçümle değiştirme disiplinidir. Katmanı belirleyin, en büyük kalemi düzeltin, sonucu ölçün ve tekrarlayın. Bu döngüyle çalışan ekipler, genellikle sunucu yükseltmeden de hedeflenen hıza ulaşır; çünkü asıl sorun neredeyse her zaman kapasitede değil, kurguda olur.