Canlı Sitede PageSpeed 100/100: Neyi, Neden, Nasıl Yaptık
bdijital.com'un 17 Temmuz 2026 tarihli PageSpeed testinde alınan 100 puanı ve o sürümde uygulanan performans kararlarını inceliyoruz.
2026-08-07Bu sitenin ana sayfası için 17 Temmuz 2026 tarihli Google PageSpeed Insights testinde, mobil ve masaüstünde performans, erişilebilirlik, en iyi uygulamalar ve SEO kategorilerinin tamamında 100/100 ölçüldü. LCP mobilde 1,0 saniye, masaüstünde 0,3 saniye çıktı. Sonuçları o tarihli test raporunda inceleyebilirsiniz.
Güncelleme notu: Anasayfa bu ölçümden sonra yenilendi. Aşağıdaki sonuçlar ve arayüz açıklamaları test edilen sürüme aittir; bugünkü performansı değerlendirmek için yeni ölçüm gerekir.
Bu yazı, ölçülen sürümde uyguladığımız mimari kararları anlatıyor. Benzer bir yaklaşımın başka bir sitede sağlayacağı kazanımı o sitenin başlangıç ölçümleri ve teknik koşulları belirler.

Neden Umursamalısınız?
Hız, teknik bir gurur meselesi değil; doğrudan para meselesi:
- Reklam bütçesi: Tıklama başına ödeme yaptığınız ziyaretçi, sayfa 4 saniyede açıldığı için ayrılıyorsa bütçe çöpe gidiyor demektir.
- Google sıralaması: Core Web Vitals, Google’ın sıralama sistemlerinde kullanılan sinyaller arasındadır. Ancak iyi puanlar tek başına yüksek sıralama sağlamaz; Google’ın açıklaması sayfa deneyiminin farklı yönlerini birlikte değerlendirmeyi önerir.
- Güven: Mobilde anında açılan bir site, daha ilk saniyede “bu işi biliyorlar” hissi verir. Yavaş açılan bir ajans sitesi ise kendi hizmetinin karşı reklamıdır.
Sonucu Üreten Beş Karar
1. HTML’i ziyaret anında değil, yayın anında üretmek
Test edilen sürüm Astro ile statik olarak derleniyordu: her sayfanın HTML’i yayın sırasında hazırlanıyordu. Böylece sayfa isteğinde veritabanı sorgusu veya şablon işleme gerekmiyordu. Sayfalar Cloudflare’in dağıtım ağı üzerinden sunuluyordu.
2. Ana ekranı görselle değil, kodla çizmek
Test edilen anasayfadaki animasyonlu panel HTML ve CSS ile çizilmişti. Bu tercih, panel için ayrı bir büyük görsel dosyası indirme ihtiyacını kaldırıyordu. Kullanılan görseller WebP olarak hazırlanmış, ilk ekranın altındakiler lazy loading ile yüklenmişti. Bugünkü anasayfada kullanılan ekran görüntüleri bu eski panelden farklıdır.
3. Yerleşimi baştan sabitlemek
Görsellerin genişlik ve yüksekliği HTML’de tanımlanmıştı. Böylece tarayıcı dosya yüklenmeden önce yer ayırabiliyor, görsel yüklemesinden kaynaklanan yerleşim kaymaları azaltılıyordu. CLS sonuçlarını değerlendirirken diğer dinamik içeriklerin etkisini de kontrol etmek gerekir.
4. JavaScript’i istisna haline getirmek
Test edilen sayfada ağır bir framework paketi veya üçüncü taraf eklenti yığını yoktu. Etkileşim için gereken betikleri sınırlı tutmak, tarayıcının ana iş parçacığındaki yükü azaltıyordu. Eklenen her betiğin etkisi ölçümle değerlendirilmişti.
5. Önbelleği agresif, HTML’i taze tutmak
Ölçülen sürümde statik varlıklar (CSS, JS, ikonlar) uzun süreli önbellek başlıklarıyla sunuluyor, HTML her yayında tazeleniyordu. Yeniden indirilecek veri miktarı, tarayıcıdaki önbelleğin durumuna ve değişen dosyalara bağlıydı.
“Bizim Site Neden Yavaş?”
Müşteri sitelerinde en sık gördüğümüz dört neden:
- Her sayfa görüntülemede sıfırdan HTML üreten, önbelleksiz kurulumlar
- 3-5 MB’lık, boyutlandırılmamış görseller
- Analitik, sohbet, ısı haritası derken birikmiş üçüncü taraf betikleri
- Tema/eklenti kalabalığının getirdiği kullanılmayan CSS ve JS yükü
Bu sorunlar her zaman siteyi baştan yazmayı gerektirmez; uygun müdahale mevcut altyapıya göre belirlenir. Çalışmaya ölçümle başlıyor, sorunları etkilerine göre sıralıyor ve değişiklikleri öncesi-sonrası raporlarıyla değerlendiriyoruz. Raporlarda test tarihi ve koşullarının açıkça belirtilmesi, farklı sürümlerin sonuçlarını doğru karşılaştırmayı sağlar.
Sitenizin mevcut durumunu görmek isterseniz site hızı optimizasyonu sayfasına bakabilir veya bize yazabilirsiniz; ilk ölçümü birlikte yapalım.