Site Hızı Optimizasyonu: Uygulamalı Bir İş Sırası
Site hızı çalışmasının güçlü bir Pareto şekli var: çoğu sitede iyileşmenin çoğunu az sayıda düzeltme sağlıyor ve bunlar neredeyse her zaman görseller, sunucu yanıtı ve üçüncü taraf betikleri oluyor.
Bu rehber hangi sırayla çalışacağınızı, bir değişikliğin işe yarayıp yaramadığını nasıl ölçeceğinizi ve genelde emeğe değmeyen optimizasyonları ele alıyor.
Bir şeyi değiştirmeden önce ölçün#
Ölçmeden optimize etmek, yavaş olanı değil kolay olanı düzeltmek demektir. İki ölçüm, sonra iş.
- Gerçek ziyaretçiler için saha verisi alın — Search Console’daki Core Web Vitals raporu ya da kendi izlemeniz.
- En önemli üç şablonda 4G’de orta seviye bir telefona kısıtlanmış bir laboratuvar testi çalıştırın.
- Başlamadan önce rakamları kaydedin. Referans olmadan bir değişikliğin işe yarayıp yaramadığını bilemezsiniz.
- Her şablonda en büyük tek varlığı ve en büyük tek engelleyici isteği belirleyin.
- Time to First Byte’ı ayrıca not edin: 800 ms üzerindeyse hiçbir front-end işi sizi kurtarmaz.
Kazandıran sıra#
Tipik bir içerik ya da tanıtım sitesi için, kabaca harcanan saat başına iyileşmeye göre.
| İş | Tipik kazanç | Emek |
|---|---|---|
| Görselleri optimize edip doğru boyutlamak | Büyük | Düşük |
| Kullanılmayan üçüncü taraf betiklerini kaldırmak | Büyük | Düşük — çoğunlukla siyasi bir iş |
| Önbellek ve CDN açmak | Büyük | Düşük |
| Çizimi engelleyen CSS ve JS’i düzeltmek | Orta–büyük | Orta |
| JavaScript paketini küçültmek | Orta–büyük | Orta–yüksek |
| Yavaş veritabanı sorgularını düzeltmek | Geçerli olduğu yerde büyük | Orta |
| Yazı tipi yüklemeyi optimize etmek | Orta | Düşük |
| Metin varlıklarını küçültüp sıkıştırmak | Küçük | Düşük — genelde zaten açık |
| CSS seçicilerini mikro-optimize etmek | İhmal edilebilir | Yapmaya değmez |
Görseller: genelde en büyük kazanç#
Çoğu sitede görseller sayfa ağırlığının çoğunluğudur ve çoğu gösterildiği boyutun birkaç katında sunulur. Bu, mevcut en ucuz büyük iyileştirmedir.
- WebP ya da AVIF sunun; ikisi de geniş desteklidir ve eşdeğer kalitede JPEG’den genelde %25–50 küçüktür.
- Birden çok boyut üretin ve srcset ile sizes kullanın ki telefonlar telefon boyutunda dosya indirsin.
- 400px’lik bir alana asla 2000px’lik görsel sunmayın — bu tek hata son derece yaygın.
- Katlamanın altındaki her şeyi geç yükleyin, üstündeki hiçbir şeyi yüklemeyin.
- Derlemede ya da CMS’te otomatikleştirin. Elle optimize edilen görseller, başkası bir tane yüklediği an optimize olmaktan çıkar.
- Meta veriyi temizleyin; kamera EXIF verisi dosya başına onlarca kilobayt olabilir.
Asıl mesele otomasyon. Tek seferlik bir optimizasyon geçişi yeni içerik eklendikçe aylar içinde bozulur ve sayfa ağırlığı ikiye katlanana kadar kimse fark etmez.
Üçüncü taraf betikleri ve sunucu#
Sorunun genelde teknik değil kurumsal olduğu iki alan: etiket yöneticisinin sahibi yok ve hosting kararının sahibi yok.
| Sorun | Ne yapmalı |
|---|---|
| Bilinmeyen etiketlerle dolu etiket yöneticisi | Her etiketi denetleyin; kimsenin gerekçelendiremediğini silin |
| Her sayfada yüklenen sohbet widget’ı | Etkileşimde yükleyin ya da yalnız destek gereken sayfalarda |
| Birden çok analitik aracı | Bir tane tutun; her biri tam bir betik ve bir bağlantı |
| Çizimi engelleyen A/B test betiği | Sunucu tarafına taşıyın ya da bir titremeyi kabul edip async yükleyin |
| Paylaşımlı hostingde yavaş TTFB | Tam sayfa önbelleği ekleyin; sürerse paketi yükseltin |
| Önbelleklenmemiş veritabanı sorguları | Pahalı olanları önbellekleyin; yaygın olanlara indeks ekleyin |
| CDN yok | Ekleyin — mevcut en ucuz küresel gecikme düzeltmesi |
Üçüncü taraf betikleri açıklanamayan yavaşlamaların en güvenilir kaynağıdır, çünkü size haber vermeden değişirler ve dağıtım sürecinizin dışındadırlar.
Sık sorulan sorular
İyi bir sayfa yüklenme süresi nedir?
İşe yarayan hedefler tek bir yüklenme sayısı değil Core Web Vitals eşikleridir: LCP 2,5 saniyenin altında ve Time to First Byte 800 ms’nin altında. Toplam yüklenme süresi kötü bir ölçüdür, çünkü bir sayfa her varlık bitmeden çok önce kullanılabilir ve yavaş bir cihazda ondan çok önce kullanılamaz olabilir.
Daha hızlı bir site dönüşümü artırır mı?
Genelde evet ve etki, sayfaların hâlihazırda yavaş olduğu ve ziyaretçilerin mobil ağda olduğu yerde en büyüktür. Üç saniyeden ikiye inmenin kazancı, bir buçuktan bire inmekten çok daha büyüktür. Siteniz zaten hızlıysa emeği içeriğe ve netliğe harcayın — getirisi daha iyidir.
Önbellek eklentileri her şeyi çözer mi?
Gerçek bir şeyi iyi çözerler — aynı sayfa için tekrarlanan sunucu işini — ve özellikle oturum açmış kullanıcılar, sepetler ve formlarla yeni sorunlar yaratabilirler. Ayrıca genelde daha büyük sorunlar olan büyük görseller ve üçüncü taraf betikleri konusunda hiçbir şey yapmazlar. Faydalı, ama yeterli değil.
Sunucu tarafında çizim hız için değer mi?
Sayfalarınız şu an yalnız tarayıcıda üretiliyorsa evet: sunucuda çizim ya da statik üretim, içerik görünmeden önceki bir tam gidiş dönüşü ortadan kaldırır ve aynı anda indekslemeye de yardım eder. Sayfalarınız zaten sunucuda üretilmiş HTML ise soru geçerli değil — faydayı zaten alıyorsunuz.
site hızı optimizasyonusayfa hızıwebsite performansıgörsel optimizasyonuönbelleklemecdn
