Bu Vue 3 yönetici arayüzü performans kontrol listesiyle virtualizasyon, debounce arama, memoize edilmiş bileşenler ve daha iyi yükleme durumlarıyla ağır listeleri hızlandırın.
Kullanıcılar nadiren, "bu bileşen verimsiz" der. Bunun yerine ekran yapışkan hisseder: kaydırma takılır, yazarken gecikme olur ve tıklamalar bir ritim gecikmeli gerçekleşir. Veri doğru olsa bile bu gecikme insanların tereddüt etmesine neden olur. Araca güvenleri azalır.
Yönetici arayüzleri hızla ağırlaşır çünkü listeler "sadece liste" değildir. Tek bir tablo binlerce satır, çok sayıda sütun ve rozeti, menüleri, avatarları, ipuçlarını ve satır içi düzenleyicileri olan özel hücreler içerebilir. Sıralama, çoklu filtreler ve canlı arama ekleyin; sayfa her küçük değişiklikte çok iş yapmaya başlar.
İnsanların genellikle ilk fark ettiği şey basittir: kaydırma kareleri düşürür, arama parmakların gerisinde kalır, satır menüleri yavaş açılır, toplu seçim donar ve yükleme durumları yanıp söner veya sayfayı sıfırlar.
İçeride desen de basittir: çok fazla şey çok sık yeniden render ediliyor. Bir tuş vuruşu filtrelemeyi tetikler, filtreleme tablo güncellemesi tetikler ve her satır hücrelerini yeniden oluşturur. Eğer her satır ucuzsa bununla idare edersiniz. Eğer her satır neredeyse mini bir uygulama ise, her seferinde bunun bedelini ödersiniz.
Bir Vue 3 yönetici arayüzü performans kontrol listesi benchmark kazanmakla ilgili değildir. Amaç yazmanın akıcı kalması, kaydırmanın sabit olması, tıklamaların hızlı hissettirmesi ve ilerlemenin kullanıcıyı bölmeden görünür olmasıdır.
İyi haber: küçük değişiklikler genelde büyük yeniden yazımlardan daha etkili olur. Daha az satır render edin (virtualizasyon), tuş vuruşu başına yapılan işi azaltın (debounce), pahalı hücrelerin yeniden çalışmamasını sağlayın (memoizasyon) ve sayfanın sıçramamasını sağlayan yükleme durumları tasarlayın.
Bir baz çizgisi olmadan ayar yapmak, yanlış şeyi "düzeltmeyi" kolaylaştırır. Yavaş bir yönetici ekranı seçin (kullanıcı tablosu, destek kuyruğu, sipariş listesi) ve hissedebileceğiniz bir hedef tanımlayın: hızlı kaydırma ve asla gecikmeyen bir arama girişi.
Yavaşlamayı yeniden üretmekle başlayın, sonra profilleyin.
Tarayıcı Performance panelinde kısa bir oturum kaydedin: listeyi yükleyin, birkaç saniye hızlıca kaydırın, sonra aramaya yazın. Ana iş parçacığında uzun görevler ve hiçbir şey yeni olmaması gerekirken tekrarlayan layout/paint işlerine bakın.
Ardından Vue Devtools'u açın ve gerçekten neyin yeniden render olduğunu kontrol edin. Bir tuş vuruşu tüm tabloyu, filtreleri ve sayfa başlığını yeniden render ediyorsa, bu genelde giriş gecikmesini açıklar.
Aşağıdaki birkaç sayıyı takip edin ki daha sonra iyileşmeleri doğrulayabilesiniz:
Son olarak darboğazın nerede olduğunu doğrulayın. Hızlı bir test, ağ gürültüsünü azaltmaktır. Eğer UI önbellekli verilerle bile takılıyorsa, sorun çoğunlukla render’dadır. Eğer UI akıcı ama sonuçlar geç geliyorsa, ağ süresine, sorgu boyutuna ve sunucu tarafı filtrelemeye odaklanın.
Virtualizasyon, bir yönetici ekranı yüzlerce veya binlerce satırı aynı anda render ettiğinde genellikle en büyük kazanımı verir. Her satırı DOM'a koymak yerine yalnızca görünürde olanları (ve küçük bir tamponu) render edersiniz. Bu render süresini kısaltır, bellek kullanımını düşürür ve kaydırma hissini sabit hale getirir.
Kullanıcıların uzun bir veri kümesi boyunca sorunsuzca kaydırması gerekiyorsa virtual scrolling (windowing) en iyisidir. Sayfalarla atlayıp hızlı sunucu tarafı sorgulamaları istiyorsanız sayfalandırma daha uygundur. "Daha fazla yükle" deseni, daha az kontrol isterken yine de devasa DOM ağaçlarından kaçınmak istediğinizde işe yarayabilir.
Yaklaşık bir kural olarak:
Sanal listeler her satırın öngörülebilir yüksekliğe sahip olduğunda en iyi çalışır. Eğer satır yüksekliği render sonrası değişiyorsa (görseller yükleniyor, metin sarılıyor, genişleyen bölümler), scroller yeniden ölçüm yapmak zorunda kalır. Bu kaydırmanın zıplamasına ve layout thrash'e yol açar.
Kararlı tutun:
Örnek: bir ticket tablosu 10.000 satır gösteriyorsa tablo gövdesini virtualize edin ve satır yüksekliğini tutarlı tutun (durum, konu, atanmış kişi). Uzun mesajları detay çekmecesinin arkasına koyarak kaydırmanın sabit kalmasını sağlayın.
Bir arama kutusu hızlı bir tabloyu yavaş hissettirebilir. Sorun genelde filtrenin kendisi değil. Zincirleme etki problem yaratır: her tuş vuruşu render, watcher ve çoğu zaman bir isteği tetikler.
Debounce, "kullanıcı yazmayı bıraktıktan biraz bekle, sonra bir kez harekete geç" demektir. Çoğu yönetici ekranı için 200–400 ms arası; tepkisel hissini korurken aşırı hassas olmaktan kaçınır. Ayrıca boşlukları kırpmayı ve veriniz uygunsa 2-3 karakterden kısa aramaları yok saymayı düşünün.
Filtreleme stratejisi veri kümesinin boyutuna ve kurallara uygun olmalı:
Sunucu çağrısı yaptığınızda eski (stale) sonuçları yönetin. Kullanıcı "inv" yazıp hızla "invoice"ı bitirirse önceki istek sonra dönebilir ve UI'ı yanlış veriyle ezebilir. Önceki isteği iptal edin (fetch ile AbortController veya kullandığınız istemcinin iptal özelliği) veya bir istek id’si takip edip en son olmayanları yok sayın.
Yükleme durumları hız kadar önemlidir. Her tuş vuruşu için tam sayfa spinner’ı göstermekten kaçının. Daha sakin bir akış şu şekilde olur: kullanıcı yazarken herhangi bir şey yakıp söndürmeyin. Uygulama arama yapıyorsa, girişin yanında küçük bir inline gösterge gösterin. Sonuçlar güncellendiğinde "42 sonuç gösteriliyor" gibi açık ve sakin bir şey gösterin. Sonuç yoksa, boş bir ızgara bırakmak yerine "Eşleşme yok" deyin.
Birçok yavaş yönetici tablosu "çok fazla veri" yüzünden değil, aynı hücrelerin tekrar tekrar yeniden render edilmesinden yavaştır.
Tekrarlayan güncellemeler genelde birkaç yaygın alışkanlıktan gelir:
Props ve handler kimlikleri değiştiğinde Vue, child'ın güncellenmesi gerekebileceğini varsayar, görünürde değişiklik olmasa bile.
Daha küçük, kararlı props göndermeye başlayın. Her hücreye tüm row nesnesini geçirmek yerine row.id ve hücrenin gösterdiği spesifik alanları verin. Türetme değerlerini computed içine taşıyın ki yalnızca girdileri değiştiğinde yeniden hesaplansın.
Satırın bir kısmı nadiren değişiyorsa v-memo yardımcı olur. Statik parçaları kararlı girdilere (ör. row.id ve row.status) göre memoize edin; böylece aramada yazıyor veya bir satırın üzerinde hover yapıyor olsanız bile her hücre şablonunu tekrar çalıştırmak zorunda kalmazsınız.
Ayrıca pahalı işleri render yolundan uzak tutun. Tarihleri bir kez önceden formatlayın (örneğin id ile keyed bir computed map içinde) veya mantıklıysa sunucuda formatlayın. Yaygın bir kazanım, "Son güncelleme" sütununun her küçük UI güncellemesinde yüzlerce satır için new Date() çağırmasını durdurmaktır.
Hedef açık: kimlikleri kararlı tutun, işi şablonların dışına alın ve yalnızca gerçekten değişen şeyi güncelleyin.
Bir liste genelde yavaş olduğundan daha yavaş hissedilir çünkü UI sürekli zıplar. İyi yükleme durumları beklemeyi öngörülebilir kılar.
İskelet (skeleton) satırlar veri şekli bilindiğinde yardımcı olur (tablolar, kartlar, zaman çizelgeleri). Bir spinner insanlar için ne beklediklerini söylemez. İskeletler beklentiyi kurar: kaç satır, eylemlerin nerede olacağı ve düzenin nasıl görüneceği.
Veriyi yenilerken (sayfalandırma, sıralama, filtreler) yeni istek uçtayken önceki sonuçları ekranda tutun. Küçük bir "yenileniyor" ipucu gösterin, tabloyu temizlemeyin. Kullanıcılar güncelleme olurken okumaya veya bir şeyi kontrol etmeye devam edebilirler.
Her şeyin donması gerekmez. Tablo yükleniyorsa, filtre çubuğunu görünür tutun ama geçici olarak devre dışı bırakın. Satır eylemleri ekstra veri gerektiriyorsa, tıklanan satırda bekleyen bir durum gösterin; tüm sayfayı değil.
Kararlı bir desen şöyle görünür:
Araç çubukları, boş durumlar ve sayfalama için yer ayırın ki sonuçlar değiştiğinde kontroller hareket etmesin. Tablo alanı için sabit bir min-yükseklik yardımcı olur ve başlık/filtre çubuğunu her zaman render edilmiş tutmak sayfa zıplamasını önler.
Somut örnek: bir ticket ekranında "Open"dan "Solved"a geçiş listeyi temizlememeli. Mevcut satırları tutun, durum filtresini kısa süreli devre dışı bırakın ve yalnızca güncellenen ticket'ta bekleyen durumu gösterin.
Bir yavaş ekran seçin ve onu küçük bir onarım gibi ele alın. Amaç mükemmellik değil. Kaydırma ve yazmada hissedilen belirgin bir iyileşme.
Önce tam olarak hangi acının olduğunu adlandırın. Sayfayı açın ve üç şey yapın: hızlıca kaydırın, arama kutusuna yazın ve sayfaları veya filtreleri değiştirin. Genelde sadece bunlardan biri gerçekten bozulmuştur ve bu size önce neyi düzeltmeniz gerektiğini söyler.
Sonra basit bir sırayla ilerleyin:
Her adım sonra aynı kötü hissedilen eylemi tekrar test edin. Virtualizasyon kaydırmayı akıcı yaptıysa bir sonraki adıma geçin. Yazma hâlâ yavaşsa, debounce ve istek iptali genelde bir sonraki en büyük kazançtır.
10.000 satırı olan bir "Kullanıcılar" tablosunu düşünün. Kaydırma, tarayıcının çok fazla satırı paint etmesi yüzünden takılıyor. Virtualize edin ki yalnızca görünür satırlar render olsun.
Sonra arama her tuş vuruşunda istek gönderdiği için gecikmeli hissediliyor. 250–400 ms debounce ekleyin ve önceki isteği AbortController ile iptal edin (veya HTTP istemcinizin iptal özelliğini kullanın) ki yalnızca en son sorgu listeyi güncellesin.
Son olarak her satırı ucuz yeniden render edilecek şekilde yapın. Propsları basit tutun (mümkün olduğunda id ve primitive değerler), satır çıktısını memoize edin ki etkilenmeyen satırlar tekrar çizilmesin ve tam ekran örtü yerine tablo gövdesi içinde yükleme gösterin ki sayfa duyarlı kalsın.
Ekipler genelde birkaç düzeltme uygular, küçük bir kazanç görür ve sonra takılır. Yaygın neden: pahalı kısım "listenin kendisi" değil; her satırın render olurken, güncellenirken ve veri çekerken yaptığı işlerdir.
Virtualizasyon yardımcı olur ama bunu kolayca iptal edebilirsiniz. Eğer her görünür satır hâlâ ağır bir grafik monte ediyor, görselleri çözüyor, çok fazla watcher çalıştırıyor veya pahalı biçimlendirme yapıyorsa kaydırma yine de takılı hissedilir. Virtualizasyon yalnızca kaç satırın var olduğunu sınırlar, her satırın ne kadar ağır olduğunu değil.
Key’ler başka bir sessiz performans katilidir. Dizi indeksini key olarak kullanırsanız Vue, satırları doğru şekilde izleyemez; ekleme, silme veya sıralamada remountlara zorlanır. Bu genelde remountlara ve input odağının kaymasına neden olur. Gerçek bir id kullanın ki Vue DOM'u ve bileşen örneklerini tekrar kullansın.
Debounce da ters tepki verebilir. Eğer gecikme çok uzunsa UI bozuk hissedilir: insanlar yazar, hiçbir şey olmaz ve ardından sonuçlar aniden zıplar. Kısa bir gecikme genelde daha iyidir ve uygulamanın girdiyi algıladığını göstermek için "Aranıyor..." gibi anlık geri bildirimler gösterebilirsiniz.
Çoğu yavaş liste denetiminde görülen beş hata:
Bir Vue 3 performans kontrol listesi kullanıyorsanız, "ne yeniden render oluyor" ve "ne yeniden fetch ediyor"u birinci sınıf sorunlar olarak ele alın.
Bir tablo veya liste yapışkan hissetmeye başladığında bu kontrol listesini kullanın. Hedef: akıcı kaydırma, öngörülebilir arama ve daha az sürpriz yeniden render.
Çoğu "yavaş liste" sorunu çok fazla şeyi çok sık render etmekten gelir.
:style="{...}"). Bir kez oluşturup yeniden kullanın.Ağ yavaş olsa bile listeyi hızlı hissettirin.
Destek ekibi ticket ekranını gün boyu açık tutuyor. Müşteri adı, etiket veya sipariş numarası ile arama yapıyorlar ve aynı zamanda canlı feed ticket durumunu güncelliyor (yeni yanıtlar, öncelik değişimleri, SLA zamanlayıcıları). Tablo kolayca 10.000 satıra ulaşabilir.
İlk versiyon teknik olarak çalışıyor ama berbat hissediyor. Yazarken karakterler geç görünüyor. Tablo üstteye atlıyor, kaydırma konumu sıfırlanıyor ve uygulama her tuş vuruşunda istek gönderiyor. Sonuçlar eski ile yeni arasında titriyor.
Ne değişti:
Debounce sonrası yazma gecikmesi kayboldu ve gereksiz istekler düştü. Eski sonuçları tutmak flicker’ı durdurdu, böylece ağ yavaş olsa bile ekran stabil hissetti.
Virtualizasyon en büyük görsel kazandı sağladı: tarayıcı artık aynı anda binlerce satırla uğraşmak zorunda kalmadığı için kaydırma akıcı kaldı. Satırı memoize etmek, tek bir ticket değiştiğinde "tüm tablo" güncellemesini önledi.
Canlı feed için bir ince ayar daha yardımcı oldu: güncellemeler biriktirilip birkaç yüz milisaniyede bir uygulandı, böylece UI sürekli yeniden akışa girmedi.
Sonuç: sabit kaydırma, hızlı yazma ve daha az sürpriz.
Hızlı bir yönetici arayüzünü korunması, sonradan kurtarmaktan daha kolaydır. Bu kontrol listesini her yeni ekran için standart olarak ele alın, tek seferlik bir temizlik olarak değil.
Kullanıcıların en çok hissettiği düzeltmeleri önceliklendirin. Büyük kazanımlar genelde tarayıcının çizmesi gerekenleri azaltmaktan ve yazmaya tepki süresini kısaltmaktan gelir.
Temellerle başlayın: DOM boyutunu azaltın (uzun listeleri virtualize edin, gizli satırları render etmeyin), sonra giriş gecikmesini azaltın (aramayı debounce edin, ağır filtrelemeyi her tuş vuruşundan çıkarın), ardından renderı kararlı hale getirin (satır bileşenlerini memoize edin, propsları sabit tutun). Küçük refaktörleri sona bırakın.
Bundan sonra, yeni ekranların gerilememesi için bazı koruyucular ekleyin. Örneğin, 200 satırın üzerindeki herhangi bir liste virtualizasyon kullanır, herhangi bir arama girişi debounce edilir ve her satır kararlı bir id key kullanır.
Yeniden kullanılabilir yapı taşları bunu kolaylaştırır. Makul varsayılanlara sahip bir virtual tablo bileşeni, debounce gömülü bir arama çubuğu ve tablo düzenine uyan iskelet/boş durumları wiki sayfasından daha fazla işe yarar.
Pratik bir alışkanlık: yeni bir yönetici ekranını merge etmeden önce 10x veri ile ve yavaş ağ ön ayarıyla test edin. Eğer o koşullarda hâlâ iyi hissediyorsa, gerçek kullanımda mükemmel hissedecektir.
Eğer dahili araçları hızla inşa ediyorsanız ve bu kalıpların ekranlar arasında tutarlı kalmasını istiyorsanız, AppMaster (appmaster.io) iyi bir seçenek olabilir. Gerçek Vue 3 web uygulamaları ürettiği için, liste ağırlaştığında aynı profilleme ve optimizasyon yaklaşımı uygulanır.
What’s the fastest first fix for a slow Vue 3 admin table?Saniyeler içinde yüzlerce satırdan fazlasını render ediyorsanız virtualizasyona başlayın. Tarayıcının kaydırma sırasında binlerce DOM düğümünü yönetmeyi bırakması genelde en büyük hissetme iyileşmesini verir.
How do I tell if the slowdown is rendering or the API?Kaydırma sırasında kareler düşüyorsa bu genelde render/DOM sorununa işaret eder. Arayüz akıcı ama sonuçlar geç geliyorsa network veya sunucu tarafı sorgulama sebeplidir. Cache’li veriyle veya hızlı yerel yanıtla test ederek doğrulayın.
What does “virtualization” actually change in a table?Virtualizasyon, tüm dataset yerine yalnızca görünür satırları (ve küçük bir tamponu) render eder. Bu DOM boyutunu, bellek kullanımını ve kaydırma sırasında tarayıcı ile Vue’nun yaptığı işi azaltır.
Why does my virtualized list feel jumpy or unstable?Tutarlı bir satır yüksekliği hedefleyin ve render sonrası boyutu değişen içerikten kaçının. Satırlar genişliyorsa, sarılıyorsa veya yüklenen görseller yükseklik değiştiriyorsa scroller yeniden ölçüm yapmak zorunda kalır ve bu atlama yaratır.
What debounce delay should I use for admin search?Varsayılan olarak 250–400 ms arası iyi bir değerdir. Bu, çok sık yeniden filtreleme ve yeniden render yapmadan tepki hissini korur.
How do I prevent stale search results from showing up out of order?Önceki isteği iptal edin veya güncel olmayan yanıtları yoksayın. Amaç basit: yalnızca en son sorgu tabloyu güncellesin, böylece eski yanıtlar yeni olanın üzerine yazamaz.
What typically causes unnecessary re-renders in table rows?Büyük reaktif nesneleri props olarak göndermekten kaçının; yalnızca gereken alanları iletin. Şablonlarda yeni inline fonksiyonlar veya nesneler oluşturmayın. Kimlikler kararlı kaldığında, değişmeyen satır parçalarını v-memo ile memoize edin.
How can I stop formatting (dates, currency) from slowing down the table?Ağır işler render yolundan çıkarılmalı. Biçimlendirmeyi (tarih, para birimi) önceden hesaplayın veya cache’leyin ve yalnızca veri değiştiğinde güncelleyin.
What loading state makes heavy lists feel faster?Yenileme sırasında önceki sonuçları ekranda tutun ve tabloyu temizlemek yerine küçük bir “güncelleniyor” ipucu gösterin. Bu, flicker’ı azaltır, layout sıçramalarını önler ve ağ yavaş olsa bile sayfanın duyarlı kalmasını sağlar.
Do these Vue 3 performance tips apply if I build the admin UI with AppMaster?Evet. AppMaster gerçek Vue 3 web uygulamaları ürettiği için aynı teknikler geçerlidir: yeniden render profili çıkarma, uzun listeleri virtualize etme, aramayı debounce etme ve satır render’ını kararlı hale getirme. Fark, bu kalıpları yeniden kullanılabilir bileşenlere standartlaştırabilmenizdir.
21 Oca 2026
8 dk
20 Oca 20268 dk
20 Oca 20268 dkÜcretsiz planla AppMaster ile denemeler yapın.
Hazır olduğunuzda uygun aboneliği seçebilirsiniz.
