Elementor vs Gutenberg: Performans Farkı Gerçekte Ne Kadar?

DOM boyutu ve katlama derinliği

Elementor bir sayfa ürettiğinde, her içerik bloğu birden fazla sarmalayıcı div katmanıyla çevrilir. elementor-section, elementor-column ve elementor-widget katmanları iç içe geçer; buna her widget'ın kendi iç yapısı da eklenir. Sade bir metin-görsel bloğu için Elementor'un ürettiği DOM düğümü sayısı, Gutenberg'in ürettiğine kıyasla çoğu durumda iki ila üç kat daha fazladır. Üstelik bu fark sayfa karmaşıklığıyla birlikte büyür: her ek bölüm ve widget, katmanları hızla çarpar.

Gutenberg, her bloğu genellikle tek bir anlamsal etiket ya da tek bir div ile sarar. Düz metin bloğu <p> olur, görsel bloğu <figure> olur, sütun düzeni ise iki katmanlı bir yapıda çözülür. Blok düzenleyici özellikle içerik ağırlıklı sayfalarda minimal DOM çıktısı üretir; bu durum tarayıcının layout hesaplama süresini doğrudan etkiler. Fazladan bir sarmalayıcı katmanı, seçici hesaplama ve stil uygulama maliyetinin birikmesine yol açar.

Dom boyutu tek başına performansı belirlemez. Ama ağır DOM, uzun layout süresi ve artan bellek kullanımı demektir; bu etki özellikle orta segment Android cihazlarda ölçülebilir hale gelir. Chrome, sayfa başına 1500 düğümü aşan DOM'lar için kendi denetim araçlarında uyarı verir. Elementor tabanlı zengin sayfalarda bu eşiğin kolayca aşıldığı görülür; katlama derinliği de önem taşır çünkü derin iç içe geçme, tarayıcının CSS seçici hesaplama maliyetini birikimli olarak artırır.

Sayfa başına CSS yükü ve render-blocking riski

Elementor varsayılan kurulumda tüm widget CSS'ini tek bir pakette sunar; sayfada hangi widget'ların kullanıldığına bakılmaz. Eski sürümlerde bu yaklaşım her sayfa için 200-300 KB arasında sıkıştırılmamış CSS yüküyle sonuçlanıyordu. Sonraki sürümlerde tanıtılan "Improved Asset Loading" özelliği yalnızca o sayfada kullanılan widget'ların CSS'ini yükler ve bu önemli bir iyileştirmedir. Ancak özelliğin etkin olup olmadığı Elementor sürümüne ve manuel etkinleştirme tercihine bağlıdır; her kurulumda kendiliğinden devreye girmez.

Gutenberg'in ürettiği CSS dosyaları blok tipine göre bölünmüş şekilde gelir. Blok kitaplığının ana stil dosyası nispeten hafiftir ve sayfadaki blok çeşitliliğine göre şekillenir. Tema tarafından kontrol edilen stillere güvenildiğinde Gutenberg sayfası gereksiz CSS taşımaz; bu yapı özellikle tema geliştiricinin kendi stil katmanını tam anlamıyla denetleyebildiği projelerde belirgindir.

Her iki editörün ürettiği stiller head'e eklenir ve ilk boyamayı geciktirebilir. Render-blocking CSS, FCP üzerinde doğrudan etkilidir. TTFB düşük ama FCP yüksek olduğunda render zincirine bakma yöntemi, CSS kaynaklı gecikmeleri izole etmek ve hangi kaynağın boyamayı engellediğini tespit etmek için kullanılabilir.

JavaScript ağırlığı ve ana iş parçacığı meşguliyeti

Elementor, kullanıcı tarafında çalışan JavaScript yüklerken bu kod yalnızca animasyon ve widget etkileşimleriyle sınırlı değildir. Waypoint kütüphanesi, jQuery bağımlılıkları ve editöre özgü başlatma mantığı da bu paketin parçasını oluşturur. Sayfada kullanılan widget tipine ve etkin Elementor eklentilerine göre frontend JavaScript boyutu geniş bir aralıkta değişir: sade sayfalar daha az yük taşır, görsel animasyon ve kaydırma efektleri içeren sayfalar ise belirgin biçimde daha fazla.

Gutenberg'in frontend'e bıraktığı JavaScript izi çok daha incedir. Blok düzenleyici varsayılan olarak içerik bloğu için JavaScript üretmez; yalnızca etkileşimli bloklar, arama ya da yorum bloğu gibi, küçük script parçaları gerektirir. Tema tarafında ek JavaScript yoksa bir Gutenberg sayfası, ana iş parçacığını Elementor tabanlı muadiline kıyasla belirgin biçimde daha az meşgul eder. Durum yalındır.

Ana iş parçacığı meşguliyeti INP (Interaction to Next Paint) puanını doğrudan etkiler. Uzun görevler (Long Tasks) kuyruğunda kullanıcı etkileşimi geldiğinde, tarayıcı yanıt vermeyi erteler ve bu gecikme kullanıcı tarafında hissedilir. Elementor tabanlı sayfalarda sayfa yüklenmesinin ilk birkaç saniyesinde birden fazla uzun görev görülmesi yaygındır; bu görevler Chrome DevTools'un Performance panelinde kırmızıyla işaretlenir ve toplam engelleme süresini (TBT) yükseltir.

LCP üzerindeki doğrudan etki

LCP görseli çoğunlukla bir Elementor ya da Gutenberg bloğunun içindedir. Editörün bu noktadaki etkisi iki yönlüdür: görselin öncelik sırası ve tarayıcı tarafından keşfedilme zamanı.

Elementor hero görselini genellikle bir img etiketi olarak işler; bu sayede tarayıcının preload scanner'ı görseli erken keşfeder. Fakat Elementor'un ürettiği img etiketleri yükleme önceliği açısından her zaman doğru yapılandırılmaz. fetchpriority="high" niteliği eksik olduğunda, tarayıcı LCP görselini düşük öncelikli diğer varlıklarla aynı kuyrukta işler ve bu durum LCP süresini uzatır. Gutenberg son sürümlerinde görsel bloğundaki LCP adayı görsele bu niteliği otomatik olarak ekler; bu küçük fark, LCP süresinde ölçülebilir iyileşmeye yol açabilir.

Arka plan görseli olarak yerleştirilen hero bölümlerinde tablo değişir: CSS background-image preload scanner tarafından keşfedilmez. Elementor'da hero bölümünü div arka planı olarak tanımlamak yaygın bir pratiktir ve bu yaklaşım LCP gecikmesini artırır. LCP görselini bulma ve gecikmesinin kaynağını tespit etme yöntemi, img etiketi ile arka plan görselinin tarayıcı tarafından nasıl farklı ele alındığını ve her iki durumda ölçümün nasıl yapılacağını açıklar.

CrUX dağılımı editör farkını yansıtıyor mu?

Chrome Kullanıcı Deneyimi Raporu (CrUX), gerçek kullanıcı cihazlarından toplanan LCP, FCP ve INP dağılımlarını içerir. Burada bir editörü diğeriyle doğrudan karşılaştıran yayınlanmış ve kontrollü bir CrUX veri seti bulunmaz; çünkü CrUX domain başına raporlar ve domain'deki tüm değişkenleri (tema, eklenti sayısı, hosting, içerik tipi ve hacmi) tek bir havuzda birleştirir. Bu nedenle ham CrUX verisi üzerinden "Elementor siteleri X ms daha yavaştır" gibi kesin bir çıkarım yapmak metodolojik açıdan doğru değildir.

HTTP Archive'ın toplu Lighthouse ve CrUX tabanlı analizleri belirli eğilimler ortaya koyar: Elementor yoğun kullanan sitelerin LCP medyanı, Gutenberg ağırlıklı sitelerin medyanına kıyasla daha uzun çıkar. Ancak bu fark, söz konusu sitelerin içerik zenginliği ve eklenti yoğunluğuyla güçlü biçimde ilişkilidir. Elementor'u seçen projeler çoğunlukla görsel açıdan zengin, widget doluyken Gutenberg'i seçen projeler içerik odaklı olur. Bunun editörün teknik etkisinden ayrıştırılması gerekir.

Gerçekten anlamlı bir karşılaştırma şunu gerektirir: aynı içerik, aynı tema, aynı hosting ortamı ve yalnızca editörün değiştiği iki sayfa. Bu kontrollu ortamda DOM ve JavaScript farkının LCP'ye katkısı gözlemlenebilir hale gelir; katkının büyüklüğü sayfa karmaşıklığına, widget yoğunluğuna ve editör yapılandırmasına göre değişir. Kontrol değişkenleri sabitlendiğinde fark gerçektir; ama aynı sayfanın hosting ve görsel kalitesiyle olan ilişkisi çoğunlukla daha belirleyicidir.

Gutenberg çıktısının neden daha az katmanlı kaldığı

Gutenberg, WordPress'in temel düzenleyicisi olarak çekirdekle birlikte gelişir. Blok API'sinin tasarımı, her bloğun minimum HTML çıktısı üretmesine yönelik bir yaklaşıma dayanır; render tarafı PHP'dir ve editör arayüzü ile frontend çıktısı birbirinden ayrılmıştır. Bu mimari ayrım, editör katmanının frontend çıktısına sızmasını önler. Gutenberg'de gördüğünüz HTML, düzenleyicinin kendisini yansıtmaz; yalnızca içeriği yansıtır.

Elementor farklı bir mimariyle çalışır. Editör widget'larının büyük bölümü hem backend render hem de frontend JavaScript gerektirir; çünkü editör güçlü ve esnek tasarım araçları sunmak için bu yaklaşımı benimser. Sürükle-bırak mantığı, anlık ön izleme ve yaygın widget kütüphanesi bu mimarinin ürünüdür. Esnekliğin bedeli ise DOM katmanları ve frontend JavaScript yüküdür; bu bir tasarım tercihidir, bir hata değildir. Tercih edilmeden önce fiyatının bilinmesi yeterlidir.

Elementor'un performans maliyeti hangi koşullarda azalır?

Elementor'un performans maliyeti sabit değildir; belirli yapılandırmalar altında önemli ölçüde azalır ya da pratik açıdan önemsizleşir.

Tam sayfa cache etkin olduğunda, Elementor'un ürettiği HTML önbelleğe alınır ve her istek için PHP işleme yükü ortadan kalkar. TTFB farkı kapanır ve sunucu yanıt süresi Gutenberg ile benzer düzeye iner. Improved Asset Loading özelliği de etkinleştirilirse CSS yükü yalnızca sayfada kullanılan widget'larla sınırlı kalır. Bazı widget'lar için JavaScript yüklemesi defer ya da ihtiyaç anında tetiklenme (on demand) olarak yapılandırılabilir; bu yöntem, sayfa yüklenmesinin kritik aşamasını uzatan uzun görevleri daha sonraki bir zaman dilimine iter.

Maliyetin artığı durumlar da belirgindir: birden fazla Elementor eklentisi widget kaydettikçe CSS havuzu büyür; animasyon ve paralaks efektleri içeren widget'lar her zaman JavaScript gerektirir; çok sayıda global widget kullanan yapılarda senkronizasyon yükü artar. Bu koşulların herhangi birinde beklenmedik bir yavaşlama yaşandığında, tanılama sırasını doğru kurmak zaman kazandırır: semptomdan nedene giden yolu kestirmeye çalışmak yerine önce TTFB ve render zincirini ayırt etmek gerekir.

Hangi durumda Gutenberg, hangi durumda Elementor?

Gutenberg şu durumlarda net avantaj sağlar: metin ve görsel ağırlıklı içerik sayfaları, blog ve haber siteleri, tema tarafında tanımlanmış bileşenlere dayanan kurumsal siteler ve Core Web Vitals puanlarına hassas e-ticaret kategori ya da ürün sayfaları. Bu tür projelerde geliştirici ya da tema tasarımcısı bileşenleri PHP ile yazıp yönetiyorsa, Gutenberg minimal HTML çıktısı ve sıfır fazla JavaScript ile ideal bir taban oluşturur.

Elementor şu durumlarda tercih edilebilir: bağımsız landing page'ler, görsel ağırlıklı kampanya sayfaları, teknik ekip desteği olmayan pazarlama ekiplerinin yönettiği projeler ve sürükle-bırak esnekliğinin ekip hızını belirleyici ölçüde artırdığı durumlar. Bu koşullarda cache ve varlık yükleme optimizasyonları doğru kurgulandığında performans farkı pratikte önemsizleşebilir. WordPress performans optimizasyonu için başlangıç noktası belirlenirken editör seçiminden önce hosting kalitesi, cache katmanı ve görsel sıkıştırma gibi değişkenlerin gözden geçirilmesi çoğu zaman daha büyük kazanımlar sağlar.

Kararı karmaşıklaştıran bir durum da vardır: aynı sitede iki editörün bir arada kullanılması. Kimi projeler blog içeriklerini Gutenberg ile, landing page'leri Elementor ile oluşturur. Bu yaklaşım mümkündür; ancak yönetim karmaşıklığı ve iki editörün CSS ile JavaScript varlıklarının her sayfada birlikte yüklenmesi riski değerlendirilmelidir.