Elementor Siteyi Yavaşlatıyor mu? Ölçüm, Gerçek Nedenler ve Çözümler

PageSpeed Insights ekranında mobil skorunuz 34 yazıyor. Forumlarda ve YouTube videolarında tek bir cümle dönüyor: "Elementor şişkin, bırakın gitsin." Müşteriniz ya da patronunuz aynı soruyu soruyor: siteyi sıfırdan yazdıralım mı? Bu noktada verilecek en pahalı karar, henüz ölçmediğiniz bir sorun için haftalarca sürecek bir yeniden yazım işine girişmektir.

Gerçek şu: Elementor bedava değildir, ama tek suçlu da neredeyse hiç değildir. Tipik bir "yavaş Elementor sitesi"nde toplam gecikmenin önemli bir kısmı ağır bir çok amaçlı temadan, birbirinin üstüne yığılmış otuz eklentiden, optimize edilmemiş görsellerden ve önbelleksiz bir paylaşımlı sunucudan gelir. Elementor bu tablonun içinde en görünür bileşendir, çünkü sayfa oluşturucu olduğu için her sayfanın işaretlemesine imzasını atar — ama en görünür olan ile en pahalı olan aynı şey değildir.

Bu yazıda ne Elementor'u savunacağız ne de reklamını yapacağız. Önce yavaşlığın gerçekten nereden geldiğini ayrıştıracak bir ölçüm yöntemi kuracağız; sonra Elementor'un ürettiği yükün ne olduğunu ve hangi ayarlarla ne kadarının geri alınabileceğini somut olarak göreceğiz. En sonda da dürüst bir soruyu cevaplayacağız: hangi durumda ayarlarla uğraşmak yerine blok temaya geçmek daha akıllıca?

"Yavaş" Tam Olarak Neyin Ölçüsü?#

Tek bir skor tartışmayı bitirmez çünkü "yavaş" en az üç farklı şeyi tarif eder ve üçünün çözümü birbirinden tamamen farklıdır:

Elementor doğrudan yalnızca ikinci ve üçüncü satıra dokunur: ürettiği CSS ve JS dosyaları ile işaretlemenin derinliği. TTFB'ye etkisi dolaylı ve çoğunlukla küçüktür. Yani PageSpeed raporunuzda ana sorun "Initial server response time" ise, Elementor ayarlarıyla oynayarak kazanacağınız süre neredeyse sıfırdır — sorun barındırma ve önbellek katmanındadır.

İkinci ayrım laboratuvar ile saha verisi arasındadır. PageSpeed Insights sayfanın üst kısmında gerçek kullanıcılardan toplanan alan verisini, altında ise tek seferlik bir simülasyonu gösterir. Karar verirken üstteki veriye bakın; alttaki skor test anındaki ağ koşullarına göre yirmi puan oynayabilir. Metriklerin ne anlama geldiğini derinlemesine görmek için WordPress Core Web Vitals yazısına, testleri doğru okumak için PageSpeed Insights skorunu yükseltme yazısına bakabilirsiniz.

Yavaşlık Elementor'dan mı Geliyor? Kaynağı Ayrıştırma Yöntemi#

Bu bölümün tamamı tek bir amaca hizmet ediyor: suçlamadan önce kanıt toplamak. Dört adımı sırayla uygulayın.

1. Aynı sitede üç farklı sayfayı karşılaştırın. Elementor ile kurulmuş bir sayfa, klasik editörle yazılmış bir yazı ve mümkünse hiç içerik olmayan bir taslak sayfa. Üçünü de aynı koşullarda ölçün:

# Ham sunucu suresi: TTFB ve toplam indirme suresi
curl -o /dev/null -s -w 'TTFB: %{time_starttransfer}s | Toplam: %{time_total}s | Boyut: %{size_download} bayt\n' \
  https://ornek.com/elementor-ile-yapilmis-sayfa/

curl -o /dev/null -s -w 'TTFB: %{time_starttransfer}s | Toplam: %{time_total}s | Boyut: %{size_download} bayt\n' \
  https://ornek.com/klasik-editorle-yazilmis-yazi/

TTFB ikisinde de benzerse sorun sunucu tarafındadır ve Elementor'la ilgisi yoktur. Elementor sayfasının indirilen boyutu diğerinin birkaç katıysa, işaretleme ve varlık yükü gerçekten fark yaratıyor demektir.

2. Query Monitor ile PHP maliyetini bileşene göre dağıtın. Query Monitor eklentisini kurup yönetici olarak bir sayfayı açın; üst çubuktaki panelde sorgu sayısı, sorgu süresi ve en önemlisi bileşene göre dağılım yer alır. Burada Elementor'un yanındaki milisaniye değerini diğer eklentilerinkiyle karşılaştırın. Çoğu vakada listenin tepesinde Elementor değil, bir form eklentisi, bir çeviri katmanı ya da bir güvenlik eklentisi durur.

3. Devre dışı bırakma testini ziyaretçileri etkilemeden yapın. Health Check & Troubleshooting eklentisinin sorun giderme modu, eklentileri yalnızca sizin oturumunuz için kapatır; ziyaretçiler siteyi normal görmeye devam eder. Eklentileri teker teker geri açarak hangisinin ölçümü bozduğunu bulun. Yöntemin ayrıntısı ve tuzakları için WordPress eklenti çakışması yazısına bakın.

4. Tarayıcıda kullanılmayan kodu ölçün. Chrome DevTools'ta Ctrl+Shift+P ile komut kutusunu açıp "Coverage" yazın, kaydı başlatıp sayfayı yenileyin. Her CSS ve JS dosyasının yanında kullanılmayan yüzde görünür. Burada Elementor'un frontend.min.css dosyası ile temanızın stil dosyasını karşılaştırın; çoğu şişkin çok amaçlı temada kullanılmayan oran Elementor'unkinden yüksektir.

Dört adım bittiğinde elinizde bir tahmin değil, bir dağılım olur. Kararı ondan sonra verin.

Elementor Gerçekte Ne Kadar Yük Ekliyor?#

Elementor sayfa içeriğini normal WordPress içeriği olarak değil, _elementor_data adlı bir postmeta alanında büyük bir JSON yapısı olarak saklar. Sayfa istendiğinde bu JSON okunur, widget ağacına dönüştürülür ve HTML'e basılır. Bunun iki pratik sonucu vardır: ağır bir sayfada postmeta kaydı yüz kilobaytları bulabilir ve her istekte bu yapının işlenmesi için PHP zamanı harcanır — ki tam da bu yüzden sayfa önbelleği Elementor sitelerinde diğerlerinden daha büyük fark yaratır.

Ön yüzde ise şu varlıklar devreye girer:

Buradaki kritik nokta, listenin ilk üç satırının zorunlu, kalan dördünün ise tercih olmasıdır. Tipik bir yavaş Elementor sitesinde ikon kütüphaneleri, birkaç farklı Google Fonts ailesi ve hiç kullanılmayan widget'ların varlıkları toplam yükün önemli bir bölümünü oluşturur — ve bunların hepsi ayarlarla geri alınabilir.

CSS dosyalarının bozulduğundan şüpheleniyorsanız Elementor → Araçlar → CSS ve Veriyi Yeniden Oluştur düğmesi tüm üretilmiş dosyaları sıfırdan yazar. Tema veya global ayar değişikliğinden sonra eski stillerin inatla kalması genellikle bu adımın atlanmasından kaynaklanır.

Elementor Performans Sekmesinde Ne Açılır, Ne Kapatılır?#

Elementor 3.22 ile birlikte performansla ilgili ayarlar dağınık yerlerden toplanıp Elementor → Ayarlar → Performans sekmesinde bir araya getirildi. Bu ekran, kod yazmadan yapabileceğiniz en yüksek getirili müdahaledir.

CSS Yazdırma Yöntemi en çok yanlış anlaşılan ayardır. "Satır İçi" seçeneği stilleri doğrudan HTML'in içine gömer; ilk istekte ekstra dosya çağrısı olmaz ama her sayfa görüntülenmesinde aynı CSS tekrar tekrar indirilir ve hiçbir zaman önbelleğe alınmaz. "Harici Dosya" ise stilleri wp-content/uploads/elementor/css/ altına yazar; ilk ziyarette bir istek daha yapılır, sonraki tüm sayfalarda o dosya tarayıcı önbelleğinden gelir. Birden fazla sayfası olan hemen her site için doğru seçim harici dosyadır.

Ayarları komut satırından doğrulamak isterseniz:

# Aktif CSS yazdirma yontemi
wp option get elementor_css_print_method

# Harici dosyaya cek
wp option update elementor_css_print_method external

# Acik olan deneysel ozellikleri listele
wp option list --search='elementor_experiment*' --format=table

Bu ayarları değiştirdikten sonra hem Elementor'un CSS'ini yeniden oluşturun hem de sayfa önbelleğinizi temizleyin; aksi hâlde ölçüm eski çıktıyı gösterir ve "hiçbir şey değişmedi" sonucuna varırsınız.

Kullanılmayan Widget ve Özellikleri Kapatmak#

Elementor kurulumda onlarca widget kaydeder. Bunların çoğunu hiç kullanmazsınız, ama kayıtlı oldukları için editör tarafında bellek ve yükleme maliyeti yaratırlar. Ön yüzde "Geliştirilmiş Varlık Yükleme" açıkken kullanılmayan widget'ın CSS/JS'i zaten gelmez; asıl kazanç editörün ağırlığında ve bakım yüzeyinde olur.

Widget'ları koddan kaldırmak isterseniz:

// mu-plugins icine koyun: kullanilmayan widget'lari kayittan dusur
add_action( 'elementor/widgets/register', function ( $widgets_manager ) {
    $kaldirilacaklar = array(
        'testimonial',
        'counter',
        'progress',
        'sound-cloud',
    );

    foreach ( $kaldirilacaklar as $widget ) {
        $widgets_manager->unregister( $widget );
    }
}, 20 );

Bu kodu uygulamadan önce bir uyarı: kaldırdığınız bir widget zaten bir sayfada kullanılıyorsa o alan boş kalır. Önce sitede aranan widget'ın gerçekten hiç kullanılmadığını doğrulayın:

-- Belirli bir widget tipini kullanan sayfa var mi?
SELECT p.ID, p.post_title
FROM wp_postmeta pm
JOIN wp_posts p ON p.ID = pm.post_id
WHERE pm.meta_key = '_elementor_data'
  AND pm.meta_value LIKE '%"widgetType":"testimonial"%';

Aynı mantık ikon kütüphaneleri için de geçerlidir. Font Awesome'ı hiç kullanmıyorsanız, Elementor'un onu yüklemesini engellemek tek başına birkaç yüz kilobayt ve iki ağ isteği kazandırır. Google Fonts tarafında ise en temiz yol, kullandığınız aile sayısını ikiye ve ağırlık sayısını üçe indirmektir; on farklı ağırlık yüklemek, hangi barındırma yöntemini seçerseniz seçin pahalıdır.

DOM Şişmesi Gerçek mi, Ne Kadar Önemli?#

Elementor'un en sık eleştirilen yanı ürettiği iç içe div katmanlarıdır. Eski sürümlerdeki bölüm-sütun yapısında tek bir widget'a ulaşmak için altı yedi sarmalayıcıdan geçmek gerekiyordu. Bu eleştiri eski sürümler için haklıydı; ancak esnek kutu (flexbox) tabanlı konteyner yapısı ve ardından gelen optimize edilmiş işaretleme seçeneği bu derinliği ciddi biçimde azalttı.

Kendi sitenizde ölçün — tahmin etmeyin. Tarayıcı konsolunda:

// Toplam dugum sayisi
document.querySelectorAll('*').length;

// En derin ic ice gecmis dugumun derinligi
Math.max(...[...document.querySelectorAll('*')].map(el => {
  let d = 0, n = el;
  while (n.parentElement) { d++; n = n.parentElement; }
  return d;
}));

Lighthouse, toplam düğüm sayısı 800'ü aştığında uyarmaya, 1.400'ü aştığında ciddi bir sorun olarak işaretlemeye başlar. Derinlik için eşik 32'dir. Ölçümünüz bunların altındaysa DOM şişmesi sizin sorununuz değildir ve enerjinizi başka yere harcamanız gerekir.

Rakamlar yüksek çıkıyorsa üç somut hamle var. Birincisi, eski bölüm-sütun yapısındaki sayfaları konteyner yapısına taşımak — yeni tasarımlarda mutlaka konteyner kullanın. İkincisi, tek bir widget'ı ortalamak için üç iç içe sütun açma alışkanlığından vazgeçmek; aynı hizalama tek konteynerde yapılabiliyor. Üçüncüsü, "optimize edilmiş işaretleme" seçeneğini açmak — ancak bunu önce bir kopya sitede deneyin, çünkü sarmalayıcı sayısı azaldığında o sarmalayıcılara yazılmış özel CSS kuralları hedefini kaybedebilir.

Elementor'a Rağmen Hızlanmak: Sunucu ve Önbellek Katmanı#

Elementor sitelerinde en büyük tek kazanç genellikle Elementor ayarlarından değil, önündeki katmandan gelir. Sebep basit: Elementor her istekte JSON'u işleyip HTML üretiyorsa, sayfa önbelleği bu işi ziyaretçilerin ezici çoğunluğu için tamamen ortadan kaldırır. Önbellekli bir Elementor sayfası ile statik bir HTML dosyası arasındaki sunucu maliyeti farkı neredeyse sıfıra iner.

Öncelik sırasıyla:

1. Sayfa önbelleği. Sunucunuzda LiteSpeed varsa yerleşik çözümü kullanın; yoksa bir önbellek eklentisi kurun. Ayrıntılar için LiteSpeed Cache ve WordPress önbellek rehberi yazılarına bakın.
2. PHP sürümü ve OPcache. Güncel bir PHP sürümü, Elementor'un ağır render döngüsünde ölçülebilir fark yaratır. PHP OPcache açık değilse her istekte tüm PHP dosyaları yeniden derlenir.
3. Nesne önbelleği. Redis veya Memcached, postmeta okumalarını veritabanından RAM'e taşır — Elementor'un veri modeli tam olarak postmeta ağırlıklı olduğu için buradan beklenenden fazla kazanç çıkar.
4. Görseller. Sayfa ağırlığının çoğu hâlâ görsellerdedir ve bu Elementor'un suçu değildir.

Bu dört maddeyi yaptıktan sonra ölçümü tekrarlayın. Çoğu vakada skor tablosu bu aşamada tanınmayacak kadar değişir ve "Elementor'u atalım mı" sorusu kendiliğinden gündemden düşer.

Ne Zaman Blok Temaya Geçmek Daha Doğru?#

Dürüst cevap: her zaman değil, ama bazen kesinlikle. Karar teknik değil, bağlamsal bir karardır.

Geçişin gizli maliyeti şudur: Elementor ile üretilmiş bir sayfanın içeriği _elementor_data içinde yaşar. Eklentiyi devre dışı bıraktığınızda o sayfalarda düz metin ve kısa kod artıkları kalır — otomatik bir dönüştürücü yoktur. Yani "geçiş" pratikte sayfaları yeniden kurmak demektir. Blok temaların nasıl çalıştığını ve neyi yerine koyduğunu WordPress FSE blok tema yazısında inceleyip kararı ondan sonra verin.

Kalmaya karar verdiyseniz, Elementor'u verimli kullanmanın kendi disiplinleri var; global renk ve tipografi kullanımından şablon mantığına kadar temel pratikler için Elementor kullanımı yazısı iyi bir başlangıçtır.

Sıkça Sorulan Sorular#

Elementor gerçekten diğer sayfa oluşturuculardan yavaş mı?#

Aralarındaki fark, çoğu sitede tema ve eklenti seçiminin yarattığı farktan küçüktür. Sayfa oluşturucuların hepsi görsel esneklik karşılığında bir miktar işaretleme ve varlık yükü ekler. Bir oluşturucudan diğerine geçmek genellikle beklenen kazancı vermez; asıl fark, önbellek, barındırma ve görsel optimizasyonu gibi katmanlarda ortaya çıkar. Geçiş kararını bir kıyaslama tablosuna değil, kendi ölçümünüze dayandırın.

CSS yazdırma yöntemini harici dosya yapmak neden bu kadar önemli?#

Satır içi seçenekte Elementor stilleri her sayfanın HTML'ine gömer. Ziyaretçi beş sayfa gezerse aynı CSS beş kez indirilir ve hiçbir zaman önbelleğe alınmaz. Harici dosyada ise stiller bir kez indirilir, sonraki tüm sayfalarda tarayıcı önbelleğinden gelir ve HTML belgesi belirgin biçimde küçülür. Tek sayfalık siteler dışında doğru tercih harici dosyadır.

Kullanmadığım widget'ları kapatırsam sayfam bozulur mu?#

Kayıttan düşürdüğünüz bir widget zaten bir sayfada kullanılıyorsa o alan boş kalır ve editörde de görünmez. Bu yüzden kaldırmadan önce ilgili widget tipini veritabanında aratıp gerçekten hiç kullanılmadığını doğrulayın. Emin değilseniz, ön yüz kazancının büyük kısmını zaten sağlayan geliştirilmiş varlık yükleme ayarıyla yetinin.

Optimize edilmiş DOM çıktısını açmak risk taşır mı?#

Az ama gerçek bir risk taşır. Bu seçenek üretilen sarmalayıcı katmanlarını azaltır; siz veya bir eklenti o sarmalayıcılara özel CSS kuralları yazdıysanız seçiciler hedefini kaybedebilir. Özel CSS'i az olan sitelerde sorunsuz çalışır. Yoğun özelleştirme yaptıysanız önce bir kopya sitede açın, kritik sayfaları gözle kontrol edin ve ardından canlıya alın.

Elementor'u kaldırırsam sayfalarım ne olur?#

İçerik _elementor_data alanında saklandığı için eklenti devre dışı kaldığında sayfalar düz metin ve kısa kod artıklarına döner. Otomatik bir dönüştürme yolu yoktur; sayfaları hedef sistemde yeniden kurmanız gerekir. Bu yüzden geçiş bir ayar değişikliği değil, planlanması gereken bir projedir. Kaldırmadan önce mutlaka tam yedek alın ve önce bir kopya ortamda deneyin.

PageSpeed skorum düşük ama site bana hızlı geliyor, hangisine güveneyim?#

Kendi izleniminize değil, gerçek kullanıcı verisine güvenin. PageSpeed raporunun üst kısmındaki alan verisi son 28 günün gerçek ziyaretçi ölçümlerini gösterir; alttaki simülasyon ise kısıtlı bir mobil cihazı taklit eder ve test anındaki koşullara göre oynar. Siz siteyi büyük ihtimalle hızlı bir bağlantıdan ve dolu bir önbellekle açıyorsunuz, bu yüzden algınız iyimser tarafta kalır.

Kapanış#

"Elementor siteyi yavaşlatıyor mu?" sorusunun tek kelimelik bir cevabı yok, ama tekrarlanabilir bir yöntemi var: önce hangi metriğin bozuk olduğunu belirleyin, sonra yükü bileşenlere dağıtın, ardından Performans sekmesindeki ayarları ve önbellek katmanını devreye alın. Bu üç adımdan sonra elinizde kalan gecikme gerçekten Elementor'un fiyatıdır — ve çoğu sitede o fiyat, sanılandan çok daha küçüktür.

Ölçüm sonuçlarınız hâlâ kötüyse sırayı doğru kurun: barındırma ve önbellek, sonra görseller, sonra widget ve font disiplini, en son işaretleme derinliği. Sıfırdan yeniden yazmak bu listenin en sonunda gelen ve en pahalı olan seçenektir; onu ancak diğerlerini denedikten sonra masaya koyun.