Site hızı optimizasyonu listelerinin çoğunun ortak sorunu, maddeleri etki sırasına göre değil kolaylık sırasına göre dizmeleridir. Sonuçta bir öğleden sonranı görsel sıkıştırmaya harcarsın, sayfa 200 milisaniye hızlanır ve asıl sorun olan önbelleksiz çalışan uygulama katmanına hiç dokunmamış olursun. Bu liste tam tersini yapıyor: maddeler kazanç büyüklüğüne göre dizildi, yani yukarıdan aşağı uyguladığında en büyük kazancı en başta alırsın.
Bir uyarıyla başlayayım. Bu liste bir teşhis aracı değildir; teşhisin yerine geçmez. Sorunun hangi katmanda olduğunu bilmiyorsan önce yavaş site teşhis akışı yazısındaki eleme adımlarını uygula, darboğazı bul, sonra bu listede o katmanın bölümüne gel. Körlemesine tüm maddeleri uygulamak zaman kaybı olmanın ötesinde risklidir; birbiriyle çelişen ayarlar açıp sonra hangisinin neye yol açtığını çözemezsin.
Listeyi Nasıl Kullanmalısın#
Üç kural var ve üçü de deneyimle öğrenilen türden.
Önce ölç, sonra değiştir, tekrar ölç. Her maddeden önce mevcut durumu kaydet. Karşılaştırma noktası olmadan yaptığın işin bir kazanç mı yoksa kayıp mı olduğunu bilemezsin. Basit bir başlangıç ölçümü şudur:
# Değişiklik öncesi ve sonrası aynı komutu çalıştır, sonuçları kaydet
for i in 1 2 3 4 5; do
curl -o /dev/null -s -w "ttfb=%{time_starttransfer} toplam=%{time_total} boyut=%{size_download}\n" \
"https://firmaniz.com/?nocache=$(date +%s%N)"
done
Tek seferde tek değişiklik yap. Aynı anda önbellek açıp PHP sürümü yükseltirsen, sonuç iyi çıksa bile hangisinin işe yaradığını bilemezsin; kötü çıkarsa hangisini geri alacağını da bilemezsin.
Geri dönüş yolunu hazırla. Yapılandırma dosyalarını değiştirmeden önce yedekle. Bir satırlık bir ayar sitenin tamamını durdurabilir ve o an geri alabilmek her şeyden değerlidir.
# Değiştireceğin her yapılandırma dosyasını tarihli olarak yedekle
cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.$(date +%F-%H%M)
1. Sunucu ve Altyapı Katmanı#
Bu katman ilk sırada çünkü buradaki bir sorun, alt katmanlardaki tüm iyileştirmeleri anlamsız kılar.
- PHP sürümünü güncelle. Eski bir PHP sürümünden güncel bir sürüme geçmek, hiçbir kod değişikliği gerektirmeden belirgin bir hız kazancı verir. Uyumluluğu önce bir test ortamında doğrula.
- OPcache'in açık ve yeterli boyutta olduğunu doğrula. Kapalıysa her istek tüm PHP dosyalarını yeniden derliyor demektir.
- PHP-FPM havuz ayarlarını belleğe göre boyutlandır.
pm.max_childrendeğerini rastgele değil, tek bir işçinin ortalama bellek tüketimine bölerek hesapla. - Kaynak doygunluğunu kontrol et. Yük ortalaması, bellek ve disk beklemesi normal aralıkta mı; ölçüt için load average nasıl okunur yazısındaki normalizasyon kuralını kullan.
- Disk doluluğunu kontrol et. Yüzde 90'ı geçmiş bir disk her şeyi yavaşlatır ve bazı servisleri tamamen durdurur.
# OPcache durumu ve isabet oranı
php -i | grep -E "opcache.enable|opcache.memory_consumption|opcache.max_accelerated_files"
# Bir FPM işçisinin ortalama bellek tüketimi (MB)
ps --no-headers -o rss -C php-fpm8.2 | awk '{t+=$1; n++} END {printf "ortalama=%.0f MB isci=%d\n", t/n/1024, n}'
# Disk ve inode doluluğu
df -h; df -i
2. Önbellek Katmanı#
Getiri/emek oranı en yüksek bölüm burasıdır. Doğru kurulmuş bir sayfa önbelleği, isteklerin büyük çoğunluğunun uygulamaya hiç inmemesini sağlar; yani aynı donanımda birkaç kat trafik taşırsın.
- Sayfa önbelleğini kur. nginx kullanıyorsan FastCGI cache, LiteSpeed kullanıyorsan sunucu düzeyinde önbellek en verimlisidir. Yapılandırma için nginx FastCGI cache ve LiteSpeed Cache yazılarına bak.
- Önbelleğin gerçekten çalıştığını doğrula. Kurmuş olmak yetmez; isabet oranını ölç.
- Nesne önbelleği ekle. Veritabanı sorgu sonuçlarını bellekte tutmak, dinamik sayfaların üretim süresini ciddi biçimde kısaltır; Memcached nedir yazısı temel mantığı anlatıyor.
- Tarayıcı önbelleği başlıklarını ayarla. Statik varlıklar için uzun süreli önbellek, HTML için kısa süre ya da doğrulama.
- Sıkıştırmayı aç. Gzip veya brotli kapalıysa metin kaynaklarında üç kat fazla veri gönderiyorsun.
# Önbellek isabet durumu (nginx günlüğünde cache= alanı varsa)
awk '{for(i=1;i<=NF;i++) if($i ~ /^cache=/) {sub("cache=","",$i); d[$i]++}} END {for(k in d) print k, d[k]}' \
/var/log/nginx/firmaniz-access.log
# Sıkıştırma aktif mi
curl -sI -H "Accept-Encoding: br,gzip" https://firmaniz.com/ | grep -i content-encoding
# Statik varlıkta önbellek başlığı var mı
curl -sI https://firmaniz.com/frontend/stil.css | grep -iE "cache-control|expires|etag"
Apache tarafında önbellek ve sıkıştırma ayarlarının tamamını .htaccess önbellek ve sıkıştırma yazısında bulabilirsin. cPanel kullanıyorsan panel üzerinden yönetilen seçenekler için cPanel önbellek yöneticisi yazısına bak.
3. Veritabanı ve Uygulama Katmanı#
Önbellekten dönmeyen her istek buraya iner; bu yüzden önbellek ne kadar iyi olursa olsun bu katman da sağlıklı olmalıdır.
- Yavaş sorgu günlüğünü aç ve en pahalı sorguları bul. Eşiği önce 1 saniyeye koy, gürültü azaldıkça düşür.
- Eksik indeksleri tamamla. Yavaş sorguların büyük kısmı indeks eksikliğindendir;
EXPLAINçıktısında tam tablo taraması görüyorsan hedefin bellidir. - Otomatik yüklenen veriyi denetle. WordPress gibi sistemlerde her istekte yüklenen ayar tablosu zamanla şişer.
- Kullanılmayan eklenti ve modülleri kaldır. Devre dışı bırakmak yetmez, silmek gerekir.
- Arka plan görevlerini gerçek bir zamanlayıcıya taşı. Ziyaretçi isteğiyle tetiklenen görevler yoğun saatte yükü katlar.
-- En yavaş sorguları yakala
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;
-- Bir sorgunun indeks kullanıp kullanmadığını gör
EXPLAIN SELECT * FROM siparisler WHERE musteri_id = 42 AND durum = 'bekliyor';
-- type sütununda ALL görüyorsan tam tablo taraması yapılıyor demektir
-- Tablo boyutlarını büyükten küçüğe listele
SELECT table_name, ROUND((data_length + index_length)/1024/1024, 1) AS mb
FROM information_schema.tables
WHERE table_schema = DATABASE()
ORDER BY (data_length + index_length) DESC
LIMIT 10;
4. Ön Yüz Varlıkları#
Sunucu hızlı cevap veriyorsa kalan süre burada harcanır.
- Toplam sayfa ağırlığını bir bütçeye bağla. Hedefler ve kaynak türü dağılımı için ideal sayfa ağırlığı yazısındaki tabloyu kullan.
- Engelleyici JavaScript'i ertele. Kritik olmayan betikleri
deferya daasyncile yükle. - Kullanılmayan CSS ve JS'i kaldır. Yalnızca tek bir sayfada gereken kütüphaneyi tüm siteye yükleme.
- Yazı tipi sayısını sınırla. İki aile ve üç dört kalınlık çoğu tasarım için yeterlidir; yalnızca gereken karakter aralığını yükle.
- Üçüncü taraf betikleri tek tek gerekçelendir. Her biri hem ağırlık hem gecikme hem de dış bağımlılık getirir.
- En büyük içerik ögesine öncelik ver. Hero görselini lazy yükleme, tersine ön yükleme yap; ayrıntı için LCP nasıl iyileştirilir yazısına bak.
- Düzen kaymasını engelle. Görsel ve reklam alanlarına boyut ver; yöntemi CLS düzen kayması yazısında.
5. Görsel ve Medya#
Çoğu sitede toplam ağırlığın yarısından fazlası buradadır, dolayısıyla en somut kazanç da buradadır.
- Gerçek gösterim boyutunda sun. 300 piksel genişliğinde görünen bir alan için 1600 piksellik dosya göndermeyi bırak.
- Modern format kullan. Fotoğraflarda WebP veya AVIF, logo ve ikonlarda SVG.
- Ekran boyutuna göre farklı sürümler sun. Mobil cihaza masaüstü görseli göndermek en yaygın israftır.
- Ekran altındaki görsellere lazy loading uygula, ilk ekrandakilere uygulama.
- Videoyu kendi sunucundan otomatik oynatma. Ağır bir video, tüm bant genişliğini tek başına tüketir.
# En büyük 15 medya dosyasını bul
find /var/www/firmaniz/uploads -type f \
\( -iname "*.jpg" -o -iname "*.png" -o -iname "*.webp" -o -iname "*.mp4" \) \
-printf "%s %p\n" | sort -rn | head -15 | awk '{printf "%.1f MB %s\n", $1/1048576, $2}'
6. Ağ, TLS ve CDN#
Bu katman özellikle coğrafi olarak dağınık kullanıcı kitlesi olan siteler için belirleyicidir.
- HTTP/2 veya HTTP/3'ün aktif olduğunu doğrula. Eski HTTP/1.1 üzerinde çoklu istek maliyeti çok daha yüksektir.
- TLS oturum yeniden kullanımını aç. Her bağlantıda tam el sıkışma yapmak gereksiz gecikme üretir.
- CDN kararını veriye dayandır. Kullanıcıların çoğu sunucuna yakınsa kazanç sınırlıdır; karar için CDN mi daha iyi hosting mi karşılaştırmasına bak.
- CDN varsa gerçekten önbelleklediğini doğrula. Her istek kaynağa iniyorsa CDN sana yalnızca ek bir atlama maliyeti çıkarıyordur.
- DNS çözümleme süresini kontrol et. Yavaş bir DNS sağlayıcısı her yeni ziyaretçiye sabit bir gecikme ekler.
# Protokol sürümü ve TLS bilgisi
curl -sI --http2 https://firmaniz.com/ | head -1
curl -s -o /dev/null -w "protokol=%{http_version} tls=%{ssl_verify_result} dns=%{time_namelookup}s\n" \
https://firmaniz.com/
# CDN önbellek durumu
curl -sI https://firmaniz.com/ | grep -Ei "cf-cache-status|age|x-cache"
Cloudflare kullanıyorsan hangi kayıtların proxy'lenmesi gerektiği konusunda turuncu bulut mu gri bulut mu yazısı doğru kurulumu anlatıyor; SSL modunu yanlış seçmek ise sessiz hatalara yol açar, o tarafı Cloudflare SSL modları yazısında ele aldım.
7. Doğrulama ve Sürekli İzleme#
Optimizasyon tek seferlik bir iş değildir; ölçmeyi bırakırsan kazandığın hızı birkaç ay içinde geri verirsin.
- Sunucu yanıt süresini sürekli izle. Kurulum için sunucu yanıt süresi izleme yazısındaki günlük ve prob düzenini uygula.
- Gerçek kullanıcı verisi topla. Laboratuvar ölçümü saha gerçeğini vermez; RUM gerçek kullanıcı ölçümü yazısındaki basit toplayıcı yeterlidir.
- Performans bütçesini otomatik denetle. Denetlenmeyen bütçe birkaç deploy içinde aşılır.
- Bot trafiğinin payını takip et. Yük artışının nedeni çoğu zaman gerçek kullanıcı değildir; bot trafiği ve sunucu yükü yazısı ölçüm yöntemini veriyor.
- Alarm eşiklerini gerçekçi tut. Sürekli öten alarm iki hafta içinde sessize alınır.
Sık Yapılan Hatalar#
Teşhis yapmadan listeye başlamak. Bu listenin başındaki uyarı buydu ve en pahalı hata budur. Darboğaz bilinmeden yapılan iyileştirme, yanlış yerde harcanmış emektir.
Çakışan önbellek katmanları kurmak. Sunucu önbelleği, eklenti önbelleği ve CDN önbelleği aynı anda ve uyumsuz sürelerle çalışırsa güncellemeler görünmez olur ve nerede takıldığını çözmek saatler alır. Katmanları bilinçli seç, her birinin görevini ayır.
Küçültme ve birleştirmeyi abartmak. HTTP/2 üzerinde dosya birleştirmenin faydası büyük ölçüde ortadan kalkmıştır; agresif birleştirme önbellek verimliliğini düşürebilir. Önce ölç.
Ölçümü dolu önbellekle yapmak. Kendi tarayıcında iyi görünen sayfa, ilk kez gelen kullanıcı için tamamen farklıdır. Ölçümü gizli sekmede ya da önbellek kapalıyken yap.
Yalnızca ana sayfayı optimize etmek. Trafiğin çoğu genelde iç sayfalara gelir. Ürün detayı, kategori ve arama sonuç sayfalarını da ölç.
Değişiklikleri belgelememek. Altı ay sonra bir ayarın neden öyle olduğunu hatırlamazsın. Yaptığın her değişikliği tarih ve gerekçesiyle bir yere yaz.
Sıkça Sorulan Sorular#
Site hızı optimizasyonuna nereden başlamalıyım#
Listeden değil, ölçümden başla. Önce sorunun sunucuda mı ön yüzde mi olduğunu belirle: saf sunucu yanıt süresi 600 milisaniyenin üzerindeyse sunucu ve önbellek katmanına, düşükse ön yüz ve sayfa ağırlığına yönel. Katmanı belirledikten sonra bu listede o bölümün maddelerini yukarıdan aşağı uygula. Tek bir genel kural verilecekse, doğru kurulmuş bir sayfa önbelleği neredeyse her zaman en yüksek getirili ilk adımdır.
Bu maddelerin hepsini uygulamam gerekir mi#
Hayır ve uygulamamalısın da. Liste bir menü, zorunluluk değil; senin darboğazına uymayan maddeler zaman kaybı, bazıları ise gereksiz risk üretir. Örneğin tüm kullanıcıları aynı şehirdeki bir siteye CDN eklemek kayda değer kazanç getirmez. Ölçümün gösterdiği katmandaki maddeleri uygula, diğerlerini o katmana sıra gelene kadar beklet.
Optimizasyondan sonra ne kadar hızlanma beklemeliyim#
Başlangıç durumuna göre çok değişir. Hiç önbelleği olmayan bir WordPress sitesinde sayfa önbelleği kurmak yanıt süresini kat kat düşürebilir; zaten iyi yapılandırılmış bir sitede aynı işlem yüzde birkaçlık kazanç verir. Gerçekçi beklenti şudur: ilk iki üç madde toplam kazancın büyük kısmını getirir, geri kalanı ise küçük ve birikimli iyileştirmelerdir. Bu yüzden her adımı ayrı ölçmek önemlidir.
Eklentiyle mi sunucu ayarıyla mı hızlandırmalıyım#
Mümkün olduğunca sunucu katmanında çöz. Sunucu düzeyinde önbellek, isteği PHP hiç çalışmadan karşılar; eklenti tabanlı önbellek ise en azından uygulamanın bir bölümünü çalıştırmak zorundadır. Sunucu yapılandırmasına erişimin yoksa (paylaşımlı hostingde olduğu gibi) eklenti çözümü doğru tercihtir ve iyi yapılandırıldığında ciddi kazanç verir. Erişimin varsa sunucu katmanı hep daha verimlidir.
Sunucu yükseltmesi hız sorununu çözer mi#
Yalnızca darboğaz gerçekten kaynak yetersizliğiyse çözer. CPU sürekli doygunsa, bellek yetmediği için takas alanı kullanılıyorsa ya da disk beklemesi yüksekse yükseltme anında sonuç verir. Ama sorun indekssiz bir sorgudan, kapalı bir önbellekten ya da 6 MB'lık bir ana sayfadan geliyorsa daha güçlü donanım yalnızca faturayı büyütür ve aynı sorun büyümeyle birlikte geri gelir. Önce ölç, sonra karar ver.
Optimizasyonu ne sıklıkta tekrar gözden geçirmeliyim#
Ayda bir kısa kontrol, altı ayda bir kapsamlı gözden geçirme iyi bir ritimdir. Bunun dışında her büyük değişiklikten sonra mutlaka ölç: tema güncellemesi, yeni eklenti, tasarım yenilemesi ve sunucu taşıması performansı sessizce bozabilecek olaylardır. Sürekli izleme kurduysan zaten bozulmayı kendisi haber verir ve planlı gözden geçirmeler yalnızca bir doğrulama adımına dönüşür.
Kapanış#
Bu listenin değeri madde sayısında değil, sırasında. Aklında kalması gereken dört alışkanlık şu: teşhis etmeden optimize etmeye başlama, katmanları yukarıdan aşağı ele al çünkü üstteki bir sorun alttaki tüm kazançları yutar, tek seferde tek değişiklik yapıp her adımı ayrı ölç ve son olarak kurduğun düzeni izlemeye bağla; ölçülmeyen bir hız kazancı birkaç ay içinde sessizce geri verilir.
Uygulama sırasında sunucu katmanının sınırına dayandığını görürsen izole kaynaklı VDS ve ihtiyaca göre ölçeklenen bulut sunucu paketlerimiz doğal bir sonraki adımdır; önbellek katmanı hazır gelen bir başlangıç için web hosting ve WordPress hosting, yoğun katalog barındıran projeler içinse e-ticaret hosting çözümümüz uygundur. Bu listeyi baştan sona senin siten üzerinde uygulamamızı istersen sunucu yönetimi hizmetimiz teşhisten izleme kurulumuna kadar süreci üstlenir.