Site Optimizasyonu Nasıl Yapılır? Frontend, Backend, Veritabanı ve CDN A'dan Z'ye

Site optimizasyonu, modern web mühendisliğinin en geniş ve en yanıltıcı konularından biridir. Optimizasyon dendiğinde çoğu kişi yalnızca görsel sıkıştırma veya bir CDN takmayı düşünür; oysa gerçek performans kazancı frontend, backend, veritabanı, ağ ve cache katmanlarının her birinde küçük ama disiplinli kararların toplamından doğar. Bu rehber, KEYDAL'in kurumsal müşterileri için uyguladığı uçtan uca optimizasyon checklist'ini — gerçek komutlar, yapılandırma örnekleri ve ölçüm yöntemleriyle — tek bir yazıya sıkıştırıyor.

Eğer yalnızca metriklere — LCP, INP, CLS — odaklı bir derinlemesine yazı arıyorsanız, ayrı bir rehberimiz var: Sayfa Hızı ve Core Web Vitals 2026. Bu yazı ise daha geniş bir bakış sunuyor — sunucu tuning'inden veritabanı indekslemesine, CDN seçiminden TLS handshake'ine kadar tüm katmanları kapsıyor.

İlgili rehberler: Arama motoru ve SEO rehberi · Core Web Vitals 2026 · WordPress SEO plugin önerileri · Dijital pazarlama · KEYDAL SEO hizmetleri

Önce Ölçüm: Ölçemediğiniz Şeyi İyileştiremezsiniz

Optimizasyona başlamanın tek doğru yolu, mevcut durumu rakamlarla belgelemektir. Yapacağınız her değişikliğin etkisini önce ve sonra metrikleriyle kıyaslamadan tek bir satır kod değiştirmeyin. Ölçümsüz optimizasyon, batıl inançtır.

Beş temel ölçüm aracını her projede kullanırız: tarayıcıda Lighthouse ve DevTools Performance paneli, sahada PageSpeed Insights (CrUX field data ile), karmaşık senaryolar için WebPageTest, gerçek kullanıcı verisi için RUM (Sentry Performance, Datadog RUM veya Google Analytics 4'ün Core Web Vitals raporları).

Lighthouse CLI ile Otomatik Ölçüm

# Lighthouse CLI kurulumu ve tek seferlik çalıştırma
npm install -g lighthouse
lighthouse https://ornek.com \
  --output=html --output=json \
  --output-path=./report \
  --chrome-flags="--headless --no-sandbox" \
  --preset=desktop

# Mobil profil ile ölçüm (varsayılan)
lighthouse https://ornek.com --view

# CI/CD entegrasyonu için skor eşikleri
lighthouse https://ornek.com \
  --budget-path=./budget.json \
  --assert

Lighthouse'u tek başına kanıt olarak kullanmayın — laboratuvar koşullarında ölçer, gerçek kullanıcının deneyimini her zaman yansıtmaz. CrUX (Chrome User Experience Report) verisini de mutlaka takip edin. HTTP Archive üzerinden sektör ortalamalarınızla kıyaslayabilirsiniz.

Real User Monitoring (RUM)

Gerçek kullanıcılar farklı cihazlarda, farklı bağlantılarda, farklı coğrafyalarda farklı performans yaşar. RUM bu çeşitliliği yakalar. Web Vitals JavaScript kütüphanesini Sentry, Datadog veya kendi backend'inize gönderecek şekilde kurun.

// web-vitals npm paketi ile manuel RUM
import { onLCP, onINP, onCLS, onFCP, onTTFB } from 'web-vitals';

function sendToAnalytics({ name, value, id }) {
  navigator.sendBeacon('/rum', JSON.stringify({
    metric: name, value, id,
    url: location.pathname,
    nav: navigator.connection?.effectiveType
  }));
}

onLCP(sendToAnalytics);
onINP(sendToAnalytics);
onCLS(sendToAnalytics);
onFCP(sendToAnalytics);
onTTFB(sendToAnalytics);

Core Web Vitals Hızlı Özet

Google'ın 2021'den bu yana sıralama sinyali olarak kullandığı üç metrik: LCP < 2.5s (largest contentful paint), INP < 200ms (interaction to next paint, 2024'te FID'nin yerine geçti), CLS < 0.1 (cumulative layout shift). Detaylar için web.dev/vitals ve dahili Core Web Vitals 2026 yazımız.

• LCP: Sayfanın en büyük görsel öğesinin (genellikle hero image) ekrana gelme süresi. Server response, render-blocking JS/CSS ve görsel optimizasyonu doğrudan etkiler.
• INP: Kullanıcı bir tıklama/dokunuş/klavye girişi yaptığında bir sonraki frame'in çizilmesine kadar geçen süre. JavaScript main thread blokları en büyük düşmandır.
• CLS: Sayfa yüklenirken görsel öğelerin ne kadar kaydığı. Width/height attribute eksik görseller, geç yüklenen reklam slot'ları ve font swap'ı en yaygın sebeplerdir.

Frontend Optimizasyonu: Görseller

Bir e-ticaret sitesinin sayfa ağırlığının ortalama %50-65'i görsellerden gelir. Yanlış formatta tek bir hero image, tüm performans bütçenizi yer. WebP JPEG'e göre %25-35 daha küçüktür ve tüm modern tarayıcılarda desteklenir. AVIF WebP'den de %20-50 daha iyi sıkıştırma sunar; Safari 16+ dahil tarayıcı desteği artık tatmin edici. caniuse.com/avif üzerinden güncel durumu kontrol edin.

<!-- AVIF + WebP + JPEG fallback ile responsive picture -->
<picture>
  <source
    type="image/avif"
    srcset="/img/hero-480.avif 480w,
            /img/hero-960.avif 960w,
            /img/hero-1920.avif 1920w"
    sizes="(max-width: 600px) 480px,
           (max-width: 1200px) 960px,
           1920px">
  <source
    type="image/webp"
    srcset="/img/hero-480.webp 480w,
            /img/hero-960.webp 960w,
            /img/hero-1920.webp 1920w"
    sizes="(max-width: 600px) 480px,
           (max-width: 1200px) 960px,
           1920px">
  <img
    src="/img/hero-960.jpg"
    alt="Açıklayıcı alt metin"
    width="1920" height="1080"
    loading="lazy"
    decoding="async"
    fetchpriority="high">
</picture>

Dikkat edilmesi gereken üç nokta: width ve height attribute'ları her zaman verilmeli (CLS'i önler), loading="lazy" fold altındaki görseller için açılmalı, hero image gibi LCP elementine ise fetchpriority="high" ve loading="eager" uygulanmalı.

Komut Satırından WebP/AVIF Üretimi

# WebP — Google libwebp
sudo apt install webp
cwebp -q 80 hero.jpg -o hero.webp

# AVIF — libavif (avifenc)
sudo apt install libavif-bin
avifenc --min 30 --max 40 -j 8 hero.jpg hero.avif

# Toplu dönüştürme — find + xargs
find ./images -name '*.jpg' -print0 | \
  xargs -0 -I{} -P 8 bash -c \
  'cwebp -q 80 "{}" -o "${1%.jpg}.webp"' _ {}

# ImageMagick ile responsive boy üretme
for w in 480 960 1920; do
  magick hero.jpg -resize ${w}x -quality 85 hero-${w}.jpg
done

Frontend Optimizasyonu: Fontlar

Web fontları LCP'yi sessizce öldürür. Üç kural: WOFF2 kullanın (WOFF'a göre %30 daha küçük), subset edin (Türkçe + Latin için 50-150KB yerine 20-40KB elde edersiniz), font-display: swap ekleyin (FOIT yerine FOUT). Variable font'lar tek dosyada birden fazla weight'i barındırır — birden fazla weight kullanan sitelerde net kazanç.

<!-- Critical font preload — head içinde, ilk -->
<link rel="preload"
      href="/fonts/inter-var-latin.woff2"
      as="font"
      type="font/woff2"
      crossorigin>

<!-- font-display: swap ile @font-face -->
<style>
  @font-face {
    font-family: 'Inter';
    src: url('/fonts/inter-var-latin.woff2') format('woff2-variations');
    font-weight: 100 900;
    font-style: normal;
    font-display: swap;
    unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC,
                   U+02C6, U+02DA, U+02DC, U+2000-206F, U+2074;
  }
</style>

Google Fonts'u CDN'den çağırmak yerine self-host edin: ek DNS lookup, ek TLS handshake ve üçüncü taraf cache'inin tutarsızlığından kurtulursunuz. google-webfonts-helper aracı ile WOFF2 paketini indirip sunucunuzdan servis edin.

Frontend Optimizasyonu: JavaScript

Modern web sayfasının %35-50'si JavaScript ağırlığından oluşuyor (HTTP Archive verisi). JavaScript yalnızca network'te değil, parse, compile ve execute aşamalarında da maliyet yaratır — özellikle düşük güçlü Android cihazlarda main thread'i 5-15 saniye bloke edebilir.

• Tree-shake: Webpack/Rollup/esbuild ile kullanılmayan exportları otomatik silin. Lodash gibi ağır kütüphaneler için lodash-es kullanın.
• Code split: import() ile dinamik chunk'lar oluşturun. Route bazlı splitting (Next.js, Nuxt, SvelteKit) en kolay kazançtır.
• Defer / async: Üçüncü taraf script'leri her zaman async veya defer ile yükleyin. document.write kullanan eski script'leri tag manager'dan kaldırın.
• Polyfill segregation: module/nomodule pattern ile modern tarayıcılara hiç polyfill göndermeyin.
• Coverage tool: Chrome DevTools > Coverage paneli ile sayfada gerçekten çalışan JS/CSS oranını ölçün — %40+ kullanılmayan kod normal sayılmaz.

// Route bazlı dynamic import — React örneği
const Dashboard = lazy(() => import(
  /* webpackChunkName: "dashboard" */
  './pages/Dashboard'
));

const Reports = lazy(() => import(
  /* webpackChunkName: "reports" */
  /* webpackPrefetch: true */
  './pages/Reports'
));

// İlk etkileşimde yüklenecek ağır widget
button.addEventListener('click', async () => {
  const { renderEditor } = await import('./editor');
  renderEditor(document.getElementById('host'));
}, { once: true });

Frontend Optimizasyonu: CSS

CSS render-blocking'dir — tarayıcı CSSOM'u inşa etmeden ekrana hiçbir şey çizmez. Üç optimizasyon: minify (terser/cssnano), critical CSS inline (above-the-fold için 8-14KB civarı bir CSS'i <style> içine gömün), purge unused (Tailwind CSS bunu otomatik yapar; başka framework'lerde PurgeCSS veya UnCSS).

<!-- Critical CSS inline + asenkron geri kalan CSS -->
<head>
  <style>
    /* above-the-fold için 8-14KB minified CSS */
    body{margin:0;font:16px/1.5 system-ui}
    .hero{min-height:60vh;display:grid;place-items:center}
    /* ... */
  </style>
  <link rel="preload" href="/css/main.css" as="style"
        onload="this.onload=null;this.rel='stylesheet'">
  <noscript><link rel="stylesheet" href="/css/main.css"></noscript>
</head>

@import zincirlerinden kaçının — her import yeni bir round-trip demektir. CSS bundler kullanın. csswizardry.com Harry Roberts'in performans odaklı CSS yazılarını kapsamlı şekilde inceleyebilirsiniz.

HTTP/2, HTTP/3 ve Sıkıştırma

HTTP/1.1'de browser host başına ~6 paralel bağlantı açar; her ek varlık yeni bir TCP+TLS round-trip demektir. HTTP/2 tek TCP bağlantısında multiplexing yapar, header compression (HPACK) sunar, prioritization destekler. HTTP/3 (QUIC üzerinde) UDP tabanlıdır, head-of-line blocking sorununu çözer ve mobil/yüksek paket kayıplı bağlantılarda %10-30 hızlanma sağlar.

Brotli sıkıştırma gzip'e göre tipik HTML/CSS/JS için %15-25 daha iyi sıkıştırma sunar. Modern tarayıcıların tamamı br kabul eder. Nginx için ngx_brotli modülü, Apache için mod_brotli kullanın.

# /etc/nginx/nginx.conf — gzip + brotli
gzip on;
gzip_vary on;
gzip_comp_level 5;
gzip_min_length 1024;
gzip_types text/plain text/css text/xml application/javascript
           application/json application/xml application/xml+rss
           image/svg+xml application/wasm font/woff2;

# brotli (ngx_brotli derlenmişse)
brotli on;
brotli_static on;
brotli_comp_level 5;
brotli_types text/plain text/css text/xml application/javascript
             application/json application/xml application/xml+rss
             image/svg+xml application/wasm font/woff2;

# HTTP/2 + HTTP/3
listen 443 ssl http2;
listen 443 quic reuseport;
add_header Alt-Svc 'h3=":443"; ma=86400';

Backend: Nginx Tuning

Nginx'in default değerleri tutucu — orta-yüksek trafikli sunucular için açıkça değiştirmeniz gereken birkaç direktif var. Detaylı bir Nginx rehberini Nginx Yapılandırma Rehberi yazımızda bulabilirsiniz.

# /etc/nginx/nginx.conf — high-traffic ayarlar
worker_processes auto;            # CPU çekirdek sayısı
worker_rlimit_nofile 65535;       # ulimit -n karşılığı

events {
    worker_connections 8192;
    multi_accept on;
    use epoll;
}

http {
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;

    keepalive_timeout 65s;
    keepalive_requests 1000;

    open_file_cache max=10000 inactive=30s;
    open_file_cache_valid 60s;
    open_file_cache_min_uses 2;
    open_file_cache_errors on;

    client_body_buffer_size 16k;
    client_max_body_size 64m;
    client_header_buffer_size 1k;
    large_client_header_buffers 4 8k;

    server_tokens off;
}

FastCGI cache (PHP siteler için) sayfa render maliyetini sıfıra yaklaştırır. WordPress için tipik bir konfigürasyon yük dakikalık 100K isteğin üstünde bile aynı sunucuda çalışmaya imkan tanır. Detaylar için nginx.org/en/docs.

Backend: Apache mpm_event ve mod_deflate

Apache 2.4 ile gelen mpm_event modülü, prefork ve worker'a göre çok daha az bellek tüketir ve idle keep-alive bağlantıları thread'lerden ayrı tutar. Hâlâ mpm_prefork kullanıyorsanız değişin — özellikle yüksek eşzamanlı bağlantılı sitelerde RAM kullanımı yarıya düşer.

# /etc/apache2/mods-available/mpm_event.conf
<IfModule mpm_event_module>
    StartServers             3
    MinSpareThreads         75
    MaxSpareThreads        250
    ThreadsPerChild         25
    ServerLimit             16
    MaxRequestWorkers      400
    MaxConnectionsPerChild   0
</IfModule>

# Caching headers (mod_expires + mod_headers)
<IfModule mod_expires.c>
  ExpiresActive On
  ExpiresByType image/avif "access plus 1 year"
  ExpiresByType image/webp "access plus 1 year"
  ExpiresByType image/jpeg "access plus 1 year"
  ExpiresByType text/css   "access plus 1 month"
  ExpiresByType application/javascript "access plus 1 month"
  ExpiresByType font/woff2 "access plus 1 year"
</IfModule>

# Brotli/Deflate
<IfModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/html text/css text/plain \
    application/javascript application/json image/svg+xml
</IfModule>

Backend: PHP Opcache, Preload ve JIT

PHP'yi gerçekten hızlandıran tek şey doğru yapılandırılmış opcache'tir. Default ayarlarla bile %3-4x hızlanma görürsünüz; preload + JIT ile bu rakam %5-8x'e çıkar. Resmi referans: php.net/manual/en/book.opcache.php.

; /etc/php/8.3/fpm/conf.d/10-opcache.ini
[opcache]
opcache.enable=1
opcache.enable_cli=0
opcache.memory_consumption=256
opcache.interned_strings_buffer=32
opcache.max_accelerated_files=20000
opcache.validate_timestamps=0    ; production: 0, dev: 1
opcache.revalidate_freq=0
opcache.fast_shutdown=1
opcache.save_comments=1          ; PHPDoc'a bağımlı framework'ler için

; Preload (PHP 7.4+)
opcache.preload=/var/www/preload.php
opcache.preload_user=www-data

; JIT (PHP 8.0+)
opcache.jit_buffer_size=128M
opcache.jit=tracing

validate_timestamps=0 production'da kritik — her istekte dosya zaman damgası kontrolünü kapatır, deploy sonrası opcache_reset veya FPM reload gerektirir. PHP-FPM pm stratejisi: yüksek RAM'li sunucularda pm = static + sabit pm.max_children kullanın; sınırlı RAM'de pm = ondemand tercih edin.

Backend: Node.js, Python, Go ve Rust

Node.js tek thread'lidir — çok çekirdekli sunucularda mutlaka cluster mode veya PM2'nin ecosystem dosyası ile her CPU çekirdeği başına bir worker çalıştırın. --max-old-space-size ile heap limitini RAM'in %75'i kadar yapın.

// ecosystem.config.js — PM2 cluster mode
module.exports = {
  apps: [{
    name: 'app',
    script: 'server.js',
    instances: 'max',          // CPU çekirdek sayısı kadar
    exec_mode: 'cluster',
    max_memory_restart: '1G',
    node_args: '--max-old-space-size=2048',
    env_production: {
      NODE_ENV: 'production',
      UV_THREADPOOL_SIZE: 16   // I/O ağırlıklı app'ler için
    }
  }]
};

Python uygulamalarında WSGI için Gunicorn (worker sayısı = 2*CPU+1), ASGI için Uvicorn workers ile FastAPI/Django Channels kullanın. Sync uygulamalar için gevent veya meinheld worker class'ı I/O bekleme süresini büyük oranda kazandırır.

Go ve Rust doğal olarak hızlı — odak noktanız connection pool boyutu, goroutine/task limitleri ve sysctl ayarları (net.core.somaxconn, net.ipv4.tcp_max_syn_backlog). Tek sunucuda 100K+ concurrent bağlantı normaldir; darboğaz neredeyse her zaman downstream sistemlerdir.

Caching Katmanları: Doğru Sırayla

Caching, optimizasyondaki en yüksek ROI'yi sunan tek tekniktir. Doğru tasarlanmış bir cache hiyerarşisi ile sunucu yükünüz 10-100x azalır. Önemli olan katmanların hangi sırayla devreye gireceğidir — istek edge → reverse proxy → app cache → DB cache → opcode cache sırasıyla işlenmeli, her katmanda mümkün olduğu kadar erken cevap üretilmeli.

• 1. CDN edge cache: Cloudflare/Bunny/Fastly. Static assetler ve cacheable HTML için. Origin'e dokunmadan dünya genelinde cevap.
• 2. Reverse proxy cache: Nginx FastCGI/proxy_cache, Varnish, LSCache. Origin sunucuda full-page cache.
• 3. Application cache: Redis veya Memcached. Object cache, session, rate limit sayacı, cron job lock.
• 4. Database query cache: PostgreSQL prepared statement cache, MySQL query cache (8.0'da kaldırıldı; ProxySQL veya app-level cache kullanın).
• 5. Opcode cache: PHP opcache, JVM tiered compilation, V8 code cache.

Redis konusunda detaylı bir yazımız yayınlanacak: Redis Nedir, Nasıl Kullanılır. LiteSpeed kullanıcıları için LSCache Rehberi ayrı bir kaynak olacak.

Veritabanı Optimizasyonu

Yavaş bir SQL sorgusu, en hızlı CDN'inizi bile çürütür. Database darboğazları çoğu yüksek trafikli sitede #1 problemdir. EXPLAIN her optimizasyoncunun ilk silahıdır — query plan'ını görmeden indeks atmayın.

-- PostgreSQL: yavaş sorguyu analiz et
EXPLAIN (ANALYZE, BUFFERS, FORMAT JSON)
SELECT u.id, u.name, COUNT(o.id) AS order_count
FROM users u
LEFT JOIN orders o ON o.user_id = u.id
WHERE u.created_at >= NOW() - INTERVAL '30 days'
GROUP BY u.id
ORDER BY order_count DESC
LIMIT 50;

-- Composite + partial index örneği
CREATE INDEX CONCURRENTLY idx_orders_user_active
  ON orders (user_id, created_at DESC)
  WHERE status = 'paid';

-- Covering index (PostgreSQL 11+)
CREATE INDEX idx_users_name_email
  ON users (created_at DESC) INCLUDE (id, name, email);

-- Sequential scan'ı bul
SELECT schemaname, relname, seq_scan, idx_scan,
       seq_tup_read, idx_tup_fetch
FROM pg_stat_user_tables
WHERE seq_scan > idx_scan
ORDER BY seq_tup_read DESC
LIMIT 20;

PostgreSQL'e özel performans tuning rehberimiz PostgreSQL Performans Optimizasyonu yazısında detaylı şekilde anlatılıyor — shared_buffers, work_mem, effective_cache_size, vacuum tuning ve daha fazlası.

• Connection pooling: PostgreSQL için PgBouncer (transaction mode), MySQL için ProxySQL. Her PHP request'inde yeni bağlantı açmak en yaygın 50ms+ kayıp noktasıdır.
• Read replicas: Read-heavy app'lerde okuma yükünü asenkron replica'lara dağıtın. Replication lag'ini izleyin (genelde <1s makul).
• Materialized views: Karmaşık reporting sorguları için. REFRESH MATERIALIZED VIEW CONCURRENTLY ile downtime'sız yenileme.
• Denormalize when needed: Pure 3NF her zaman doğru değil. Sıkça okunan join'ler için kontrollü tekrarlama performansı 10x artırabilir.
• Auto vacuum: PostgreSQL bloat'ı production'da en sessiz performans katilidir. autovacuum_vacuum_scale_factor'ı tablo bazlı 0.05'e düşürün.
• Slow query log: log_min_duration_statement = 500 (ms). Haftada bir log analiz edin, en yavaş 10 sorguya odaklanın.

CDN Seçimi

CDN sadece statik dosyaları hızlandırmaz; doğru yapılandırılırsa origin yükünü %80+ azaltır, DDoS'a karşı tampon olur, Anycast routing ile latency'i 10x düşürür. Türkiye'de en yaygın seçenekler:

• Cloudflare: Free plan bile etkileyici (Anycast + Argo Light). Pro/Business'ta full-page cache, image optimization, R2 storage. WAF ve bot management dahil. Çoğu KEYDAL müşterisi için varsayılan seçim.
• Bunny CDN: 5-10x daha ucuz, performansı Cloudflare'le yarışır. Per-GB pricing media-heavy siteler için cazip. bunny.net.
• Fastly: VCL ile programlanabilir edge — kompleks rule'lar gerektiren büyük yayıncılar için. Pahalı ama en esnek.
• AWS CloudFront: AWS ekosistemine bağlıysanız mantıklı. Lambda@Edge ile JS-based edge logic.
• Akamai / Imperva / Sucuri: Enterprise — fiyat etiketi yüksek, çoğu KOBİ için aşırı.

cloudflare.com/learning/performance CDN ve edge networking hakkında en iyi ücretsiz eğitim kaynaklarından biri. Origin Shield, signed URL ve cache key tuning detayları için Cloudflare/Fastly resmi docs'larını inceleyin.

Mobil Optimizasyon

Trafiğin %60-70'i artık mobil — masaüstü performansını iyi tutup mobilde kötü hizalamak ölümcül bir seo hatasıdır. Google 2023'ten beri mobile-first indexing uyguluyor: site sıralamanız mobil sürümünüzle belirleniyor.

• Tap target ≥ 48×48 CSS px: Material guideline. Buton aralarında en az 8px boşluk.
• Conditional bundle: navigator.deviceMemory ve navigator.connection.saveData ile düşük güçlü cihazlara hafif bundle gönderin.
• Reduce motion: @media (prefers-reduced-motion: reduce) medya sorgusunu CSS animasyonlarınızda mutlaka kullanın.
• Service worker + offline: Workbox ile asset cache + offline fallback. Repeat visit'lerde LCP 200ms'e iner.
• Viewport meta: <meta name="viewport" content="width=device-width, initial-scale=1"> şart — eksiklik mobil sıralamayı düşürür.

Güvenlik-Bağlantılı Performans: TLS, HSTS, OCSP

Güvenlik ve performans aynı madalyonun iki yüzü. TLS 1.3 handshake'i 1-RTT'e (eski 2-RTT yerine) indirir; 0-RTT resumption ile daha da hızlandırılabilir. OCSP stapling sertifika revocation kontrolünün ek round-trip maliyetini ortadan kaldırır.

# Modern TLS yapılandırması
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:
             ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:
             ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';

ssl_session_cache shared:SSL:50m;
ssl_session_timeout 1d;
ssl_session_tickets off;

# OCSP stapling
ssl_stapling on;
ssl_stapling_verify on;
resolver 1.1.1.1 8.8.8.8 valid=300s;
resolver_timeout 5s;

# HSTS — domain'i tüm browser'larda HTTPS-only yapar
add_header Strict-Transport-Security
  "max-age=63072000; includeSubDomains; preload" always;

Konfigürasyonunuzu ssllabs.com/ssltest ile test edin — A+ skor hedefleyin. KEYDAL'in kendi SSL Sertifika Kontrol aracı da hızlı kontrol için kullanılabilir.

Üçüncü Taraf Script'leri: Sessiz Performans Katili

Google Analytics, Tag Manager, Hotjar, Intercom, Facebook Pixel, AdSense — her biri ayrı ayrı zararsız görünür ama beraber 1.5MB JS, 50+ network request ve main thread'de 3-5 saniyelik blok demektir. web.dev/articles/third-party-javascript bu konuda detaylı rehberdir.

• Audit edin: WebPageTest'in 'Block 3rd party' option'u ile her birini izole ölçün — gerçek performans maliyetini görün.
• Async / defer + facade pattern: YouTube embed yerine static thumbnail + click-to-load (lite-youtube-embed). Intercom yerine basit kontak formu, JS yalnızca ihtiyaç anında.
• GTM priority: Tag Manager'da non-essential tag'leri DOM Ready/Window Loaded'a kaydırın.
• Self-host: Google Fonts, GA4, Plausible self-host edilebilir. Üçüncü taraf DNS lookup'ı tamamen elimine olur.
• Remove what you don't measure: Aktif olmayan analytics tag'i her ay denetleyip silin.

Lighthouse CI ve Sürekli Performans

Bir kez optimize edip bırakmak yetmez — yeni feature'lar, sürüklenmeler ve içerik değişiklikleri performansı zamanla aşağı çeker. Lighthouse CI her PR'da bütçeleri kontrol eder, regresyona karşı koruma sağlar.

# .github/workflows/lighthouse.yml
name: Lighthouse CI
on:
  pull_request:
    branches: [main]

jobs:
  lhci:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 20 }
      - run: npm ci
      - run: npm run build
      - name: Lighthouse CI
        run: |
          npm install -g @lhci/cli@0.13.x
          lhci autorun
        env:
          LHCI_GITHUB_APP_TOKEN: ${{ secrets.LHCI_GITHUB_APP_TOKEN }}

# lighthouserc.json
# {
#   "ci": {
#     "collect": { "url": ["https://staging.example.com/"], "numberOfRuns": 3 },
#     "assert": {
#       "assertions": {
#         "categories:performance": ["error", { "minScore": 0.9 }],
#         "first-contentful-paint": ["warn", { "maxNumericValue": 1800 }],
#         "largest-contentful-paint": ["error", { "maxNumericValue": 2500 }],
#         "cumulative-layout-shift": ["error", { "maxNumericValue": 0.1 }]
#       }
#     }
#   }
# }

Monitoring: APM, Uptime ve Log Aggregation

Optimizasyon, sürekli görünürlük gerektirir. Üç katman izleme: uptime (UptimeRobot, Pingdom, StatusCake — 1 dakika kontrol, multi-region check), APM (New Relic, Datadog APM, Sentry Performance — transaction trace, slow query, error correlation), log aggregation (Grafana Loki, ELK stack, Better Stack — structured log + metric).

• Uptime check SSL expiry, status code ve content match kontrolü ile yapılmalı.
• APM p50/p95/p99 latency'i ayrı ayrı izleyin — ortalama yanıltır.
• Error budget: Aylık %0.1 hata bütçesi — aşılırsa yeni feature'lar durdurulur, performans/stabilite öncelikli.
• Synthetic monitoring: Kritik kullanıcı yolları (login, checkout) headless tarayıcıyla 5 dakikada bir kontrol edilmeli.

80/20 Hızlı Kazançlar (ROI Sırasıyla)

Tüm bu rehberi okuduktan sonra bile bir öncelik listesi gerekiyor. KEYDAL'in audit'lerde sıkça karşılaştığı, en az çabayla en çok kazanç sağlayan 12 madde — uygulama sırasıyla:

• 1. Görsel format dönüşümü (JPEG → WebP/AVIF) — sayfa ağırlığında %30-50 azalma.
• 2. Brotli + gzip aktivasyonu — text-based assetlerde %20-30 ek küçülme.
• 3. HTTP/2 veya HTTP/3 etkinleştirme — multiplexing kazancı.
• 4. Cache-Control headers + immutable — repeat visit'lerde 0 byte indirme.
• 5. CDN'e geçiş — global latency düşüşü, origin yükü azalması.
• 6. FastCGI/proxy cache (PHP siteler için) — origin yükü 10x düşer.
• 7. PHP opcache + preload — CPU kullanımı yarıya iner.
• 8. Database missing index'leri — yavaş sorgular 100x hızlanabilir.
• 9. Render-blocking JS/CSS kaldırma + critical CSS inline — LCP 1-2s azalabilir.
• 10. Font preload + WOFF2 + subset — FOIT/FOUT bitsi.
• 11. Üçüncü taraf script audit'i — gereksiz pixel/widget'ları kaldır.
• 12. RUM kurulumu — gerçek kullanıcı verisi, regresyon erken yakalanır.

Bu 12 madde tipik bir kurumsal sitede toplam Lighthouse performans skorunu 35-50'den 90+'a taşır. web.dev, MDN Web Performance ve PageSpeed Insights docs ileri okuma için temel kaynaklarınız olsun.

Streaming, Server-Sent Events ve İleri Konular

Çok büyük sayfalar için HTML streaming ile TTFB'yi etkilemeden Time-to-First-Byte ile First Paint arasını kısaltabilirsiniz. React Server Components, Next.js streaming SSR, Remix, SvelteKit — hepsi aynı paradigmayı kullanır. Jake Archibald'ın streams ftw yazısı temel referansdır.

Server-Sent Events (SSE) ve WebSocket, polling'e göre çok daha düşük overhead'le real-time veri akışı sağlar — bildirimler, dashboard güncellemeleri, live chat için ideal. WebTransport (HTTP/3 üzerinde) gelecekteki standart.

Arama Motoru Optimizasyonu ve İçerik Stratejisi

Arama motoru optimizasyonu (SEO) üç ayaklı bir disiplindir: teknik SEO (sayfa hızı / Core Web Vitals, indekslenebilirlik, mobil uyum, schema markup), içerik SEO (anahtar kelime araştırması, kullanıcı niyetine uygun içerik, semantic enrichment, internal linking) ve off-page SEO (kaliteli backlink kazanımı, marka otoritesi, sosyal sinyaller). Google'ın E-E-A-T (Experience, Expertise, Authoritativeness, Trustworthiness) kriterleri özellikle YMYL (Your Money Your Life) sayfalarında belirleyicidir. Organik trafik kazanmak için SERP analizi, rakip içerik incelemesi, anahtar kelime cluster oluşturma ve düzenli içerik güncellemesi şarttır. Google Search Console ile indeksleme durumu, Lighthouse ile performans, Ahrefs/SEMrush ile rakip analizi yapılabilir.

Kaynaklar

• web.dev — Google'ın resmi web performans bilgi tabanı
• web.dev/vitals — Core Web Vitals tanımları
• PageSpeed Insights — saha + lab veri
• Lighthouse docs
• WebPageTest
• MDN Web Performance
• HTTP Archive — sektör benchmark
• nginx.org/en/docs
• PHP Opcache manual
• caniuse.com — tarayıcı destek
• PageSpeed Insights docs
• web.dev — Third-party JS
• csswizardry.com
• Cloudflare Learning Center
• Jake Archibald — streams ftw
• GoogleChrome/lighthouse
• SSL Labs

İlgili Yazılar

• Sayfa Hızı ve Core Web Vitals 2026 — LCP/INP/CLS metriklerine derin dalış
• Nginx Yapılandırma Rehberi — reverse proxy, cache, rate limit
• PostgreSQL Performans Optimizasyonu — index, vacuum, query tuning
• KEYDAL SEO Hizmetleri
• KEYDAL Yazılım Geliştirme