WordPress hızlandırma hizmeti: kısaca ne yapıyorum?
WordPress hızlandırma, yavaş açılan bir WordPress sitesinin neden yavaş olduğunu ölçerek bulmak ve bu nedenleri gidermektir. Değişiklikleri mümkün olduğunda önce canlı siteden ayrı bir test kopyasında deniyorum; CDN ya da sunucu önbelleği gibi bazı ayarlar yalnızca canlı sitede yapılabiliyor, bunları önceden size yazıyorum. Hiçbir değişiklik onayınız olmadan yayına geçmiyor; iş bitince öncesi ve sonrası ölçümlerini raporluyorum.
Bu hizmet yavaş açılan WordPress siteleri için: kurumsal siteler, WooCommerce e-ticaret siteleri, Elementor gibi bir sayfa oluşturucuyla yapılmış siteler ve başkasının kurduğu siteler. Ajansların müşteri sitelerinde, onların adına da çalışıyorum.
Kapsamda görseller ve yazı tipleri, sayfanın açılmasını geciktiren kod dosyaları, eklentiler, veritabanı ve önbellek ayarları yer alıyor. Yavaşlığın bir kısmı sunucudan geliyorsa bunu da ölçümle ortaya koyuyorum. Hangisine ne kadar emek gerektiğini ölçüm belirliyor.
Fiyat, sitenin durumuna ve işin kapsamına göre belirleniyor. Ücretsiz ön teklif formunda sitenizin adresini ve yaşadığınız sorunu kısaca yazın; bir iş günü içinde dönüyorum. Kesin kapsam, süre ve fiyat teknik incelemeden ve yazışmamızdan sonra netleşiyor.
Önce ölçüyorum: hangi verilere bakıyorum?
PageSpeed Insights’ta iki tür sonuç görürsünüz: gerçek ziyaretçilerinizin son 28 gündeki deneyimi ve tek seferlik bir laboratuvar testi. Google, Core Web Vitals (Önemli Web Verileri) değerlendirmesinde gerçek ziyaretçi verisine bakar; ben de işe oradan başlıyorum.
Google bir metriği, ziyaretlerin en az yüzde 75’i aşağıdaki eşiğin içinde kaldığında “iyi” sayar:
| Metrik | Neyi ölçer? | “İyi” eşiği |
|---|---|---|
| LCP (Largest Contentful Paint) | İlk ekrandaki en büyük görselin ya da metin bloğunun (çoğu zaman ana görsel veya başlık) ne kadar sürede göründüğü | 2,5 saniye veya daha az |
| INP (Interaction to Next Paint) | Bir tıklamaya ya da dokunmaya sayfanın ne kadar hızlı tepki verdiği | 200 milisaniye veya daha az |
| CLS (Cumulative Layout Shift) | Sayfadaki içeriğin beklenmedik şekilde ne kadar kaydığı | 0,1 veya daha az |
Trafiği az olan sitelerde gerçek ziyaretçi verisi çoğu zaman yeterli olmaz. PageSpeed Insights o sayfa için yeterli veri bulamazsa sitenin genel verisini gösterir; site geneli için de veri yoksa hiç göstermez. Bu durumda laboratuvar testlerini aynı koşullarda birkaç kez tekrarlayarak ölçüyorum.
Sunucunun ilk yanıt süresine (TTFB) de bakıyorum. Önbellekli ve önbelleksiz sayfaları karşılaştırarak yavaşlığın sunucudan mı yoksa sitenin kendisinden mi geldiğini ayırt ediyorum.
WordPress site hızlandırma: nedenleri tek tek ele alıyorum
Bir görselin neden yarım saniye geç göründüğünü bulmadan bırakamayanlardanım. Ölçüm, hangi eklentinin, script’in, yazı tipinin ya da sayfa oluşturucu öğesinin ne kadar yük getirdiğini gösterir. Düzeltmeleri bu verilere göre yapıyorum:
- Görseller: Doğru boyuta küçültme, WebP ya da sunucunuz destekliyorsa AVIF biçimine dönüştürme, kaymayı önlemek için genişlik ve yükseklik bilgisi ekleme. Sayfanın ana görselini (LCP görseli) asla geç yüklemeye bırakmıyor, öncelikli yüklenmesini sağlıyorum.
- Yazı tipleri: Kullanılmayan font ağırlıklarını ayıklama, kritik fontları önceden yükleme ve font değişirken metnin kaymasını önleyen yedek font ayarları.
- CSS ve JavaScript: Sayfanın görünmesini engelleyen dosyaları azaltma, her script’i yalnızca gerektiği sayfada yükleme, ertelenebilecekleri erteleme.
- Eklentiler ve sayfa oluşturucu: Aynı işi yapan ya da WordPress’in zaten yaptığı işi tekrarlayan eklentileri ayıklama. WordPress artık olası ana görsele kendiliğinden öncelik veriyor; bunu bozan bir eklenti hız kazandırmaz, kaybettirir. Elementor gibi bir sayfa oluşturucu varsa önce onun kendi performans ayarlarını ve kullanılmayan öğelerini ele alıyorum.
- Veritabanı: Her sayfada otomatik yüklenen ayarların boyutu, kaldırılmış eklentilerden kalan kayıtlar ve süresi dolmuş geçici veriler. Otomatik yüklenen ayarlar şiştiğinde WordPress’in Site Sağlığı ekranı uyarı veriyor; bu da kontrol ettiğim noktalardan biri. Yazı ve sayfaların birikmiş eski sürümlerini de temizliyorum, ama bunun ziyaretçinin gördüğü hıza etkisi genellikle sınırlıdır.
- Önbellekleme: Sayfa ve tarayıcı önbelleği. Birbiriyle çakışan birkaç eklenti yerine tek ve doğru ayarlanmış bir yapı kuruyorum.
- WooCommerce: Sepet, ödeme ve hesap sayfaları kişiye özel olduğu için sayfa önbelleğinden sunulamaz. Bu sayfaların hızı sunucu yanıtına, eklenti yüküne ve ürün filtresi ya da arama gibi sorgulara bağlıdır. Bu sayfaları ayrıca ölçüyor, önbellek kurallarını sepeti ve ödemeyi bozmayacak şekilde ayarlıyorum.
- Sunucu ve PHP: Yavaşlığın bir kısmı sunucudan geliyorsa bunu ölçümle gösteriyorum. Sizin ya da hosting firmanızın yapması gereken bir ayar varsa ne yapılacağını yazılı olarak iletiyorum. Sitede WordPress’in önerdiği güncel bir PHP sürümü kullanılmıyorsa güncellemeyi önce test kopyasında deniyorum.
- CDN ve dış script’ler: Ziyaretçileriniz farklı bölgelerden geliyorsa ya da dosyalar ağırsa, bir CDN’in (içerik dağıtım ağı) işe yarayıp yaramayacağını ölçümle gösteriyorum. Canlı destek balonları, takip pikselleri ve gömülü videolar gibi dış script’lerin tıklamalara tepki süresine etkisini de ölçüyorum.
Tasarımınız ve işlevleriniz bozulmadan
CSS ve JavaScript dosyalarını küçültmek, birleştirmek ya da ertelemek, özensiz yapıldığında formları, kaydırıcıları ve WooCommerce sepetini bozabilir. Bu yüzden işe sitenin yedeğini alarak başlıyor, değişiklikleri mümkün olduğunda önce canlı siteden ayrı bir test kopyasında yapıyorum.
Yayına almadan önce iletişim formunu, menüleri, mobil görünümü ve varsa sepet ile ödeme adımlarını tek tek deniyorum. Değişiklikleri canlı siteye ancak siz onay verdikten sonra uyguluyorum.
Sonuçları nasıl raporluyorum?
Öncesi ve sonrası ölçümlerini iki aşamada raporluyorum:
- İş bitince: Aynı sayfalarda, aynı koşullarda ve birkaç tekrarla yapılmış laboratuvar ölçümleri. Laboratuvar puanı sayfada hiçbir şey değişmese de testten teste oynar, bu yüzden tek bir ölçüme bakmıyorum.
- Yaklaşık bir ay sonra: Sitenizin gerçek ziyaretçi verisi varsa bu verideki değişim. Gerçek ziyaretçi verisi son 28 günü kapsadığı ve Search Console’daki düzeltme doğrulaması da 28 gün sürdüğü için iyileşme ancak bu sürenin sonunda tam olarak görünür.
Ölçümleri ve onay adımlarını yazılı olarak paylaşıyorum; muhatabınız baştan sona benim.
Size PageSpeed’de 100 puan ya da “bir saniyenin altında açılır” gibi bir açılış süresi garantisi vermiyorum. Google’ın kendi dokümanları da 100 puanın beklenen bir sonuç olmadığını söylüyor. Hedefim bir puan tablosu değil; ziyaretçilerinizin gerçekten beklediği sürenin kısalması ve ölçülebildiği yerde Core Web Vitals değerlerinin “iyi” aralığa girmesi.
Hızı arama görünürlüğünün bütünü içinde ele almak isterseniz SEO ve GEO danışmanlığı ile birlikte planlayabiliriz.
Hız kalıcı olsun diye
Hızlanan bir site zamanla yeniden yavaşlayabilir. En sık nedenler yeni eklentiler, optimize edilmeden yüklenen görseller ve sonradan eklenen dış script’lerdir. Rapora, bundan sonra neye dikkat etmeniz gerektiğini anlatan kısa bir not ekliyorum. İsterseniz sayfa ağırlığı ve eklenti sayısı için birlikte bir üst sınır belirleyebiliriz; buna performans bütçesi deniyor.
Güncellemeleri ve düzenli kontrolleri bana bırakmak isterseniz WordPress bakım hizmeti hızın korunmasına da yardımcı olur; tema ve eklenti güncellemeleri önce test kopyasında deneniyor. Yavaşlık bozuk bir tema, çakışan eklentiler ya da yarım kalmış bir projenin belirtisiyse işe WordPress hata çözümü ile başlamak daha doğru olur. Hosting değişecekse geçişi WordPress site taşıma sürecinde, veriyi ve arama görünürlüğünü koruyacak şekilde planlıyorum.