WordPress Hızlandırma Rehberi: 15 Etkili İpucu

WordPress siteniz yavaş açılıyorsa yapılabilecek ilk şey yeni bir hız eklentisi kurmak değil, siteyi neyin yavaşlattığını anlamak olmalı.

Çünkü görünürde aynı problemi yaşayan iki WordPress sitesinin yavaşlama nedeni tamamen farklı olabilir. Bir projede sunucu ilk cevabı geç verirken başka bir projede birkaç megabaytlık görseller, gereksiz JavaScript dosyaları veya ağır çalışan bir eklenti sayfanın açılışını geciktirebilir.

Bu nedenle WordPress performans çalışmalarında tek bir PageSpeed puanına bakarak işlem yapmak yerine sitenin tamamını değerlendirmek daha sağlıklı sonuç verir. Hosting altyapısı, tema, eklentiler, görseller, cache sistemi, veritabanı ve üçüncü taraf kaynaklar birbirleriyle birlikte çalışır.

Ben de bir WordPress site hızlandırma çalışmasına başlamadan önce mevcut performansı ölçüp asıl darboğazın nerede olduğunu belirlemeyi tercih ediyorum. Böylece sırf test aracındaki puanı artırmak yerine ziyaretçinin gerçekten daha hızlı kullandığı bir site ortaya çıkıyor.

Aşağıdaki 15 madde, kendi WordPress sitenizde kontrol edebileceğiniz en önemli performans noktalarını kapsıyor.

1. Önce sitenizin mevcut hızını ölçün

Optimizasyondan önce başlangıç değerlerini bilmezseniz yaptığınız işlemlerin gerçekten işe yarayıp yaramadığını anlamak zorlaşır.

İlk olarak PageSpeed Insights ile ana sayfanızı ve sitenizde önemli gördüğünüz birkaç farklı sayfayı test edebilirsiniz. Yalnızca ana sayfayı ölçmek çoğu zaman yeterli değildir. Özellikle WooCommerce kullanıyorsanız ürün, kategori ve sepet gibi farklı sayfa tiplerinin çalışma biçimi değişebilir.

Raporda ilk bakılabilecek metriklerden bazıları şunlardır:

• LCP
• INP
• CLS
• TTFB
• render engelleyen kaynaklar
• kullanılmayan JavaScript
• büyük görsel dosyaları
• uzun süren ana iş parçacığı görevleri

Google, iyi kullanıcı deneyimi için LCP değerinin 2,5 saniyenin altında, INP değerinin 200 ms’nin altında ve CLS değerinin 0,1’in altında olmasını öneriyor. Ancak bu değerlerin iyi olması tek başına Google’da üst sıralama garantisi değil; Core Web Vitals sayfa deneyiminin yalnızca bir parçası.

Chrome geliştirici araçlarındaki Network ve Performance sekmeleri de hangi kaynağın ne zaman yüklendiğini görmek için oldukça faydalı.

Ben optimizasyon öncesinde test sonuçlarını kaydetmeyi tercih ediyorum. Çalışma tamamlandığında aynı sayfalarda yeniden test yapmak, hangi işlemin ne kadar fark oluşturduğunu daha net gösteriyor.

2. Hosting ve sunucu performansını kontrol edin

WordPress hızlandırma çalışmalarında gözden kaçırılan konulardan biri hosting altyapısı.

Tema ve eklentiler ne kadar optimize edilirse edilsin, sunucu istekleri geç işliyorsa sitenin performansı belirli bir noktadan sonra iyileşmez.

Özellikle yoğun kullanılan paylaşımlı hostinglerde kaynak limitleri nedeniyle dönemsel yavaşlamalar görülebilir. CPU kullanımı, kullanılabilir RAM, disk performansı ve PHP worker sayısı gibi değerler aynı sunucudaki diğer sitelerin yoğunluğundan da etkilenebilir.

Sunucu tarafında şu noktaların kontrol edilmesi faydalıdır:

• güncel ve uyumlu PHP sürümü
• PHP memory limit
• PHP-FPM yapılandırması
• OPcache
• CPU ve RAM kullanımı
• disk performansı
• web server yapısı
• veritabanı performansı
• sunucunun hedef ziyaretçilere uzaklığı

WordPress’in resmi performans dokümantasyonu da donanım kapasitesi, sunucu yükü, coğrafi uzaklık ve cache yapılandırmasının performansı doğrudan etkilediğini belirtiyor.

Özellikle boş bir WordPress kurulumu bile yavaş yanıt veriyorsa problemi yalnızca tema ve eklentilerde aramak doğru olmayabilir.

3. Doğru bir sayfa cache sistemi kullanın

WordPress dinamik çalışan bir içerik yönetim sistemi.

Bir ziyaretçi sayfayı açtığında PHP çalışır, gerekli veriler veritabanından alınır ve kullanıcının göreceği HTML oluşturulur. Aynı içerik binlerce ziyaretçi tarafından görüntüleniyorsa bu işlemlerin her seferinde yeniden yapılması sunucuda gereksiz işlem yükü oluşturabilir.

Sayfa cache sistemi, uygun sayfaların hazırlanmış çıktısını saklayarak sonraki ziyaretçilere daha hızlı cevap verilmesini sağlar.

Kullanacağınız sistem hosting altyapınıza göre değişebilir.

Örneğin LiteSpeed sunucularda LiteSpeed Cache’in sunucu seviyesindeki cache özelliklerinden yararlanılabilir. Farklı altyapılarda WP Rocket, Nginx FastCGI Cache veya sunucu tarafında kullanılan başka cache çözümleri tercih edilebilir.

Daha önce hazırladığım en iyi WordPress eklentileri rehberinde performans eklentileri arasındaki farkları daha ayrıntılı ele aldım.

Buradaki önemli konu aynı işi yapan birkaç farklı optimizasyon sistemini kontrolsüz biçimde birlikte kullanmamak.

Bir eklentide CSS minify, başka bir eklentide tekrar minify ve üçüncü bir sistemde JavaScript delay açılması bazen hızlandırmak yerine sayfanın bozulmasına neden olabilir.

4. Object cache her WordPress sitesinde gerekli değildir

Sayfa cache ile object cache birbirinden farklı işler yapar.

Persistent object cache; WordPress’in sık ihtiyaç duyduğu bazı verilerin tekrar tekrar veritabanından alınması yerine Redis veya Memcached gibi sistemlerde bellekte tutulmasına yardımcı olabilir.

Özellikle:

• WooCommerce mağazaları
• üyelik siteleri
• yoğun yönetim paneli kullanılan projeler
• çok sayıda dinamik sorgu çalıştıran sistemler

object cache’den daha fazla fayda görebilir.

WordPress de persistent object cache kullanımının veritabanına yapılan tekrar eden erişimleri azaltabileceğini belirtiyor.

Ancak burada “Redis kurdum, sitem mutlaka hızlandı” mantığı doğru değil.

Küçük ve çoğunlukla cache’den sunulan bir kurumsal web sitesinde fark sınırlı olabilir. Hatta yanlış yapılandırılmış bir Redis bağlantısı yeni sorunlara neden olabilir.

İhtiyaç olup olmadığı yapılan sorgular ve sunucu davranışı incelendikten sonra belirlenmeli.

5. Görselleri doğru boyutta yükleyin

WordPress sitelerinde en kolay fark yaratılan alanlardan biri görseller.

Örneğin sayfada 700 piksel genişliğinde görüntülenecek bir fotoğrafı 5000 piksel genişliğinde ve birkaç megabayt boyutunda yüklemek gereksiz veri transferine neden olur.

Görseli WordPress’e yüklemeden önce kullanım alanına uygun boyuta getirmek hâlâ en temiz yöntemlerden biri.

Bunun yanında:

• JPEG veya PNG yerine uygun yerlerde WebP/AVIF kullanmak,
• görselleri sıkıştırmak,
• doğru width ve height değerlerini kullanmak,
• responsive image yapısından faydalanmak,
• ihtiyaç olmayan büyük dosyaları kaldırmak

sayfa ağırlığını ciddi şekilde azaltabilir.

Özellikle sayfanın üst bölümündeki büyük hero görseline dikkat edin. Bu görsel çoğu zaman LCP öğesi olduğu için yanlış lazy load uygulanması sayfanın daha yavaş görünmesine neden olabilir.

6. Lazy load özelliğini her görsele uygulamayın

Lazy loading, ekranın altındaki görselleri ihtiyaç oluşana kadar yüklemeyerek ilk sayfa açılışındaki veri miktarını azaltabilir.

Ama burada önemli bir ayrım var.

Ekran açıldığında ziyaretçinin hemen gördüğü ana görsellerin geciktirilmesi performans açısından ters sonuç oluşturabilir.

Özellikle:

• hero görseli,
• sayfanın ana ürün görseli,
• ekranın üst bölümündeki önemli içerikler

körlemesine lazy load edilmemeli.

Sayfanın aşağısındaki galeri, blog görselleri veya benzeri içeriklerde ise lazy loading oldukça faydalı olabilir.

Kısacası amaç “bütün görseller lazy olsun” değil, hangi görselin ne zaman yüklenmesi gerektiğini doğru belirlemek.

7. Kullanılmayan JavaScript dosyalarını azaltın

Modern WordPress sitelerinde performansı zorlayan en önemli konulardan biri JavaScript.

Page builder, popup, slider, analytics, canlı destek, reklam takip kodları ve çeşitli eklentiler sayfaya kendi JavaScript dosyalarını ekleyebilir.

Sorun yalnızca dosyanın indirilmesi değil. Tarayıcı bu kodları okumak ve çalıştırmak için de işlem yapmak zorunda.

Örneğin iletişim formunun bulunmadığı bir sayfada form eklentisinin tüm JavaScript dosyalarının yüklenmesi gerekmeyebilir.

Ben bu nedenle hangi dosyanın hangi sayfada gerçekten gerekli olduğuna bakıyorum.

Perfmatters Script Manager, Asset CleanUp veya manuel enqueue/dequeue işlemleriyle gereksiz kaynakları belirli sayfalarda kapatmak mümkün.

Ancak bunu yaparken eklentinin başka bir fonksiyonunu bozmamak için siteyi farklı cihaz ve sayfalarda test etmek gerekir.

8. JavaScript delay ve defer ayarlarını kontrollü kullanın

JavaScript dosyalarının çalışmasını ertelemek ilk açılış performansını ciddi şekilde iyileştirebilir.

Ama tüm scriptleri tek seferde delay yapmak genellikle doğru yaklaşım değil.

Özellikle:

• mobil menü
• sepet
• ödeme fonksiyonları
• varyasyon seçimi
• slider
• popup
• form doğrulama

gibi ziyaretçinin doğrudan etkileşim kurduğu özellikler etkilenebilir.

Bir ayarı açtıktan sonra yalnızca PageSpeed’e bakmayın.

Telefonunuzdan siteyi açın, menüyü kullanın, ürün ekleyin, form gönderin ve önemli işlevlerin tamamını kontrol edin.

Performans optimizasyonunun sonunda hızlı fakat çalışmayan bir site bırakmak başarı değildir.

9. CSS yükünü azaltın

Birçok tema ve page builder bütün bileşenlerin CSS dosyalarını her sayfada yükleyebilir.

Bu dosyaların küçültülmesi faydalı olsa da asıl kazanç çoğu zaman gereksiz CSS’in hiç yüklenmemesinden gelir.

Özellikle eski sitelerde zaman içinde:

• kullanılmayan widget stilleri,
• eski eklenti CSS’leri,
• tema özellikleri,
• üçüncü taraf kütüphaneler

birikmiş olabilir.

Unused CSS sistemleri bu noktada yardımcı olabilir.

Ancak kritik CSS veya unused CSS araçları yanlış yapılandırıldığında ilk açılışta tasarımın kısa süreli bozuk görünmesi gibi problemler ortaya çıkabilir.

Bu nedenle optimizasyon sonrası masaüstü ve mobil görünümü birlikte kontrol etmek gerekir.

10. Font kullanımını sadeleştirin

Bir web sitesinde dört farklı font ailesinin beşer farklı ağırlığını kullanmak tasarım açısından küçük bir fark yaratırken yüklenen dosya sayısını ciddi biçimde artırabilir.

Mümkün olduğunca:

• az sayıda font ailesi,
• gerçekten kullanılan font ağırlıkları,
• WOFF2 formatı,
• doğru font-display ayarları

tercih edilmeli.

Google Fonts kullanılıyorsa fontları yerel olarak barındırmak bazı projelerde dış bağlantı ihtiyacını azaltabilir.

Ancak burada da her font dosyasını preload etmek doğru değil. Sayfanın ilk görünümünde gerçekten gerekli birkaç kaynak önceliklendirilmeli.

11. Veritabanını düzenli olarak kontrol edin

WordPress sitesi uzun süre kullanıldığında veritabanında ihtiyaç duyulmayan kayıtlar birikebilir.

Bunlar arasında:

• eski revision kayıtları
• spam yorumlar
• silinmiş içerik kalıntıları
• süresi geçmiş transient’ler
• kaldırılmış eklentilerden kalan tablolar
• büyümüş autoload kayıtları

bulunabilir.

Ancak veritabanı optimizasyonunda “temizle” butonuna basmadan önce mutlaka yedek alın.

Özellikle wp_options içerisindeki autoload verilerinde veya bilinmeyen tablolarda yapılan kontrolsüz silme işlemleri sitenin çalışmasını bozabilir.

Ben büyük bir veritabanında önce hangi tabloların gerçekten büyüdüğünü ve hangi eklentinin bu veriyi ürettiğini anlamayı tercih ediyorum.

Sorun üreten eklenti çalışmaya devam ediyorsa yalnızca veritabanını temizlemek geçici çözüm olur.

12. Gereksiz eklentileri azaltın

WordPress hızlandırmayla ilgili en sık duyulan tavsiyelerden biri “eklenti sayısını azaltın”.

Burada sayı tek başına anlamlı değil.

İyi geliştirilmiş 25 küçük eklenti, bütün sitede ağır sorgular ve dosyalar çalıştıran 5 eklentiden daha hızlı olabilir.

Bu nedenle eklentileri yalnızca sayarak karar vermek yerine şunlara bakın:

• Bu eklenti gerçekten kullanılıyor mu?
• Aynı fonksiyon başka bir eklentide zaten var mı?
• Her sayfada CSS veya JS yüklüyor mu?
• Fazla veritabanı sorgusu oluşturuyor mu?
• Arka planda yoğun cron görevleri çalıştırıyor mu?
• Uzun süredir güncellenmiş mi?
• Kaldırıldığında siteyi etkileyen bir özelliği var mı?

Kullanılmayan eklentileri yalnızca pasif hale getirmek yerine, gerçekten ihtiyaç yoksa yedeğinizi aldıktan sonra kaldırmak daha temiz bir yapı sağlar.

13. CDN kullanımını ihtiyaca göre değerlendirin

CDN, statik kaynakların ziyaretçiye coğrafi olarak daha yakın bir noktadan sunulmasına yardımcı olabilir.

WordPress’in performans dokümantasyonu da sunucu ile kullanıcı arasındaki coğrafi uzaklığın yükleme sürelerini etkileyebildiğini ve CDN kullanımının statik dosyaları farklı bölgelerden sunmak için kullanılabileceğini belirtiyor.

Cloudflare, BunnyCDN veya hosting sağlayıcısının sunduğu CDN sistemleri kullanılabilir.

Ancak CDN tek başına kötü hostingi düzeltmez.

Origin sunucu çok geç cevap veriyorsa, PHP işlemleri sürekli hata oluşturuyorsa veya veritabanı sorguları problemliyse önce temel altyapı düzeltilmeli.

Ayrıca agresif cache kuralları uygularken giriş yapılmış kullanıcılar, WooCommerce sepeti ve checkout gibi dinamik alanlara dikkat edilmeli.

14. WooCommerce sitelerini ayrı değerlendirin

WooCommerce mağazalarının performans ihtiyacı standart bir kurumsal siteden farklıdır.

Ürünler, varyasyonlar, stok bilgileri, müşteri oturumları, sepet ve checkout gibi dinamik süreçler bulunur.

Özellikle büyük mağazalarda şunlar incelenebilir:

• ürün sorguları
• varyasyon sayısı
• AJAX işlemleri
• ödeme eklentileri
• kargo entegrasyonları
• filtre sistemleri
• Action Scheduler
• WooCommerce session yapısı
• wp_postmeta ve ilgili tablolar
• üçüncü taraf API çağrıları

Sepet ve ödeme sayfalarının yanlış cache’lenmesi ciddi problemlere neden olabilir.

Bu nedenle büyük veya özel geliştirmeler bulunan mağazalarda genel WordPress hız tavsiyelerini doğrudan uygulamak yerine WooCommerce yapısını ayrıca analiz etmek gerekir.

E-ticaret altyapısı tarafında daha kapsamlı geliştirme ihtiyacınız varsa WooCommerce uzmanı hizmet sayfamda üzerinde çalıştığım alanları daha detaylı görebilirsiniz.

15. Optimizasyon bittikten sonra tekrar ölçün

WordPress hızlandırma işi ayarları yaptıktan sonra bitmiş sayılmaz.

Başlangıçta kaydettiğiniz testleri aynı URL’ler üzerinde tekrar yapın.

Ancak yalnızca:

Önce 55’ti, şimdi 95 oldu.

şeklinde değerlendirmeyin.

Şunlara da bakın:

• gerçek yükleme süresi değişti mi?
• LCP hangi öğe?
• INP problemi devam ediyor mu?
• CLS oluşuyor mu?
• mobil deneyim nasıl?
• sayfanın önemli fonksiyonları çalışıyor mu?
• sunucu kaynak kullanımı düştü mü?
• gerçek kullanıcı verileri zaman içinde iyileşiyor mu?

Core Web Vitals gerçek kullanıcı deneyimini ölçmeye yönelik metriklerdir ve Search Console içerisindeki raporlar da performansı zaman içerisinde takip etmek için kullanılabilir.

Ayrıca siteye yeni eklenti, reklam kodu, görsel veya tasarım bileşeni eklendikçe performans zaman içinde yeniden değişebilir.

Bu nedenle hız optimizasyonunu tek seferlik bir “puan yükseltme işlemi” olarak değil, sitenin teknik bakımının bir parçası olarak görmek daha doğru.

WordPress hızlandırırken en sık yapılan hatalar

Yukarıdaki tekniklerin çoğu doğru kullanıldığında faydalıdır. Problem genellikle hepsini aynı anda ve ne yaptığını bilmeden uygulamaya çalışınca ortaya çıkıyor.

Örneğin aynı anda birkaç cache eklentisi kullanmak, tüm JavaScript dosyalarını geciktirmek, bütün görselleri lazy load yapmak veya veritabanındaki bilinmeyen tabloları temizlemek sitenin çalışmasını bozabilir.

Benim dikkat ettiğim temel kural şu:

Önce ölç, problemi bul, gerekli değişikliği yap ve tekrar ölç.

Bu yöntem biraz daha yavaş ilerliyor gibi görünse de hangi değişikliğin gerçekten fayda sağladığını bilmenizi sağlar.

Özellikle aktif müşteri veya sipariş alan bir sitede büyük performans işlemlerinden önce yedek almak ve mümkünse staging ortamında test yapmak gerekir.

WordPress ile ilgili diğer teknik içeriklerimi WordPress rehberleri sayfasında bir araya getiriyorum.

Cache eklentisi kurmak WordPress’i hızlandırmak için yeterli mi?

Genellikle hayır.

Cache, performansın önemli parçalarından biridir ancak siteyi yavaşlatan neden ağır görseller, kötü sunucu performansı, üçüncü taraf scriptler veya problemli veritabanı sorgularıysa yalnızca cache kullanarak tüm sorun çözülemez.

Bazı sitelerde cache kurulduktan sonra çok büyük fark görülmesinin nedeni mevcut sistemde hiç önbellekleme kullanılmamasıdır. Başka bir projede ise zaten iyi çalışan cache yapısı olduğundan farklı alanlara müdahale etmek gerekir.

WordPress için iyi bir PageSpeed skoru kaç olmalı?

PageSpeed Insights’ın performans puanı faydalı bir kontrol noktasıdır fakat tek başarı ölçütü olarak kullanılmamalı.

Sitenin gerçek kullanım sırasında ne kadar hızlı hissettirdiği, Core Web Vitals verileri ve kritik fonksiyonların düzgün çalışması daha önemlidir.

Google da iyi Core Web Vitals değerlerinin tek başına üst sıralama garantisi olmadığını açıkça belirtiyor.

Bu nedenle 99 puan almak için kullanıcı deneyimini bozacak agresif işlemler yapmak yerine dengeli bir optimizasyon tercih edilmeli.

WordPress hızlandırma SEO’ya katkı sağlar mı?

Hızlı ve kullanılabilir bir site daha iyi bir sayfa deneyimi oluşturur. Core Web Vitals da Google’ın sistemlerinin kullandığı sinyaller arasındadır. Ancak hız çalışmasını “siteyi hızlandırırsam Google’da kesin yükselirim” şeklinde değerlendirmek doğru olmaz.

SEO; içerik kalitesi, arama niyeti, site yapısı, bağlantılar, teknik erişilebilirlik ve daha birçok sinyalin birlikte değerlendirildiği bir alan.

Bu nedenle performans optimizasyonunu SEO’nun tamamı değil, sağlıklı bir web sitesinin teknik parçalarından biri olarak görmek daha doğru.

Kendi başıma yapabilir miyim, profesyonel destek ne zaman gerekir?

Görselleri küçültmek, gereksiz eklentileri kaldırmak veya temel cache ayarlarını yapmak birçok site sahibinin kendisinin gerçekleştirebileceği işlemler.

Ancak sunucu tarafında hata varsa, JavaScript optimizasyonundan sonra site bozuluyorsa, WooCommerce gibi dinamik bir altyapı kullanılıyorsa veya yapılan işlemlere rağmen performans düzelmiyorsa daha detaylı analiz gerekebilir.

Bu noktada amaç daha fazla optimizasyon eklentisi yüklemek değil, problemin kaynağını bulmak olmalı.

Ben de WordPress uzmanı olarak çalıştığım projelerde site yapısını, eklentileri ve sunucu tarafını birlikte değerlendiriyorum. Performans tarafında doğrudan destek almak istiyorsanız WordPress site hızlandırma hizmeti sayfasından çalışma kapsamını ve uyguladığım süreci inceleyebilirsiniz.