DOM boyutunu optimize edin uyarısı nasıl giderilir?
Sayfada çok fazla öğe var. Bunun neden yavaşlattığı, hangi yapıların şişirdiği ve nasıl sadeleştirileceği.
Uyarı ne diyor?
Rapordaki başlık: "DOM boyutunu optimize edin". Yanında sayfadaki toplam öğe sayısı yazılı.
DOM, tarayıcının sayfayı oluştururken kurduğu öğe ağacı. Her başlık, paragraf, görsel, kap ve düğme bu ağaçta bir düğüm.
Ağaç büyüdükçe tarayıcının yaptığı iş artıyor: her öğe için stil hesaplanıyor, konum belirleniyor, çizim yapılıyor.
Bir değişiklik olduğunda — kaydırma, tıklama, animasyon — bu hesaplamaların bir kısmı yeniden yapılıyor. Ağaç büyükse her etkileşim yavaşlıyor.
Neden önemli?
Bu uyarının etkisi ilk yüklemede değil etkileşimde görünüyor.
Belirtileri:
- Sayfa kaydırırken takılıyor
- Menü açılırken gecikiyor
- Tıklamalara geç tepki veriliyor
- Mobilde belirgin şekilde daha kötü
Bu, tıklamaya ne kadar sürede tepki verildiğini ölçen değere yansıyor. Ölçünün tanımı web.dev üzerinde yayımlanıyor.
Düşük güçlü cihazlarda etki çok daha belirgin. Masaüstünde sorun görünmeyen bir sayfa, orta seviye bir telefonda kullanılamaz hâle gelebiliyor.
Ölçülerin tanımı ve eşikleri web.dev üzerinde yayımlanıyor.
En yaygın kaynak — sayfa kurucular
Sahada gördüğümüz şişmenin büyük kısmı buradan çıkıyor.
Sayfa kurucu eklentiler esneklik sağlamak için her öğeyi birkaç katman kabın içine koyuyor: bölüm kabı, satır kabı, sütun kabı, öğe kabı, iç kap.
Tek bir görsel için altı yedi seviye iç içe geçmiş kap oluşabiliyor ve bunların hiçbiri görünür bir işe yaramıyor.
Sonuç: elle yazıldığında 200 öğe olacak bir sayfa, sayfa kurucuyla 1.500 öğeye çıkabiliyor.
Bu, sayfa kurucuların bilinen bir maliyeti ve tema seçimiyle birlikte değerlendirilmesi gerekiyor; konuyu tema seçimi yazısında ayrıca ele aldık.
İpucu — Sayfanızın öğe sayısını görmek için tarayıcının konsolunda tek satırlık bir sorgu yeterli. Farklı sayfa tiplerini karşılaştırdığınızda hangi şablonun şiştiği hemen görünüyor.
İkinci kaynak — uzun listeler
Yüzlerce ürünün, yorumun ya da liste öğesinin tek sayfada gösterilmesi.
Her öğe kendi içinde birkaç düğüm taşıyor: görsel, başlık, fiyat, düğme. Yüz öğe kolayca binlerce düğüme çıkıyor.
Çözüm sayfalama. Kullanıcı deneyimi açısından da daha iyi: kimse yüz ürünü tek sayfada taramıyor.
Sonsuz kaydırma bu sorunu çözmüyor, erteliyor — kullanıcı kaydırdıkça DOM büyümeye devam ediyor. Ayrıca taranabilirlik sorunu da üretiyor; tembel yükleme yazısında değindik.
Üçüncü kaynak — gizlenen içerik
Bu, en çok gözden kaçan kalem.
CSS ile gizlenen bir blok HTML'de duruyor. Görünmüyor ama DOM'da yer kaplıyor ve tarayıcı onun için de hesaplama yapıyor.
Sık görülen örnekler:
- Mobilde gizlenen masaüstü menüsü ve tersi
- Açılmadıkça görünmeyen sekme içerikleri
- Modal pencereler
- Kullanılmayan tema bölümleri
Bunlardan bir kısmı gerekli — sekme içeriğinin HTML'de bulunması indekslenmesi açısından önemli. Ama kullanılmayan tema bölümlerinin sayfada durmasının bir gerekçesi yok.
Kaynak | Çözüm | Zorluk |
|---|---|---|
Sayfa kurucu katmanları | Sade yapıya geçmek | Yüksek |
Uzun listeler | Sayfalama | Orta |
Gizlenen tema bölümleri | Kapatmak | Düşük |
Modal ve açılır pencereler | İhtiyaç anında oluşturmak | Orta |
Gereksiz kap katmanları | Şablon sadeleştirme | Orta |
Kaç öğe fazla?
Rapor bir eşik belirtiyor ve aşıldığında uyarı çıkıyor.
Ama asıl gösterge sayı değil belirti. Sayfa kaydırırken takılıyorsa, menü geç açılıyorsa, tıklamalara gecikmeli tepki veriliyorsa DOM boyutu gerçekten sorun demektir.
Eşiğin biraz üstünde olup hiçbir belirti göstermeyen sayfalar için bu uyarı düşük öncelikli kalıyor.
Ölçüt şu: saha verisinde tıklama tepkisi ölçüsü kırmızı mı? Değilse uyarı beklemeye alınabilir.
Nasıl sadeleştirilir?
Kazanç sırasına göre.
1. Kullanılmayan tema bölümlerini kapatın. Tema ayarlarında kapatılabiliyorsa öğeler hiç oluşmuyor.
2. Uzun listeleri sayfalayın. Hem DOM hem kullanıcı deneyimi kazanıyor.
3. Modal ve açılır pencereleri ihtiyaç anında oluşturun. Sayfa açılırken var olmalarına gerek yok.
4. Şablonlardaki gereksiz kap katmanlarını azaltın. Geliştirici işi ama kalıcı kazanç.
5. Sayfa kurucudan çıkmayı değerlendirin. En büyük kazanç ama en büyük emek.
Beşinci madde bir tasarım kararı, teknik bir ayar değil. Ve içerik o eklentinin biçimine bağlıysa taşıma maliyeti yüksek oluyor.
Dikkat — DOM sadeleştirmek için içeriği HTML'den kaldırmayın. Mobilde gizlenen içerik indeksleniyor, kaldırılan içerik indekslenmiyor. Bu ayrımı mobil öncelikli indeksleme yazısında anlattık.
Ölçüm
Değişiklik öncesi ve sonrası karşılaştırma için üç ölçü:
Toplam öğe sayısı. Tarayıcı konsolundan tek satırla alınabiliyor.
En derin iç içe geçme. Rapor bunu da gösteriyor; derinlik de hesaplama maliyetini artırıyor.
Etkileşim gecikmesi. Asıl önemli olan. Saha verisinde takip ediliyor.
Üçüncüsü düzelmiyorsa DOM boyutu sizin sorununuz değildi demektir; sebep başka yerde.
Örnek senaryo — Bir kurumsal sitede ana sayfa 2.400 öğe taşıyor ve mobilde kaydırma takılıyor. İnceleme: sayfa kurucu her bölüm için beş katman kap oluşturuyor ve temanın kullanılmayan yedi bölümü hâlâ yükleniyor. Kullanılmayan bölümler kapatılıyor, iki bölüm sade HTML'e çevriliyor. Öğe sayısı 900'e iniyor ve kaydırma sorunu ortadan kalkıyor.
Ne zaman uğraşmaya değmez?
Üç durumda bu uyarı beklemeye alınabilir.
Belirti yoksa. Sayfa akıcı çalışıyorsa ve saha verisinde etkileşim ölçüsü yeşilse, sayı tek başına bir sorun değil.
Sayfa nadiren ziyaret ediliyorsa. Yılda birkaç kez açılan bir sayfa için sadeleştirme emeği karşılığını vermiyor.
Çözüm sayfa kurucudan çıkmayı gerektiriyorsa ve buna hazır değilseniz. Yarım bir müdahale, içeriği bozma riski taşıyor.
Öncelik sırasının nasıl kurulacağını PageSpeed uyarıları yazısında tablo hâlinde verdik.
Tablo ve liste yapıları
Uzun tablolar sık atlanan bir şişme kaynağı.
Her hücre bir düğüm. Yirmi satırlık ve altı sütunlu bir tablo, yalnızca hücrelerle 120 düğüm demek — üstüne kap katmanları ekleniyor.
Veri tabloları gerekliyse çözüm sayfalama ya da yalnızca görünür satırların oluşturulması.
Ama asıl soru şu: bu tablo gerçekten tablo olmalı mı? Karşılaştırma için evet; sıralı bilgi için liste, üç maddelik bilgi için paragraf daha az düğüm üretiyor.
Simgeler ve vektörler
Sayfaya gömülen vektör simgeler, göründüklerinden çok daha fazla düğüm taşıyabiliyor. Karmaşık bir simge onlarca yol öğesinden oluşuyor.
Onlarca simge kullanan bir arayüzde bu toplam belirgin hâle geliyor.
Çözümler:
Simgeleri sadeleştirmek. Karmaşık çizimler yerine basit formlar.
Tekrar eden simgeleri bir kez tanımlayıp yeniden kullanmak. Aynı simge on yerde kullanılıyorsa on kez tanımlanmasına gerek yok.
Gerçekten gerekli olmayanları kaldırmak. Her metnin yanında simge olması bir gereklilik değil.
Kendi sitemizde listeleme kartlarının görselleri satır içi vektör olarak çiziliyor; sade tutulmalarının bir sebebi de bu.
Sonuç — DOM boyutu uyarısı, sayfanın ilk açılışından çok kullanım akıcılığını etkiliyor. Çözümü genellikle teknik bir ayar değil bir yapı kararı: sayfa kurucudan çıkmak ya da uzun listeleri bölmek.
Şablon sadeleştirme ve hız düzeltmelerini teknik SEO kapsamında yapıyoruz; yeni bir sitede sade bir yapı baştan kuruluyor — kurumsal web tasarım ve web sitesi geliştirme sayfalarında anlattık.
