Bu rehber, bir VPS sunucu üzerinde hangi ayarın ne kadar kazandırdığını ve hangi sırayla uygulanması gerektiğini anlatıyor. Ölçümle başlıyor, sunucu katmanıyla devam ediyor, içerik tarafında bitiyor. Her bölümün sonunda somut bir kontrol var.

Peki neden sıralama bu kadar önemli? Çünkü VPS optimizasyonunun büyük kısmı ölçmeden yapıldığında görünmez kalıyor. Önce nerede olduğunuzu bilmeniz gerekiyor.

Özetle

  • Ölçmeden optimize etmeyin: TTFB VPS'i, LCP içeriği işaret eder. İkisi farklı çözüm ister.
  • Google'ın "iyi" eşikleri net: LCP 2,5 saniye, INP 200 milisaniye, CLS 0,1 ve TTFB 0,8 saniye.
  • PHP sürümünü yükseltmek tek başına sihir değil; Kinsta'nın kıyaslamasında sade bir WordPress kurulumunda kazanç yüzde 6,6.
  • Asıl kazanç önbellek katmanlarında: bir VPS üzerinde OPcache, nesne önbelleği ve sayfa önbelleği birlikte çalışır.
  • Görsel ve sıkıştırma tarafında tek seferlik ayarlar var: Brotli metin varlıklarını gzip'e göre yüzde 15-25 küçültür.

Site Hızı Neden Doğrudan Ciroya Yazılıyor?

Çünkü hız ile dönüşüm arasındaki bağ ölçülmüş durumda. Google ve Deloitte'un 37 markanın gerçek verisiyle yürüttüğü "Milliseconds Make Millions" araştırmasında, mobil yüklenme süresindeki 0,1 saniyelik iyileşme perakendede dönüşümü yüzde 8,4, sepet ortalamasını yüzde 9,2 yükseltti. Seyahat kategorisinde dönüşüm artışı yüzde 10,1'e çıktı.

Rakamı tersten okuyun: site hızının bir saniye düşmesi, aynı trafikten belirgin biçimde daha az satış anlamına geliyor. Reklam bütçesi aynı kalıyor, gelir düşüyor.

İkinci etki arama tarafında. Google, sayfa deneyimini Core Web Vitals metrikleriyle ölçüyor ve bu metrikleri gerçek kullanıcı verisinin 75. yüzdeliğinden hesaplıyor. Yani bir kullanıcının hızlı deneyim yaşaması yetmiyor; kullanıcılarınızın dörtte üçünün eşiği geçmesi gerekiyor.

WhatsApp’tan Yeni Güvenlik Hamlesi: Dolandırıcılar Anlık Olarak Tespit Edilecek
WhatsApp’tan Yeni Güvenlik Hamlesi: Dolandırıcılar Anlık Olarak Tespit Edilecek
İçeriği Görüntüle

Paylaşımlı hostingde bu eşikleri tutturmak çoğu zaman mümkün olmuyor, çünkü kaynak paylaşımı yanıt süresini öngörülemez kılıyor. Garantili kaynak sunan bir VPS, optimizasyonun üzerine inşa edileceği zemini sağlıyor.

BÖLÜM 1 · ÖLÇÜM: NEREDE OLDUĞUNUZU BİLMEDEN HIZLANAMAZSINIZ

1. VPS'te Hangi Metrikleri Ölçmelisiniz?

Dört rakam yeterli. Üçü Google'ın resmî Core Web Vitals metrikleri, dördüncüsü ise VPS tarafının aynası. Eşikler şöyle:

Metrik Ne ölçer İyi Kötü Sorumlu katman
TTFB İlk baytın gelme süresi 0,8 sn ve altı 1,8 sn üzeri Sunucu, PHP, veritabanı
LCP En büyük içeriğin görünme süresi 2,5 sn ve altı 4 sn üzeri Görsel, CSS, sunucu
INP Etkileşime yanıt gecikmesi 200 ms ve altı 500 ms üzeri JavaScript
CLS Yerleşim kayması 0,1 ve altı 0,25 üzeri CSS, reklam, yazı tipi

Tablodaki son sütun rehberin can alıcı noktası. Bir metriği kimin bozduğunu bilmezseniz yanlış katmanda çalışırsınız. INP kötüyken VPS paketini yükseltmek para kaybıdır; o metriği JavaScript belirler.

TTFB eşiği web.dev'in kendi tavsiyesi ve içine ne girdiğini bilmek işe yarar: yönlendirmeler, DNS çözümlemesi, bağlantı kurulumu, TLS el sıkışması ve sunucunun yanıtı üretme süresi. Yani TTFB yüksekse suçlu her zaman PHP olmaz; bazen fazladan bir yönlendirme yeter.

2. VPS Üzerinde Ölçümü Nasıl Yaparsınız?

İki tür ölçüm var ve ikisini karıştırmak en sık yapılan hata. Laboratuvar ölçümü tek bir simüle edilmiş ziyaretten çıkar. Saha ölçümü ise gerçek kullanıcılarınızın verisidir ve Google'ın sıralamada baktığı veri budur.

  • Saha verisi: Search Console'daki Sayfa Deneyimi raporu ve CrUX verisi. Yavaş ama gerçek.
  • Laboratuvar verisi: PageSpeed Insights ve Lighthouse. Hızlı geri bildirim verir, tek ölçümdür.
  • VPS tarafı: curl -w "%{time_starttransfer}" -o /dev/null -s https://siteniz.com komutu TTFB'yi doğrudan ölçer.
  • Yük testi: ApacheBench veya benzeri bir araçla eşzamanlı istek altında ne olduğunu görün.

Ölçümü her zaman aynı koşulda tekrarlayın. Farklı saatte, farklı bağlantıdan alınan sonuçları karşılaştırmak yanıltır. Bir değişiklik yapıp ölçün, sonra bir sonrakine geçin.

Deneyimimiz: Optimizasyon taleplerinde en sık gördüğümüz durum, tek bir PageSpeed puanına bakıp panik yapılması. Aynı sayfayı beş kez ölçtüğünüzde puan on beş baz sapabiliyor. Karar vermek için saha verisine bakmak gerekiyor.

3. Darboğaz VPS'te mi, Sitede mi?

Bu ayrımı yapmanın basit bir yolu var: TTFB'ye bakın. TTFB 0,8 saniyenin altındaysa VPS'iniz işini yapıyor, sorun içerik tarafındadır. TTFB yüksekse önce VPS katmanını çözmeniz gerekir; görselleri sıkıştırmak o durumda hiçbir şeyi değiştirmez.

Teşhis mantığı şöyle işler:

Belirti Muhtemel neden Nereye bakılır
TTFB yüksek, LCP yüksek VPS yavaş yanıt üretiyor PHP sürümü, OPcache, veritabanı sorguları
TTFB düşük, LCP yüksek Büyük görsel veya engelleyici CSS Görsel boyutu, kritik CSS, yazı tipi yükleme
LCP iyi, INP kötü Ağır JavaScript Üçüncü taraf betikler, eklenti sayısı
CLS kötü Boyutu belirtilmemiş öğeler Görsel width/height, reklam alanları, yazı tipi
Yoğun saatte hepsi bozuluyor Kaynak yetersizliği veya paylaşımı CPU/RAM kullanımı, kaynak garantisi

Son satır özellikle önemli. Sitenizin gece hızlı, gündüz yavaş olması bir yazılım sorunu değil kaynak sorunudur. Böyle bir durumda önce VPS paketinizdeki kaynağın gerçekten size ayrıldığını teyit etmek gerekir.

BÖLÜM 2 · SUNUCU KATMANI: VPS'İN İÇİNDE NE AYARLANIR

1. PHP Sürümü ve OPcache: Gerçek Kazanç Ne Kadar?

Burada bloglarda dolaşan bir efsaneyi düzeltmek gerekiyor. "PHP 8'e geçin, siteniz iki kat hızlanır" cümlesi ölçümlerle desteklenmiyor. Kinsta'nın 13 Aralık 2025'te güncellediği PHP kıyaslamasında, eklentisiz ve önbelleksiz bir WordPress 6.8 kurulumu PHP 7.4'te saniyede 139,06 istek karşılarken PHP 8.5'te 148,30 isteğe çıkıyor. Aradaki fark yüzde 6,6.

Yani sürüm yükseltmesi değerli ama tek başına dönüştürücü değil. Eklenti yoğun kurulumlarda fark büyüyor, çünkü çalıştırılan kod miktarı artıyor. Yine de "iki kat" iddiası buradan çıkmıyor.

Asıl kazanç OPcache'te. OPcache, PHP dosyalarının derlenmiş hâlini bellekte tutar ve her istekte yeniden derleme yükünü ortadan kaldırır. Çoğu VPS kurulumunda etkin gelir, ama ayarları varsayılan bırakılır.

Kontrol edilecek üç değer:

  • opcache.memory_consumption: Orta ölçekli bir site için 128-256 MB makul. Yetersizse önbellek sürekli boşalır.
  • opcache.max_accelerated_files: WordPress ve eklentileri kolayca on binlerce dosya eder. 10000 ve üzeri bir değer güvenlidir.
  • opcache.validate_timestamps: Üretimde 0 yapılabilir, ama o zaman her dağıtımdan sonra önbelleği elle temizlemeniz gerekir.

PHP-FPM tarafında da bir ayar var: pm.max_children. Bu değer VPS'inizde kaç eşzamanlı PHP isteğinin işleneceğini belirler. Çok düşükse istekler kuyrukta bekler, çok yüksekse RAM tükenir ve sunucu takas alanına düşer. Kabaca hesabı, kullanılabilir RAM'i tek bir PHP işçisinin ortalama bellek tüketimine bölmektir.

2. VPS'te Web Sunucusu Seçimi Ne Kadar Fark Yapar?

Statik dosya sunumunda ve eşzamanlı bağlantı yönetiminde belirgin fark var; dinamik PHP işlemede ise fark küçülür. Üç yaygın seçeneğin güçlü olduğu yerler şöyle ayrışıyor:

Sunucu Güçlü olduğu yer Dikkat
Nginx Statik dosya, yüksek eşzamanlılık, ters vekil .htaccess desteklemez, kurallar konfigürasyonda tanımlanır
LiteSpeed / OpenLiteSpeed Dahili sayfa önbelleği, .htaccess uyumu Kurumsal sürüm lisanslıdır
Apache Yaygın uyumluluk, modül zenginliği Yoğun eşzamanlılıkta daha fazla bellek tüketir

Pratik bir orta yol var: Apache'yi arkada bırakıp önüne Nginx'i ters vekil olarak koymak. Statik dosyaları Nginx sunar, PHP isteklerini Apache'ye geçirir. Mevcut .htaccess kurallarınızı kaybetmeden statik sunum kazancını alırsınız.

VPS'inizde hangisini kullanıyorsanız iki ayarı mutlaka açın: keepalive bağlantıları ve statik dosyalar için uzun süreli tarayıcı önbelleği başlıkları. İkisi de tek satırlık değişiklik, etkisi her ziyarette tekrarlanır.

3. Sıkıştırma: Gzip mi, Brotli mi?

Brotli, metin tabanlı varlıklarda gzip'e göre yüzde 15-25 daha küçük dosya üretiyor. HTML, CSS, JavaScript, JSON ve SVG bu gruba giriyor. Karşılaştırmalı ölçümlerde Brotli seviye 4, gzip seviye 6'ya kıyaslanabilir işlemci maliyetiyle yüzde 15-20 daha iyi sıkıştırma veriyor.

Aynı dosyanın üç hâli kabaca şöyle duruyor:

Durum Göreli boyut Ölçek
Sıkıştırmasız %100 ██████████
Gzip ~%35 ███▌
Brotli ~%30 ███

Oranlar metin varlıkları için temsilidir; dosya türüne göre değişir.

Uygulamada iki ayarı birlikte yapın. Statik varlıkları yüksek Brotli seviyesiyle önceden sıkıştırıp diske yazın; dinamik çıktı için orta seviye (4-6) kullanın. Yüksek seviyeyi dinamik içerikte kullanmak VPS işlemcisini boşa yorar.

Bir de eksik kalan nokta: sıkıştırmanın hangi MIME türlerinde açık olduğunu kontrol edin. Varsayılan yapılandırmalar genelde HTML ve CSS'i kapsar, JSON ve yazı tipi dosyalarını atlar.

4. HTTP/2, HTTP/3 ve TLS Ayarları

Protokol sürümü, özellikle çok sayıda küçük dosya sunan sitelerde hissedilir fark yaratır. HTTP/1.1'de tarayıcı aynı bağlantıda istekleri sıraya dizer; HTTP/2 bunları tek bağlantı üzerinde paralelleştirir. HTTP/3 ise TCP yerine UDP tabanlı QUIC kullanarak bağlantı kurulum süresini kısaltır.

Kazanç en çok mobil ve kayıplı ağlarda görünür. Paket kaybı olan bir bağlantıda HTTP/2 tüm akışı bekletirken HTTP/3 yalnızca etkilenen akışı bekletir.

Kontrol listesi kısa:

  • HTTP/2 açık mı? Modern sunucularda TLS ile birlikte gelir, ama eski yapılandırmalarda kapalı kalabilir.
  • HTTP/3 destekleniyor mu? VPS tarafında desteklenmiyorsa CDN katmanında devreye alınabilir.
  • TLS oturum yeniden kullanımı: Tekrar eden ziyaretlerde el sıkışma maliyetini düşürür.
  • OCSP stapling: Sertifika doğrulaması için tarayıcının ayrı istek atmasını engeller.
  • Gereksiz yönlendirmeler: http'den https'e, sonra www'ya giden zincirler TTFB'ye doğrudan eklenir.

Son madde çoğu sitede birkaç yüz milisaniye kazandırıyor. Yönlendirme zincirini tek adıma indirmek, VPS'e hiçbir yazılım kurmadan yapılan en ucuz iyileştirmelerden biri.

5. VPS'te Veritabanı ve Nesne Önbelleği

Dinamik bir sitede TTFB'nin büyük kısmı veritabanı sorgularında geçer. WordPress gibi sistemlerde her sayfa yüklenmesi onlarca, bazen yüzlerce sorgu üretir. Nesne önbelleği bu sorguların sonucunu bellekte tutar ve tekrarını engeller.

Redis ya da Memcached kurup uygulamaya bağlamak, yoğun sitelerde tek başına en büyük TTFB kazancını verebilir. Root erişimi olan bir VPS'te bu kurulum birkaç komutluk iş. Kurulum sonrası kontrol edilecek şey isabet oranıdır: önbellek isabet oranı yüzde 90'ın altındaysa yapılandırmada bir sorun var.

Veritabanının kendisinde de bakılacak üç yer var:

  • Yavaş sorgu kaydı: slow_query_log açıp eşiği 1 saniyeye çekin. Bir gün sonra kaydı okuyun; suçlular listelenmiş olur.
  • Eksik indeks: Yavaş sorguların çoğu indekssiz sütunda arama yapar. Tek bir indeks bazen saniyeleri milisaniyeye indirir.
  • Şişmiş tablolar: Geçici kayıtlar, revizyonlar ve süresi geçmiş oturum verileri tabloyu büyütür. Düzenli temizlik sorgu süresini kısaltır.

InnoDB kullanıyorsanız innodb_buffer_pool_size değerini de gözden geçirin. Bu havuz, veritabanının sık kullanılan verisini bellekte tuttuğu alan; varsayılan değer çoğu VPS için fazla küçük kalır. VPS belleğinizin kabaca yarısını bu havuza ayırmak yaygın bir başlangıç noktası.

6. VPS'te Disk, RAM ve Kaynak Garantisi

Donanım tarafında site hızını en çok belirleyen kalem disk. Veritabanı yazımı, log kaydı ve önbellek dosyaları hep disk üzerinde çalışır. NVMe diskli bir VPS, SATA SSD'li bir pakete göre belirgin biçimde daha yüksek rastgele okuma-yazma kapasitesi verir.

RAM tarafında kritik eşik takas alanı (swap). VPS belleği tükendiğinde işletim sistemi diski bellek gibi kullanmaya başlar ve yanıt süreleri katlanır. Takas kullanımı sıfırın üzerinde seyrediyorsa optimizasyon değil kaynak artışı gerekir.

Kontrol için iki komut yeterli: free -m bellek ve takas durumunu, iostat -x 1 disk bekleme sürelerini gösterir. İkinci komutta await değeri sürekli yükseliyorsa disk darboğazdasınız.

İpucu: Yoğun saatte ölçün, gece ölçmeyin. Kaynak sorunları yalnızca yük altında görünür ve tam olarak o anda müşterinizi kaybediyorsunuz.

BÖLÜM 3 · İÇERİK KATMANI: SUNUCUDAN SONRA NE KALIR

1. Görseller: WebP ve AVIF Gerçekten Ne Kazandırır?

Görseller çoğu sayfanın en büyük parçası, dolayısıyla LCP metriğinin en sık suçlusu. Google'ın WebP Compression Study çalışmasına göre WebP, aynı SSIM kalite ölçümünde JPEG'e kıyasla yüzde 25-34 daha küçük dosya üretiyor. AVIF ise daha ileri gidiyor: bağımsız ölçümlerde JPEG'e göre yaklaşık yarı boyut, WebP'ye göre yüzde 20-30 daha küçük.

Aynı fotoğrafın üç formattaki göreli boyutu kabaca şöyle:

Format Göreli boyut Ölçek Destek
JPEG %100 (referans) ██████████ Her yerde
WebP ~%70 ███████ Tüm modern tarayıcılar
AVIF ~%50 █████ Modern tarayıcılar, kodlama daha yavaş

Burada dürüst bir uyarı gerekiyor. Google'ın yüzde 25-34 rakamı 2011 tarihli bir çalışmadan geliyor ve o dönemin JPEG kodlayıcısıyla karşılaştırılmış. Modern bir JPEG kodlayıcı ve güncel bir kalite ölçütü kullandığınızda fotoğrafik içerikte bu farkın önemli bir kısmı kapanıyor. Yani kazanç gerçek, ama beklentiyi rakamın tamamı üzerine kurmayın.

Format değişikliğinden önce, VPS'inizde tek satır ayar bile gerektirmeyen daha etkili bir iş var: doğru boyutta servis etmek. 3000 piksel genişliğinde bir fotoğrafı 600 piksel alana koyup tarayıcıya küçültmesini söylemek, hangi formatı kullanırsanız kullanın israftır.

Görsel tarafında sırayla şunları uygulayın:

  • Boyutlandırma: Görseli kullanılacağı en büyük ölçüde üretin, fazlasını değil.
  • Duyarlı sürümler: srcset ile mobil ve masaüstü için ayrı genişlikler sunun.
  • Modern format: WebP'ye geçin, AVIF'i destekleyen tarayıcılara AVIF sunun.
  • Tembel yükleme: Ekran dışındaki görsellere loading="lazy" ekleyin. Ama ilk ekrandaki görsele eklemeyin, LCP'yi bozar.
  • Boyut niteliği: Her görsele width ve height yazın. Bu tek adım CLS metriğini büyük ölçüde düzeltir.

Dördüncü maddedeki tuzağı özellikle not edin. Tüm görsellere tembel yükleme eklemek yaygın bir eklenti davranışı ve ilk ekrandaki görselde LCP'yi geciktiriyor.

2. Önbellek Katmanları Nasıl Sıralanır?

Önbellek tek bir şey değil, üst üste duran beş katman. Her biri farklı bir maliyeti ortadan kaldırıyor ve doğru sıralandığında birbirlerini destekliyorlar.

Katman Ne saklar Nerede durur Ortadan kaldırdığı maliyet
Opcode (OPcache) Derlenmiş PHP kodu Sunucu belleği Her istekte yeniden derleme
Nesne önbelleği Veritabanı sorgu sonuçları Redis / Memcached Tekrarlanan sorgular
Sayfa önbelleği Hazır HTML çıktısı Disk veya bellek PHP'nin tamamı
Tarayıcı önbelleği CSS, JS, görsel Ziyaretçi cihazı Tekrar ziyarette ağ isteği
CDN önbelleği Statik varlıklar Kenar sunucular Coğrafi mesafe gecikmesi

Kalın yazılan satır en büyük kazancı verir. Sayfa önbelleği devredeyken PHP hiç çalışmaz, veritabanına hiç gidilmez; VPS hazır bir HTML dosyasını gönderir. TTFB bu durumda genelde onlu milisaniyelere iner.

Ama bir şartı var: sayfa önbelleği yalnızca herkese aynı görünen sayfalarda çalışır. Sepet, üyelik paneli ve arama sonucu gibi kişiye özel sayfalar bu önbellekten muaf tutulmalıdır. Muafiyet kurallarını yanlış yazmak, bir kullanıcıya başkasının sepetini göstermeye kadar gider.

E-ticaret sitelerinde katmanları ayırmak gerekir: kategori ve ürün sayfaları sayfa önbelleğinde, sepet ve ödeme adımları nesne önbelleğinde. İkisini karıştıran VPS kurulumları en tuhaf hataları üretir.

3. CSS, JavaScript ve Yazı Tipleri

Bu üçlü, VPS hızlı olsa bile sayfayı geciktirebilir. Tarayıcı, ekrana ilk boyamayı yapmadan önce belirli dosyaları indirmek ve işlemek zorundadır. Bunlara engelleyici (render-blocking) kaynak deniyor.

Uygulama sırası şöyle:

  • Kullanılmayanı çıkarın: Sayfada işe yaramayan eklenti CSS ve JS dosyalarını yüklemeyin. Bu, küçültmekten daha etkilidir.
  • Kritik CSS: İlk ekranın stilini satır içi verin, kalanını sonradan yükleyin.
  • JS'yi geciktirin: defer ya da async ekleyerek betiklerin ekran boyamasını beklememesini sağlayın.
  • Üçüncü taraf betikleri sayın: Analitik, sohbet, harita ve reklam betikleri INP metriğini en çok bozan kalemdir.
  • Yazı tipi: font-display: swap kullanın ve yalnızca ihtiyacınız olan ağırlıkları yükleyin.

Yazı tipi maddesi CLS ile de bağlantılı. Yedek yazı tipi ile asıl yazı tipinin genişlikleri farklıysa, yazı tipi yüklendiği anda metin yerinden kayar. Yedek yazı tipini benzer ölçülerde seçmek bu kaymayı azaltır.

Deneyimimiz: Optimizasyon projelerinde en büyük tek seferlik kazanç genelde eklenti temizliğinden çıkıyor. Yirmi eklentili bir kurulumda dosyaların yarısı, o sayfada hiç kullanılmayan işlevlere ait oluyor.

4. CDN ve VPS Sunucu Konumu

CDN, statik dosyalarınızı ziyaretçiye en yakın noktadan sunar ve coğrafi mesafeden doğan gecikmeyi kısaltır. Ama bir yanlış anlama var: CDN yavaş bir VPS'i hızlandırmaz. Dinamik HTML isteği yine ana sunucunuza gider.

VPS konumu bu nedenle CDN'den önce gelen bir karar. Ziyaretçilerinizin çoğu Türkiye'deyse, Türkiye konumlu bir VPS her istek için eklenen gidiş-dönüş süresini kısaltır. Yurt dışı lokasyonda bu fark her istekte tekrarlanır ve sayfa açılışında birikir.

CDN kullanacaksanız üç ayarı kontrol edin:

  • Hangi dosyalar önbelleğe alınıyor? Yalnızca görsel değil, CSS ve JS de dahil edilmeli.
  • Önbellek süresi ne kadar? Statik varlıklar için uzun süre + sürüm etiketli dosya adı en sağlıklısı.
  • HTML önbelleğe alınıyor mu? Alınıyorsa kişiye özel sayfalar için muafiyet tanımlanmalı.

BÖLÜM 4 · UYGULAMA: DOĞRU SIRA VE KANIT

1. Sekiz Adımda VPS Optimizasyonu

Sıra önemli, çünkü her adım bir sonrakinin ölçümünü etkiler. Aşağıdaki dizilim, bir VPS üzerinde en yüksek kazancı en az riskle veren yoldan gider.

  • Adım 1 · Ölçüm alın. TTFB, LCP, INP ve CLS değerlerini kaydedin. Bu rakamlar sizin başlangıç çizginiz.
  • Adım 2 · Yönlendirme zincirini temizleyin. Tek adımlı yönlendirme bırakın. Risk yok, kazanç anında.
  • Adım 3 · PHP sürümünü ve OPcache'i güncelleyin. Önce hazırlık ortamında deneyin, uyumsuz eklenti olabilir.
  • Adım 4 · Sıkıştırmayı ve önbellek başlıklarını açın. Brotli, keepalive ve statik varlık başlıkları tek oturumda yapılır.
  • Adım 5 · Nesne önbelleğini kurun. Redis veya Memcached. Kurulum sonrası isabet oranını doğrulayın.
  • Adım 6 · Sayfa önbelleğini devreye alın. Muafiyet kurallarını yazmadan açmayın; sepet ve panel sayfaları hariç tutulmalı.
  • Adım 7 · Görselleri düzeltin. Boyutlandırma, modern format, tembel yükleme ve boyut nitelikleri.
  • Adım 8 · CSS ve JS'yi ele alın. En son bırakılır, çünkü tema ve eklenti davranışını bozma riski en yüksek olan adımdır.

Her adımdan sonra ölçün ve sonucu not edin. Sekiz değişikliği birlikte yapıp sonra ölçerseniz, bir şey bozulduğunda hangisinin bozduğunu bulamazsınız.

Adım 3 ve Adım 8 için bir güvenlik ağı kurun: değişiklikten önce anlık görüntü (snapshot) alın. Çoğu VPS panelinde tek tıkla snapshot alınıyor ve geri dönüş dakikalar sürüyor.

2. VPS Optimizasyonunda Sık Yapılan Yedi Hata

Bu hataların ortak yanı, iyi niyetli olmaları. Hepsi "daha hızlı olsun" diye yapılıyor ve tersine çalışıyor.

Hata Neden ters çalışır
Üç ayrı önbellek eklentisi kurmak Katmanlar çakışır, sayfa eski içerik gösterir
Tüm görsellere tembel yükleme eklemek İlk ekrandaki görsel gecikir, LCP bozulur
Tüm JS'yi tek dosyada birleştirmek HTTP/2 sonrası kazanç kalmadı, tek büyük dosya daha kötü
Sadece PageSpeed puanını hedeflemek Puan laboratuvar ölçümü; sıralamada saha verisi sayılır
Yönetici panelinde de önbellek açmak Yapılan değişiklikler görünmez, saatler kaybedilir
Takas alanı dolarken optimizasyon aramak Sorun yazılımda değil, kaynakta
Değişiklikleri toplu uygulamak Bozan değişiklik tespit edilemez

Üçüncü satır güncelliğini yeni kazandı. HTTP/1.1 döneminde dosya birleştirme mantıklıydı, çünkü her istek ayrı bağlantı maliyeti taşıyordu. HTTP/2 ile bu maliyet düştü; artık tek büyük dosya, önbellek verimliliğini de düşürüyor.

3. "İki Kat Hız" Nasıl Kanıtlanır?

Kanıt tek bir ekran görüntüsü değil, öncesi ve sonrası ölçümlerin aynı koşulda alınmış tablosu. Optimize edilmemiş bir WordPress kurulumunda sekiz adımın sonunda tablo tipik olarak şöyle görünür:

Metrik Önce Sonra Hangi adım kazandırdı
TTFB 1,9 sn 0,4 sn Adım 2, 3, 5, 6
LCP 4,6 sn 2,1 sn Adım 6, 7
INP 320 ms 140 ms Adım 8
CLS 0,24 0,04 Adım 7
Sayfa boyutu 3.480 KB 1.240 KB Adım 4, 7

Yukarıdaki değerler tek bir gerçek ölçümün sonucu değil; tablonun nasıl doldurulacağını ve hangi adımın hangi metriği hareket ettirdiğini göstermek için hazırlanmış temsili bir örnektir. Kendi rakamlarınız başlangıç noktanıza göre değişir.

Tablodaki hareketi okumak da öğretici. TTFB beşte bire inmiş, çünkü sayfa önbelleği devreye girmiş ve PHP artık çalışmıyor. LCP yarıya düşmüş ama sıfırlanmamış, çünkü görseller küçülse bile indirilmeye devam ediyor. CLS neredeyse kaybolmuş, zira tek gereken görsellere boyut niteliği eklemekti.

Tabloyu doldurmak için ölçümü her seferinde aynı sayfada, aynı cihaz profilinde ve mümkünse aynı saat aralığında alın. Site hızı gün içinde dalgalanır. Ana sayfa yerine gerçek trafik alan bir kategori ya da ürün sayfasını seçmek daha anlamlı sonuç verir.

Saha verisinin güncellenmesi zaman alır. Search Console'daki Core Web Vitals raporu 28 günlük pencere kullanır, dolayısıyla değişikliğin etkisini birkaç hafta sonra görürsünüz. Laboratuvar ölçümü hemen tepki verir, saha ölçümü gerçeği söyler.

Sıkça Sorulan Sorular

  • VPS optimizasyonu gerçekten hızı iki katına çıkarır mı?
    Başlangıç noktanıza bağlı. Optimize edilmemiş, önbelleksiz ve eski PHP sürümü çalıştıran bir sitede iki kat ve üzeri kazanç sık görülür. Zaten önbellekli ve ayarlı bir kurulumda kazanç yüzde 10-20 bandında kalır.
  • VPS'te hangi ayar en çok kazandırır?
    Dinamik sitelerde sayfa önbelleği. Devreye girdiğinde PHP hiç çalışmaz ve veritabanına gidilmez; TTFB genelde onlu milisaniyelere iner. Kişiye özel sayfalar için muafiyet tanımlamak şart.
  • Sadece PHP sürümünü yükseltmek yeter mi?
    Yetmez. Kinsta'nın Aralık 2025 kıyaslamasında eklentisiz bir WordPress kurulumunda PHP 7.4'ten 8.5'e geçiş yüzde 6,6 kazanç verdi. Sürüm yükseltmesi değerli ama tek başına dönüştürücü değil.
  • Paylaşımlı hostingde aynı optimizasyonlar yapılabilir mi?
    Kısmen. Görsel, CSS ve önbellek eklentisi tarafı yapılabilir. Ama PHP-FPM ayarları, Brotli seviyesi, Redis kurulumu ve HTTP/3 gibi sunucu düzeyi değişiklikler VPS ve root erişimi gerektirir.
  • VPS için kaç vCPU ve kaç GB RAM gerekir?
    Mevcut kullanımı ölçmeden verilecek rakam tahmindir. Orta trafikli bir WordPress veya küçük e-ticaret sitesi genelde 2-4 vCPU ve 4-8 GB RAM aralığında rahat çalışır. Takas alanı kullanımı görülüyorsa bir kademe üste geçin.
  • CDN kullanırsam sunucu konumu önemsiz mi olur?
    Hayır. CDN statik dosyaları yakından sunar, ama dinamik HTML isteği ana sunucuya gider. Hedef kitleniz Türkiye'deyse sunucu konumu her istekte fark yaratmaya devam eder.
  • Core Web Vitals eşiklerini tutturamazsam sıralamam düşer mi?
    Metrikler sıralama sinyali ama tek belirleyici değil. Google eşikleri gerçek kullanıcı verisinin 75. yüzdeliğinden hesaplar. Rakiplerinizle içerik kalitesi eşitken hız, ayırt edici hâle gelir.
  • Optimizasyon sonrası bir şey bozulursa nasıl geri dönerim?
    Her adımdan önce anlık görüntü (snapshot) alarak. Snapshot desteği olan bir sunucuda geri dönüş dakikalar sürer. Değişiklikleri tek tek uygulamak da hangi adımın bozduğunu bulmayı kolaylaştırır.

VPS'te Hız Kazancı Nerede Başlar?

Optimizasyonun tamamı, kaynağın gerçekten size ait olması varsayımına dayanır. Yoğun saatte komşularla bölüşülen bir işlemcide OPcache ayarı da Brotli seviyesi de beklediğiniz sonucu vermez; ölçümleriniz her gün başka bir rakam gösterir.

Sıralama bu nedenle şöyle: önce garantili kaynak, sonra ölçüm, sonra sekiz adım. Türkiye konumu ve TL bazlı öngörülebilir maliyet sizin için öncelikliyse, Merhaba İnternet'in VPS Kirala sayfasındaki paketleri bu rehberdeki gereksinimlerle karşılaştırabilirsiniz.

Fiyat ve paket bilgileri zaman içinde değişir; karar öncesi güncel tutarları sağlayıcının panelinden teyit edin.

Son bir hatırlatma: ölçüm almadan yapılan hiçbir değişiklik optimizasyon sayılmaz. Başlangıç çizginizi kaydedin, tek tek uygulayın, her adımdan sonra ölçün. Kazanç o tabloda görünür hâle geldiğinde neyin işe yaradığını da öğrenmiş olursunuz.