Web Sitesi Hızlandırma ve Core Web Vitals Optimizasyonu

Site hızlandırma, tek bir eklenti kurup bitirilecek bir iş değil, sunucudan tarayıcıya uzanan zincirin her halkasını ayrı ayrı iyileştirme sürecidir. Ölçüsü de bellidir: Google’ın Core Web Vitals metrikleri. LCP 2,5 saniyenin, INP 200 milisaniyenin, CLS 0,1 değerinin altında olmalıdır. Bu üç sayı hem kullanıcı deneyimini hem de arama sıralamasını doğrudan etkiler.

Bu rehber işi doğru sırayla ele alıyor: önce ölçüm, sonra sunucu tarafı (TTFB), ardından görseller, önbellekleme, CSS/JS optimizasyonu, veritabanı ve son olarak izleme. Sıralama önemlidir; sunucu yavaşken ön yüz optimizasyonu yapmak boşa emek olur.

Önce Ölçün: Hangi Araç Neyi Söyler?#

Ölçmeden yapılan optimizasyon tahmine dayanır. Üç tür veri vardır ve karıştırılmamalıdır:

Tarayıcının kendi geliştirici araçları (F12 > Network ve Performance sekmeleri) çoğu sorunu göstermeye yeter. Sunucu tarafında ise gerçek yanıt süresini komut satırından ölçebilirsiniz:

# Yanıt süresi ayrıntılı ölçüm
curl -o /dev/null -s -w "DNS: %{time_namelookup}s\nBaglanti: %{time_connect}s\nTLS: %{time_appconnect}s\nTTFB: %{time_starttransfer}s\nToplam: %{time_total}s\n" https://alanadiniz.com

# Örnek çıktı:
# DNS: 0.004s
# Baglanti: 0.021s
# TLS: 0.058s
# TTFB: 0.187s
# Toplam: 0.312s

TTFB 200 ms’nin altındaysa sunucu tarafı iyidir, sorun ön yüzdedir. 600 ms’nin üzerindeyse önce sunucuya bakın.

Sunucu Yanıt Süresini (TTFB) Düşürme#

Hız zincirinin ilk halkası sunucudur ve buradaki gecikme diğer her şeye eklenir. TTFB’yi belirleyen dört şey vardır:

1. Disk hızı#

Dinamik bir sayfa üretilirken onlarca veritabanı sorgusu çalışır ve her sorgu diskten okuma yapar. SATA SSD ile NVMe arasındaki gecikme farkı, sayfa üretim süresine doğrudan yansır. Ciddi bir site için NVMe SSD asgari şarttır; HDD tabanlı bir pakette hiçbir optimizasyon TTFB’yi kurtaramaz.

2. İşlemci saat hızı#

PHP tek bir iş parçacığında çalışır; bir isteği işleyen çekirdeğin saat hızı, o isteğin ne kadar sürede biteceğini belirler. Çok çekirdekli ama düşük frekanslı sunucular eşzamanlı istek sayısını artırır, tek isteğin süresini kısaltmaz. Bu yüzden yüksek saat hızlı AMD Ryzen tabanlı sunucular hem oyun hem web iş yüklerinde belirgin fark yaratır.

3. PHP sürümü ve OPcache#

; php.ini - OPcache ayarları
opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000
opcache.revalidate_freq=60
opcache.jit=tracing
opcache.jit_buffer_size=128M

; Genel limitler
memory_limit=512M
max_execution_time=300
realpath_cache_size=4096K
realpath_cache_ttl=600

OPcache, derlenmiş PHP kodunu bellekte tutar ve her istekte yeniden derleme maliyetini ortadan kaldırır. Kapalıysa açmak tek başına belirgin bir kazanç sağlar. Paylaşımlı hostingte bu ayarlar sağlayıcı tarafından yönetilir; cPanel’deki “MultiPHP INI Editor” bölümünden bir kısmına erişebilirsiniz. Panelin diğer bölümleri için cPanel kullanım rehberine, paket türleri arasındaki kaynak farkları için web hosting nedir sayfasına bakabilirsiniz.

4. Sunucu yazılımı ve önbellek katmanı#

LiteSpeed ve Nginx, statik dosya sunumunda Apache’ye göre daha az kaynak tüketir. Bunun üzerine bir nesne önbelleği (Redis) eklemek, tekrar eden veritabanı sorgularını tamamen ortadan kaldırır:

# Redis kurulumu (Ubuntu 24.04)
sudo apt update
sudo apt install -y redis-server php-redis

# Belleği sınırla ve tahliye politikası belirle
sudo sed -i 's/^# maxmemory .*/maxmemory 512mb/' /etc/redis/redis.conf
sudo sed -i 's/^# maxmemory-policy .*/maxmemory-policy allkeys-lru/' /etc/redis/redis.conf

sudo systemctl restart redis-server
redis-cli ping
# Beklenen çıktı: PONG

Görsel Optimizasyonu: En Büyük Kazanç#

Ortalama bir sayfanın ağırlığının büyük bölümü görsellerden gelir ve LCP metriğinin ölçtüğü öğe de çoğu zaman bir görseldir. Dört adımda hallolur:

1. Doğru boyutta sunun#

   4000 piksel genişliğinde bir fotoğrafı CSS ile 800 piksele küçültmek, tarayıcının o dosyanın tamamını indirmesini engellemez. Görseli gösterileceği boyutta üretin.

2. Modern formata çevirin#

   WebP ve AVIF, aynı görsel kalitesinde JPEG ve PNG’den belirgin biçimde küçük dosya üretir. Sunucu tarafında toplu dönüşüm yapabilirsiniz.

3. Ekran dışındakileri geciktirin#

   İlk ekranda görünmeyen tüm görsellere loading="lazy" ekleyin. LCP görselinize eklemeyin; bu, en kritik görselin yüklenmesini geciktirir ve metriği kötüleştirir.

4. Boyut niteliklerini yazın#

   width ve height nitelikleri olmayan görseller yüklendikçe sayfayı kaydırır ve CLS değerini bozar. Bu iki nitelik CLS sorunlarının çoğunu tek başına çözer.

# Toplu WebP dönüşümü (ImageMagick)
sudo apt install -y imagemagick webp

# Klasördeki tüm JPEG'leri WebP'ye çevir
find ./uploads -type f \( -name "*.jpg" -o -name "*.jpeg" \) \
  -exec sh -c 'cwebp -q 82 "$1" -o "${1%.*}.webp"' _ {} \;

# Kazancı gör
du -sh ./uploads/*.jpg ./uploads/*.webp | tail -20

HTML tarafında doğru kullanım şöyledir:

<picture>
  <source srcset="/gorsel/kapak.avif" type="image/avif">
  <source srcset="/gorsel/kapak.webp" type="image/webp">
  <img src="/gorsel/kapak.jpg" width="1200" height="675"
       alt="Sunucu kabinleri" fetchpriority="high">
</picture>

fetchpriority="high" niteliği, LCP görselinizin diğer kaynaklardan önce indirilmesini sağlar ve tek satırla ölçülebilir kazanç verir.

Önbellekleme Katmanları#

Önbellek tek bir şey değil, üst üste binen birkaç katmandır. Her katman farklı bir maliyeti ortadan kaldırır:

Tarayıcı önbelleği için sunucuda doğru başlıkları göndermek gerekir:

# Nginx - statik dosyalar için uzun süreli önbellek
location ~* \.(jpg|jpeg|png|webp|avif|gif|ico|svg|woff2|css|js)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
    access_log off;
}

# HTML her zaman taze gelsin
location ~* \.html$ {
    add_header Cache-Control "public, max-age=0, must-revalidate";
}

# Gzip ve Brotli sıkıştırma
gzip on;
gzip_comp_level 5;
gzip_min_length 256;
gzip_types text/plain text/css application/json application/javascript
           text/xml application/xml image/svg+xml;

CSS ve JavaScript Optimizasyonu#

Render’ı bloklayan kaynaklar, tarayıcının sayfayı çizmeye başlamasını geciktirir. Tarayıcı, <head> içindeki her CSS dosyasını ve defer/async taşımayan her betiği indirip işlemeden ilk pikseli boyamaz.

• Kullanılmayan CSS’i temizleyin. Geliştirici araçlarındaki Coverage sekmesi hangi kuralların hiç kullanılmadığını gösterir.
• Kritik CSS’i satır içine alın, kalanını asenkron yükleyin.
• Betikleri erteleyin. Analitik, sohbet ve pazarlama betiklerine defer ekleyin ya da etkileşimden sonra yükleyin.
• Üçüncü taraf betiklerini sayın. Her biri bir DNS sorgusu, bir TLS el sıkışması ve bir indirme demektir. Kullanmadığınız bir izleme kodu sitede kalmışsa silin.
• Yazı tiplerini yerel sunun. font-display: swap kullanın ve yalnızca gereken karakter setini yükleyin.
• Dosyaları birleştirmeyin. HTTP/2 ve HTTP/3 çoklu isteği paralel taşır; eski “tek dosyada birleştir” tavsiyesi artık geçerli değildir.

<!-- Yazı tipi ön yükleme + swap -->
<link rel="preload" href="/fonts/inter.woff2" as="font" type="font/woff2" crossorigin>

<!-- Üçüncü taraf alan adına erken bağlantı -->
<link rel="preconnect" href="https://analitik.ornek.com" crossorigin>

<!-- Kritik olmayan betik -->
<script src="/js/sohbet.js" defer></script>

Veritabanı Tarafı#

Yavaş sayfaların önemli bir kısmının suçlusu ön yüz değil, tek bir kötü sorgudur. Yavaş sorgu günlüğünü açıp gerçekte ne olduğunu görün:

# MySQL/MariaDB yavaş sorgu günlüğünü aç
sudo mysql -u root -p -e "
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;
SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log';"

# Bir süre sonra en yavaş sorguları özetle
sudo mysqldumpslow -s t -t 10 /var/log/mysql/slow.log

# Tablo boyutlarını gör
sudo mysql -u root -p -e "
SELECT table_name, ROUND(((data_length + index_length) / 1024 / 1024), 1) AS 'MB'
FROM information_schema.TABLES
WHERE table_schema = 'wp_site'
ORDER BY (data_length + index_length) DESC LIMIT 10;"

WordPress sitelerinde en sık şişen tablolar wp_options (otomatik yüklenen veriler), wp_postmeta ve geçici veri (transient) kayıtlarıdır. Düzenli temizlik ve autoload alanının denetlenmesi ciddi fark yaratır. Kurulum ve bakım tarafı için WordPress kurulumu sayfasına bakabilirsiniz.

CDN ve Coğrafi Yakınlık#

CDN, statik dosyalarınızın kopyalarını dünyanın farklı noktalarındaki sunucularda tutar ve ziyaretçiye en yakın olandan servis eder. Faydası, hedef kitlenizin dağılımına bağlıdır:

• Ziyaretçileriniz Türkiye’deyse ve sunucunuz da Türkiye’deyse CDN’in kazancı sınırlıdır; sunucu tarafı önbellek daha etkilidir.
• Yurt dışından ciddi trafik alıyorsanız CDN mesafeden kaynaklanan gecikmeyi doğrudan siler.
• DDoS koruması CDN’lerin yan faydasıdır; trafik filtreleme katmanı olarak da çalışırlar. Konunun tamamı DDoS saldırısı ve korunma sayfasında.

Sunucu lokasyonunun kendisi de bir hız kararıdır. Türkiye’den hizmet veren bir siteyi yurt dışı sunucuda barındırmak, her istek için onlarca milisaniye ek gecikme demektir. Lokasyon ve ping farkları için sunucu kiralama rehberine göz atın.

Hız Optimizasyonu Kontrol Listesi#

Kalıcı İzleme Kurun#

Optimizasyon bir kez yapılıp bitirilen iş değildir. Yeni bir eklenti, bir tema güncellemesi ya da eklenen bir pazarlama betiği kazanımlarınızı sessizce geri alabilir. Bu yüzden ölçümü otomatikleştirin:

• Sitenin ana sayfası ve en önemli üç iç sayfası için haftalık ölçüm alın.
• Sunucu tarafında CPU, RAM ve disk I/O grafiklerini sürekli izleyin.
• Yanıt süresi eşiğini aştığında uyarı gönderen bir kontrol kurun.
• Büyük değişikliklerden önce ve sonra ölçüm alıp karşılaştırın.

Bu işleri Netdata, Prometheus ya da Uptime Kuma ile kurmayı sunucu izleme rehberinde anlattık. Paylaşımlı pakette kaynak sınırlarına takıldığınızı fark ederseniz sıradaki adım, garantili çekirdek ve NVMe disk sunan bir yüksek frekanslı VDS olacaktır.

Özetle#

Hız çalışmasında sıra şudur: önce ölç, sonra sunucuyu düzelt, sonra görselleri, sonra önbelleği, en son ön yüz kodunu. TTFB 600 ms’nin üzerindeyse ön yüzde harcadığınız emek boşa gider; önce NVMe disk, güncel PHP ve OPcache tarafını halledin.

Ardından görselleri WebP/AVIF’e çevirip width/height niteliklerini ekleyin — bu iki adım çoğu sitede LCP ve CLS sorunlarının büyük kısmını çözer. Son olarak render’ı bloklayan CSS ve JS’i temizleyin, uzun süreli tarayıcı önbelleği tanımlayın ve kalıcı bir izleme kurun ki kazandığınız hızı geri kaptırmayın.