Ağır Bir 3D Sitede PageSpeed 100 Nasıl Alınır? Kendi Sitemizin Ölçümleri

3D web sitesi konuşulan her toplantıda aynı soru geliyor: "Güzel olacak da sitem yavaşlamaz mı?" Soru yerinde. Tarayıcıda çalışan bir 3D sahne, sıradan bir kurumsal siteye göre kat kat fazla veri ve işlem taşıyor. Ama yavaşlığın sebebi 3D'nin kendisi değil, sahnenin sayfanın önüne konması. Bu yazıda kendi sitemizde ölçtüğümüz sayıları, hangi müdahalenin ne kazandırdığını ve her yayından önce çalışan otomatik kapıyı anlatıyoruz.

Kısa cevap

Evet, alınabilir. Şu anda okuduğunuz sitenin ana sayfasında iki ayrı WebGL sahnesi çalışıyor ve site mobilde PageSpeed 98-100 bandında ölçülüyor. Başlangıç noktası 39'du.

Değişen şey sahnenin kalitesi değil, sahnenin ne zaman kurulduğu. İçerik önce geliyor, sahne ziyaretçi sayfayla ilk teması kurduğunda kuruluyor. Arama motorunun ve ilk boyamanın gördüğü sayfa, 3D yükü olmayan bir sayfa.

Neden bu bir müşteri ihtiyacı

PageSpeed puanı tek başına bir hedef değil, ama iki yerde doğrudan işe dokunuyor. Birincisi Google'ın sıralama sinyalleri: Core Web Vitals ölçütleri saha verisinden geliyor ve yavaş sayfalar rekabetçi sorgularda geri düşüyor. İkincisi dönüşüm: ziyaretçi ilk birkaç saniyede bir şey görmezse geri dönüyor ve o ziyaretçi için sahnenin ne kadar güzel olduğu hiç önemli olmuyor.

Bu yüzden 3D bir projede performans, teslimden sonra bakılacak bir iyileştirme kalemi değil, tasarımın ilk gününde konulan bir bütçe olmalı.

Kendi sitemizde ne yaptık

Ana sayfamız mobilde 39 puandaydı. Sorun tek bir hatada değil, birbirine eklenen beş kararda birikiyordu. Sırayla çözdük ve her adımı ölçtük.

Bugün aynı sayfada üç WebGL sahnesi ve gömülü olarak çalışan bir müşteri sitesi var. Ölçüm hâlâ aynı yerde: mobilde en büyük içerik 1,7 saniyede boyanıyor, toplam engelleme süresi 20 milisaniye, düzen kayması sıfır, ilk yükte inen toplam veri 345 KB.

Sahne kapısı: en önemli tek karar

Anlatılacak tek bir teknik varsa o da şu: ağır sahne, ilk boyamanın kritik yolundan çıkarılır.

Bizim kurulumumuzda sahne iki şeyden ilki gerçekleştiğinde kuruluyor: ziyaretçinin ilk teması (fare hareketi, dokunma, kaydırma) ya da sayfa yüklendikten birkaç saniye sonraki boş an. Sayfanın aşağısındaki sahneler ayrıca görünür alana girene kadar hiç kurulmuyor.

Bunun ölçülebilir sonucu şu: tarayıcı ilk saniyelerde yalnızca metni, görselleri ve stili indiriyor. 3D model ve ortam haritası gibi megabaytlık dosyalar, ziyaretçi gerçekten o bölüme geldiğinde iniyor. Ana sayfamızda ölçtüğümüz fark net: ilk yükte 345 KB, ziyaretçi 3D bölümüne kaydırdığında masaüstünde 4,7 MB.

Neyi, nasıl ölçüyoruz

Performans iddiası ölçümle birlikte anlam taşıyor. Kullandığımız üç kaynak var ve üçü farklı soruya cevap veriyor.

Laboratuvar ölçümü (Lighthouse ve PageSpeed Insights): Kontrollü koşulda aynı sayfayı tekrar tekrar ölçer. Değişikliğin işe yarayıp yaramadığını burada görürsünüz.

Saha verisi (Chrome UX Report): Gerçek ziyaretçilerin cihazlarından gelen veri. Sıralamaya giren ölçüt budur. Trafiği düşük sitelerde veri birikmez, o zaman laboratuvar ölçümüyle yetinmek gerekir.

Kaynak listesi: Hangi dosyanın ne zaman indiğini gösteren ağ kaydı. Puan iyi görünse bile ağır dosya kritik yolda iniyorsa burada yakalanır.

Bir tuzağı da yazalım, çünkü çok sayıda ajans buna düşüyor: geliştirme makinesinde yerel sunucuyla yapılan ölçüm yanıltır. Yerel sunucu dosyaları neredeyse anında verdiği için sıralama gerçekte olmayan bir düzende çıkar ve tahmine dayalı metrikler şişer. Ölçüm ya canlı adres üzerinden ya da gecikme eklenmiş bir sunucuyla yapılmalı.

Yayın öncesi otomatik kapı

Bir kez iyi ölçüm almak kolaydır, zor olan aylar sonra da aynı yerde durmaktır. Yeni bir görsel, üçüncü taraf bir betik ya da unutulmuş bir yazı tipi puanı sessizce düşürür.

Bu yüzden her değişiklik, yayına çıkmadan önce otomatik bir kapıdan geçiyor. Kapıda dört sayfa ölçülüyor ve şu sınırlar aşılırsa sürüm durduruluyor:

Buna ek olarak on dört sayfa WCAG 2.1 AA erişilebilirlik denetiminden geçiyor ve tek bir ihlal bile sürümü durduruyor. Performans ölçütlerini bilinçli olarak uyarı seviyesinde tutuyoruz: ölçüm sunucusunda ekran kartı bulunmadığı için 3D sahneler orada gerçekte olduğundan yavaş çıkıyor, sert kapı yanlış alarm üretirdi.

Akışkan ve derinlikli tasarımı nasıl planlıyoruz

Performans yalnızca kod tarafında kazanılmıyor. Tasarım kararları da bütçeyi harcıyor ya da koruyor.

Hareket bütçesi baştan konuyor. Her bölüme animasyon koymak yerine, ziyaretçinin dikkatini hak eden iki üç ana an seçiliyor. Geri kalanı sabit duruyor. Bu hem performans hem okunabilirlik kararı.

Mobil ayrı bir profil, uyarlama değil. Sahne mobilde daha az üçgen, daha küçük doku ve daha sade son işlemle çalışıyor. Düşük güç modundaki cihazlarda sahne yerine hareketsiz kare gösteriliyor.

Hareket tercihine saygı. İşletim sisteminde hareket azaltma açıksa animasyonlar durduruluyor. Bu hem erişilebilirlik gereği hem de o ziyaretçi için gereksiz yükün hiç inmemesi demek.

Veri tasarrufu dikkate alınıyor. Tarayıcı veri tasarrufu bildirdiğinde ya da bağlantı yavaşsa ağır sahne hiç kurulmuyor, yerine duran görsel geçiyor.

Yer baştan ayrılıyor. Görsellerin ve sahnelerin kaplayacağı alan en baştan ayrıldığı için içerik yüklendikçe sayfa zıplamıyor. Düzen kaymasını sıfırda tutmanın yolu bu.

Hangi müdahale hangi ölçütü düzeltir

Bir sayfada sorun görüldüğünde nereye bakılacağını bilmek zaman kazandırıyor.

Ne söz veriyoruz, ne söz vermiyoruz

Açık olmakta fayda var, çünkü bu alanda abartılı vaat çok.

Söz verdiğimiz: Projeye başlarken bir performans bütçesi belirliyoruz, tasarımı bu bütçeye göre planlıyoruz, her yayından önce otomatik kapıdan geçiriyoruz ve teslimde ölçüm raporunu paylaşıyoruz. Kendi sitemiz bu yöntemin çalıştığının kanıtı.

Söz vermediğimiz: Her projede 100 puan garantisi. Puanı biz tek başımıza belirlemiyoruz. Sitenize eklenecek üçüncü taraf betikler, dış sohbet servisleri, reklam etiketleri ve barındırma tercihi puanı doğrudan etkiliyor. Bir müşteri yayından sonra üç ayrı izleme betiği eklediğinde puan düşer ve bu teknik bir kusur değil, bir tercihtir.

Ayrıca puanın kendisini tek hedef haline getirmiyoruz. 100 puanlık ama kimseye bir şey anlatmayan bir sayfa, 92 puanlık ama ürünü doğru anlatan bir sayfadan daha başarılı değildir. Hedef, hızlı olan ile etkileyici olan arasında bilinçli bir denge kurmak.

Teklif alırken sorabileceğiniz sorular

Hangi ajansla çalışırsanız çalışın, şu dört soru işin ciddiyetini hızla ortaya koyar.

Birincisi: Projeye başlarken bir performans bütçesi belirliyor musunuz, belirliyorsanız hangi ölçütlerde? Cevap somut sayı içermiyorsa bütçe yok demektir.

İkincisi: Ölçümü nerede yapıyorsunuz, kendi makinenizde mi canlı adreste mi? Yerel ölçüm iyimser sonuç verir.

Üçüncüsü: Yayından sonra bir değişiklik puanı düşürürse bunu nasıl fark ediyorsunuz? Otomatik kontrol yoksa cevap "fark etmiyoruz" olur.

Dördüncüsü: Kendi sitenizin mobil puanı kaç? Bu sorunun cevabı çoğu zaman diğer üçünü de özetler.

Sonuç

3D ile hız arasındaki gerilim gerçek ama çözülmüş bir gerilim. Anahtar, sahneyi sayfanın önüne değil arkasına koymak: içerik önce boyanır, sahne ziyaretçi oradayken kurulur, ağır dosyalar ancak gerektiğinde iner.

Rise of Digital olarak hem Three.js ve WebGL ile 3D web siteleri hem de veri yoğun yazılım arayüzleri geliştiriyoruz ve ikisinde de aynı disiplini uyguluyoruz: baştan konan performans bütçesi, ölçümle doğrulanan tasarım kararları ve yayın öncesi otomatik kapı. Yaptığımız işlerden birini 3D web sitesi tasarımı sayfasında gömülü olarak, çalışır halde görebilirsiniz; tek ürün ölçeğindeki sahneler için 3D örnekler sayfasına bakabilirsiniz.

Mevcut sitenizin ölçüm raporunu bizimle paylaşın, hangi kalemin ne kazandıracağını somut olarak gösterelim.