Drupal Web Sitesinde Teknik Performans Optimizasyonu

Drupal; entity/field mimarisi, render-cache katmanları, Views, taksonomi, çok dilli altyapı ve zengin modül ekosistemiyle son derece esnektir. Ancak esneklik; yanlış konfigürasyonlar, gereksiz modüller, hatalı cache etiketleri, karmaşık sorgular, kuyruk/c ron darboğazları, ağır JS paketleri ve medya boru hattı hatalarıyla birleştiğinde algılanan hızı (LCP/INP/CLS) ve sunucu yanıtını (TTFB/P95) olumsuz etkileyebilir. Bu rehber, Drupal’da teknik performans optimizasyonunu “sistem” olarak kurmanız için uçtan uca bir yol haritası sunar: ölçüm, mimari kararlar, cache anatomisi, veritabanı ve arama, ön uç (CWV), medya/CDN, kuyruk/cron, dağıtım ve canary, izleme/alarmlar, otomasyon ve 90 günlük uygulama planı. Her bölümde kontrol listeleri, somut komutlar, vaka senaryoları ve “hemen bugün” yapılabilir aksiyonlar bulacaksınız

1) Ölçmeden Optimizasyon Olmaz: Metrik Taksonomisi

• Kullanıcı odaklı (RUM): LCP, INP, CLS.

• Sunucu odaklı: TTFB, P95/P99 yanıt süresi, CPU/IO, PHP-FPM kuyruk uzunluğu.

• İş metrikleri: Form gönderim süresi, arama sonuç zamanı, sepet/checkout adımları.
  Kural: RUM (gerçek kullanıcı) + sentetik (Lighthouse/WebPageTest) birlikte çalışır. P95/P99 değerleri karar kapılarında kullanılır.

---

2) Mimari Karar: SSR, Edge ve “Kişiselleştirme Sınırı”

• Tam sayfa cache (anonim): CDN/edge ile en büyük kazanç.

• Dinamik sayfa cache (oturumlu): Fragman bazlı hız; “kişiselleştirilen alanları” minimumda tutun.

• Kişiselleştirme sınırı: Kullanıcıya özel parça gerçekten gerekli mi? Değilse varyantları azaltın.
  Kontrol listesi: Edge varyant anahtarları (cookie, dil, cihaz) gerçekten mecburi mi?

---

3) Drupal Cache Anatomisi: Page, Dynamic, Render, Entity, Route, Twig

• Render cache’in kalbi #cache dizisidir: keys, contexts, tags, max-age.

• Yanlış context → gereksiz miss; yanlış tags → ya hiç invalid olmaz ya da global purge.

• Uygulama: Problemli blok/komponent için cache keys/contexts/tags matrisini yazın; “hangi olayda” invalid olduğunu belgeleyin.
  Hızlı kazanç: “Global purge” yapan kodu kaldırın, etiket bazlı invalidasyon kullanın.

---

4) CDN/Edge Stratejisi: “Kenar Isısı”nı Arttırın

• Header’lar: Cache-Control, stale-while-revalidate, ETag/Last-Modified.

• Isındırma (warm-up): Yayın sonrası en çok ziyaret edilen rotaları otomatik ısıtın.

• Hedefli purge: İçerik güncellendiğinde yalnız ilgili cache-tag eşlemeleri temizlensin.
  KPI: Edge hit ratio ≥ %85 (anonim trafik için).

---

5) Veritabanı: Yavaş Sorguları Diyete Sokun

• Slow query log: En ağır 10 sorgu ve plan analizleri.

• İndeksler: Views/EntityQuery için bileşik (ör. status, created), LIKE yerine fulltext/elasticsearch kullanımı.

• N+1 tuzakları: Döngü içinde sorgu; View önbellekleme ve JOIN’leri gözden geçirin.
  Hızlı kazanç: “Liste” sayfalarında sayfa başına kayıt ve alan sayısını azaltın; no_found_rows benzeri optimizasyon mantığını düşünün.

---

6) Arama Katmanı: Search API + Solr/ES

• İndeks gecikmesi: Yayın → indeks → görünürlük zincirini izleyin; kuyruk birikiyorsa işçi sayısını arttırın.

• Facet maliyeti: Çok derin facet kombinasyonlarını sınırlayın; min_doc_count eşikleri belirleyin.

• Degrade planı: Arama down ise basit veritabanı aramasına düşme ve nazik kullanıcı mesajı.

---

7) Cron & Queue: Sessiz Performans Katili

• Sistem cron kullanın; trafik tetikli cron’dan kaçının.

• Kuyruklar: Parti boyutu/timeout; zehirli iş (aynı item sürekli hata) algısı.

• Gözlem: Bekleyen iş grafiği ve ortalama tamamlama süresi; gece penceresinde biriktirmeyin

8) PHP-FPM, Opcache ve Web Sunucusu Ayarları

• PHP-FPM: pm.max_children doygunluğu → P95 TTFB artar. İzleyin, ayarlayın; aşırı büyütmeyin.

• Opcache: Dağıtım sonrası reset; bellek boyutu/max_accelerated_files uygun.

• Nginx/Apache: Gzip/brotli, HTTP/2/3, sendfile ve keepalive ayarları dengeli.
  İpucu: “CPU yüksek → işlemci ekleyelim” refleksi yerine bottleneck kanıtı toplayın.

---

9) Twig & Render Pipeline: Şablonları Hafifletin

• Twig debug ile gereksiz katmanları görün; büyük döngüler, ağır filtreler azaltılsın.

• Önbellekli alt parça (fragment) üretin; şablonda iş kuralı bulundurmayın.

• Escaping ve hazırlık: #pre_render yerine mümkünse veri hazırlığını controller/service katmanında yapın.

---

10) Frontend ve Core Web Vitals: LCP/INP/CLS

• LCP: Hero görsel preload + doğru boyut; kritik CSS inline; büyük JS paketleri koşullu yükleme.

• INP: Event handler’lar hafif, uzun görevleri bölün; 3P script’leri azaltın.

• CLS: Görseller/iframe’ler aspect-ratio ile sabit; web font preload + font-display.
  Kural: Lighthouse “geçti” yetmez; alan verisi (RUM) ile doğrulayın.

---

11) Asset Yönetimi: Paket Diyeti

• CSS/JS ayrıştırma: Route’lara göre koşullu enqueue; global dosya şişirmeyin.

• Kod bölme: Dinamik import; kullanılmayan modülleri atın.

• Bütçeler: “Toplam JS (mobil) ≤ 150KB gzip, CSS ≤ 100KB gzip” gibi hedefler belirleyin.
  Vaka: Haber sitesinde tek “slider” için 300KB JS yükleniyordu; route-conditional ile yalnız galeri sayfalarına taşındı → LCP -350ms.

---

12) Medya Boru Hattı: Görsel Ekonomisi

• Format: WebP/AVIF; srcset/sizes; loading="lazy" ve decoding="async".

• CDN görüntü işleme: Genişliğe göre otomatik kırpma/ölçekleme; orijinal tekilleştirme.

• KB bütçesi: Galeri sayfası toplam transfer < 1.5MB (mobil).
  Kural: SVG güvenliği (sanitizasyon) + boyut optimizasyonu.

---

13) Çok Dilli ve Çoklu Site Performansı

• Hreflang/URL varyantı cache anahtarlarını patlatmasın; varyant sayılarını sınırlayın.

• Paylaşımlı kod, site bazlı config: Farklı sitelerin cache politikaları ayrı, ama kod tek.

• Dil anahtarları: Edge’de varyant sayısını asgariye indirin (ör. cihaz + dil = yeterli).

---

14) Konfig ve Ortam Eşliği: Staging ≈ Prod

• PHP/NGINX/PHP-FPM sürümleri aynı olsun; aksi halde “staging iyi, prod kötü” şaşkınlığı çıkar.

• Config Split: Ortam farklarını kontrollü yönetin; performansla ilgili bayraklar belgelensin.

• Veri boyutu: Staging’de prod verisinin temsil edici alt kümesi bulunsun (PII maskeli).

---

15) İzleme, Alarm ve Panolar

• Panolar: TTFB, P95 yanıt, 5xx, JS hataları, edge hit, LCP/INP/CLS, kuyruk uzunluğu.

• Alarm eşikleri: “P95 TTFB > 800ms 5 dk boyunca” → uyarı; “5xx > %1 3 dk boyunca” → P1.

• Korelasyon: Alarmda “son dağıtım diff” linki; kök neden süresini kısaltır.

---

16) Otomasyon: CI/CD Kapıları

• Performans kapısı: Lighthouse + bütçeler; kırmızıysa deploy yok.

• Görsel regresyon: Tema değişimlerinde piksel farkı kapısı.

• Skriptler: Hedefli CDN purge, warm-up, sitemap ping, schema/canonical/hreflang hızlı testleri.

---

17) Vaka A: İçerik Ağır Portal – LCP Dalgalanması

Belirti: Mobil LCP P95 2.9s → 3.6s.
Kök neden: Yeni eklenti global JS enjekte ediyor; hero görsel boyutu büyümüş.
Çözüm: Route-conditional enqueue + hero preload + görsel yeniden işleme.
Sonuç: LCP P95 2.3s; edge hit ratio %88.

---

18) Vaka B: Arama Sonuçları Yavaş

Belirti: TTFB P95 > 1.2s sadece arama sayfalarında.
Kök neden: Facet kombinasyonları çok; Solr’da pahalı aggregations.
Çözüm: Facet sınırları, min_doc_count, sık kullanılan facet’ler için önbellek; indeks güncelleme penceresi.
Sonuç: Arama TTFB P95 480ms.

---

19) Vaka C: Cron/Kuyruk Birikmesi

Belirti: Gece 02:00’den sonra P95 artıyor.
Kök neden: Medya küçük resim üretimi tek işçi ve büyük parti boyutu ile çalışıyor.
Çözüm: Paralel işçi + uygun parti/timeout; problemli item’lar için retry sınırı.
Sonuç: Kuyruk sabit; P95 gece dalgası yok.

---

20) Güvenlik ≠ Yavaşlık: WAF ve CSP’nin Doğru Kullanımı

• WAF: Hız limiti ve bot yönetimi ile kötü trafiği erken keser → TTFB’yi bile iyileştirebilir.

• CSP: 3P script enflasyonunu azaltarak INP’yi iyileştirir.
  Not: Yanlış kural → form kırılması; QA listesine WAF/CSP testlerini ekleyin.

---

21) Drupal Views ve Liste Sayfaları İçin “Fit” Planı

• Alan diyeti: Gereksiz rendered entity yerine özet alanlar.

• Ön sayfalama (prefetch): Sonraki sayfanın hafif verisini hazırlama.

• Önceden ısındırma: En yoğun 20 URL’yi dağıtımdan sonra ısıtın.

---

22) Headless/Decoupled Drupal: API Performansı

• REST/JSON:API: Sayfalama, alan seçimi (sparse fieldsets), include kullanımı bilinçli.

• Rate limit: İstemci hatalarını engelleyin; TTL ile CDN cache kullanılabilir.

• Şema baskısı: Aşırı esnek uçlar yerine kararlı sözleşme (contract) ve versiyonlama.

---

23) Performans Testleri: Yük–Gerilim–Kalıcılık

• Yük (RPS/ eşzamanlı): Cache ısınmış/ısınmamış ayrı koşun.

• Gerilim: Saturasyon noktasını bulun; degrade stratejisi tetikleniyor mu?

• Kalıcılık (4–8 saat): Bellek sızıntısı, log büyümesi, cron/kuyruk kilitleri.
  Rapor: P95/P99, hata oranı, kaynak grafikleri, öneriler.

---

24) Maliyet–Performans Optimizasyonu

• Edge vs. origin: Edge’i güçlendirmek origin maliyetini düşürür.

• Birim başına maliyet: RPS başına CPU/IO; CDN egress/işleme maliyeti.

• Karar matrisi: “LCP -300ms için aylık +X$” → görünürlük/dönüşüm etkisiyle birlikte sunun.

---

25) 90 Günlük Uygulama Planı (Örnek)

Ay 1: Pano ve alarmlar (TTFB, P95, 5xx, LCP/INP/CLS, edge hit), cache-tag/contexts denetimi, CDN hedefli purge + warm-up, slow query taraması, kuyruk konfig temizliği.
Ay 2: Medya boru hattı (WebP/AVIF, srcset), route-conditional asset, Views optimizasyonu, arama facet sınırları, canary + rollout stratejisi, otomatik Lighthouse kapıları.
Ay 3: Yük/gerilim/kalıcılık testleri, Headless uç sözleşmeleri, görsel regresyon, maliyet-performans analizi, “yüksek etki/düşük çaba” backlog’unu kapatma.
KPI: LCP P95 -300ms, TTFB P95 < 600ms, 5xx < %0.5, edge hit > %85, kuyruk bekleyen iş = 0±.

---

Sonuç: Performans, Tek Seferlik İyileştirme Değil, Süreçtir

Drupal’da performans optimizasyonu; birkaç ayar ve eklentiyle “bitti” denecek bir konu değildir. Ölçüm → Mimari → Cache/Edge → DB/Arama → Frontend/CWV → Medya → Kuyruk/Cron → İzleme/Alarm → Otomasyon → Test döngüsünü kurduğunuzda, hız bir organizasyon alışkanlığına dönüşür. Bu yazıdaki çerçeveyle; anonim trafikte edge’i parlatır, oturumlu trafikte fragment cache’i disipline eder, veritabanı ve arama sorgularını diyete sokar, medya ve asset yükünü azaltır, cron/kuyruk darboğazlarını giderir, WAF/CSP ile güvenli ve hızlı bir hat kurarsınız.

Öneri: Bugün panoları kurup P95 TTFB ve LCP için net hedef yazın; cache-tag/contexts denetimi yapın ve CDN’de hedefli purge + warm-up scriptlerini devreye alın. Ardından medya boru hattını ve route-conditional asset modelini uygulayın; arama ve Views’i optimize edin. Üç ay sonra yalnız metriklerin değil, kullanıcı memnuniyeti ve dönüşümlerin de iyileştiğini göreceksiniz.

Bill Gates Web: Profesyonel Çözümler Sunan Güvenilir Partneriniz

Bill Gates Web, dijital dünyada varlık gösteren herkes için kapsamlı çözümler sunan öncü bir platformdur. Web tasarım, yazılım geliştirme, uygulama ve programlama gibi birçok alanda uzmanlaşmış olan ekibimiz, sizin işinizi büyütmeniz için gereken her şeyi sunmak için burada. Sektördeki en son teknolojilere hakim olan ekibimiz, projenizin başarılı bir şekilde hayata geçirilmesini sağlamak için elinden gelenin en iyisini yapar.

Dijital Varlığınızı Güçlendirecek Profesyonel Dokunuşlar

Bill Gates Web olarak, işinizi bir adım öteye taşıyacak benzersiz çözümler sunuyoruz. İhtiyaçlarınıza özel olarak tasarlanmış web siteleri, kullanıcı dostu arayüzler, özelleştirilmiş yazılımlar ve mobil uygulamalarla dijital varlığınızı güçlendiriyoruz. Ayrıca, itibar danışmanlığı hizmetimizle markanızın çevrimiçi itibarını korumak ve geliştirmek için size rehberlik ediyoruz.

İlerlemenin Anahtarını Bugün Yakalayın

Siz de işinizi dijital dünyada büyütmek ve ilerlemek istiyorsanız, Bill Gates Web sizin için doğru adres. Profesyonel ekibimizle çalışarak, rekabetin önüne geçecek çözümlerle tanışabilir, başarıya giden yolda adımlarınızı sağlam atabilirsiniz. Hemen bizimle iletişime geçin ve dijital dünyadaki potansiyelinizi keşfedin!