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? Her iki platformda 2026 standartlarını karşılamak için ne yapılmalı? VDS mi, paylaşımlı hosting mi daha mantıklı? Bu soruları teknik kanıtlarla cevaplıyoruz.

Kapsam notu: Bu yazı platform karşılaştırması ve karar rehberi. Saf WordPress CWV detayı için wp-cwv yazımıza, genel CWV eşik değerleri için cwv-2026 yazımıza bakabilirsiniz. Cloudflare CDN entegrasyonu cdn-cloudflare yazısında anlatılıyor.

1. Hız Neden 2026'da Daha Kritik?

Google, Core Web Vitals'ı 2021'de sıralama sinyali olarak açıkladı; ancak 2024-2026 arasında ağırlığı giderek arttı. Temel değişiklik: artık FID (First Input Delay) yerine INP (Interaction to Next Paint) geçerli. FID sadece ilk etkileşimi ölçüyordu; INP sayfanın tüm ömrü boyunca en kötü etkileşimi ölçer. Bu çok daha katı bir kriter.

Hız sıralamanın tek belirleyicisi değil — içerik, backlink, kullanıcı sinyalleri önde gelir. Ama iki rakip eşit içerik kalitesindeyse CWV metriklerini geçen öne çıkar. Türkiye'de mobil trafik %65-75 oranında olduğundan mobil performans özellikle kritik.

Pratik etkisi: PageSpeed Insights'ta puanı 30-40 olan bir site, benzer içerikle 80+ puana sahip rakibine kıyasla görünürlük kaybeder. Bu fark çoğunlukla hosting + platform seçiminden kaynaklanıyor.

2. Core Web Vitals 2026: LCP, INP, CLS Eşik Değerleri

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

Lab vs Field ayrımı: PageSpeed Insights ve Lighthouse, kontrollü ortamda "lab" ölçümü verir. "Field" veri ise gerçek kullanıcı cihazlarından gelen Chrome User Experience Report (CrUX) verisidir. Google sıralama için field veriyi kullanır; INP için bu özellikle önemlidir çünkü INP etkileşim gerektiriyor ve lab ortamında simüle edilmesi zor.

3. Ölçüm Araçları: Nereden Başlamalı?

PageSpeed Insights (pagespeed.web.dev) — ücretsiz, hem lab hem field veri, URL bazlı. Başlangıç noktası.

Google Search Console > Core Web Vitals — sitenizin URL grupları "iyi / iyileştir / kötü" olarak sınıflandırılıyor. Düzeltme sonrası "Validation Fix" talebi gönderin, Google 4 hafta içinde yeniden doğrular.

Chrome DevTools — F12 > Lighthouse > Mobile + Performance. Lab ortamı, anında geri bildirim.

web-vitals.js (RUM) — gerçek kullanıcı ölçümü. Üretim sitesine ekleyip GA4'e gönderin:

import { onLCP, onINP, onCLS } from 'web-vitals';

function sendToGA4(metric) {
  gtag('event', metric.name, {
    value: Math.round(metric.name === 'CLS' ? metric.value * 1000 : metric.value),
    metric_rating: metric.rating,  // 'good' | 'needs-improvement' | 'poor'
    metric_id: metric.id,
  });
}

onLCP(sendToGA4);
onINP(sendToGA4);
onCLS(sendToGA4);

Bu dört araç birlikte kullanıldığında hem anlık sorunları hem uzun vadeli trendi görebilirsiniz.

4. WordPress'te Darboğazlar: Neler Performansı Öldürür?

WordPress, PHP + MySQL mimarisinde çalışır. Her sayfa isteği default olarak şu zinciri işler: PHP parse → DB sorgusu → tema/eklenti kodu → HTML üretimi → tarayıcıya gönder. Önbellekleme yoksa bu zincir her istekte tekrar çalışır.

Tipik darboğazlar:

• PHP execution: Ağır tema ve ç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örevleri rastgele HTTP isteklerinde tetikler; yoğun sitede darboğaz yaratır (sistem cron'una taşıyın)
• Render-blocking CSS/JS: Header'da senkron yüklenen stil ve script dosyaları LCP'yi geciktirir
• Şişirilmiş temalar: Sayfa builder'lı temalar her sayfa için 500 KB–2 MB arası JS yükler

Bu darboğazların çoğu doğru stack seçimiyle çözülür.

5. WordPress Hızlandırma Stack'i: LiteSpeed + Redis + LSCache

Buyukweb paylaşımlı hosting paketlerinde standart olarak LiteSpeed Web Server kurulu gelir. Bu önemlidir çünkü LSCache (LiteSpeed Cache eklentisi) sunucu tarafında HTML önbelleği üretir; Apache + cache eklentisi kombosuna göre TTFB tipik %60-70 daha hızlıdır.

Önerilen temel stack:

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

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

Yedekleme:
  JetBackup (haftalık otomatik backup — Buyukweb standarttır)

Redis Object Cache neden önemlidir? WordPress DB sorguları tekrar eden içerikler için (menü, widget, transient) Redis'te önbelleğe alınır. Sayfa cache'i bypass eden login olmuş kullanıcılar veya WooCommerce sepeti gibi dinamik sayfalar için kritik. Buyukweb hosting paketlerinde Redis Object Cache desteği mevcuttur.

LSCache ayarları için minimal başlangıç:

LiteSpeed Cache > Cache > Enable Page Cache: açık
LiteSpeed Cache > Image Optimization > WebP Replacement: açık
LiteSpeed Cache > CSS/JS: CSS Minify, JS Minify, JS Defer: açık
LiteSpeed Cache > Database > Scheduler: haftalık çalıştır

6. WordPress İmaj Optimizasyonu: WebP/AVIF, Lazy Load, Priority Hint

LCP elementinin %60-70'i hero resmidir. İmaj optimizasyonu LCP için en hızlı kazanım.

<!-- Modern tarayıcılar için AVIF/WebP, eski için JPEG fallback -->
<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>

<!-- Fold altı görseller için lazy loading -->
<img src="/urun.webp" alt="Ürün görseli" width="800" height="600"
     loading="lazy" decoding="async">

Kritik kural: LCP görseline loading="lazy" ASLA koymayın. Bu LCP süresini 300-800 ms artırır. Fold üstü görsellerde fetchpriority="high" ve loading="eager" (ya da hiç loading attribute) kullanın.

WordPress'te otomatik çözüm: ShortPixel veya Imagify eklentisi WebP/AVIF dönüşümü + lazy loading'i otomatik halleder. LSCache'in kendi WebP dönüşümü de yeterlidir.

Boyut belirtmek CLS için zorunlu — width ve height attribute olmayan resimler layout shift yaratır.

7. WordPress JS/CSS Optimizasyonu: Defer, Async, Critical CSS

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

<!-- Kritik CSS inline (above-the-fold için) -->
<style>
  body { font-family: 'Inter', sans-serif; margin: 0; }
  .hero { background: #1a1a2e; color: white; padding: 4rem 2rem; }
</style>

<!-- Geri kalan CSS async yükle -->
<link rel="stylesheet" href="/styles/full.css"
      media="print" onload="this.media='all'">

<!-- Bağımsız script: async -->
<script src="/analytics.js" async></script>

<!-- DOM'a bağımlı script: defer -->
<script src="/app.js" defer></script>

Eklenti seçimi: LSCache Native > Autoptimize > Asset CleanUp > WP Rocket. LiteSpeed sunucusunda LSCache'in kendi CSS/JS optimizasyonu yeterlidir; ek minify eklentisi gerekmez, çakışma riski artar. WP Rocket, Apache sunucularda iyi çalışır ancak LiteSpeed ortamında LSCache ile çakışabilir — tek eklenti kullanın.

8. Next.js Avantajları: SSR, SSG, ISR ve React Server Components

Next.js, React üzerine inşa edilmiş full-stack framework. Temel avantajı render stratejisi esnekliğidir:

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+)

next/image bileşeni — otomatik WebP/AVIF dönüşümü, lazy loading, boyut optimizasyonu, blur placeholder. WordPress'teki ShortPixel + LSCache kombosu Next.js'te tek bileşenle halledilir:

import Image from 'next/image';

// LCP görseli — priority=true fetchpriority="high" karşılığı
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..."
    />
  );
}

next/font — Google Fonts'u self-host ederek CLS ve FOIT'u sıfırlar:

import { Inter } from 'next/font/google';

const inter = Inter({ subsets: ['latin'], display: 'swap', variable: '--font-inter' });

export default function RootLayout({ children }) {
  return <html className={inter.variable}><body>{children}</body></html>;
}

9. Next.js Performans Detayı: ISR, Streaming ve Code Splitting

ISR ile dinamik içeriği önbelleğe alın:

// app/blog/[slug]/page.tsx (App Router)
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>;
}

// On-demand revalidation (CMS webhook'ta)
import { revalidatePath } from 'next/cache';
revalidatePath('/blog/[slug]', 'page');

Streaming ile TTFB'yi düşürün: React Suspense ile ağır bileşenleri sonraya bırakın, sayfa shell'i anında gönderilsin:

import { Suspense } from 'react';

export default function Page() {
  return (
    <>
      <Header />                    {/* anında render */}
      <Suspense fallback={<Skeleton />}>
        <SlowDataComponent />        {/* veri gelince render */}
      </Suspense>
    </>
  );
}

Kod bölme (code splitting):

import dynamic from 'next/dynamic';

// Ağır bileşeni lazy yükle (INP + bundle size için)
const HeavyChart = dynamic(() => import('./HeavyChart'), {
  loading: () => <ChartSkeleton />,
  ssr: false,
});

Partial Prerendering (PPR) Next.js canary'de deneysel; statik shell + dinamik slot birleşimi olarak 2026'da stable release sürecinde.

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. CDN Katmanı: Cloudflare Entegrasyonu ve Sınırları

CDN, statik dosyaları (resim, CSS, JS, font) kullanıcıya coğrafi olarak yakın edge node'dan sunar. TTFB'yi etkileyen origin sunucu yükünü azaltır ama kaldırmaz.

Cloudflare + WordPress:

Cloudflare Automatic Platform Optimization (APO), WordPress sayfalarını edge'de önbelleğe alır. Türkiye'deki CDN edge'leri Istanbul, Ankara üzerinden hizmet verir. LSCache'in Cloudflare API entegrasyonu cache invalidation'ı otomatikleştirir.

Cloudflare + Next.js (VDS self-host):

VDS üzerinde çalışan Next.js için Cloudflare önünde proxy + CDN olarak kullanılır. Statik dosyalar edge cache'e alınır; SSR/SSG sayfaları origin'e gelir. VDS self-host için basit senaryo: Cloudflare proxy açık, /_next/static/ için immutable cache kuralı.

CDN sınırı: CDN cache miss durumunda istek doğrudan origin sunucuya gelir. Origin TTFB zayıfsa CDN pek bir şey kurtarmaz. İlk adım her zaman origin hızıdır.

12. Hosting Katmanı: TTFB Hedefi ve Buyukweb Altyapısı

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

Buyukweb paylaşımlı hosting:

• LiteSpeed Web Server + LSCache (sunucu seviyesi önbellek)
• Redis Object Cache (dinamik sayfa, WooCommerce için kritik)
• NVMe disk (disk I/O darboğazını ortadan kaldırır)
• JetBackup — haftalık otomatik yedekleme standart
• Bursa Tier 3 veri merkezi — Türkiye ziyaretçisi için 10-30 ms RTT

Türkiye'deki ziyaretçi için Bursa datacenter'dan servis etmek, Avrupa veya ABD bazlı sunuculara kıyasla 80-150 ms latency avantajı sağlar. Yurt içi trafik ağırlıklı siteler için bu fark LCP'ye doğrudan yansır.

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. Buyukweb VDS paketleri: NVMe + KVM sanallaştırma + KVM konsol kurtarma + e5v4/e5v2 CPU. Self-host Next.js için VDS'e PM2 veya Docker ile deploy yapılabilir; platform bağımlılığı yoktur.

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

13. Mobil Performans: 4G Simülasyon ve JS Bundle Disiplini

Google sıralama için mobil CWV masaüstü CWV'den önce gelir. Türkiye'de 4G bağlantı hâlâ egemen; 5G yaygınlığı şehirle sınırlı.

4G simülasyon testi: Chrome DevTools > Network > "Fast 4G" veya "Slow 4G" seçin > sayfa reload. Gerçek kullanıcı koşullarını bu şekilde lab ortamında test edersiniz.

JavaScript bundle hedefi: 2026 için pratik hedef gzipped bundle boyutu < 170 KB (kritik yol). Next.js next build çıktısında bundle analizi için:

ANALYZE=true next build
# next.config.js'de @next/bundle-analyzer entegrasyonu gerekli

WordPress'te JS bundle analizi için Chrome DevTools > Coverage sekmesi kullanılmayan JS yüzdesini gösterir. %50+ kullanılmayan JS varsa eklenti ve tema şişkinliği var demektir.

Düşük uç cihaz testi: Entry-level Android cihaz (2-4 GB RAM, orta işlemci) INP'i öldürür çünkü main thread çok zayıf. web-vitals.js ile gerçek kullanıcı INP değerlerini toplayın; lab değerinden çok farklı çıkabilir.

14. INP Optimizasyonu: Long Task Kırmak ve React Batching

INP, main thread'i bloke eden JavaScript'ten kaynaklanır. En yaygın suçlu: event handler'da çok iş yapmak veya büyük React component yeniden render.

Long task kırma:

// scheduler.yield() ile parçala (Chromium 129+)
async function processLargeList(items) {
  for (const item of items) {
    heavyTransform(item);
    if ('scheduler' in window && 'yield' in scheduler) {
      await scheduler.yield();
    } else {
      await new Promise(r => setTimeout(r, 0));
    }
  }
}

Event handler debounce:

// Her tuş basışında değil, 300 ms durgunlukta çalış
let debounceTimer;
input.addEventListener('input', (e) => {
  clearTimeout(debounceTimer);
  debounceTimer = setTimeout(() => fetchSuggestions(e.target.value), 300);
});

React batching (React 18+):

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üncellemelerini "düşük öncelikli" olarak işaretler; kullanıcı etkileşimi önce gelir, INP düşer.

15. 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. Next.js'in avantajı render esnekliği ve JS ekosistemi; dezavantajı içerik yönetimi için ayrı CMS ihtiyacı ve yüksek teknik eşik. Geçiş kararı için: "mevcut stack CWV hedeflerimi tutturabiliyor mu?" sorusunu önce 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. Buyukweb'in iki seçeneği de Bursa Tier 3 datacenter'dan hizmet verir; latency avantajı her ikisinde geçerli.

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ü? INP bu süreyi sayfanın tüm ömrü boyunca takip eder ve 75. yüzdeliği raporlar. ≤ 200 ms iyi, > 500 ms kötü. Eski FID sadece ilk etkileşime bakıyordu; INP çok daha katı.

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; Buyukweb'de LSCache zaten dahil, ek ücretli eklentiye gerek yok.

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

Platform bağımlılığına girmeden Buyukweb 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.

CLS sorunum var, nereden başlamalı?

DevTools > Lighthouse > CLS skoru tıklayın, hangi elementlerin shift yaptığını listeler. Tipik suçlular: boyutsuz resim (width/height ekleyin), geç yüklenen reklam/embed (min-height ile yer rezerv edin), font swap (font-display: swap + size-adjust). CLS genellikle birkaç saatlik çalışmayla çözülebilir.

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ı mevcut.

---

Sayfa hızı tek seferlik bir optimizasyon değil, sürekli izleme gerektiren bir süreç. Her büyük içerik veya kod değişikliğinin ardından PageSpeed Insights + Search Console CWV raporunu kontrol edin. Altyapı tarafı için Buyukweb hosting veya VDS paketleri Türkiye'deki hedef kitlenize en kısa latency'yi sağlar.

Sorularınız için 0850 302 60 70 numaralı destek hattımıza 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ı destek hattımıza veya iletişim sayfamıza yazabilirsiniz.