scrubex.com.tr Vaka Analizi: Lighthouse 58'den 96'ya Yükselen WordPress Performansı

Lighthouse skorları kullanıcı için dolaylı olarak önemli olsa da markanız dünya devleri arasında değilse sizin için son derece önemli olacaktır. Çünkü markanız tarayıcıya ezberden yazılmıyor, arama sonuçlarında çıkıyorsa SEO ve GEO sizin için en iyi yatırım olacaktır. Tam bu noktada ise Lighthouse skorları devreye giriyor.

Müşteri Profili ve Başlangıç Durumu

scrubex.com.tr, endüstriyel temizlik sektöründe faaliyet gösteren bir e-ticaret ve kurumsal tanıtım sitesidir. Yerli bir markanın paylaşımlı hosting (shared hosting) altyapısı üzerinde barındırılan site; WordPress tabanında Elementor page builder ile inşa edilmiş ve ACF (Advanced Custom Fields) eklentisiyle zenginleştirilmiş bir yapıya sahiptir. Site, optimizasyon öncesinde ciddi performans sorunları yaşıyordu ve ziyaretçi deneyimini doğrudan olumsuz etkileyen teknik darboğazlar mevcuttu.

Projeye başlarken Google Lighthouse ile yapılan ilk ölçümde sitenin durumu şu şekildeydi:

Metrik	Önceki Skor	Durum
Performance	58	⚠️ Orta
Accessibility	88	⚠️ Orta
Best Practices	73	⚠️ Orta
SEO	100	✅ İyi
LCP	3.16 sn	❌ Kötü
CLS	0.00	✅ İyi
INP	8 ms	✅ İyi

LCP değeri 3.16 saniye ile Google’ın belirlediği 2.5 saniyelik “iyi” eşiğinin çok üzerindeydi. LCP öğesi video.elementor-background-video-hosted olarak tespit edildi; yani arka plan videosu, sayfanın en büyük içerikli boyama öğesiydi ve yüklenmesi aşırı uzun sürüyordu.

Uygulanan Optimizasyon Adımları

Optimizasyon sürecinde 10 farklı katmanda eş zamanlı müdahale yapıldı. Her adım, bir öncekinin etkisini güçlendirecek şekilde planlandı.

1. PHP Sürümü Güncellendi: 8.0 → 8.3

PHP 8.0’dan 8.3’e yükseltme, optimizasyon sürecinin temel taşıdır. PHP 8.3, JIT (Just-in-Time) derleyici iyileştirmeleri, readonly sınıf desteği ve gelişmiş bellek yönetimi ile önceki sürümlere kıyasla %15-20 daha yüksek throughput sunar. PHP 8.0 ise Kasım 2023’te güvenlik desteği son bulan bir sürümdür; yani hem performans hem güvenlik açısından güncelleme zorunluydu.

Güncelleme öncesinde tüm eklentilerin ve temanın PHP 8.3 uyumluluğu test edildi. Elementor Pro, ACF ve WooCommerce gibi kritik eklentilerin 8.3 ile tam uyumlu olduğu doğrulandı.

PHP güncellemeleri çoğu zaman göz ardı edilse de, TTFB (Time to First Byte) metriğini doğrudan etkileyen en temel faktördür. Sunucunun bir isteği işleyip ilk baytı tarayıcıya gönderme süresindeki bu yapısal iyileşme, arama motoru botlarının siteyi daha hızlı taramasını sağlayarak SEO performansına ve tarama bütçesinin (crawl budget) verimli kullanılmasına doğrudan katkı sunar.

2. OPcache Aktif Edildi

OPcache, PHP dosyalarını her istekte yeniden derlemek yerine, derlenmiş bytecode’u paylaşımlı bellekte tutarak PHP işleme süresini %50-70 oranında azaltır (Pantheon, 2024). Scrubex projesinde OPcache varsayılan olarak kapalıydı; bu, her sayfa isteğinde PHP’nin tüm dosyaları sıfırdan derlemesi anlamına geliyordu.

PHP bellek limiti de varsayılan 128 MB’dan 512 MB’a yükseltildi. Bu ayar wp-config.php dosyasına eklendi:

define('WP_MEMORY_LIMIT', '512M');

Bu değişiklik, özellikle Elementor gibi bellek yoğun page builder’ların render sürecinde zaman aşımı hatalarını ortadan kaldırdı.

Ayrıca, OPcache’in aktif edilmesiyle birlikte disk okuma/yazma (I/O) işlemlerindeki yük büyük ölçüde hafifletilmiştir. Disk darboğazlarının önüne geçilmesi, sunucunun anlık trafik artışlarına (spike) karşı çok daha dirençli olmasını ve eşzamanlı kullanıcılara stabil bir ziyaretçi deneyimi sunmasını mümkün kılmıştır.

3. MyISAM → InnoDB Dönüşümü Tamamlandı

Veritabanı tablolarının bir kısmı hâlâ eski MyISAM motoruyla çalışıyordu. MyISAM, tablo seviyesinde kilitleme yapar; bir kullanıcı yorum yazdığında veya bir sipariş işlendiğinde tüm tablo kilitlenir ve diğer kullanıcılar beklemek zorunda kalır. Bu durum, eşzamanlı ziyaretçi sayısı arttığında ciddi performans darboğazına neden olur.

InnoDB ise satır seviyesinde kilitleme, ACID uyumlu işlemler ve otomatik çökme kurtarma (crash recovery) sunar. Dönüşüm, her tablo için aşağıdaki SQL komutu çalıştırılarak gerçekleştirildi:

ALTER TABLE table_name ENGINE=InnoDB;

Bu dönüşüm özellikle wp_posts, wp_postmeta, wp_options ve wp_comments gibi yoğun okuma-yazma yapılan tablolarda belirgin performans iyileşmesi sağladı.

Not: Bu değişik yalnızca SQL komutu ile değil aynı zamanda LiteSpeed Cache eklentisi üzerinden de gerçekleştirilebilir. LiteSpeed Cache → Database → Database Table Engine Converter.

InnoDB mimarisine geçiş sadece hız değil, aynı zamanda veri bütünlüğü (data integrity) açısından da hayati bir adımdır. Olası bir sunucu kesintisi veya ani kapanma durumunda InnoDB’nin kurtarma mekanizmaları (crash recovery) veritabanı bozulmalarını engelleyerek işletmenin sürekliliğini güvence altına alır.

4. Redis Object Cache Aktif Edildi

WordPress, her sayfa yüklemesinde onlarca veritabanı sorgusu çalıştırır. Redis, bu sorguların sonuçlarını RAM’de tutarak tekrar eden isteklerde veritabanına hiç gitmeden yanıt verir. Gerçek dünya uygulamalarında Redis, veritabanı sorgu sayısında %70-90 azalma sağlar (SmartRoots, 2024).

LiteSpeed Cache konfigürasyonunda Redis bağlantısı şu şekilde yapılandırıldı:

object: true
object-kind: true # Redis
object-host: localhost
object-port: 11211
object-life: 360
object-persistent: true
object-admin: true
object-transients: true

Bu yapılandırma ile hem frontend hem admin paneli için object cache aktif hale getirildi. object-transients: true ayarı, WordPress transient’larının da Redis üzerinden sunulmasını sağlayarak wp_options tablosundaki autoload yükünü önemli ölçüde azalttı.

Redis’in RAM tabanlı çalışma prensibi, özellikle ürün filtrelemeleri, site içi aramalar ve sepete ürün ekleme gibi önbelleğe alınamayan (bypass cache) dinamik işlemlerde veritabanı yanıt sürelerini milisaniye seviyelerine çekmiştir. Bu gelişme, ziyaretçilerin site içi gezinme akıcılığını doğrudan artırarak alışveriş dönüşüm oranlarına pozitif yansır.

5. Eklentiler Güncellendi ve Temizlendi

Tüm aktif eklentiler en son sürümlerine güncellendi. Kullanılmayan temalar kaldırıldı; WordPress, aktif olmayan temaları da yükleme sürecinde tarar ve bu gereksiz dosya sistemi işlemleri sunucu yanıt süresini artırır.

Elementor Pro ve ACF arasındaki uyumsuzluktan kaynaklanan bir hata da bu aşamada düzeltildi:

PHP Warning: Undefined array key 1 in 
/wp-content/plugins/elementor-pro/modules/dynamic-tags/acf/tags/acf-image.php on line 40

Bu hata, ACF image alanlarının dönüş formatının yanlış yapılandırılmasından kaynaklanıyordu. Çözüm olarak ACF alanlarına fallback görsel atandı ve dönüş formatı “Image Array” olarak değiştirildi. Bu düzeltme, error log’daki yüzlerce PHP uyarısını ortadan kaldırdı ve sunucunun hata işleme yükünü azalttı.

Arka planda sessizce biriken PHP hataları ve uyarılar (warnings), sunucunun error.log dosyalarını şişirmenin yanı sıra gereksiz CPU döngüleri tüketmesine yol açar. Bu tür gizli darboğazların giderilmesi, sunucu kaynaklarının tamamen ziyaretçilere içerik sunmaya odaklanmasını sağlar ve genel sistem sağlığını (health) artırır.

6. Görseller Optimize Edildi: WebP Dönüşümü

Sitedeki tüm görseller tek tek boyutlandırıldı ve WebP formatına dönüştürüldü. WebP, JPEG’e kıyasla aynı görsel kalitesinde %25-35 daha küçük dosya boyutu sunar. Bu dönüşüm, özellikle ürün görselleri ve hero section’daki büyük görseller için dramatik bant genişliği tasarrufu sağladı.

LiteSpeed Cache konfigürasyonunda WebP ayarları:

img_optm-auto: true   # Otomatik optimizasyon
img_optm-webp: 1      # WebP dönüşümü aktif
img_optm-jpg_quality: 82  # JPEG kalite seviyesi
img_optm-webp_replace_srcset: true  # srcset'lerde de WebP

Ayrıca LCP öğesinin lazy loading’den hariç tutulması kritik bir adımdı. Hero section’daki görseller ve logo media-lazy_exc listesine eklenerek tarayıcının bu görselleri hemen yüklemesi sağlandı:

media-lazy_exc:
  - /wp-content/uploads/2025/02/logoscrubex-scaled.webp
  - /wp-content/uploads/2025/02/a68ba5fa...1536x1024.webp
  - /wp-content/uploads/2024/11/BYP0728-copy-1536x1024.webp

Lazy load (tembel yükleme) modern web’in vazgeçilmezi olsa da, ekranın ilk görünür kısmında (above-the-fold) yer alan ana görseller için bir performans katiline dönüşebilir. LCP öğesi olan görsellerin tarayıcıya “eager” (hemen yükle) talimatıyla sunulması ve lazy load işleminden muaf tutulması, LCP süresindeki devasa düşüşün ana teknik mimarlarından biridir.

7. LiteSpeed Cache Yapılandırması Optimize Edildi

LiteSpeed Cache, Scrubex projesinin önbellekleme omurgasını oluşturdu. Cloudflare ile API bağlantısı kurularak iki katmanlı bir cache mimarisi elde edildi. İşte yapılandırmanın kritik noktaları:

Cache TTL Değerleri:

• Genel sayfalar: 604.800 saniye (7 gün)
• Ana sayfa: 604.800 saniye (7 gün)
• RSS feed: 86.400 saniye (1 gün)
• Tarayıcı cache: 31.557.600 saniye (1 yıl)
• 404 hataları: 3.600 saniye (1 saat)
• 500 hataları: 600 saniye (10 dakika)

Sayfa Optimizasyonu:

• CSS minify: ✅ Aktif
• CSS combine: ✅ Aktif
• UCSS (Kullanılmayan CSS kaldırma): ✅ Aktif
• JS minify: ✅ Aktif
• JS combine: ✅ Aktif
• HTML minify: ✅ Aktif
• JS defer: ✅ Aktif
• Emoji scripti kaldırma: ✅ Aktif
• Query string kaldırma: ✅ Aktif

Guest Mode ve Viewport Optimizasyonu:

• Guest Mode: ✅ Aktif - İlk kez gelen ziyaretçilere optimize edilmiş statik sayfa sunar.
• Guest Optimization: ✅ Aktif
• VPI (Viewport Images): ✅ Aktif - Yalnızca görünür alandaki görselleri yükler.

DNS Prefetch:

dns_prefetch:
  - "//fonts.gstatic.com"
  - "//www.google-analytics.com"
  - "//connect.facebook.net"

Üçüncü taraf kaynaklara (third-party scripts) yapılan DNS sorgularının sayfa render sürecini bloke etmesini önlemek amacıyla yapılan bu prefetch tanımlamaları, dış bağlantıların getirdiği gecikme maliyetini en aza indirmiştir. LiteSpeed’in CSS ve JS birleştirme özellikleriyle birlikte kurulan bu mimari, sayfanın toplam HTTP istek sayısında radikal bir düşüş sağlamıştır.

8. Cloudflare Cache Kuralları Yapılandırıldı

Cloudflare’de üç ayrı cache kuralı oluşturularak dinamik ve statik içerikler ayrıştırıldı:

Kural 1: wp-admin Bypass:

(http.request.full_uri wildcard "*scrubex.com.tr/wp-admin*")
# → Bypass cache

Kural 2: wp-login Bypass:

(http.request.full_uri wildcard "*scrubex.com.tr/wp-login.php*")
# → Bypass cache

Bu iki kural, admin paneli ve giriş sayfasının asla önbelleklenmemesini garanti eder. Önbelleğe alınmış bir login sayfası güvenlik açığı oluşturabilir ve admin panelinde eski verilerin gösterilmesine neden olabilir.

Kural 3: Genel Sayfa Cache:

(http.request.full_uri wildcard "scrubex.com.tr*")
# → Eligible for cache
# → Edge TTL: Cache-control header varsa kullan, yoksa Cloudflare varsayılanını uygula

Bu yapılandırma, LiteSpeed’in origin’den gönderdiği cache-control başlıklarına saygı gösterirken, başlık yoksa Cloudflare’in kendi TTL politikasını uygulamasını sağlar.

Cache kurallarının bu şekilde granüler (parçalı) olarak tasarlanması, admin paneli ve dinamik işlemlerin bozulmasını engellerken aynı zamanda genel ziyaretçi sayfalarının saniyede binlerce isteği sorunsuzca karşılayabilen (Edge Cache) bir yapıya kavuşmasını mümkün kılmıştır. Bu kurgu, erişilebilirlik ve performansın kusursuz bir sentezidir.

9. Güvenlik Başlıkları Eklendi (Security Headers)

Cloudflare Transform Rules üzerinden tüm gelen isteklere altı kritik güvenlik başlığı eklendi:

Başlık	Değer	İşlev
Strict-Transport-Security	max-age=31536000; includeSubDomains; preload	HTTPS zorunlu kılar
Content-Security-Policy	Özelleştirilmiş politika	XSS ve injection saldırılarını engeller
X-Frame-Options	SAMEORIGIN	Clickjacking saldırılarını önler
X-Content-Type-Options	nosniff	MIME type sniffing'i engeller
Referrer-Policy	strict-origin-when-cross-origin	Referrer bilgi sızıntısını sınırlar
Permissions-Policy	camera=(), microphone=(), geolocation=()	Gereksiz API erişimlerini kapatır

Bu yapılandırma sonucunda securityheaders.com’dan A+ notu alındı: Mümkün olan en yüksek güvenlik başlığı skoru.

Güvenlik başlıkları sadece olası siber saldırılara karşı kalkan oluşturmakla kalmaz; aynı zamanda HSTS preload gibi özellikler sayesinde tarayıcıların HTTP’den HTTPS’ye yönlendirme sürecinde kaybettiği o değerli milisaniyeleri de kurtarır. Arama motorları ve yapay zeka botları da bu yüksek güvenlik standartlarını sıralama ve alıntı yapma kriterlerinde güçlü bir güven sinyali (E-E-A-T) olarak değerlendirir.

10. Cloudflare-LiteSpeed API Bağlantısı

LiteSpeed Cache eklentisi, Cloudflare ile API üzerinden entegre edildi. Bu sayede LiteSpeed’de bir cache temizleme (purge) işlemi yapıldığında, aynı anda Cloudflare edge sunucularındaki cache de otomatik olarak temizlenir. İki katmanlı bu yapı, içerik güncellemelerinin ziyaretçilere anında yansımasını garanti eder.

cdn-cloudflare: true
cdn-cloudflare_name: scrubex.com.tr

Sunucu (Origin) ile CDN (Edge) arasındaki bu kusursuz çift yönlü entegrasyon, içerik yöneticilerinin site üzerinde bir değişiklik yaptıklarında manuel olarak Cloudflare önbelleğini temizleme zahmetine girmelerini engeller. Otomasyona bağlanan bu senkronizasyon süreci, ziyaretçilere her zaman en güncel içeriğin ışık hızında ulaştırılmasını garanti altına alır.

Sonuçlar: Öncesi ve Sonrası Karşılaştırması

Tüm optimizasyonlar tamamlandıktan sonra yapılan Lighthouse ölçümünde sonuçlar şu şekilde gerçekleşti:

Metrik	Öncesi	Sonrası	İyileşme
Performance	58	96	+%66
Accessibility	88	97	+%10
Best Practices	73	96	+%32
SEO	100	100	Korundu
LCP	3.16 sn	0.44 sn	-%86
FCP	-	0.6 sn	✅ İyi
Security Headers	Yok	A+	Sıfırdan kuruldu

En çarpıcı iyileşme LCP metriğinde yaşandı. 3.16 saniyeden 0.44 saniyeye düşen LCP, ziyaretçilerin sayfayı neredeyse anında görmesini sağladı. LCP öğesi de video.elementor-background-video-hosted yerine div.elementor-element.elementor-element-988444f olarak değişti; bu, arka plan videosunun artık LCP darboğazı olmaktan çıktığını göstermektedir.

Teknik Mimari Özeti

Bu vaka çalışmasında uygulanan optimizasyonların katmanlı mimarisini şu şekilde özetleyebiliriz:

Katman	Uygulanan Optimizasyon	Etki Alanı
PHP Runtime	PHP 8.0 → 8.3, OPcache, 512 MB bellek	Sunucu yanıt süresi (TTFB)
Veritabanı	MyISAM → InnoDB, Redis object cache	Sorgu hızı, eşzamanlılık
Uygulama	Eklenti güncelleme, tema temizliği, hata düzeltme	Kararlılık, hata yükü
Ön Yüz	WebP dönüşümü, lazy load istisnaları, CSS/JS minify	LCP, sayfa boyutu
CDN/Cache	LiteSpeed Cache + Cloudflare çift katman	Edge delivery, TTL yönetimi
Güvenlik	6 güvenlik başlığı, cache bypass kuralları	Güvenlik skoru, HTTPS

Bu Projeden Çıkarılacak Dersler

1. Tek başına cache eklentisi yetmez. LiteSpeed Cache aktifti ancak PHP sürümü eski, OPcache kapalı ve veritabanı MyISAM olduğu sürece cache sadece yüzeydeki sorunu maskeliyordu.

2. PHP sürümü performansın temelidir. PHP 8.0’dan 8.3’e geçiş, tek başına bile ölçülebilir bir hız artışı sağladı. Üstelik 8.0 artık güvenlik güncellemesi almıyor.

3. LCP öğesini tanımak kritiktir. Scrubex’te LCP öğesi bir arka plan videosuydu. Video optimizasyonu ve lazy load istisnaları ile bu darboğaz kökten çözüldü.

4. Güvenlik ve performans birlikte yürür. Security headers eklemek sadece güvenlik değil, tarayıcı davranışını da optimize eder. HSTS preload ile tarayıcı HTTPS yönlendirme gecikmesini atlar.

5. Cloudflare cache kuralları granüler olmalıdır. wp-admin ve wp-login bypass kuralları olmadan, admin panelinde eski önbelleğe alınmış sayfalar gösterilebilir; bu hem güvenlik riski hem kullanılabilirlik sorunudur.

Sonuç

scrubex.com.tr projesi, WordPress performans optimizasyonunun tek bir eklenti veya tek bir ayar değişikliğiyle çözülemeyeceğini somut verilerle kanıtlamaktadır. WordPress asla kötü bir tercih değildir; ancak performans sorunları yaşamamak ve rekabetin gerisinde kalmamak için son derece iyi yapılandırılması gerektiği aşikardır. Lighthouse 58’den 96’ya, LCP 3.16 saniyeden 0.44 saniyeye düşürülmesi, PHP runtime’dan veritabanı motoruna, görsel formatından CDN cache kurallarına kadar her katmanın birlikte optimize edilmesinin sonucudur.

Deloitte ve Google’ın ortak araştırmasına göre, yükleme süresindeki 0.1 saniyelik iyileşme dönüşüm oranlarını %8.4’e kadar artırabilir (Think with Google, 2020). Scrubex projesinde elde edilen 2.72 saniyelik LCP iyileşmesi, bu oranın katlarla çarpılması anlamına gelir.

Bu sonuca ulaşırken benimsediğimiz temel yaklaşım; gerekmedikçe eklenti kullanmamak, functions.php dosyasına doğrudan müdahale etmek yerine özel kodları dışarıdan güvenli bir şekilde enjekte etmek ve hafifliği kanıtlanmış hafif veya özel (custom) temaları tercih etmek olmuştur. Performans optimizasyonu statik bir süreç değildir; bu nedenle Scrubex projesinde sürekli optimizasyon döngüleri işletilerek çalışmalarımız aynı titizlikle sürdürülmeye devam edilecektir.

WordPress sitenizin performansını profesyonel olarak analiz ettirmek ve benzer sonuçlar elde etmek için hız optimizasyonu hizmetimizi inceleyebilir veya iletişim sayfamızdan ücretsiz ön analiz talep edebilirsiniz.

---

Bu vaka analizi, modern yapay zeka arama motorları (GEO) tarafından en iyi şekilde işlenebilmesi için makine okunabilir (machine-readable) standartlarda yapılandırılmış olup; içerik ve verilerin tamamı %100 insan emeği ve gerçek saha tecrübesiyle oluşturulmuştur.