Ön Uç Performansı 2021: Test Etme ve İzleme

Yayınlanan: 2022-03-10
Kısa özet ↬ 2021'i hızlı yapalım! Metriklerden araçlara ve ön uç tekniklerine kadar, bugün web'de hızlı deneyimler oluşturmak için bilmeniz gereken her şeyi içeren yıllık bir ön uç performans kontrol listesi. 2016'dan beri güncellendi.

İç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.

Test ve İzleme

  1. Denetim iş akışınızı optimize ettiniz mi?
    Kulağa çok büyük bir şey gibi gelmeyebilir, ancak doğru ayarların parmaklarınızın ucunda olması, test etmede size biraz zaman kazandırabilir. WebPageTest'in genel örneğine bir test göndermek için Tim Kadlec'in WebPageTest için Alfred İş Akışını kullanmayı düşünün. Aslında, WebPageTest'in pek çok belirsiz özelliği vardır, bu nedenle performans sorunlarını daha hızlı tanılamak ve çözmek için WebPageTest Şelale Görünümü grafiğini ve WebPageTest Bağlantı Görünümü grafiğini nasıl okuyacağınızı öğrenmek için zaman ayırın.

    Ayrıca bir Google E-Tablosundan WebPageTest'i çalıştırabilir ve erişilebilirlik, performans ve SEO puanlarını Lighthouse CI ile Travis kurulumunuza veya doğrudan Webpack'e dahil edebilirsiniz.

    Birden çok kaynaktan performans verilerinin otomatik olarak toplanmasını sağlayan modüler bir araç olan ve yakın zamanda piyasaya sürülen AutoWebPerf'e bir göz atın. Örneğin, CrUX API'sinden alan verilerini ve PageSpeed ​​Insights'tan bir Lighthouse raporundan laboratuvar verilerini yakalamak için kritik sayfalarınızda günlük bir test ayarlayabiliriz.

    Ve bir şeyi hızlı bir şekilde hata ayıklamanız gerekiyorsa, ancak oluşturma süreciniz oldukça yavaş görünüyorsa, "boşluk kaldırma ve sembol değiştirmenin çoğu JavaScript için küçültülmüş koddaki boyut küçültmenin %95'ini oluşturduğunu - ayrıntılı kod dönüşümlerini değil. Uglify yapılarını 3 ila 4 kat hızlandırmak için sıkıştırmayı devre dışı bırakın."

GitHub'ın Çekme İsteği bildiriminin, incelemenin gerekli olduğunu ve kontroller başarıyla çözülene kadar birleştirmenin engellendiğini belirten ekran görüntüsü
Lighthouse CI ile erişilebilirlik, performans ve SEO puanlarını Travis kurulumunuza entegre etmek, katkıda bulunan tüm geliştiriciler için yeni bir özelliğin performans etkisini vurgulayacaktır. (Görüntü kaynağı) (Geniş önizleme)
  1. Proxy tarayıcılarda ve eski tarayıcılarda test ettiniz mi?
    Chrome ve Firefox'ta test etmek yeterli değil. Web sitenizin proxy tarayıcılarda ve eski tarayıcılarda nasıl çalıştığını inceleyin. Örneğin, UC Tarayıcı ve Opera Mini Asya'da önemli bir pazar payına sahiptir (Asya'da %35'e kadar). Yolda büyük sürprizlerden kaçınmak için ilgilendiğiniz ülkelerdeki ortalama İnternet hızını ölçün. Ağ daraltma ile test edin ve yüksek DPI'lı bir cihazı taklit edin. BrowserStack, uzak gerçek cihazlarda test etmek için harikadır ve ofisinizdeki en az birkaç gerçek cihazla onu tamamlar - buna değer.
  1. 404 sayfanızın performansını test ettiniz mi?
    Normalde 404 sayfa söz konusu olduğunda ikinci kez düşünmeyiz. Sonuçta, bir istemci sunucuda olmayan bir sayfa istediğinde, sunucu bir 404 durum kodu ve ilgili 404 sayfası ile yanıt verecektir. O kadar çok şey yok, değil mi?

    404 yanıtının önemli bir yönü, tarayıcıya gönderilen gerçek yanıt gövdesi boyutudur . Matt Hobbs'un 404 sayfalık araştırmasına göre, 404 yanıtın büyük çoğunluğu eksik favori simgelerden, WordPress yükleme isteklerinden, bozuk JavaScript isteklerinden, bildirim dosyalarından ve ayrıca CSS ve yazı tipi dosyalarından geliyor. Bir müşteri var olmayan bir varlık talep ettiğinde, bir 404 yanıtı alırlar ve bu yanıt genellikle çok büyüktür.

    404 sayfanız için önbelleğe alma stratejisini incelediğinizden ve optimize ettiğinizden emin olun. Amacımız, tarayıcıya yalnızca bir HTML yanıtı beklediğinde HTML sunmak ve diğer tüm yanıtlar için küçük bir hata yükü döndürmektir. Matt'e göre, "Eğer kaynağımızın önüne bir CDN yerleştirirsek, 404 sayfalık yanıtı CDN'de önbelleğe alma şansımız olur. CDN'nin önbelleğe alınmış bir sürümle yanıt vermesine izin vermek yerine, kaynak sunucuyu her 404 isteğine yanıt vermeye zorlamak."

    404 hataları yalnızca performansınıza zarar vermekle kalmaz, aynı zamanda trafiğe de mal olabilir, bu nedenle Lighthouse test paketinize bir 404 hata sayfası eklemek ve zaman içindeki puanını izlemek iyi bir fikirdir.

  2. GDPR onay istemlerinizin performansını test ettiniz mi?
    GDPR ve CCPA zamanlarında, AB müşterilerinin izlemeyi etkinleştirme veya izlemeyi devre dışı bırakma seçenekleri sağlamak için üçüncü taraflara güvenmek yaygınlaştı. Ancak, diğer herhangi bir üçüncü taraf komut dosyasında olduğu gibi, performanslarının tüm performans çabası üzerinde oldukça yıkıcı bir etkisi olabilir.

    Elbette, gerçek onay, komut dosyalarının genel performans üzerindeki etkisini değiştirecektir, bu nedenle Boris Schapira'nın belirttiği gibi, birkaç farklı web performans profilini incelemek isteyebiliriz:

    • Rıza tamamen reddedildi,
    • Rıza kısmen reddedildi,
    • Muvafakat tamamen verildi.
    • Kullanıcı izin isteminde işlem yapmamış (veya istem bir içerik engelleyici tarafından engellenmiştir),

    Normalde tanımlama bilgisi onay istemlerinin CLS üzerinde bir etkisi olmaması gerekir, ancak bazen etkiler, bu nedenle ücretsiz ve açık kaynak seçenekleri Osano veya tanımlama bilgisi onay kutusu kullanmayı düşünün.

    Genel olarak, fare olayının yatay veya dikey ofsetini belirlemeniz ve açılır pencereyi bağlantıya göre doğru şekilde konumlandırmanız gerekeceğinden, açılır pencere performansını incelemeye değer. Noam Rosenthal, Wikimedia ekibinin öğrendiklerini Web performansı vaka çalışması makalesinde paylaşıyor: Wikipedia sayfası önizlemeleri (video ve dakika olarak da mevcuttur).

  3. Performans tanılama CSS'si tutuyor musunuz?
    Performanssız kodun konuşlandırılmasını sağlamak için her türlü denetimi dahil edebilsek de, genellikle kolayca çözülebilecek bazı düşük asılı meyveler hakkında hızlı bir fikir edinmek yararlıdır. Bunun için Tim Kadlec'in mükemmel Performance Diagnostics CSS'sini kullanabiliriz (Harry Roberts'ın geç yüklenen görüntüleri, boyutlandırılmamış görüntüleri, eski biçimli görüntüleri ve eşzamanlı komut dosyalarını vurgulayan snippet'inden esinlenilmiştir).

    Örneğin, ekranın üst kısmındaki hiçbir resmin tembel yüklenmediğinden emin olmak isteyebilirsiniz. Parçacığı, örneğin kullanılmayan web yazı tiplerini vurgulamak veya simge yazı tiplerini algılamak için ihtiyaçlarınıza göre özelleştirebilirsiniz. Hata ayıklama sırasında hataların görünmesini sağlamak veya yalnızca mevcut projeyi çok hızlı bir şekilde denetlemek için harika bir küçük araç.

    /* Performance Diagnostics CSS */ /* via Harry Roberts. https://twitter.com/csswizardry/status/1346477682544951296 */ img[loading=lazy] { outline: 10px solid red; }
  1. Erişilebilirlik üzerindeki etkisini test ettiniz mi?
    Tarayıcı bir sayfayı yüklemeye başladığında bir DOM oluşturur ve çalışan ekran okuyucu gibi yardımcı bir teknoloji varsa aynı zamanda bir erişilebilirlik ağacı oluşturur. Ekran okuyucunun daha sonra bilgileri almak ve bazen varsayılan olarak bazen de isteğe bağlı olarak kullanıcının kullanımına sunmak için erişilebilirlik ağacını sorgulaması gerekir. Ve bazen zaman alır.

    Hızlı Etkileşime Geçme Süresi hakkında konuşurken, genellikle bir kullanıcının bağlantılara ve düğmelere tıklayarak veya bunlara dokunarak sayfayla ne kadar sürede etkileşime geçebileceğinin bir göstergesini kastediyoruz. Ekran okuyucularda bağlam biraz farklıdır. Bu durumda, Hızlı Etkileşim Süresi, ekran okuyucunun belirli bir sayfada gezinmeyi duyurabilmesine ve ekran okuyucu kullanıcısının etkileşim için klavyeye gerçekten basabilmesine kadar ne kadar zaman geçtiği anlamına gelir.

    Leonie Watson, erişilebilirlik performansı ve özellikle yavaş yüklemenin ekran okuyucu duyuru gecikmeleri üzerindeki etkisi hakkında ufuk açıcı bir konuşma yaptı. Ekran okuyucular, hızlı duyurular ve hızlı gezinme için kullanılır ve bu nedenle, görebilen kullanıcılara göre potansiyel olarak daha az sabırlı olabilir.

    JavaScript ile büyük sayfalar ve DOM manipülasyonları, ekran okuyucu duyurularında gecikmelere neden olur. Tam anlamıyla her platformda (Jaws, NVDA, Voiceover, Narrator, Orca) bulunan ekran okuyucular olarak biraz dikkat ve test gerektiren oldukça keşfedilmemiş bir alan.

  2. Sürekli izleme ayarlandı mı?
    WebPagetest'in özel bir örneğine sahip olmak, hızlı ve sınırsız testler için her zaman faydalıdır. Ancak, otomatik uyarılara sahip Sitespeed, Calibre ve SpeedCurve gibi sürekli bir izleme aracı size performansınızın daha ayrıntılı bir resmini verir. İşletmeye özel metrikleri ölçmek ve izlemek için kendi kullanıcı zamanlama işaretlerinizi ayarlayın. Ayrıca, zaman içindeki değişiklikleri izlemek için otomatik performans gerileme uyarıları eklemeyi düşünün.

    Zaman içinde performanstaki değişiklikleri izlemek için RUM çözümlerini kullanmayı inceleyin. Otomatik birim testi benzeri yük testi araçları için, komut dosyası oluşturma API'si ile k6'yı kullanabilirsiniz. Ayrıca SpeedTracker, Lighthouse ve Calibre'ye bakı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.