Ön Uç Performansı 2021: Planlama ve Metrikler

Bu kılavuz, daha iyi müşteri deneyimleri oluşturmanıza yardımcı olmak için ön uç performans izleme , oturum yeniden oynatma ve ürün analitiğini birleştiren bir hizmet olan LogRocket'teki arkadaşlarımız tarafından nazikçe desteklenmiştir. LogRocket , dahil olmak üzere temel ölçümleri izler. DOM tamamlandı, ilk bayta kadar geçen süre, ilk giriş gecikmesi, istemci CPU ve bellek kullanımı. Bugün LogRocket'in ücretsiz deneme sürümünü edinin.

İçindekiler

1. Hazırlanmak: Planlama ve Metrikler
   Performans kültürü, Önemli Web Verileri, performans profilleri, CrUX, Lighthouse, FID, TTI, CLS, cihazlar.
2. Gerçekçi Hedefler Belirleme
   Performans bütçeleri, performans hedefleri, RAIL çerçevesi, 170KB/30KB bütçeler.
3. Çevreyi Tanımlamak
   Bir çerçeve seçme, temel performans maliyeti, Web paketi, bağımlılıklar, CDN, ön uç mimarisi, CSR, SSR, CSR + SSR, statik oluşturma, önceden oluşturma, PRPL modeli.
4. Varlık Optimizasyonları
   Brotli, AVIF, WebP, duyarlı görüntüler, AV1, uyarlanabilir medya yükleme, video sıkıştırma, web yazı tipleri, Google yazı tipleri.
5. Derleme Optimizasyonları
   JavaScript modülleri, modül/nomodül modeli, ağaç sallama, kod bölme, kapsam kaldırma, Web paketi, diferansiyel sunma, web çalışanı, WebAssembly, JavaScript paketleri, React, SPA, kısmi hidrasyon, içe aktarma etkileşimi, 3. taraflar, önbellek.
6. Teslimat Optimizasyonları
   Tembel yükleme, kesişim gözlemcisi, işlemeyi ve kod çözmeyi erteleme, kritik CSS, akış, kaynak ipuçları, düzen kaymaları, hizmet çalışanı.
7. Ağ, HTTP/2, HTTP/3
   OCSP zımbalama, EV/DV sertifikaları, paketleme, IPv6, QUIC, HTTP/3.
8. Test ve İzleme
   Denetim iş akışı, proxy tarayıcıları, 404 sayfası, GDPR tanımlama bilgisi onay istemleri, performans tanılama CSS'si, erişilebilirlik.
9. Hızlı kazanç
10. Her şey tek sayfada
11. Kontrol Listesini İndirin (PDF, Apple Pages, MS Word)
12. Sonraki kılavuzları kaçırmamak için e-posta bültenimize abone olun.

Hazırlanmak: Planlama ve Metrikler

Mikro optimizasyonlar, performansı takip etmek için harikadır, ancak akılda açıkça tanımlanmış hedeflere sahip olmak çok önemlidir - süreç boyunca verilen kararları etkileyecek ölçülebilir hedefler. Birkaç farklı model var ve aşağıda tartışılanlar oldukça fikirli - sadece kendi önceliklerinizi önceden belirlediğinizden emin olun.

1. Bir performans kültürü oluşturun.
   Birçok kuruluşta, ön uç geliştiriciler, altta yatan ortak sorunların tam olarak ne olduğunu ve bunları düzeltmek için hangi stratejilerin kullanılması gerektiğini bilir. Ancak, performans kültürünün yerleşik bir onayı olmadığı sürece, her karar bir departman savaş alanına dönüşecek ve organizasyonu silolara bölecektir. Bir iş paydaşının katılımına ihtiyacınız var ve bunu elde etmek için, hızın - özellikle daha sonra ayrıntılı olarak ele alacağımız Önemli Web Verilerinin - metriklere ve Temel Performans Göstergelerine ne kadar fayda sağladığına dair bir vaka çalışması veya bir kavram kanıtı oluşturmanız gerekir. ( KPI'lar ) umursarlar.

   Örneğin, performansı daha somut hale getirmek için, dönüştürme oranı ile uygulama yükleme süresi arasındaki korelasyonu ve ayrıca işleme performansını göstererek gelir performansının etkisini ortaya çıkarabilirsiniz. Veya arama botu tarama hızı (PDF, sayfa 27–50).

   Geliştirme/tasarım ve işletme/pazarlama ekipleri arasında güçlü bir uyum olmadan, performans uzun vadede sürdürülemez. Müşteri hizmetlerine ve satış ekibine gelen yaygın şikayetleri inceleyin, yüksek hemen çıkma oranları ve dönüşüm düşüşleri için analitiği inceleyin. Performansı iyileştirmenin bu yaygın sorunlardan bazılarını gidermeye nasıl yardımcı olabileceğini keşfedin. Tartışmayı konuştuğunuz paydaş grubuna göre ayarlayın.

   Hem mobilde hem de masaüstünde (örneğin, Google Analytics ile) performans deneyleri yapın ve sonuçları ölçün. Gerçek verilerle şirkete özel bir vaka çalışması oluşturmanıza yardımcı olacaktır. Ayrıca, WPO İstatistikleri'nde yayınlanan vaka çalışmaları ve deneylerden elde edilen verilerin kullanılması, performansın neden önemli olduğu ve bunun kullanıcı deneyimi ve iş metrikleri üzerinde ne gibi bir etkisi olduğu konusunda iş dünyasının duyarlılığını artırmaya yardımcı olacaktır. Performansın tek başına önemli olduğunu söylemek yeterli değil - ayrıca bazı ölçülebilir ve izlenebilir hedefler belirlemeniz ve bunları zaman içinde gözlemlemeniz gerekir.

   Oraya nasıl gidilir? Uzun Vadede Performans Oluşturma konulu konuşmasında Allison McKnight, Etsy'de (slaytlar) bir performans kültürünün oluşturulmasına nasıl yardımcı olduğuna dair kapsamlı bir vaka çalışmasını paylaşıyor. Daha yakın zamanlarda, Tammy Everts, hem küçük hem de büyük kuruluşlardaki son derece etkili performans ekiplerinin alışkanlıklarından bahsetti.

   Kuruluşlarda bu konuşmaları yaparken, UX'in bir deneyimler yelpazesi olduğu gibi, web performansının da bir dağıtım olduğunu akılda tutmak önemlidir. Karolina Szczur'un belirttiği gibi, "tek bir sayının arzu edilen bir derecelendirme sağlayabilmesini beklemek hatalı bir varsayımdır." Bu nedenle performans hedeflerinin ayrıntılı, izlenebilir ve somut olması gerekir.

1. Hedef: En hızlı rakibinizden en az %20 daha hızlı olun.
   Psikolojik araştırmalara göre, kullanıcıların web sitenizin rakibinizin web sitesinden daha hızlı olduğunu hissetmesini istiyorsanız, en az %20 daha hızlı olmanız gerekir. Ana rakiplerinizi inceleyin, mobil ve masaüstünde nasıl performans gösterdiğine dair metrikler toplayın ve onları geride bırakmanıza yardımcı olacak eşikler belirleyin. Yine de doğru sonuçlar ve hedefler elde etmek için, önce analitiklerinizi inceleyerek kullanıcılarınızın deneyiminin kapsamlı bir resmini aldığınızdan emin olun. Ardından, test için 90. yüzdelik dilimin deneyimini taklit edebilirsiniz.

   Rakiplerinizin nasıl performans gösterdiğine dair iyi bir ilk izlenim elde etmek için Chrome UX Report'u ( CrUX , hazır bir RUM veri seti, Ilya Grigorik'in video tanıtımı ve Rick Viscomi'nin ayrıntılı kılavuzu) veya bir RUM izleme aracı olan Treo'yu kullanabilirsiniz. Chrome UX Raporu tarafından desteklenmektedir. Veriler, Chrome tarayıcı kullanıcılarından toplanır, bu nedenle raporlar Chrome'a ​​özel olacaktır, ancak size çok çeşitli ziyaretçileriniz arasında, en önemlisi Önemli Web Verileri puanları olmak üzere, size oldukça kapsamlı bir performans dağılımı sağlayacaktır. Yeni CrUX veri kümelerinin her ayın ikinci Salı günü yayınlandığını unutmayın.

   Alternatif olarak şunları da kullanabilirsiniz:

   • Addy Osmani'nin Chrome UX Rapor Karşılaştırma Aracı,
   • Hız Puan Kartı (ayrıca bir gelir etkisi tahmincisi sağlar),
   • Gerçek Kullanıcı Deneyimi Testi Karşılaştırması veya
   • SiteSpeed ​​CI (sentetik teste dayalı).

   Not : Page Speed ​​Insights veya Page Speed ​​Insights API kullanıyorsanız (hayır, kullanımdan kaldırılmamıştır!), yalnızca toplamlar yerine belirli sayfalar için CrUX performans verilerini alabilirsiniz. Bu veriler, "açılış sayfası" veya "ürün listeleme" gibi varlıklar için performans hedefleri belirlemek için çok daha faydalı olabilir. Ve bütçeleri test etmek için CI kullanıyorsanız, hedefi belirlemek için CrUX kullandıysanız, test edilen ortamınızın CrUX ile eşleştiğinden emin olmanız gerekir ( teşekkürler Patrick Meenan! ).

   Hıza öncelik verilmesinin ardındaki mantığı göstermek için biraz yardıma ihtiyacınız varsa veya dönüşüm oranındaki düşüşü veya daha düşük performansla hemen çıkma oranındaki artışı görselleştirmek istiyorsanız veya belki de kuruluşunuzda bir RUM çözümünü savunmanız gerekiyorsa, Sergey Chernyshev, verileri simüle etmenize ve noktanızı yönlendirmek için görselleştirmenize yardımcı olan açık kaynaklı bir araç olan bir UX Hız Hesaplayıcı oluşturdu.

   

   

   Bazen, yavaşlamaların, kör noktaların ve verimsizliklerin nerede olduğunu - rakipleriniz veya projeniz için - hızlı bir şekilde çalışmak zorunda olduğunuz diğer verilerle CrUX'tan gelen verileri birleştirerek biraz daha derine inmek isteyebilirsiniz. Harry Roberts, çalışmasında, performansı önemli sayfa türlerine göre ayırmak ve bunlar arasında ne kadar farklı temel metriklerin olduğunu izlemek için kullandığı bir Site Hızında Topografi Elektronik Tablosu kullanıyor. E-tabloyu Google E-Tablolar, Excel, OpenOffice belgesi veya CSV olarak indirebilirsiniz.

   

   Ve sonuna kadar gitmek istiyorsanız, bir sitenin her sayfasında (Lightouse Parade aracılığıyla) bir çıktı CSV olarak kaydedilmiş bir Lighthouse performans denetimi çalıştırabilirsiniz. Bu, rakiplerinizin hangi belirli sayfalarının (veya sayfa türlerinin) daha kötü veya daha iyi performans gösterdiğini ve çabalarınızı neye odaklamak isteyebileceğinizi belirlemenize yardımcı olacaktır. (Yine de kendi siteniz için verileri bir analitik uç noktasına göndermek muhtemelen daha iyidir!).

   

   Veri toplayın, bir elektronik tablo oluşturun, %20'den tasarruf edin ve hedeflerinizi ( performans bütçeleri ) bu şekilde belirleyin. Artık test etmek için ölçülebilir bir şeye sahipsiniz. Bütçeyi aklınızda tutuyorsanız ve hızlı bir etkileşim süresi elde etmek için yalnızca minimum yükü indirmeye çalışıyorsanız, makul bir yoldasınız demektir.

   Başlamak için kaynaklara mı ihtiyacınız var?

   • Addy Osmani, performans bütçelemeye nasıl başlayacağınız, yeni özelliklerin etkisinin nasıl ölçüleceği ve bütçeyi aştığınızda nereden başlayacağınız konusunda çok ayrıntılı bir yazı yazdı.
   • Lara Hogan'ın performans bütçesi ile tasarımlara nasıl yaklaşılacağına dair kılavuzu, tasarımcılara faydalı ipuçları sağlayabilir.
   • Harry Roberts, İstek Haritası'nı kullanarak üçüncü taraf komut dosyalarının performans üzerindeki etkisini görüntülemek için bir Google E-Tablosu oluşturmaya ilişkin bir kılavuz yayınladı.
   • Jonathan Fielding'in Performans Bütçesi Hesaplayıcısı, Katie Hempenius'un mükemmel bütçe hesaplayıcısı ve Tarayıcı Kalorileri bütçe oluşturmaya yardımcı olabilir (ilgi için Karolina Szczur'a teşekkürler).
   • Birçok şirkette, performans bütçeleri hevesli değil, pragmatik olmalı ve belirli bir noktayı geçmemek için bir tutma işareti olarak hizmet etmelidir. Bu durumda eşik olarak son iki haftadaki en kötü veri noktanızı seçip oradan alabilirsiniz. Performans Bütçeleri, Pragmatik olarak size bunu başarmak için bir strateji gösterir.
   • Ayrıca, yapı boyutlarını bildiren grafikler içeren panolar ayarlayarak hem performans bütçesini hem de mevcut performansı görünür hale getirin. Bunu başarmanıza izin veren birçok araç vardır: SiteSpeed.io kontrol paneli (açık kaynak), SpeedCurve ve Calibre bunlardan sadece birkaçıdır ve perf.rocks'ta daha fazla araç bulabilirsiniz.

   

   Bir bütçeniz olduğunda, çekme taleplerinde bütçeleri zorlamak ve PR yorumlarında bir puan geçmişi sağlamak için bunları Web Paketi Performans İpuçları ve Bundlesize, Lighthouse CI, PWMetrics veya Sitespeed CI ile oluşturma sürecinize dahil edin.

   Performans bütçelerini tüm ekibe göstermek için Lighthouse'a Lighthouse üzerinden performans bütçelerini entegre edin veya hızlı Github Actions entegrasyonu için LHCI Action'ı kullanın. Ve özel bir şeye ihtiyacınız varsa, WebPagetest sonuçlarından grafikler oluşturmak için bir uç nokta API'si olan webpagetest-charts-api'yi kullanabilirsiniz.

   Performans farkındalığı, yalnızca performans bütçelerinden gelmemelidir. Tıpkı Pinterest gibi, bağımlılık açısından ağır olduğu bilinen ve paketi şişirecek dosyalardan ve dizinlerden içe aktarmaya izin vermeyen özel bir eslint kuralı oluşturabilirsiniz. Tüm ekip arasında paylaşılabilecek "güvenli" paketlerin bir listesini oluşturun.

   Ayrıca, işiniz için en faydalı olan kritik müşteri görevlerini düşünün. Kritik eylemler için kabul edilebilir zaman eşiklerini inceleyin, tartışın ve tanımlayın ve tüm kuruluşun onayladığı "UX'e hazır" kullanıcı zamanlama işaretlerini belirleyin. Çoğu durumda, kullanıcı yolculukları birçok farklı departmanın çalışmasına değinecektir, bu nedenle kabul edilebilir zamanlamalar açısından uyum, yolda performans tartışmalarını desteklemeye veya önlemeye yardımcı olacaktır. Eklenen kaynakların ve özelliklerin ek maliyetlerinin görünür ve anlaşılır olduğundan emin olun.

   Performans çabalarını, inşa edilen ürünün yeni özelliklerinden yeniden düzenlemeye ve yeni küresel izleyicilere ulaşmaya kadar değişen diğer teknik girişimlerle uyumlu hale getirin. Bu nedenle, daha fazla gelişme hakkında bir konuşma her gerçekleştiğinde, performans da bu konuşmanın bir parçasıdır. Kod tabanı yeni olduğunda veya yeniden düzenleme aşamasındayken performans hedeflerine ulaşmak çok daha kolaydır.

   Ayrıca, Patrick Meenan'ın önerdiği gibi, tasarım sürecinde bir yükleme sırası ve ödünleşimler planlamaya değer. Hangi parçaların daha kritik olduğuna erkenden öncelik verirseniz ve bunların hangi sırayla ortaya çıkacağını tanımlarsanız, nelerin gecikebileceğini de bilirsiniz. İdeal olarak, bu sıra CSS ve JavaScript içe aktarmalarınızın sırasını da yansıtacaktır, bu nedenle bunları derleme işlemi sırasında kullanmak daha kolay olacaktır. Ayrıca, sayfa yüklenirken (örneğin web yazı tipleri henüz yüklenmediğinde) "arada" durumlarında görsel deneyimin ne olması gerektiğini düşünün.

   Kuruluşunuzda güçlü bir performans kültürü oluşturduktan sonra, zaman geçtikçe öncelikleri hassas tutmak için eski halinizden %20 daha hızlı olmayı hedefleyin ( teşekkürler Guy Podjarny! ). Ancak, müşterilerinizin farklı türlerini ve kullanım davranışlarını (Tobias Baldauf'un kadans ve kohortlar olarak adlandırdığı), bot trafiği ve mevsimsellik etkileriyle birlikte hesaba katın.

   Planlama, planlama, planlama. Bazı hızlı "düşük kalıcı" optimizasyonlara erkenden girmek cazip gelebilir - ve hızlı kazançlar için iyi bir strateji olabilir - ancak gerçekçi bir planlama ve ayarlama yapmadan performansı bir öncelik olarak tutmak çok zor olacaktır. -özel performans hedefleri.

1. Doğru metrikleri seçin.
   Tüm metrikler eşit derecede önemli değildir. Uygulamanız için hangi metriklerin en önemli olduğunu inceleyin: genellikle, bu , arayüzünüzün en önemli piksellerini ne kadar hızlı oluşturmaya başlayabileceğiniz ve bu oluşturulan pikseller için ne kadar hızlı girdi yanıtı sağlayabileceğinizle tanımlanır. Bu bilgi, devam eden çabalar için size en iyi optimizasyon hedefini verecektir. Sonunda, deneyimi tanımlayan yükleme olayları veya sunucu yanıt süreleri değil, arayüzün ne kadar hızlı hissettirdiği algısıdır.

   Bunun anlamı ne? Tam sayfa yükleme süresine odaklanmak yerine (örneğin onLoad ve DOMContentLoaded zamanlamaları aracılığıyla), müşterilerinizin algıladığı şekilde sayfa yüklemeye öncelik verin. Bu, biraz farklı bir metrik grubuna odaklanmak anlamına gelir. Aslında, doğru metriği seçmek, bariz kazananların olmadığı bir süreçtir.

   Tim Kadlec'in araştırmasına ve Marcos Iglesias'ın konuşmasındaki notlarına dayanarak, geleneksel ölçütler birkaç kümeye ayrılabilir. Genellikle, performansın tam bir resmini elde etmek için hepsine ihtiyacımız olacak ve sizin özel durumunuzda bazıları diğerlerinden daha önemli olacaktır.

   • Miktar tabanlı metrikler , istek sayısını, ağırlığı ve performans puanını ölçer. Alarmları yükseltmek ve zaman içindeki değişiklikleri izlemek için iyi, kullanıcı deneyimini anlamak için pek iyi değil.
   • Kilometre taşı ölçümleri , yükleme işleminin ömrü boyunca durumları kullanır, örneğin İlk Bayt Süresi ve Etkileşim Süresi . Kullanıcı deneyimini ve izlemeyi tanımlamak için iyi, kilometre taşları arasında ne olduğunu bilmek için pek iyi değil.
   • İşleme metrikleri , içeriğin ne kadar hızlı işlendiğine dair bir tahmin sağlar (örn. İşleme Başlatma zamanı, Hız İndeksi ). Oluşturma performansını ölçmek ve ince ayar yapmak için iyi, ancak önemli içeriğin ne zaman göründüğünü ve etkileşime girebileceğini ölçmek için çok iyi değil.
   • Özel metrikler , kullanıcı için belirli, özel bir olayı ölçer, örneğin Twitter'ın İlk Tweet'i Atma Zamanı ve Pinterest'in PinnerWaitTime. Kullanıcı deneyimini tam olarak tanımlamak için iyi, metrikleri ölçeklendirmek ve rakiplerle karşılaştırmak için pek iyi değil.

   Resmi tamamlamak için, genellikle tüm bu gruplar arasında yararlı ölçümler arardık. Genellikle, en spesifik ve alakalı olanlar:

   • Etkileşim Zamanı (TTI)
     Düzenin stabilize olduğu nokta , önemli web yazı tiplerinin görünür olduğu ve ana iş parçacığının kullanıcı girişini işlemeye yetecek kadar mevcut olduğu nokta - temel olarak bir kullanıcının kullanıcı arayüzü ile etkileşime girebileceği zaman işareti. Bir kullanıcının siteyi gecikme olmadan kullanmak için ne kadar beklemesi gerektiğini anlamak için temel metrikler. Boris Schapira, TTI'nin nasıl güvenilir bir şekilde ölçüleceğine dair ayrıntılı bir yazı yazdı.
   • İlk Giriş Gecikmesi (FID) veya Giriş yanıtı
     Bir kullanıcının sitenizle ilk etkileşime girdiği andan tarayıcının bu etkileşime gerçekten yanıt verebildiği zamana kadar geçen süre. TTI'yi tamamlar, çünkü resmin eksik kısmını tanımlar: bir kullanıcı siteyle gerçekten etkileşime girdiğinde ne olur. Yalnızca bir RUM metriği olarak tasarlanmıştır. Tarayıcıda FID'yi ölçmek için bir JavaScript kitaplığı vardır.
   • En Büyük İçerikli Boya (LCP)
     Sayfanın önemli içeriği büyük olasılıkla yüklendiğinde, sayfa yükleme zaman çizelgesinde noktayı işaretler. Varsayım, sayfanın en önemli öğesinin, kullanıcının görünümünde görünen en büyük öğe olduğudur. Öğeler ekranın hem üstünde hem de altında işlenirse, yalnızca görünen kısım ilgili kabul edilir.
   • Toplam Bloke Süresi ( TBT )
     Güvenilir bir şekilde etkileşimli hale gelmeden önce bir sayfanın ne kadar etkileşimli olmadığının önem derecesini ölçmeye yardımcı olan bir ölçümdür (yani, ana iş parçacığında en az 5 saniye boyunca 50 ms'nin üzerinde ( uzun görevler ) çalışan herhangi bir görev yoktur). Metrik, ilk boyama ile ana iş parçacığının giriş yanıt vermesini önlemek için yeterince uzun süre engellendiği Etkileşim Süresi (TTI) arasındaki toplam süreyi ölçer. Öyleyse, düşük bir TBT'nin iyi performans için iyi bir gösterge olmasına şaşmamalı. (teşekkürler, Artem, Phil)
   • Kümülatif Düzen Kaydırma ( CLS )
     Metrik, kullanıcıların siteye erişirken ne sıklıkla beklenmedik düzen değişiklikleri ( yeniden akışlar ) yaşadığını vurgular. Kararsız unsurları ve bunların genel deneyim üzerindeki etkilerini inceler. Skor ne kadar düşükse o kadar iyidir.
   • Hız Endeksi
     Sayfa içeriğinin görsel olarak ne kadar hızlı doldurulduğunu ölçer; puan ne kadar düşükse o kadar iyidir. Hız İndeksi puanı, görsel ilerleme hızına göre hesaplanır, ancak bu yalnızca hesaplanmış bir değerdir. Ayrıca görüntü alanı boyutuna duyarlıdır, bu nedenle hedef kitlenizle eşleşen bir dizi test yapılandırması tanımlamanız gerekir. LCP'nin daha alakalı bir ölçüm haline gelmesiyle daha az önemli hale geldiğini unutmayın ( teşekkürler, Boris, Artem! ).
   • harcanan CPU zamanı
     Ana iş parçacığının ne sıklıkta ve ne kadar süreyle engellendiğini gösteren, boyama, oluşturma, komut dosyası oluşturma ve yükleme üzerinde çalışan bir ölçüm. Yüksek CPU süresi, hızlı bir deneyimin açık bir göstergesidir , yani kullanıcı, eylemi ile yanıtı arasında fark edilir bir gecikme yaşadığında. WebPageTest ile, WebPageTest kullanan herhangi bir cihazda çalışırken ana iş parçacığının dökümünü ortaya çıkarmak için "Chrome" sekmesinde "Capture Dev Tools Timeline" öğesini seçebilirsiniz.
   • Bileşen Düzeyinde CPU Maliyetleri
     Tıpkı harcanan CPU zamanında olduğu gibi, Stoyan Stefanov tarafından önerilen bu ölçüm, JavaScript'in CPU üzerindeki etkisini araştırıyor. Buradaki fikir, genel deneyim üzerindeki etkisini ayrı ayrı anlamak için bileşen başına CPU talimat sayısını kullanmaktır. Puppeteer ve Chrome kullanılarak uygulanabilir.
   • Hayal kırıklığıIndex
     Yukarıda belirtilen birçok ölçüm belirli bir olayın ne zaman gerçekleştiğini açıklarken, Tim Vereecke'nin FrustrationIndex'i, ölçümlere tek tek bakmak yerine aralarındaki boşluklara bakar. Başlık görünür, İlk içerik görünür, Görsel olarak hazır ve Sayfa hazır görünüyor gibi son kullanıcı tarafından algılanan kilit kilometre taşlarına bakar ve bir sayfa yüklerken hayal kırıklığı seviyesini gösteren bir puan hesaplar. Boşluk ne kadar büyük olursa, kullanıcının hayal kırıklığına uğrama şansı o kadar artar. Kullanıcı deneyimi için potansiyel olarak iyi bir KPI. Tim, FrustrationIndex ve nasıl çalıştığı hakkında ayrıntılı bir gönderi yayınladı.
   • Reklam Ağırlığı Etkisi
     Siteniz reklamcılıktan elde edilen gelire bağlıysa, reklamla ilgili kodun ağırlığını izlemek yararlıdır. Paddy Ganti'nin komut dosyası iki URL oluşturur (biri normal ve biri reklamları engeller), WebPageTest aracılığıyla bir video karşılaştırması oluşturulmasını ister ve bir delta bildirir.
   • Sapma metrikleri
     Wikipedia mühendisleri tarafından belirtildiği gibi, sonuçlarınızda ne kadar varyans olduğuna dair veriler, araçlarınızın ne kadar güvenilir olduğu ve sapmalara ve aykırı değerlere ne kadar dikkat etmeniz gerektiği konusunda size bilgi verebilir. Büyük fark, kurulumda gereken ayarlamaların bir göstergesidir. Ayrıca, örneğin önemli farklılıklara neden olan üçüncü taraf komut dosyaları nedeniyle belirli sayfaların güvenilir bir şekilde ölçülmesinin daha zor olup olmadığını anlamaya yardımcı olur. Yeni bir tarayıcı sürümü kullanıma sunulduğunda performanstaki artışları anlamak için tarayıcı sürümünü izlemek de iyi bir fikir olabilir.
   • Özel metrikler
     Özel metrikler, iş ihtiyaçlarınız ve müşteri deneyiminiz tarafından tanımlanır. Önemli pikselleri, kritik komut dosyalarını, gerekli CSS'yi ve ilgili varlıkları tanımlamanızı ve bunların kullanıcıya ne kadar hızlı teslim edildiğini ölçmenizi gerektirir. Bunun için Hero Rendering Times'ı izleyebilir veya işiniz için önemli olan olaylar için belirli zaman damgalarını işaretleyerek Performance API'yi kullanabilirsiniz. Ayrıca, bir testin sonunda rastgele JavaScript yürüterek WebPagetest ile özel ölçümler toplayabilirsiniz.

   İlk Anlamlı Boya'nın (FMP) yukarıdaki genel bakışta görünmediğini unutmayın. Sunucunun herhangi bir veriyi ne kadar hızlı çıkardığına dair bir fikir sağlamak için kullanılır. Uzun FMP genellikle JavaScript'in ana iş parçacığını engellediğini belirtir, ancak arka uç/sunucu sorunlarıyla da ilgili olabilir. Bununla birlikte, vakaların yaklaşık %20'sinde doğru olmadığı anlaşıldığından metrik son zamanlarda kullanımdan kaldırılmıştır. Etkili bir şekilde hem daha güvenilir hem de akıl yürütmesi daha kolay olan LCP ile değiştirildi. Artık Lighthouse'da desteklenmiyor. Güvenli sayfada olduğunuzdan emin olmak için en son kullanıcı merkezli performans ölçümlerini ve önerilerini iki kez kontrol edin ( teşekkürler, Patrick Meenan ).

   

   Steve Souders, bu ölçümlerin birçoğunun ayrıntılı bir açıklamasına sahiptir. Etkileşim Süresi, sözde laboratuvar ortamında otomatik denetimler çalıştırılarak ölçülürken, İlk Giriş Gecikmesi, gerçek kullanıcıların gözle görülür bir gecikme yaşadığı gerçek kullanıcı deneyimini temsil eder. Genel olarak, her ikisini de her zaman ölçmek ve izlemek muhtemelen iyi bir fikirdir.

   Uygulamanızın bağlamına bağlı olarak, tercih edilen metrikler farklılık gösterebilir: örneğin Netflix TV kullanıcı arayüzü için tuş girişi yanıt hızı, bellek kullanımı ve TTI daha kritiktir ve Wikipedia için ilk/son görsel değişiklikler ve harcanan CPU süresi ölçümleri daha önemlidir.

   Not : Hem FID hem de TTI, kaydırma davranışını hesaba katmaz; kaydırma, ana iş parçacığı dışında olduğundan bağımsız olarak gerçekleşebilir, bu nedenle birçok içerik tüketim sitesi için bu ölçümler çok daha az önemli olabilir ( teşekkürler Patrick! ).

1. Önemli Web Verilerini ölçün ve optimize edin .
   Uzun bir süre boyunca, performans ölçümleri oldukça teknikti ve sunucuların ne kadar hızlı yanıt verdiğine ve tarayıcıların ne kadar hızlı yüklendiğine ilişkin mühendislik görünümüne odaklanıyordu. Metrikler yıllar içinde değişti - sunucu zamanlamaları yerine gerçek kullanıcı deneyimini yakalamanın bir yolunu bulmaya çalışıyor. Mayıs 2020'de Google, her biri kullanıcı deneyiminin farklı bir yönünü temsil eden bir dizi yeni kullanıcı odaklı performans metriği olan Önemli Web Verilerini duyurdu.

   Google, her biri için bir dizi kabul edilebilir hız hedefi önerir. Bu değerlendirmeyi geçmek için tüm sayfa görüntülemelerinin en az %75'i İyi aralığını aşmalıdır. Bu metrikler hızla ilgi gördü ve Önemli Web Verileri Mayıs 2021'de Google Arama için sıralama sinyalleri haline geldiğinden ( Sayfa Deneyimi sıralama algoritması güncellemesi ), birçok şirket dikkatlerini performans puanlarına çevirdi.

   Bu metrikleri göz önünde bulundurarak deneyimlerinizi optimize etmek için faydalı teknikler ve araçlarla birlikte Temel Web Verilerinin her birini tek tek inceleyelim. (Bu makaledeki genel bir tavsiyeyi izleyerek daha iyi Core Web Vitals puanları alacağınızı belirtmekte fayda var.)

   • En Büyük İçerikli Boya ( LCP ) < 2,5 sn.
     Bir sayfanın yüklenmesini ölçer ve görünüm alanında görünen en büyük resmin veya metin bloğunun oluşturma süresini bildirir. Bu nedenle, LCP önemli bilgilerin işlenmesini erteleyen her şeyden etkilenir - yavaş sunucu yanıt süreleri, CSS'yi engelleme, uçuş sırasında JavaScript (birinci taraf veya üçüncü taraf), web yazı tipi yükleme, pahalı oluşturma veya boyama işlemleri, tembel -yüklü görüntüler, iskelet ekranlar veya istemci tarafı oluşturma.
     
     İyi bir deneyim için, LCP, sayfanın ilk yüklenmeye başladığı andan itibaren 2,5 saniye içinde gerçekleşmelidir. Bu, sayfanın ilk görünür bölümünü mümkün olduğunca erken oluşturmamız gerektiği anlamına gelir. Bu, her şablon için uyarlanmış kritik CSS'yi, <head> sırasını düzenlemeyi ve kritik varlıkları önceden getirmeyi gerektirir (bunları daha sonra ele alacağız).

     Düşük bir LCP puanının ana nedeni genellikle görüntülerdir. İyi optimize edilmiş bir sunucuda barındırılan Hızlı 3G'de <2,5 sn'de bir LCP sunmak, tamamı istemci tarafı oluşturma olmaksızın statik ve özel bir görüntü CDN'sinden gelen bir görüntü ile - maksimum teorik görüntü boyutunun yalnızca 144KB civarında olduğu anlamına gelir. Bu nedenle duyarlı görüntüler önemlidir ve kritik görüntüleri erkenden yükler ( preload ile).

     Hızlı ipucu : Bir sayfada neyin LCP olarak kabul edildiğini keşfetmek için DevTools'ta Performans Panelinde "Zamanlamalar" altındaki LCP rozetinin üzerine gelebilirsiniz ( teşekkürler, Tim Kadlec !).

   • İlk Giriş Gecikmesi ( FID ) < 100ms.
     Kullanıcı arayüzünün yanıt verme hızını, yani tarayıcının bir dokunma veya tıklama gibi ayrı bir kullanıcı giriş olayına tepki vermeden önce diğer görevlerle ne kadar meşgul olduğunu ölçer. Özellikle sayfa yükleme sırasında ana iş parçacığının meşgul olmasından kaynaklanan gecikmeleri yakalamak için tasarlanmıştır.
     
     Amaç, her etkileşim için 50-100 ms içinde kalmaktır. Oraya ulaşmak için, uzun görevleri tanımlamamız (ana iş parçacığını> 50ms için bloke eder) ve bunları bölmemiz, bir paketi birden çok parçaya kodla bölmemiz, JavaScript yürütme süresini azaltmamız, veri getirmeyi optimize etmemiz, üçüncü tarafların komut dosyası yürütmesini ertelememiz gerekir. , JavaScript'i Web çalışanları ile arka plan dizisine taşıyın ve SPA'larda rehidrasyon maliyetlerini azaltmak için aşamalı hidrasyon kullanın.

     Hızlı ipucu : Genel olarak, daha iyi bir FID puanı elde etmek için güvenilir bir strateji, daha büyük paketleri daha küçük paketlere bölerek ve kullanıcının ihtiyaç duyduğu şeyi ihtiyaç duyduğunda sunarak ana iş parçacığı üzerindeki işi en aza indirmektir , böylece kullanıcı etkileşimleri gecikmez . Aşağıda bununla ilgili daha ayrıntılı olarak ele alacağız.

   • Kümülatif Düzen Kayması ( CLS ) < 0.1.
     Sorunsuz ve doğal etkileşimler sağlamak için UI'nin görsel kararlılığını ölçer, yani sayfanın ömrü boyunca meydana gelen her beklenmedik düzen değişikliği için tüm bireysel düzen kaydırma puanlarının toplamı. Halihazırda görünür durumda olan bir öğenin sayfadaki konumunu her değiştirdiğinde, ayrı bir düzen kayması meydana gelir. İçeriğin boyutuna ve hareket ettiği mesafeye göre puanlanır.
     
     Bu nedenle, her kaydırma göründüğünde - örneğin, yedek yazı tiplerinin ve web yazı tiplerinin farklı yazı tipi metrikleri olduğunda veya reklamlar, yerleştirmeler veya iframe'ler geç geldiğinde veya resim/video boyutları ayrılmadığında veya geç CSS yeniden boyamaya zorladığında veya değişiklikler geç JavaScript — CLS puanı üzerinde bir etkisi vardır. İyi bir deneyim için önerilen değer, CLS < 0,1'dir.

   Önemli Web Verilerinin, tahmin edilebilir bir yıllık döngü ile zaman içinde gelişmesi gerektiğini belirtmekte fayda var. İlk yıl güncellemesi için First Contentful Paint'in Core Web Vitals'e yükseltilmesini, azaltılmış bir FID eşiğini ve tek sayfalık uygulamalar için daha iyi desteği bekleyebiliriz. Güvenlik, gizlilik ve erişilebilirlik (!) hususlarının yanı sıra, yük daha fazla ağırlık kazandıktan sonra kullanıcı girdilerine yanıt verilmesini de görebiliriz.

   Önemli Web Verileri ile ilgili olarak, incelemeye değer çok sayıda faydalı kaynak ve makale bulunmaktadır:

   • Web Vitals Leaderboard, puanlarınızı mobil, tablet, masaüstü ve 3G ve 4G üzerindeki rekabetle karşılaştırmanıza olanak tanır.
   • Core SERP Vitals, Google Arama Sonuçlarında CrUX'tan Önemli Web Verilerini gösteren bir Chrome uzantısı.
   • CLS'yi basit bir GIF ile görselleştiren Layout Shift GIF Oluşturucu (komut satırından da edinilebilir).
   • web-vitals kitaplığı, Önemli Web Verilerini toplayabilir ve Google Analytics, Google Etiket Yöneticisi veya diğer herhangi bir analitik uç noktasına gönderebilir.
   • Patrick Meenan'ın WebPageTest'in Önemli Web Verileri hakkındaki verileri nasıl ortaya çıkardığını araştırdığı WebPageTest ile Önemli Web Verilerini Analiz Etme.
   • Addy Osmani ile bir e-Ticaret vaka çalışmasında Temel Web Verilerinin nasıl iyileştirileceğini vurguladığı 50 dakikalık bir video olan Core Web Vitals ile Optimizasyon.
   • Pratikte Kümülatif Düzen Kayması ve Gerçek Dünyada Kümülatif Düzen Kayması, Nic Jansma'nın kapsamlı makaleleridir ve CLS hakkında hemen hemen her şeyi ve bunun Hemen Çıkma Oranı, Oturum Süresi veya Öfke Tıklamaları gibi temel ölçümlerle ilişkisini kapsar.
   • JavaScript'te istendiğinde/çağrıldığında, özelliklerin veya yöntemlerin genel görünümüyle Yeniden Akışı Zorlayan Şey, tarayıcıyı stil ve düzeni eşzamanlı olarak hesaplaması için tetikler.
   • CSS Tetikleyicileri, hangi CSS özelliklerinin Düzen, Boya ve Kompozit'i tetiklediğini gösterir.
   • Düzen Kararsızlığını Düzeltme, düzen kararsızlığı sorunlarını belirlemek ve düzeltmek için WebPageTest'i kullanmanın bir yoludur.
   • Kümülatif Düzen Kayması, Düzen Kararsızlığı Metriği, Boris Schapira'nın CLS, nasıl hesaplandığı, nasıl ölçüleceği ve bunun için nasıl optimize edileceği konusunda çok ayrıntılı bir başka kılavuz.
   • Temel Web Verileri Nasıl İyileştirilir, Simon Hearne tarafından hazırlanan ayrıntılı bir kılavuz (FCP, TTI, TBT gibi diğer Web Verileri dahil), ne zaman ortaya çıktıkları ve nasıl ölçüldükleri hakkında.

   Peki, Temel Web Verileri takip edilmesi gereken nihai ölçümler mi? Pek değil. Cloudflare, Treo, SpeedCurve, Calibre, WebPageTest (zaten film şeridi görünümünde), Newrelic, Shopify, Next.js, tüm Google araçları (PageSpeed ​​Insights, Lighthouse + CI, Search) dahil olmak üzere çoğu RUM çözümü ve platformunda zaten teşhir ediliyorlar. Konsol vb) ve diğerleri.

   Ancak Katie Sylor-Miller'in açıkladığı gibi, Önemli Web Verileri ile ilgili temel sorunlardan bazıları tarayıcılar arası desteğin olmamasıdır, bir kullanıcı deneyiminin tüm yaşam döngüsünü gerçekten ölçmüyoruz, ayrıca FID ve FID'deki değişiklikleri ilişkilendirmek zordur. İş sonuçları ile CLS.

   Önemli Web Verilerinin gelişmesini beklememiz gerektiğinden, performans açısından nerede durduğunuzu daha iyi anlamak için Web Verilerini her zaman özel olarak tasarlanmış ölçümlerinizle birleştirmek yalnızca makul görünüyor.

2. Kitlenizi temsil eden bir cihazda veri toplayın.
   Doğru verileri toplamak için test edilecek cihazları kapsamlı bir şekilde seçmemiz gerekir. Çoğu şirkette bu, analizlere bakmak ve en yaygın cihaz türlerine göre kullanıcı profilleri oluşturmak anlamına gelir. Yine de çoğu zaman analitik tek başına tam bir resim sağlamaz. Hedef kitlenin önemli bir kısmı, deneyimleri çok yavaş olduğu için siteyi terk ediyor (ve geri dönmüyor) olabilir ve cihazlarının bu nedenle analitikte en popüler cihazlar olarak görünmesi pek olası değildir. Bu nedenle, ek olarak hedef grubunuzdaki yaygın cihazlar üzerinde araştırma yapmak iyi bir fikir olabilir.

   IDC'ye göre 2020'de küresel olarak gönderilen tüm cep telefonlarının %84,8'i Android cihazlardır. Ortalama bir tüketici, telefonunu her 2 yılda bir yükseltir ve ABD'de telefon değiştirme döngüsü 33 aydır. Dünya çapında ortalama en çok satan telefonların fiyatı 200 doların altında olacak.

   O halde temsili bir cihaz, en az 24 aylık , maliyeti 200 ABD doları veya daha az olan, yavaş 3G, 400 ms RTT ve 400 kbps aktarımla çalışan, biraz daha karamsar bir Android cihazıdır. Bu, elbette, şirketiniz için çok farklı olabilir, ancak bu, oradaki müşterilerin çoğunluğu için yeterince yakın bir tahmindir. Aslında, hedef pazarınız için mevcut Amazon En Çok Satanları araştırmak iyi bir fikir olabilir. ( İşaretçiler için Tim Kadlec, Henri Helvetica ve Alex Russell'a teşekkürler! ).

   

   O zaman hangi test cihazlarını seçmeli? Yukarıda özetlenen profile iyi uyanlar. Biraz daha eski bir Moto G4/G5 Plus, orta sınıf bir Samsung cihazı (Galaxy A50, S8), Nexus 5X, Xiaomi Mi A3 veya Xiaomi Redmi Note gibi iyi bir orta yol cihazı seçmek iyi bir seçenektir. 7 ve Alcatel 1X veya Cubot X19 gibi yavaş bir cihaz, belki de açık bir cihaz laboratuvarında. Daha yavaş termal kısılmış cihazlarda test yapmak için, fiyatı yaklaşık 100 ABD doları olan bir Nexus 4 de alabilirsiniz.

   Ayrıca, her cihazda kullanılan yonga setlerini kontrol edin ve bir yonga setini aşırı temsil etmeyin : birkaç nesil Snapdragon ve Apple ile düşük kaliteli Rockchip, Mediatek yeterli olacaktır (teşekkürler, Patrick!) .

   Elinizde bir cihaz yoksa, kısılmış bir CPU (5× yavaşlama) ile kısılmış bir 3G ağında (örn. 300ms RTT, 1,6 Mbps aşağı, 0,8 Mbps yukarı) test ederek masaüstünde mobil deneyimi taklit edin. Sonunda normal 3G, yavaş 4G (örneğin 170ms RTT, 9 Mbps aşağı, 9Mbps yukarı) ve Wi-Fi'ye geçin. Performans etkisini daha görünür hale getirmek için Salı günleri 2G'yi tanıtabilir veya daha hızlı test için ofisinizde kısılmış bir 3G/4G ağı kurabilirsiniz.

   Bir mobil cihazda masaüstü makinelere kıyasla 4×–5× yavaşlama beklememiz gerektiğini unutmayın. Mobil cihazların farklı GPU'ları, CPU'ları, bellekleri ve farklı pil özellikleri vardır. Bu nedenle, ortalama bir cihazın iyi bir profiline sahip olmak ve her zaman böyle bir cihazda test etmek önemlidir.



Neyse ki, veri toplamayı otomatikleştirmenize ve bu metriklere göre web sitenizin zaman içinde nasıl performans gösterdiğini ölçmenize yardımcı olacak birçok harika seçenek var. İyi bir performans resminin bir dizi performans metriğini, laboratuvar verilerini ve saha verilerini kapsadığını unutmayın:

• Sentetik test araçları , önceden tanımlanmış cihaz ve ağ ayarları (örn. Lighthouse , Calibre , WebPageTest ) ile tekrarlanabilir bir ortamda laboratuvar verilerini toplar ve
• Gerçek Kullanıcı İzleme ( RUM ) araçları, kullanıcı etkileşimlerini sürekli olarak değerlendirir ve saha verilerini toplar (örn . SpeedCurve , New Relic — araçlar da sentetik testler sağlar).

İlki, ürün üzerinde çalışırken performans sorunlarını belirlemenize, yalıtmanıza ve düzeltmenize yardımcı olacağından, geliştirme sırasında özellikle yararlıdır. İkincisi, uzun vadeli bakım için kullanışlıdır, çünkü performans darboğazlarınızı canlı olarak meydana gelirken - kullanıcılar siteye gerçekten eriştiğinde - anlamanıza yardımcı olacaktır.

Gezinme Zamanlaması, Kaynak Zamanlaması, Boyama Zamanlaması, Uzun Görevler vb. gibi yerleşik RUM API'lerinden yararlanarak, sentetik test araçları ve RUM birlikte uygulamanızdaki performansın eksiksiz bir resmini sunar. Performans izleme için harika seçenekler olan Calibre, Treo, SpeedCurve, mPulse ve Boomerang, Sitespeed.io'yu kullanabilirsiniz. Ayrıca, Sunucu Zamanlama başlığı ile arka uç ve ön uç performansını tek bir yerden bile izleyebilirsiniz.

Not : Tarayıcının dışında, ağ düzeyinde kısıcıları seçmek her zaman daha güvenli bir bahistir, çünkü örneğin, DevTools'un uygulanma şekli nedeniyle HTTP/2 push ile etkileşimde sorunlar vardır ( teşekkürler, Yoav, Patrick !). Mac OS için Network Link Conditioner, Windows Windows Traffic Shaper, Linux netem ve FreeBSD dummynet için kullanabiliriz.

Deniz Feneri'nde test etme olasılığınız yüksek olduğundan, şunları yapabileceğinizi unutmayın:

• Lighthouse puanlarını zaman içinde izlemek için Lighthouse CI'yi kullanın (oldukça etkileyici),
• Her PR ile birlikte bir Lighthouse raporu almak için GitHub Actions'da Lighthouse'u çalıştırın,
• bir sitenin her sayfasında (Lightouse Parade aracılığıyla) bir çıktı CSV olarak kaydedilmiş olarak bir Lighthouse performans denetimi çalıştırın,
• Daha fazla ayrıntıya dalmanız gerekiyorsa, Deniz Feneri Puan Hesaplayıcı ve Deniz Feneri metrik ağırlıklarını kullanın.
• Lighthouse, Firefox için de mevcuttur, ancak kaputun altında PageSpeed ​​Insights API'sini kullanır ve başsız bir Chrome 79 Kullanıcı Aracısına dayalı bir rapor oluşturur.

1. Test için "temiz" ve "müşteri" profilleri ayarlayın.
   Pasif izleme araçlarında testler çalıştırırken, anti-virüs ve arka plan CPU görevlerini kapatmak, arka plan bant genişliği aktarımlarını kaldırmak ve çarpık sonuçları önlemek için (Firefox ve Chrome'da) tarayıcı uzantıları olmadan temiz bir kullanıcı profili ile test etmek yaygın bir stratejidir.

   

   Ancak, müşterilerinizin hangi tarayıcı uzantılarını sıklıkla kullandığını araştırmak ve özel "müşteri" profilleriyle de test etmek de iyi bir fikirdir. Aslında, bazı uzantıların uygulamanız üzerinde büyük bir performans etkisi (2020 Chrome Uzantısı Performans Raporu) olabilir ve kullanıcılarınız bunları çok kullanıyorsa, bunu önceden hesaba katmak isteyebilirsiniz. Bu nedenle, tek başına "temiz" profil sonuçları aşırı iyimserdir ve gerçek yaşam senaryolarında ezilebilir.

2. Performans hedeflerini iş arkadaşlarınızla paylaşın.
   Sırada yanlış anlamaları önlemek için performans hedeflerinin ekibinizin her üyesine aşina olduğundan emin olun. Tasarım, pazarlama veya aradaki herhangi bir karar olsun, her kararın performans sonuçları vardır ve sorumluluğun ve sahipliğin tüm ekip arasında dağıtılması, daha sonra performans odaklı kararları kolaylaştıracaktır. Tasarım kararlarını performans bütçesine ve önceden tanımlanmış önceliklere göre haritalayın.

İçindekiler

1. Hazırlanmak: Planlama ve Metrikler
2. Gerçekçi Hedefler Belirleme
3. Çevreyi Tanımlamak
4. Varlık Optimizasyonları
5. Derleme Optimizasyonları
6. Teslimat Optimizasyonları
7. Ağ, HTTP/2, HTTP/3
8. Test ve İzleme
9. Hızlı kazanç
10. Her şey tek sayfada
11. Kontrol Listesini İndirin (PDF, Apple Pages, MS Word)
12. Sonraki kılavuzları kaçırmamak için e-posta bültenimize abone olun.