Sayfa Hızı Optimizasyonu: WordPress ve Next.js Performans İpuçları

Sayfa Hızı Optimizasyonu: WordPress ve Next.js Performans İpuçları

Sayfa hızı, 2026 itibarıyla hem kullanıcı deneyiminin hem de Google sıralamasının en ölçülebilir belirleyicilerinden biri. Google Mart 2024'te Interaction to Next Paint (INP) metriğini devreye alıp eski FID'i emekliye ayırdı. Artık üç Core Web Vitals metriği (LCP, INP, CLS) arama sıralamasını doğrudan etkileyen "page experience" sinyali olarak geçerli.

Bu yazıda iki farklı platformun — WordPress ve Next.js — hız performansını karşılaştırıyoruz. Hangi platform hangi proje tipi için uygundur? Aynı hız hedefine her platform hangi yoldan ulaşır? VDS mi, paylaşımlı hosting mi daha mantıklı? Bu soruları teknik kanıtlarla, adım adım karşılaştırarak cevaplıyoruz.

Kapsam notu: Bu yazı bir platform karşılaştırması ve karar rehberidir; performans ipuçları bu karşılaştırma ekseninde ele alınır. Saf WordPress CWV detayı için WordPress Hız Optimizasyonu yazımıza, genel CWV eşik değerleri ve ölçüm yöntemleri için Core Web Vitals 2026 rehberimize, INP'in derinlemesine optimizasyonu için INP Optimizasyonu yazımıza bakabilirsiniz.

1. Neden WordPress ve Next.js'i Hız Üzerinden Karşılaştırıyoruz?

Google, Core Web Vitals'ı sıralama sinyali olarak kullanıyor; 2024'te FID yerine INP geçti — artık sayfanın tüm ömrü boyunca en kötü etkileşim ölçülüyor, bu çok daha katı bir kriter. Hız tek başına sıralamayı belirlemez ama eşit içerik kalitesindeki iki rakip arasında CWV metriklerini geçen öne çıkar. Türkiye'de mobil trafik %65-75 aralığında olduğundan bu fark mobilde daha da belirgin.

Bu noktada platform seçimi devreye giriyor: WordPress'in PHP+MySQL mimarisi ile Next.js'in React tabanlı render stratejileri, aynı hız hedefine çok farklı yollardan ulaşır. Bu yazı, iki platformun hız tavanını, darboğazlarını ve optimizasyon araçlarını yan yana karşılaştırıyor.

2. Core Web Vitals Kısa Hatırlatma: LCP, INP, CLS

Metrik	Açıklama	İyi	İyileştir	Kötü
LCP (Largest Contentful Paint)	Görünür alandaki en büyük öğenin render süresi	≤ 2.5 sn	2.5–4.0 sn	> 4.0 sn
INP (Interaction to Next Paint)	Tüm etkileşimlerin 75. yüzdelik yanıt süresi	≤ 200 ms	200–500 ms	> 500 ms
CLS (Cumulative Layout Shift)	Sayfa yükleme sırasında öğelerin kayma skoru	≤ 0.1	0.1–0.25	> 0.25

Google sıralama için field veriyi (Chrome User Experience Report / CrUX) kullanır; PageSpeed Insights ve Lighthouse'un verdiği "lab" skoru sadece kontrollü ortam tahminidir. Eşik değerlerin tam açıklaması ve ölçüm araçları için Core Web Vitals 2026 rehberimize bakabilirsiniz — bu yazıda doğrudan WordPress ve Next.js'in bu metrikleri nasıl farklı şekilde etkilediğine odaklanıyoruz.

3. Mimari Fark: PHP+MySQL (WordPress) vs React Render Stratejileri (Next.js)

WordPress her sayfa isteğini aynı zincirde işler: PHP parse → veritabanı sorgusu → tema/eklenti kodu → HTML üretimi → tarayıcıya gönderim. Önbellekleme yoksa bu zincir her istekte yeniden çalışır. Tipik darboğazlar:

• PHP execution: ağır tema + çok sayıda aktif eklenti PHP süresini 300-800 ms'ye çıkarabilir
• Veritabanı sorguları: optimize edilmemiş WooCommerce sorguları, büyük meta tablolar TTFB'yi doğrudan artırır
• WP-Cron: periyodik görevler rastgele HTTP isteklerinde tetiklenir; yoğun sitede darboğaz yaratır (sistem cron'una taşıyın)
• Şişirilmiş temalar: sayfa builder'lı temalar her sayfa için 500 KB–2 MB arası JS yükler

Next.js ise render zamanını sayfa bazında seçmenizi sağlar:

Strateji	Nasıl çalışır	Ne zaman kullan
SSG (Static Site Generation)	Build zamanı HTML üret, CDN'den sun	Blog, dokümantasyon, landing page
SSR (Server-Side Rendering)	Her istekte server'da HTML üret	Kişiselleştirilmiş içerik, auth
ISR (Incremental Static Regeneration)	Statik + arka planda yenile	E-ticaret katalog, CMS içerik
RSC (React Server Components)	Server'da render, minimal JS client'a	App Router (Next.js 13+)

Bu esneklik Next.js'in hız tavanını WordPress'e göre yapısal olarak yükseğe taşır: statik HTML doğrudan CDN'den servis edilirken, WordPress her istekte (cache yoksa) PHP+DB zincirini baştan çalıştırmak zorundadır. Ama pratikte WordPress + doğru cache stack ile bu fark büyük ölçüde kapanır — sonraki bölümler bunu gösteriyor.

4. Görsel Optimizasyonu: WordPress Eklentileri vs next/image

LCP elementinin %60-70'i genelde hero görselidir; imaj optimizasyonu LCP için en hızlı kazanımdır.

WordPress'te ShortPixel veya Imagify eklentisi WebP/AVIF dönüşümü + lazy loading'i otomatik yapar; LSCache'in kendi WebP dönüşümü de yeterlidir. Manuel HTML kontrolü gerektiğinde:

<picture>
  <source srcset="/hero.avif" type="image/avif">
  <source srcset="/hero.webp" type="image/webp">
  <img src="/hero.jpg" alt="Ana görsel" width="1200" height="630"
       fetchpriority="high" loading="eager">
</picture>

<img src="/urun.webp" alt="Ürün görseli" width="800" height="600"
     loading="lazy" decoding="async">

Next.js'te aynı işi next/image bileşeni tek yerde halleder — otomatik WebP/AVIF, lazy loading, boyut optimizasyonu, blur placeholder:

import Image from 'next/image';

export function HeroSection() {
  return (
    <Image
      src="/hero.jpg"
      alt="Hero görseli"
      width={1200}
      height={630}
      priority        // LCP için kritik; lazy loading'i devre dışı bırakır
      quality={85}
      placeholder="blur"
      blurDataURL="data:image/jpeg;base64,/9j/4AAQSkZJRgAB..."
    />
  );
}

Kritik kural (her iki platformda geçerli): LCP görseline loading="lazy" ASLA koymayın — bu LCP süresini 300-800 ms artırır. Fold üstü görsellerde fetchpriority="high" (Next.js'te priority) kullanın. Boyut belirtmek (width/height) CLS için zorunludur.

Fark: WordPress'te bu otomasyon üçüncü parti eklentiye bağımlıdır (ek yapılandırma, olası çakışma riski); Next.js'te framework'ün kendisinde yerleşiktir.

5. CSS/JS ve Bundle Boyutu: WordPress Disiplini vs Next.js Code Splitting

Render-blocking kaynaklar: tarayıcı <head>'deki senkron CSS/JS'i indirip işlemeden sayfayı render etmez.

WordPress'te bunu manuel kontrol etmek zordur çünkü CSS/JS çoğunlukla eklentiler tarafından enjekte edilir:

<style>
  body { font-family: 'Inter', sans-serif; margin: 0; }
  .hero { background: #1a1a2e; color: white; padding: 4rem 2rem; }
</style>

<link rel="stylesheet" href="/styles/full.css"
      media="print" onload="this.media='all'">

<script src="/analytics.js" async></script>
<script src="/app.js" defer></script>

Eklenti seçiminde tek kural: tek minify/optimize eklentisi kullanın. LiteSpeed sunucusunda LSCache'in kendi CSS/JS optimizasyonu yeterlidir; WP Rocket gibi ek bir eklenti eklemek çakışma riski yaratır ve Apache için tasarlandığından LiteSpeed ortamında ek fayda sağlamaz.

Next.js'te bu disiplin framework seviyesinde otomatiktir: her sayfa sadece kendi bağımlılığını yükler, ağır bileşenler dynamic() ile ayrıca bölünebilir:

import dynamic from 'next/dynamic';

const HeavyChart = dynamic(() => import('./HeavyChart'), {
  loading: () => <ChartSkeleton />,
  ssr: false,
});

Bundle hedefi (her iki platform için): kritik yolda gzipped JS < 170 KB. Next.js'te ANALYZE=true next build ile (bundle-analyzer entegrasyonu gerekir) bundle raporu alınır; WordPress'te Chrome DevTools > Coverage sekmesi kullanılmayan JS yüzdesini gösterir — %50+ ise eklenti/tema şişkinliği var demektir.

Fark: WordPress'te JS/CSS optimizasyonu eklenti disiplini ve doğru sunucu yapılandırmasıyla sınırlıdır; Next.js'te derleme zamanında otomatik code splitting devreye girer, geliştirici sadece ağır bileşenleri işaretler.

6. Önbellekleme ve Render: LiteSpeed/Redis (WordPress) vs ISR/Streaming (Next.js)

WordPress tarafında Büyükweb paylaşımlı hosting'de standart gelen stack:

Sunucu katmanı:
  LiteSpeed Web Server (cPanel'de standart)
  Redis Object Cache
  Brotli sıkıştırma
  HTTP/3

WordPress eklenti katmanı:
  LiteSpeed Cache (ücretsiz, en entegre seçenek)
  → Page Cache, Redis bağlantısı, WebP dönüşüm
  → CSS/JS minify + combine + defer

Yedekleme:
  JetBackup (günlük otomatik yedek — Buyukweb standarttır)

LSCache sunucu tarafında HTML önbelleği üretir; Apache + cache eklentisi kombosuna göre TTFB tipik %60-70 daha hızlıdır. Redis Object Cache ise login olmuş kullanıcı veya WooCommerce sepeti gibi sayfa cache'ini bypass eden dinamik sayfalarda kritiktir — Büyükweb hosting paketlerinde dahildir.

Next.js'te önbellekleme framework içinde, kod seviyesinde tanımlanır:

export const revalidate = 3600; // 1 saatte bir arka planda yenile

export default async function BlogPost({ params }) {
  const post = await getPost(params.slug);
  return <article>{post.content}</article>;
}

import { revalidatePath } from 'next/cache';
revalidatePath('/blog/[slug]', 'page');

Streaming ile TTFB düşürülür — sayfa shell'i anında gönderilir, ağır veri Suspense ile sonraya bırakılır:

import { Suspense } from 'react';

export default function Page() {
  return (
    <>
      <Header />
      <Suspense fallback={<Skeleton />}>
        <SlowDataComponent />
      </Suspense>
    </>
  );
}

Fark: WordPress'te cache katmanı sunucu + eklenti kombinasyonuyla dışarıdan eklenir; Next.js'te ISR/streaming render mantığının parçasıdır, kod içinde tanımlanır ve deploy anında devreye girer.

7. INP Karşılaştırması: WordPress'te Azaltma, Next.js'te Kontrol

INP, main thread'i bloke eden JavaScript'ten kaynaklanır. Derinlemesine teknikler için INP Optimizasyonu rehberimize bakabilirsiniz; burada platform farkına odaklanıyoruz.

WordPress'te geliştiricinin event handler kodu üzerinde doğrudan kontrolü sınırlıdır — INP iyileştirmesi genelde üçüncü parti script azaltma, gereksiz eklenti kaldırma ve senkron çalışan tema JS'ini defer etmekle sınırlı kalır (bkz. Bölüm 5).

Next.js'te React 18 batching ile acil olmayan state güncellemeleri düşük öncelikli işaretlenebilir:

import { startTransition, useState } from 'react';

function SearchPage() {
  const [query, setQuery] = useState('');
  const [results, setResults] = useState([]);

  function handleInput(value) {
    setQuery(value);                        // acil: anında güncelle
    startTransition(() => {
      setResults(computeResults(value));    // acil değil: ertelenebilir
    });
  }

  return <input onChange={(e) => handleInput(e.target.value)} />;
}

startTransition, ağır state güncellemesini kullanıcı etkileşiminin arkasına atar; INP düşer. WordPress'te bu seviyede ince taneli kontrol mümkün değildir çünkü render mantığı framework içinde değil, tema/eklenti kodunda dağınık halde bulunur.

Fark: Next.js geliştiriciye render önceliklendirme araçları (Suspense, startTransition) sunar; WordPress'te INP optimizasyonu büyük ölçüde "daha az JS çalıştır" disiplinine dayanır.

8. Mobil Performans: 4G Testi ve Platform Farkı

Google sıralama için mobil CWV öncelikli; Türkiye'de 4G bağlantı hâlâ egemen. Chrome DevTools > Network > "Fast 4G" / "Slow 4G" seçilerek gerçek kullanıcı koşulları lab ortamında simüle edilebilir.

Düşük uçlu Android cihazlarda (2-4 GB RAM) zayıf main thread INP'i özellikle vurur. WordPress sitelerinde bunun tipik nedeni eklenti/tema JS birikimidir; Next.js self-host'ta ise code splitting doğru yapılandırılmadıysa tek büyük bundle aynı soruna yol açabilir — Bölüm 5'teki bundle disiplini mobilde daha da kritik hale gelir.

9. Hosting ve CDN Katmanı: TTFB Hedefi, Büyükweb Altyapısı, Cloudflare

TTFB (Time to First Byte) < 200 ms, LCP hedefinin altyapı tarafıdır — origin sunucu bu eşiği tutturamazsa CDN ve eklenti optimizasyonu sınırlı kalır.

CDN katmanı: statik dosyaları (resim, CSS, JS, font) kullanıcıya coğrafi yakın edge node'dan sunar, origin yükünü azaltır ama sıfırlamaz. WordPress'te Cloudflare Automatic Platform Optimization (APO) sayfaları edge'de önbelleğe alır, LSCache'in Cloudflare API entegrasyonu cache invalidation'ı otomatikleştirir — detaylar Cloudflare CDN kurulum rehberimizde. Next.js self-host'ta Cloudflare önde proxy+CDN olarak çalışır; statik dosyalar (/_next/static/) edge'e alınır, SSR/SSG sayfaları origin'e gelir. CDN sınırı: cache miss durumunda istek origin sunucuya düşer — origin TTFB zayıfsa CDN pek bir şey kurtaramaz.

Büyükweb altyapısı (her iki platform için ortak):

• NVMe disk — disk I/O darboğazını ortadan kaldırır
• İstanbul'daki Tier III standartlarındaki veri merkezi — Türkiye ziyaretçisi için 10-30 ms RTT, Avrupa/ABD bazlı sunuculara göre 80-150 ms latency avantajı
• Günlük otomatik yedekleme (JetBackup) — hosting ve VDS paketlerinde standart

Ne zaman VDS? Paylaşımlı hosting orta büyüklükte WordPress siteleri için yeterli. Yüksek eş zamanlı trafik, Next.js self-host veya özel yazılım ihtiyacında VDS daha uygun — Büyükweb VDS paketleri NVMe + VMware vSphere sanallaştırma + Web Konsol kurtarma sağlar; pm2 veya Docker ile platform bağımlılığı olmadan deploy edilir.

Kapasite rehberi (yaklaşık):
  Aylık 30.000 ziyaret altı WP    → paylaşımlı hosting yeterli
  30.000-200.000 arası            → güçlü paylaşımlı veya başlangıç VDS
  200.000+ veya Next.js self-host → VDS 4+ vCPU, 8+ GB RAM

10. WordPress mu Next.js mi? Karar Matrisi

Bu sorunun tek doğru cevabı yok; proje tipine göre karar verilmeli.

Kriter	WordPress	Next.js
Teknik bilgi eşiği	Düşük (görsel yönetim, eklentiler)	Yüksek (React, Node.js, deploy)
İçerik yönetimi	Dahili (Gutenberg, WooCommerce)	Ayrı CMS gerekir (WP REST API, GraphQL)
Hız tavanı	İyi (LiteSpeed + cache stack ile)	Çok yüksek (SSG/ISR + CDN)
Hosting maliyeti	Paylaşımlı hosting yeterli	VDS/container önerilir
Eklenti ekosistemi	60.000+ eklenti	npm, kütüphane tabanlı
E-ticaret	WooCommerce (olgun)	Kendi implantasyonu gerekir
Headless CMS hybrid	WP REST API / GraphQL ile mümkün	Doğal uyum
Tipik kullanım	Blog, KOBİ sitesi, WooCommerce	SaaS, marketplace, özel UI

Pratik kural:

• Küçük/orta blog, kurumsal site, WooCommerce mağazası → WordPress + LiteSpeed stack
• Özel kullanıcı deneyimi, yüksek trafik SaaS, marketplace, JAMstack → Next.js + VDS self-host
• Mevcut WP sitesini koruyup özel frontend → Headless: WP REST API + Next.js

Headless hybrid, her iki dünyayı birleştirir: WordPress'in içerik yönetimini, Next.js'in render esnekliğini alırsınız. Ancak iki sistem yönetme maliyeti var.

11. Sık Sorulan Sorular

WordPress'ten Next.js'e geçeyim mi?

Çoğu durumda gerekmez. WordPress + LiteSpeed + doğru cache stack ile CWV hedeflerini tutturmak mümkün (Bölüm 6). Next.js'in avantajı render esnekliği ve derleme zamanı optimizasyonları; dezavantajı içerik yönetimi için ayrı CMS ihtiyacı ve yüksek teknik eşik. Geçiş kararı için önce "mevcut stack CWV hedeflerimi tutturabiliyor mu?" sorusunu yanıtlayın.

Hosting VDS mi, paylaşımlı mı?

Küçük/orta WordPress siteleri için LiteSpeed paylaşımlı hosting TTFB < 200 ms hedefini tutturur. Yüksek trafik, Next.js self-host veya özel yazılım gerektiren projelerde VDS. Büyükweb'in iki seçeneği de İstanbul'daki Tier III standartlarındaki veri merkezinden hizmet verir; latency avantajı her ikisinde geçerlidir.

INP nedir, kısaca?

Kullanıcı sayfayla etkileşime girdiğinde (tıklama, tuş, dokunma) tarayıcının yanıt vermesi ne kadar sürdü sorusunun cevabıdır — sayfanın tüm ömrü boyunca takip edilir, 75. yüzdelik raporlanır. ≤ 200 ms iyi, > 500 ms kötü. Detaylı optimizasyon teknikleri için INP rehberimize bakabilirsiniz.

LiteSpeed Cache mi, WP Rocket mi?

LiteSpeed sunucusunda LiteSpeed Cache kesinlikle önce gelir — sunucu seviyesi önbellek, ücretsiz, tam entegre. WP Rocket Apache sunucular için güçlü bir seçenek; Büyükweb'de LSCache zaten dahil, ek ücretli eklentiye gerek yok.

Next.js'i self-host ederken ne kullanmalı?

Platform bağımlılığına girmeden Büyükweb VDS üzerinde pm2 veya Docker ile koşturabilirsiniz. next build && next start yeterlidir. VDS'in avantajı: root yetki, kendi Redis cache'i, özel Nginx/Caddy ters proxy, tam kontrol.

VDS'te Next.js için Cloudflare gerekli mi?

Zorunlu değil ama önerilir. Cloudflare ücretsiz katmanı DDoS koruması + statik dosya cache'i + SSL sağlar. Türkiye ziyaretçileri için ek latency getirmez; İstanbul ve Ankara edge node'ları mevcuttur.

---

Sayfa hızı tek seferlik bir optimizasyon değil, sürekli izleme gerektiren bir süreç. Platform seçimi bu sürecin başlangıç noktası: WordPress + doğru cache stack ile de, Next.js + VDS self-host ile de 2026 CWV hedefleri tutturulabilir — seçim proje ihtiyacına göre yapılmalı (Bölüm 10). Her büyük içerik veya kod değişikliğinin ardından PageSpeed Insights + Search Console CWV raporunu kontrol edin.

Sorularınız için 0850 302 60 70 numaralı satış öncesi destek numaramıza ulaşabilir veya iletişim sayfamıza yazabilirsiniz.

---

İlgili Büyükweb Hizmetleri

Hız ve uptime, sıralama için kritik. Türkiye lokasyonlu hızlı hosting paketlerimiz:

• LiteSpeed + NVMe Web Hosting
• WordPress Hosting
• VDS Sunucu
• cPanel Web Hosting
• Türkiye VDS (Düşük Ping)

Sorularınız için 0850 302 60 70 numaralı satış öncesi destek numaramıza ulaşabilir veya iletişim sayfamıza yazabilirsiniz.