Web Sitesinde Preloader (Yükleme Ekranı) Kullanılmalı mı?

Bu rehberde Talha Aslan ve ekibi olarak preloader kararını nasıl verdiğimizi adım adım anlatıyoruz. Önce tam ekran yükleme ekranının hız ölçümlerine etkisini ele alıyoruz. Ardından ne zaman kabul edilebilir olduğunu, yerine neyi koymanız gerektiğini ve hareket azaltma tercihini konuşuyoruz. Sonunda da kendi sitenizde uygulayabileceğiniz bir kontrol listesi bulacaksınız.

Preloader tam olarak nedir, neden bu kadar yaygınlaştı?

Preloader, Türkçede genellikle yükleme ekranı ya da açılış animasyonu diye bilinir. Ziyaretçi sayfayı açtığında logo, dönen bir halka veya yüzde sayacı görür; sayfa ancak bu katman kalkınca ortaya çıkar. Teknik olarak çoğu zaman sayfanın üstünde duran ve belirli bir olaydan sonra kaybolan bir katmandır.

Yaygınlaşmasının nedeni aslında tasarım şablonlarıdır. Hazır temaların birçoğu preloader seçeneğini tek tıkla açılan bir özellik olarak sunar. Böylece site sahibi, açılışta markasını gösteren şık bir an kazandığına inanır. Ancak bu şıklık, ziyaretçinin asıl istediği içeriğe ulaşmasını geciktirir. Dolayısıyla preloader bir görsel tercih gibi görünse de aslında bir performans ve kullanılabilirlik kararıdır.

• Dönen halka veya nokta: En sık gördüğümüz, içerik taşımayan bekleme işareti.
• Logo animasyonu: Marka logosunun belirip kaybolduğu açılış sahnesi.
• Yüzde sayacı: Yüzde 0'dan 100'e sayan, çoğu zaman gerçek ilerlemeyi göstermeyen sayaç.
• Perde efekti: Ekranı kaplayan bir rengin yana kayarak sayfayı açması.

Preloader algılanan hızı nasıl etkiler?

Algılanan hız, ziyaretçinin sayfanın ne kadar hızlı olduğunu hissetmesidir. Ölçülen süre ile hissedilen süre aynı şey değildir. Örneğin metin ve başlık yarım saniyede gelse bile, preloader iki saniye boyunca bunları gizliyorsa ziyaretçi iki saniye bekledi diye hisseder.

Nielsen Norman Group, yanıt süresi sınırları üzerine yazısında üç eşik tanımlar: 0,1 saniye anlık hissedilir, 1 saniye düşünce akışını bozmaz, 10 saniye ise dikkatin sınırıdır. Bu çerçeveye göre ilerleme göstergesi aslında uzun beklemeler içindir. Kısa bir yüklemede tam ekran bekleme animasyonu göstermek ise beklemeyi görünür kılar; yani sorunu çözmek yerine sorunu vurgular.

Üstelik preloader çoğu zaman sayfanın parça parça gelmesini engeller. Oysa ziyaretçi başlığı okumaya başladığında beklediğini unutur. Bu nedenle biz, içeriği erken göstermeyi animasyonla oyalamaktan her zaman daha değerli buluyoruz.

Ayrıca bekleme sırasında ziyaretçinin zihni boş kalmaz; sitenin çalışıp çalışmadığını sorgular. İçerik parça parça gelirse bu soru hiç oluşmaz, çünkü sayfa ilk andan itibaren yanıt verdiğini gösterir.

Preloader LCP ölçümünü nasıl etkiler?

LCP (Largest Contentful Paint), ekrandaki en büyük içerik öğesinin ekrana çizildiği andır. web.dev, LCP rehberinde iyi bir deneyim için bu sürenin 2,5 saniye veya altında olmasını önerir. Ayrıca ölçümün sayfa yüklemelerinin 75. yüzdelik dilimine göre değerlendirildiğini belirtir.

Aynı rehber, opaklığı sıfır olan, yani görünmeyen öğeleri LCP adayı saymaz. Ekranın tamamını kaplayan öğeleri de içerik değil arka plan gibi ele alır. Dolayısıyla preloader arkasında gizlenen başlık ve görsel, katman kalkana kadar LCP adayı olamaz. Sonuç olarak tarayıcı içeriği çoktan indirmiş olsa bile LCP, animasyonun bittiği ana kayar.

LCP'nin bileşenlerini ve iyileştirme yollarını ayrıntılı merak ediyorsanız LCP nedir ve nasıl iyileştirilir yazımıza göz atabilirsiniz. Burada yalnız preloader ile ilişkisini ele alıyoruz.

Preloader Core Web Vitals'ın diğer ölçümlerine de dokunur mu?

Evet, dolaylı olarak dokunabilir. Core Web Vitals, LCP'nin yanında INP (etkileşim yanıt süresi) ve CLS (düzen kayması) ölçümlerinden oluşur. Bu üç ölçümün genel çerçevesini Core Web Vitals rehberimizde anlattık; burada yalnız preloader ile kesiştikleri noktaları sıralıyoruz.

• INP: Preloader'ı yöneten betik, ana iş parçacığını meşgul ederse ilk tıklamalar gecikebilir.
• CLS: Katman kalkarken yazı tipi veya görsel boyutu sonradan yerleşirse sayfa kayabilir.
• Toplam iş yükü: Animasyon kütüphanesi, sayfaya ek kod ve ek indirme getirir.

Kısacası preloader yalnız bir saniyelik görsel efekt değildir. Ek kod, ek boyama ve gecikmiş içerik anlamına gelir. Özellikle JavaScript'in site hızına etkisini hesaba kattığınızda maliyet daha da netleşir.

Örneğin katman kalkar kalkmaz ziyaretçi menüye dokunuyor ama animasyon kütüphanesi hâlâ çalışıyorsa, menü gecikmeli açılır. Ziyaretçi bunu sitenin donması olarak yorumlar ve aynı düğmeye tekrar tekrar basar.

Preloader hemen çıkma oranını artırır mı?

Doğrudan bir yüzde vermek doğru olmaz; çünkü her sitenin kitlesi ve trafiği farklıdır. Ancak mantık açıktır: ziyaretçi içerik yerine bekleme ekranı görürse sabrını daha erken kaybeder. Özellikle mobilde ve zayıf bağlantıda geri tuşuna basmak çok kolaydır.

Örnek senaryo: Reklamdan gelen bir ziyaretçi, ürün sayfası yerine dönen bir logo görüyor. Logo üç saniye dönüyor ve ziyaretçi bunun sitenin çöktüğünü mü yoksa yüklendiğini mi gösterdiğinden emin olamıyor. Bu belirsizlik, reklam bütçesinin bir kısmının hiç içerik görmeden harcanması demektir.

Hemen çıkma oranını düşürmek için başka hangi adımları atabileceğinizi kurumsal sitelerde hemen çıkma oranını düşürme yazımızda topladık.

Preloader ile aşamalı yükleme arasında ne fark var?

Aşamalı yükleme, sayfanın hazır olan bölümünü hemen göstermek ve geri kalanını geldikçe eklemektir. Preloader ise tam tersini yapar: her şey hazır olana kadar hiçbir şeyi göstermez. Aşağıdaki tablo iki yaklaşımı ve araya giren iskelet ekranı karşılaştırıyor.

Görüldüğü gibi aşamalı yükleme, sıradan bir site için varsayılan doğru seçimdir. Öte yandan veri bekleyen bölümlerde iskelet ekran iyi bir ara çözümdür.

Örnek senaryo: Bir hizmet sayfasında başlık ve kısa açıklama sunucudan hazır geliyor, müşteri yorumları ise ayrı bir kaynaktan çekiliyor. Aşamalı yüklemede ziyaretçi başlığı hemen okur, yorumlar birkaç an sonra yerine oturur. Preloader ile ise ziyaretçi yorumlar gelene kadar hiçbir şey görmez; yani en yavaş parça bütün sayfanın hızını belirler.

İskelet ekran preloader'ın yerine geçebilir mi?

Çoğu durumda evet, ama yalnız ilgili bölüm için. İskelet ekran, içeriğin geleceği yerde sayfa düzenini gri kutularla önceden gösterir. Böylece ziyaretçi sayfanın neye benzeyeceğini anlar ve beklemeyi daha kısa hisseder. Üstelik kutular gerçek boyutlarda olursa içerik gelince sayfa kaymaz.

Ancak iskelet ekranı tüm sayfaya yaymak, preloader'ın farklı bir kılığa girmesinden ibaret olur. Başlık, metin ve menü gibi sunucudan hazır gelen parçalar doğrudan görünmelidir. İskelet ekranın doğru kullanımını, hatalarını ve tasarım ayrıntılarını skeleton screen nedir yazımızda ayrıca anlattık.

Ayrıca iskelet ekranın da bir süresi vardır. Taslak kutular uzun süre ekranda kalırsa ziyaretçi bunları da bekleme ekranı gibi algılar. Bu yüzden iskelet ekranı yalnız gerçekten veri bekleyen bölümlerde ve kısa süreli kullanmanızı öneriyoruz.

Preloader ne zaman kabul edilebilir?

Preloader'ın tamamen yasak olduğunu söylemiyoruz. Bazı ürünlerde içerik, kullanıcı hiçbir şey yapamadan önce büyük miktarda kaynağın inmesine bağlıdır. Böyle durumlarda dürüst bir ilerleme göstergesi, boş ve donmuş görünen bir ekrandan iyidir.

• Tarayıcı oyunları: Doku, ses ve seviye dosyaları inmeden oyun başlayamaz.
• Ağır web uygulamaları: Tasarım araçları, 3D yapılandırıcılar ve harita tabanlı paneller.
• Oturum sonrası uygulama kabuğu: Giriş yapmış kullanıcının panel verisini beklediği an.
• Büyük dosya işlemleri: Video dönüştürme veya dosya yükleme gibi gerçek süre gerektiren işler.

Ortak nokta şudur: bu senaryolarda içerik zaten sayfanın kendisi değil, inmesi gereken bir uygulamadır. Kurumsal tanıtım sayfası, blog yazısı veya ürün sayfası ise bu sınıfa girmez.

Yine de bu ürünlerde bile tüm arayüzü tek bir bekleme ekranının arkasına saklamak şart değildir. Örneğin bir tasarım aracında önce menüyü ve boş çalışma alanını gösterip ağır modülleri arka planda indirebilirsiniz. Böylece kullanıcı hazırlanmaya başlar, bekleme ise daha kısa hissettirir.

Kabul edilebilir bir preloader nasıl tasarlanır, hangi kurallara uymalısınız?

Preloader'ın gerçekten gerektiği durumda bile birkaç kural deneyimi ciddi biçimde iyileştirir. Biz ekipte bu kuralları bir tasarım kontrolü olarak kullanıyoruz.

1. Gerçek ilerlemeyi gösterin; sahte yüzde sayacı kullanmayın.
2. Yükleme bitince animasyonu beklemeden hemen kapatın.
3. Minimum gösterim süresi koymayın; hızlı bağlantıdaki kullanıcıyı cezalandırmayın.
4. Ne beklendiğini yazıyla söyleyin, örneğin oyun dosyalarını indiriyoruz.
5. Uzun işlemlerde iptal veya geri dönme imkânı verin.
6. Hareket azaltma tercihini mutlaka dikkate alın.

Nielsen Norman Group'un 10 saniye sınırı burada iyi bir referanstır. Bekleme bu süreye yaklaşıyorsa yüzde veya adım bilgisi vermek, kullanıcının kontrolde olduğunu hissettirir. Ayrıca bekleme ekranında kullanıcının okuyabileceği kısa bir ipucu, süreyi daha anlamlı kılar.

Hareket azaltma tercihi preloader için neden önemlidir?

Bazı kullanıcılar işletim sistemlerinde hareketi azaltma ayarını açar. Bunun nedeni baş dönmesi, mide bulantısı veya dikkat dağınıklığı gibi gerçek rahatsızlıklar olabilir. Tarayıcılar bu tercihi prefers-reduced-motion adlı medya sorgusuyla sitelere iletir.

W3C, WCAG 2.3.3 Etkileşimden Kaynaklanan Animasyon açıklamasında bu sorguyu yeterli teknikler arasında sayar. Bu kriter AAA düzeyindedir; yani zorunlu asgari seviye değildir. Ancak iyi bir tasarım ilkesi olarak dikkate almanızı öneriyoruz.

Uygulamada yaklaşımımız basittir: hareket azaltma açıksa dönen ve kayan animasyonları kapatır, yerine sabit bir metin veya sade bir ilerleme çubuğu koyarız. Böylece kullanıcı yine bilgi alır ama rahatsız edici hareket ortadan kalkar.

Ayrıca hareket azaltma tercihini yalnız preloader ile sınırlı tutmayın. Sayfa geçişleri, kayan görseller ve paralaks efektleri de aynı kullanıcıyı rahatsız edebilir. Bu yüzden tercihi sitenin genel animasyon kuralına bağlamak daha tutarlı bir sonuç verir.

Preloader neden çoğu zaman yavaş bir sitenin belirtisidir?

Sahada gördüğümüz en yaygın tablo şudur: site yavaş açılıyor ve birisi bunu saklamak için yükleme ekranı ekliyor. Böylece ziyaretçi yarım yüklenmiş, kırık görünen bir sayfa yerine düzenli bir animasyon görüyor. Ancak bu yaklaşım sorunu çözmez, yalnız başka bir yere taşır.

Kök nedenler genellikle bellidir: sıkıştırılmamış büyük görseller, açılışta çalışan çok sayıda eklenti, yavaş sunucu yanıtı ve gereksiz yazı tipi dosyaları. Bunları düzelttiğinizde sayfa kendi başına hızlı açılır. Dolayısıyla preloader'a ihtiyaç duyduğunuz an, aslında bir performans denetimine ihtiyaç duyduğunuz andır.

Biz bu yüzden bir projede preloader isteği geldiğinde önce şu soruyu sorarız: sayfa neden beklemeyi gerektiriyor? Cevap çoğu zaman tasarımla değil, teknik altyapıyla ilgilidir.

Mobil kullanıcılar preloader'ı nasıl deneyimler?

Masaüstünde hızlı bağlantıyla test ettiğinizde preloader çoğu zaman göz açıp kapayıncaya kadar geçer. Bu yüzden ekipler sorunu fark etmez. Oysa ziyaretçilerin önemli bir kısmı telefondan, değişken mobil bağlantıyla gelir.

Telefonda animasyonu çalıştıran betik, daha zayıf bir işlemcide daha uzun sürer. Üstelik yavaş bağlantıda kaynakların inmesi de gecikir. Sonuç olarak masaüstünde bir saniyelik açılış, telefonda birkaç saniyelik bir bekleme ekranına dönüşebilir.

• Daha yavaş işlemci: Animasyon ve betikler daha uzun çalışır.
• Değişken bağlantı: Kaynakların inme süresi öngörülemez.
• Küçük ekran: Tam ekran katman tüm görüş alanını kaplar ve kaçış yolu bırakmaz.
• Düşük sabır: Telefonda geri tuşu her zaman bir dokunuş uzaklıktadır.

Bu nedenle preloader kararını her zaman yavaş bir mobil profil ile test etmenizi öneriyoruz.

Sahte yüzde sayacı neden güveni zedeler?

Birçok temada yüzde sayacı gerçek indirmeyi ölçmez; yalnız belirli bir sürede sıfırdan yüze sayar. Ziyaretçi bunu kısa sürede fark eder, çünkü sayaç bazen yüzde doksan dokuzda takılır, bazen de içerik hazırken saymaya devam eder.

Bu durum küçük ama gerçek bir güven kaybı yaratır. Ziyaretçi, sitenin kendisine doğru bilgi vermediğini hisseder. Öte yandan gerçek ilerlemeyi gösteren bir çubuk, beklemeyi anlamlı kılar ve kullanıcıya ne kadar kaldığını dürüstçe söyler.

Kısacası ilerleme göstergesi kullanacaksanız ya gerçek veriye bağlayın ya da hiç kullanmayın. Belirsiz bir bekleme için sade bir durum metni, uydurma bir yüzdeden her zaman daha dürüsttür.

Örneğin oyun gibi gerçekten uzun süren bir yüklemede indirilen dosya sayısını veya boyutunu temel alan bir çubuk, kullanıcının sabrını korumaya yardım eder.

Preloader WCAG açısından başka bir risk taşır mı?

Evet. WCAG 2.2.2 Durdur, Duraklat, Gizle kriteri, kendiliğinden başlayan, beş saniyeden uzun süren ve başka içerikle birlikte sunulan hareketli içerik için kullanıcıya durdurma imkânı ister. Bu kriter A düzeyindedir. Ayrıntıyı W3C açıklama sayfasında okuyabilirsiniz.

Kısa bir preloader genellikle bu sınırın altında kalır. Öte yandan yavaş bağlantıda animasyon uzadığında durum değişebilir. Ayrıca ekran okuyucu kullanan bir ziyaretçi, görsel animasyonu göremez; bu nedenle bekleme durumunu metinle duyurmak gerekir. Erişilebilirliğin genel çerçevesi için web erişilebilirliği ve WCAG rehberimize bakabilirsiniz.

Preloader yerine sitenize ne koymalısınız?

Asıl soru preloader'ı kaldırmak değil, beklemeyi gereksiz kılmaktır. Biz bir siteyi devraldığımızda önce sayfanın neden geç göründüğünü buluruz; animasyon genellikle yavaşlığın üzerini örten bir perde olur.

• Kritik içeriği önce gönderin: Başlık, ana metin ve ilk görsel sunucudan hazır gelsin.
• Görselleri doğru boyutlayın: Ekrandaki ana görseli sıkıştırın ve doğru ölçüde sunun.
• Ekran dışını erteleyin: Alt bölümlerdeki görseller için tembel yükleme kullanın.
• Gereksiz betikleri ayıklayın: Açılışta çalışması gerekmeyen kodu sonraya bırakın.
• Yazı tiplerini planlayın: Metin, yazı tipi beklenirken de görünsün.

Tembel yüklemenin hangi görselde işe yarayıp hangisinde zarar verdiğini lazy load rehberimizde ayrıca anlattık. Bu adımlar sonrasında sayfa zaten hızlı açılır ve preloader ihtiyacı kendiliğinden ortadan kalkar.

Örnek senaryo: Bir kurumsal sitede ana görsel birkaç megabayt boyutunda ve açılışta beş ayrı eklenti çalışıyor. Görseli sıkıştırıp doğru boyuta getirdiğinizde ve gereksiz eklentileri kapattığınızda sayfa belirgin biçimde hızlanır. Bu noktada preloader yalnız gereksiz bir gecikme olarak kalır.

Preloader'ı kaldırmak sitenin görünümünü bozar mı?

Genellikle bozmaz; ancak bazı temalarda preloader, alttaki düzen sorunlarını saklar. Örneğin yazı tipi geç yüklenip metin zıplıyorsa, bunu perde arkasında yaşatmak kolaydır. Perde kalkınca sorun ortaya çıkar.

Bu yüzden preloader'ı kaldırdıktan sonra sayfayı mobilde ve yavaş bağlantıda mutlaka gözle kontrol edin. Kayma görürseniz bunu düzen kayması olarak ele alın; CLS'yi iyileştirme rehberimiz bu adımda yol gösterir. Ayrıca mobil uyumluluk testi aracımızla sayfanın küçük ekranda nasıl göründüğüne hızlıca bakabilirsiniz.

Sitenizde preloader'ın arkasında bu tür düzen sorunları birikmişse, bu bölümü baştan doğru kurmak çoğu zaman en kısa yoldur. Web tasarım hizmetimiz kapsamında açılış deneyimini içerik önce gelecek şekilde yeniden kuruyoruz; teklif almak için hizmet sayfasındaki formu kullanabilirsiniz.

Preloader'ın sitede olup olmadığını nasıl anlarsınız?

Bazen site sahibi preloader'ın açık olduğunu bilmez; tema kurulumundan kalmıştır. Basit bir kontrolle bunu öğrenebilirsiniz.

1. Sayfayı gizli pencerede açın ve ilk saniyelere dikkat edin.
2. Tarayıcının geliştirici araçlarında ağ hızını yavaş bir mobil profile düşürün.
3. Sayfayı yeniden yükleyin; içerikten önce logo, halka veya düz renk görüyorsanız preloader vardır.
4. Tema veya sayfa oluşturucu ayarlarında yükleme ekranı benzeri bir seçenek arayın.
5. Performans raporunda LCP öğesinin ne zaman çizildiğine bakın.

Örnek senaryo: Bir hazır temada içerik yarım saniyede hazır olmasına rağmen tema, yükleme ekranını en az bir buçuk saniye gösteriyor olabilir. Bu durumda ayarı kapatmak tek başına belirgin bir fark yaratır.

Bunun yanında sayfanın kaynak koduna bakmak da ipucu verir. Sayfa oluşturucuların çoğu yükleme ekranı katmanına anlaşılır bir sınıf adı verir. Emin olamıyorsanız geliştiricinize hangi ayarın bu ekranı açtığını sormanız yeterlidir.

Preloader SEO'yu doğrudan etkiler mi?

Google, sayfa deneyimini sıralama sistemlerinde dikkate alır, ancak bunu tek başına belirleyici bir sinyal olarak anlatmaz. Dolayısıyla preloader sitenizi tek başına aşağı itmez. Yine de LCP'yi geciktirip ziyaretçiyi erken kaçırıyorsa, hem ölçümlerinizi hem de dönüşümünüzü zayıflatır.

Ayrıca arama motoru içeriği HTML'den okuyabilir; bu açıdan arama motoru perde arkasındaki metni genellikle okur. Ancak içerik yalnız betik çalıştıktan sonra ekleniyorsa, işler karmaşıklaşır. Kısacası SEO tarafında asıl risk preloader'ın kendisi değil, onunla birlikte gelen geç ve betiğe bağlı içerik yapısıdır. Hızın sıralamadaki yerini site hızı ve SEO yazımızda daha geniş ele aldık.

Google'ın sayfa deneyimi konusundaki genel yaklaşımını Search Central sayfa deneyimi belgesinde okuyabilirsiniz. Belge, iyi bir sayfa deneyiminin tek bir ölçümle sınırlı olmadığını ve içerik kalitesinin önde geldiğini vurgular.

E-ticaret ve kurumsal sitelerde preloader kararını nasıl vermelisiniz?

Bu iki site türünde kararımız neredeyse her zaman aynıdır: preloader yok. Çünkü ziyaretçi ürünü ya da hizmeti görmek için gelir; marka animasyonu izlemek için gelmez. Özellikle reklam trafiğinde her saniyelik bekleme, parasını ödediğiniz bir tıklamanın boşa gitme riskini artırır.

Bunun yerine marka hissini sayfanın kendisinde veririz. Örneğin üst alanda net bir başlık, özenle seçtiğiniz bir görsel ve tutarlı renkler, açılış animasyonundan daha güçlü bir ilk izlenim bırakır. Üstelik bu ilk izlenim, ziyaretçiyi bekletmeden oluşur.

Sayfa geçişlerinde hafif bir yumuşatma isterseniz, tam ekran katman yerine küçük ve hızlı bir geçiş tercih edin. Böylece marka hissini korursunuz, içeriği ise hiç gizlemezsiniz.

Ayrıca e-ticarette ziyaretçi genellikle birden çok sayfa gezer. Her sayfa geçişinde yeniden açılan bir yükleme ekranı, alışverişi sürekli bölen bir engel hâline gelir. Bu yüzden özellikle kategori ve ürün sayfalarında preloader'ı tamamen kapatmanızı öneriyoruz.

Preloader kararı için hangi soruları sormalısınız?

Karar verirken aşağıdaki sorular işinizi kolaylaştırır. Cevapların çoğu hayırsa preloader'a ihtiyacınız yoktur.

• Sayfa, kullanıcı hiçbir şey yapamadan önce büyük bir uygulama indirmek zorunda mı?
• Bekleme süresi gerçekten birkaç saniyeyi aşıyor mu?
• Gerçek ilerlemeyi ölçebiliyor ve gösterebiliyor muyuz?
• Kısmi içerik göstermek imkânsız mı?
• Hareket azaltma tercihine uygun bir sade sürüm hazır mı?

Örneğin bir tarayıcı oyunu için bu soruların çoğuna evet dersiniz. Öte yandan bir diş kliniği veya avukatlık bürosu sitesi için hepsinin cevabı hayırdır. Bu fark, kararın aslında ne kadar net olduğunu gösterir.

Bu soruları ekip içinde tasarım aşamasında sormak, sonradan yapılacak düzeltmelerden çok daha ucuzdur. Çünkü yayına girmiş bir sitede preloader'ı kaldırmak, arkasında saklanan sorunları da aynı anda çözmeyi gerektirir. Tasarım aşamasında ise açılışı baştan içerik önce gelecek şekilde kurarsınız ve bu borç hiç oluşmaz.

Preloader kontrol listesi: sitenizde neyi kontrol etmelisiniz?

Aşağıdaki listeyi yayına almadan önce veya mevcut sitenizi gözden geçirirken kullanabilirsiniz.

1. Preloader gerçekten gerekli mi, yoksa temadan mı kalmış?
2. İçerik hazır olduğunda katman hemen kalkıyor mu?
3. Minimum gösterim süresi tanımlı mı? Tanımlıysa kaldırın.
4. LCP öğesi katmanın arkasında mı kalıyor?
5. Hareket azaltma tercihinde animasyon duruyor mu?
6. Ekran okuyucu, bekleme durumunu metin olarak duyuyor mu?
7. Beş saniyeyi aşan hareket için durdurma imkânı var mı?
8. Katman kalkınca düzen kayması oluyor mu?
9. Mobilde ve yavaş bağlantıda deneyim kabul edilebilir mi?
10. Veri bekleyen bölümler için iskelet ekran daha iyi bir seçenek mi?

Bu listede birden fazla hayır cevabı çıkıyorsa preloader'ı kaldırmayı ve kök nedenleri çözmeyi öneriyoruz. Listeyi her büyük tasarım değişikliğinden sonra yeniden gözden geçirmeniz de iyi bir alışkanlıktır; çünkü yeni eklentiler ve tema güncellemeleri yükleme ekranını sessizce yeniden açabilir.

Preloader kaldırıldıktan sonra sonucu nasıl ölçersiniz?

Değişikliğin etkisini görmek için önce ve sonra aynı ölçümleri kıyaslayın. Laboratuvar testleri hızlı geri bildirim verir; gerçek kullanıcı verisi ise birkaç hafta içinde birikir.

• Laboratuvar ölçümü: Aynı sayfayı aynı ayarlarla test edin ve LCP zamanını not edin.
• Saha verisi: Gerçek kullanıcı ölçümlerinin değişmesi için zaman tanıyın.
• Davranış verisi: Analitikte etkileşimsiz oturumların değişimine bakın.

Ancak tek bir haftalık dalgalanmaya bakarak karar vermeyin. Kampanya, mevsim ve trafik kaynağı gibi etkenler sonuçları değiştirebilir. Bu yüzden karşılaştırmayı benzer dönemler arasında yapmanız daha sağlıklı olur.

Örnek hesap: Önceki dört haftanın verisini sonraki dört haftayla, aynı trafik kaynakları üzerinden kıyaslayabilirsiniz. Bu yaklaşım, kampanya etkisini ayırmanıza yardım eder. Sonuç beklediğiniz kadar net değilse sayfadaki diğer hız sorunlarına da bakın.

Sitenizin açılış deneyimini birlikte kuralım mı?

Preloader, çoğu sitede küçük bir tasarım detayı gibi durur ama arkasında hız, erişilebilirlik ve dönüşüm kararları yatar. Biz yeni bir siteyi tasarlarken açılışı içerik önce gelecek şekilde planlıyor, ağır bölümler için iskelet ekran ve aşamalı yükleme kurguluyoruz.

Mevcut sitenizde yükleme ekranı varsa ve kaldırdığınızda sorunlar ortaya çıkıyorsa, bu bölümü sitenize biz kuralım. Web tasarım hizmeti sayfamızdaki teklif formunu doldurun; sitenizi inceleyip kapsamı ve süreyi içeren bir teklif hazırlayalım.

Teklifimizde preloader'ın kaldırılması, kritik içeriğin öne alınması, görsel ve betik düzeni ile hareket azaltma desteği gibi adımları ayrı ayrı belirtiriz. Böylece neye ödeme yaptığınızı ve hangi sonucu hedeflediğimizi baştan bilirsiniz.