Ön Uç Performansı 2021: Varlık Optimizasyonları

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

Varlık Optimizasyonları

1. Düz metin sıkıştırma için Brotli kullanın.
   2015'te Google, artık tüm modern tarayıcılarda desteklenen yeni bir açık kaynaklı kayıpsız veri biçimi olan Brotli'yi tanıttı. Brotli için bir kodlayıcı ve kod çözücü uygulayan açık kaynaklı Brotli kitaplığı, kodlayıcı için önceden tanımlanmış 11 kalite düzeyine sahiptir ve daha yüksek kalite düzeyi, daha iyi bir sıkıştırma oranı karşılığında daha fazla CPU gerektirir. Daha yavaş sıkıştırma, sonuçta daha yüksek sıkıştırma oranlarına yol açacaktır, ancak yine de Brotli sıkıştırmayı hızlı bir şekilde açar. 4 sıkıştırma düzeyine sahip Brotli'nin Gzip'ten hem daha küçük hem de daha hızlı sıkıştırdığını belirtmekte fayda var.

   Pratikte Brotli, Gzip'ten çok daha etkili görünüyor. Görüşler ve deneyimler farklıdır, ancak siteniz zaten Gzip ile optimize edilmişse, boyut küçültme ve FCP zamanlamalarında en azından tek haneli iyileştirmeler ve en iyi ihtimalle çift haneli iyileştirmeler bekliyor olabilirsiniz. Ayrıca siteniz için Brotli sıkıştırma tasarruflarını da tahmin edebilirsiniz.

   Tarayıcılar, yalnızca kullanıcı HTTPS üzerinden bir web sitesini ziyaret ediyorsa Brotli'yi kabul eder. Brotli yaygın olarak desteklenir ve birçok CDN onu destekler (Akamai, Netlify Edge, AWS, KeyCDN, Fastly (şu anda yalnızca geçiş olarak), Cloudflare, CDN77) ve Brotli'yi henüz desteklemeyen CDN'lerde bile etkinleştirebilirsiniz (bir servis çalışanı ile).

   Buradaki sorun şu ki, Brotli ile tüm varlıkları yüksek sıkıştırma düzeyinde sıkıştırmak pahalı olduğundan, birçok barındırma sağlayıcısı, ürettiği büyük maliyet yükü nedeniyle bunu tam ölçeklendirmede kullanamaz. Aslında, en yüksek sıkıştırma düzeyinde, Brotli o kadar yavaştır ki, dosya boyutundaki olası kazançlar, sunucunun varlığı dinamik olarak sıkıştırmayı beklerken yanıtı göndermeye başlaması için geçen süre tarafından geçersiz kılınabilir. (Ancak statik sıkıştırma ile build süresinde vaktiniz varsa tabii ki daha yüksek sıkıştırma ayarları tercih edilir.)

   

   Gerçi bu değişiyor olabilir. Brotli dosya biçimi yerleşik bir statik sözlük içerir ve birden çok dilde çeşitli dizeler içermesine ek olarak, bu sözcüklere birden çok dönüşüm uygulama seçeneğini de destekleyerek çok yönlülüğünü artırır. Felix Hanau, araştırmasında, "sözlüğün varsayılandan daha özel bir alt kümesini" kullanarak ve kompresöre bir kullanıp kullanmayacağını söylemek için Content-Type başlığına güvenerek 5. ila 9. düzeylerde sıkıştırmayı iyileştirmenin bir yolunu keşfetti. HTML, JavaScript veya CSS için sözlük. Sonuç, "web içeriğini sınırlı bir sözlük kullanımı yaklaşımı kullanarak yüksek sıkıştırma seviyelerinde sıkıştırırken ihmal edilebilir bir performans etkisi (normalde %12'ye kıyasla %1 ila %3 daha fazla CPU)" oldu.

   

   Bunun da ötesinde, Elena Kirilenko'nun araştırmasıyla, önceki sıkıştırma artefaktlarını kullanarak hızlı ve verimli Brotli yeniden sıkıştırması elde edebiliriz. Elena'ya göre, "Brotli aracılığıyla sıkıştırılmış bir varlığımız olduğunda ve içeriğin önceden elimizde bulunan içeriğe benzediği hareket halindeyken dinamik içeriği sıkıştırmaya çalıştığımızda, sıkıştırma sürelerinde önemli iyileştirmeler elde edebiliriz. "

   Durum ne sıklıkla? Örneğin, JavaScript paketleri alt kümelerinin teslimi ile (örneğin, kodun bölümleri istemcide zaten önbelleğe alındığında veya WebBundles ile dinamik paket sunumuyla). Veya önceden bilinen şablonlara dayalı dinamik HTML veya dinamik olarak alt kümelenmiş WOFF2 yazı tipleri . Elena'ya göre, içeriğin %10'unu kaldırdığımızda sıkıştırmada %5,3 ve sıkıştırma hızında %39 iyileşme ve içeriğin %50'sini kaldırdığımızda %3,2 daha iyi sıkıştırma oranları ve %26 daha hızlı sıkıştırma elde edebiliyoruz.

   Brotli sıkıştırması daha iyi hale geliyor, bu nedenle statik varlıkları dinamik olarak sıkıştırmanın maliyetini atlayabiliyorsanız, kesinlikle çabaya değer. Brotli'nin HTML, CSS, SVG, JavaScript, JSON vb. gibi herhangi bir düz metin yükü için kullanılabileceğini söylemeye gerek yok.

   Not : 2021'in başlarından itibaren, HTTP yanıtlarının yaklaşık %60'ı metin tabanlı sıkıştırma olmadan, %30.82'si Gzip ile ve %9.1'i Brotli ile sıkıştırılarak (hem mobil hem de masaüstünde) teslim edilir. Örneğin, Angular sayfalarının %23.4'ü sıkıştırılmamıştır (gzip veya Brotli aracılığıyla). Yine de çoğu zaman sıkıştırmayı açmak, basit bir anahtarı çevirerek performansı artırmanın en kolay kazançlarından biridir.

   Strateji? Statik varlıkları en yüksek düzeyde Brotli+Gzip ile önceden sıkıştırın ve Brotli ile 4-6 düzeyinde anında HTML'yi sıkıştırın (dinamik). Sunucunun, Brotli veya Gzip için içerik anlaşmasını düzgün şekilde işlediğinden emin olun.

1. Uyarlanabilir medya yükleme ve istemci ipuçları kullanıyor muyuz?
   Eski haberler diyarından geliyor, ancak srcset , sizes ve <picture> öğesi ile duyarlı görüntüler kullanmak her zaman iyi bir hatırlatmadır. Özellikle medya ayak izinin yoğun olduğu siteler için, yavaş ağlara ve düşük bellekli cihazlara hafif deneyim ve hızlı ağ ve yüksek ağlara tam deneyim sunan uyarlamalı medya yükleme (bu örnekte React + Next.js) ile bir adım daha ileri götürebiliriz. -hafıza aygıtları. React bağlamında, sunucudaki istemci ipuçları ve istemcideki tepki-uyarlamalı kancalar ile bunu başarabiliriz.

   Duyarlı görüntülerin geleceği, istemci ipuçlarının daha geniş çapta benimsenmesiyle önemli ölçüde değişebilir. İstemci ipuçları, HTTP istek başlık alanlarıdır, örneğin DPR , Viewport-Width , Width , Save-Data , Accept (görüntü formatı tercihlerini belirtmek için) ve diğerleri. Kullanıcının tarayıcısı, ekranı, bağlantısı vb. özellikleri hakkında sunucuyu bilgilendirmeleri gerekir.

   Sonuç olarak, sunucu mizanpajı uygun boyuttaki resimlerle nasıl dolduracağına karar verebilir ve sadece bu resimleri istenilen formatlarda sunabilir. İstemci ipuçlarıyla, kaynak seçimini HTML işaretlemesinden istemci ile sunucu arasındaki istek-yanıt anlaşmasına taşırız.

   

   Ilya Grigorik'in bir süre önce belirttiği gibi, müşteri ipuçları resmi tamamlıyor - bunlar duyarlı görüntülere bir alternatif değil. " <picture> öğesi, HTML işaretlemesinde gerekli sanat yönü denetimini sağlar. İstemci ipuçları, kaynak seçimi otomasyonunu etkinleştiren sonuç görüntü istekleri hakkında ek açıklamalar sağlar. Service Worker, istemcide tam istek ve yanıt yönetimi yetenekleri sağlar."

   Örneğin bir hizmet çalışanı, isteğe yeni istemci ipuçları üstbilgi değerleri ekleyebilir , URL'yi yeniden yazabilir ve görüntü isteğini bir CDN'ye yönlendirebilir, yanıtı bağlantıya ve kullanıcı tercihlerine göre uyarlayabilir, vb. Bu yalnızca görüntü varlıkları için değil, aynı zamanda hemen hemen tüm diğer istekler için de.

   İstemci ipuçlarını destekleyen istemciler için, görüntülerde %42 bayt tasarrufu ve 70.+ yüzdelik dilim için 1MB+ daha az bayt ölçülebilir. Smashing Magazine'de de %19-32'lik bir iyileşme ölçebiliriz. İstemci ipuçları Chromium tabanlı tarayıcılarda desteklenir, ancak Firefox'ta hala değerlendirme aşamasındadır.

   Ancak, İstemci İpuçları için hem normal duyarlı görüntü işaretlemesini hem de <meta> etiketini sağlarsanız, destekleyici bir tarayıcı, duyarlı görüntü işaretlemesini değerlendirecek ve İstemci İpuçları HTTP başlıklarını kullanarak uygun görüntü kaynağını isteyecektir.

2. Arka plan resimleri için duyarlı resimler kullanıyor muyuz?
   Kesinlikle yapmalıyız! Artık Safari 14'te ve Firefox dışındaki çoğu modern tarayıcıda desteklenen image-set ile, duyarlı arka plan resimleri de sunabiliyoruz:

   background-image: url("fallback.jpg"); background-image: image-set( "photo-small.jpg" 1x, "photo-large.jpg" 2x, "photo-print.jpg" 600dpi);

   Temelde koşullu olarak 1x tanımlayıcılı düşük çözünürlüklü arka plan resimleri ve 2x tanımlayıcılı daha yüksek çözünürlüklü görüntüler ve hatta 600dpi tanımlayıcılı baskı kalitesinde bir görüntü sunabiliriz. Yine de dikkatli olun: tarayıcılar, yardımcı teknolojiye arka plan görüntüleri hakkında herhangi bir özel bilgi sağlamaz, bu nedenle ideal olarak bu fotoğraflar yalnızca dekorasyon olacaktır.

3. WebP kullanıyor muyuz?
   Görüntü sıkıştırma genellikle hızlı bir kazanç olarak kabul edilir, ancak pratikte hala yeterince kullanılmamaktadır. Elbette görüntüler oluşturmayı engellemez, ancak düşük LCP puanlarına büyük ölçüde katkıda bulunurlar ve sıklıkla tüketildikleri cihaz için çok ağır ve çok büyüktürler.

   Yani en azından görsellerimiz için WebP formatını kullanarak keşfedebiliriz. Aslında, WebP efsanesi, Apple'ın Safari 14'e WebP desteği eklemesiyle geçen yıl sona yaklaşıyor. Dolayısıyla, uzun yıllar süren tartışmalar ve tartışmalardan sonra, bugün itibariyle WebP tüm modern tarayıcılarda destekleniyor. Böylece, WebP görüntülerini <picture> öğesi ve gerekirse bir JPEG yedeği ile (bkz. Andreas Bovens'in kod parçacığı) veya içerik anlaşmasını kullanarak ( Accept başlıklarını kullanarak) sunabiliriz.

   WebP'nin dezavantajları da yoktur. WebP görüntü dosyası boyutları, eşdeğer Guetzli ve Zopfli ile karşılaştırıldığında, biçim JPEG gibi aşamalı oluşturmayı desteklemez; bu nedenle, WebP görüntüleri ağ üzerinden daha hızlı ilerliyor olsa da, kullanıcılar bitmiş görüntüyü iyi bir eski JPEG ile daha hızlı görebilir. JPEG ile, WebP'de olduğu gibi yarı boş bir görüntüye sahip olmak yerine, verilerin yarısı veya hatta çeyreği ile "iyi" bir kullanıcı deneyimi sunabilir ve geri kalanını daha sonra yükleyebiliriz.

   Kararınız neyin peşinde olduğunuza bağlı olacaktır: WebP ile yükü azaltacaksınız ve JPEG ile algılanan performansı iyileştireceksiniz. Google Pascal Massimino'nun WebP Rewind konuşmasında WebP hakkında daha fazla bilgi edinebilirsiniz.

   WebP'ye dönüştürmek için WebP Converter, cwebp veya libwebp kullanabilirsiniz. Ire Aderinokun'un görüntüleri WebP'ye dönüştürme konusunda da çok ayrıntılı bir eğitimi var - ve Josh Comeau'nun modern görüntü formatlarını benimseme konusundaki parçasında da öyle.

   

   Sketch, WebP'yi yerel olarak destekler ve WebP görüntüleri, Photoshop için bir WebP eklentisi kullanılarak Photoshop'tan dışa aktarılabilir. Ama başka seçenekler de mevcut.

   WordPress veya Joomla kullanıyorsanız, WordPress için Optimus ve Önbellek Etkinleştirici ve Joomla'nın kendi desteklenen uzantısı (Cody Arsenault aracılığıyla) gibi WebP desteğini kolayca uygulamanıza yardımcı olacak uzantılar vardır. Ayrıca <picture> öğesini React, stil bileşenleri veya gatsby-image ile soyutlayabilirsiniz.

   Ah — utanmaz fiş! — Jeremy Wagner, WebP ile ilgili her şeyle ilgilenip ilgilenmediğinizi kontrol etmek isteyebileceğiniz WebP üzerine bir Smashing kitabı bile yayınladı.

4. AVIF kullanıyor muyuz?
   Büyük haberi duymuş olabilirsiniz: AVIF indi. AV1 videosunun ana karelerinden türetilen yeni bir görüntü formatıdır. Kayıplı ve kayıpsız sıkıştırmayı, animasyonu, kayıplı alfa kanalını destekleyen ve her ikisinde de daha iyi sonuçlar sağlarken keskin çizgileri ve düz renkleri (JPEG'de bir sorun olan) işleyebilen açık, telifsiz bir formattır.

   Aslında, WebP ve JPEG ile karşılaştırıldığında, AVIF önemli ölçüde daha iyi performans gösterir ve insan görüşüne yaklaşan bir algoritma kullanarak aynı DSSIM'de ((benzersizlik) iki veya daha fazla görüntü arasında %50'ye kadar medyan dosya boyutu tasarrufu sağlar). Aslında, resim yüklemeyi optimize etme konusundaki kapsamlı yazısında Malte Ubl, AVIF'in "çok tutarlı bir şekilde JPEG'den çok önemli bir şekilde daha iyi performans gösterdiğini" belirtiyor. Bu, her zaman JPEG'den daha küçük resimler üretmeyen WebP'den farklıdır ve aslında bir ağ olabilir. aşamalı yükleme için destek eksikliğinden kaynaklanan kayıp."

   

   İronik olarak, AVIF büyük SVG'lerden bile daha iyi performans gösterebilir, ancak elbette SVG'lerin yerine geçmemesi gerekir. Ayrıca HDR renk desteğini destekleyen ilk görüntü formatlarından biridir; daha yüksek parlaklık, renk bit derinliği ve renk gamları sunar. Tek dezavantajı, şu anda AVIF'nin aşamalı görüntü kod çözmeyi desteklememesidir (henüz?) ve Brotli'ye benzer şekilde, kod çözme hızlı olmasına rağmen yüksek sıkıştırma oranlı kodlama şu anda oldukça yavaştır.

   AVIF şu anda Chrome, Firefox ve Opera'da destekleniyor ve Safari'deki desteğin yakında gelmesi bekleniyor (Apple, AV1'i oluşturan grubun bir üyesi olduğu için).

   O halde bu günlerde görselleri sunmanın en iyi yolu nedir? Çizimler ve vektör görüntüler için (sıkıştırılmış) SVG şüphesiz en iyi seçimdir. Fotoğraflar için picture öğesi ile içerik müzakere yöntemlerini kullanıyoruz. AVIF destekleniyorsa, bir AVIF görüntüsü göndeririz; değilse, önce WebP'ye döneriz ve WebP de desteklenmiyorsa, geri dönüş olarak JPEG veya PNG'ye geçeriz (gerekirse @media koşullarını uygulayarak):

   <picture> <source type="image/avif"> <source type="image/webp"> <img src="image.jpg" alt="Photo" width="450" height="350"> </picture>

   Açıkçası, picture öğesi içinde bazı koşulları kullanmamız daha olasıdır:

   <picture> <source type="image/avif" /> <source type="image/webp" /> <source type="image/jpeg" /> <img src="fallback-image.jpg" alt="Photo" width="450" height="350"> </picture>
   <picture> <source type="image/avif" /> <source type="image/webp" /> <source type="image/jpeg" /> <img src="fallback-image.jpg" alt="Photo" width="450" height="350"> </picture>

   prefers-reduced-motion eden müşteriler için hareketli görüntüleri statik görüntülerle değiştirerek daha da ileri gidebilirsiniz:

   <picture> <source media="(prefers-reduced-motion: reduce)" type="image/avif"></source> <source media="(prefers-reduced-motion: reduce)" type="image/jpeg"></source> <source type="image/avif"></source> <img src="motion.jpg" alt="Animated AVIF"> </picture>
   <picture> <source media="(prefers-reduced-motion: reduce)" type="image/avif"></source> <source media="(prefers-reduced-motion: reduce)" type="image/jpeg"></source> <source type="image/avif"></source> <img src="motion.jpg" alt="Animated AVIF"> </picture>

   Birkaç ay içinde AVIF oldukça ilgi gördü:

   • WebP/AVIF yedeklerini DevTools'daki Rendering panelinde test edebiliriz.
   • AVIF dosyalarını kodlamak, kodunu çözmek, sıkıştırmak ve dönüştürmek için Squoosh, AVIF.io ve libavif kullanabiliriz.
   • Bir çalışandaki bir AVIF dosyasının kodunu çözen ve sonucu bir tuval üzerinde görüntüleyen Jake Archibald'ın AVIF Preact bileşenini kullanabiliriz,
   • AVIF'yi yalnızca destekleyen tarayıcılara sunmak için, CSS bildirimlerinizde AVIF'yi kullanmak için 315B komut dosyasıyla birlikte bir PostCSS eklentisi kullanabiliriz.
   • Döndürülen HTML belgesini dinamik olarak değiştirmek, accept başlığından bilgi çıkarmak ve ardından uygun şekilde webp/avif vb. sınıflarını eklemek için CSS ve Cloudlare Workers ile aşamalı olarak yeni görüntü formatları sunabiliriz.
   • AVIF, Cloudinary'de (kullanım limitleri ile) zaten mevcuttur, Cloudflare, Görüntü Yeniden Boyutlandırmada AVIF'yi destekler ve Netlify'da Özel AVIF Başlıkları ile AVIF'yi etkinleştirebilirsiniz.
   • Animasyon söz konusu olduğunda, AVIF Safari'nin <img src=mp4> kadar iyi performans gösterir, GIF ve WebP'den genel olarak daha iyi performans gösterir, ancak MP4 yine de daha iyi performans gösterir.
   • Genel olarak, animasyonlar için, Chromium tabanlı tarayıcıların hiç <img src=mp4> destekleyeceği varsayılarak, AVC1 (h264) > HVC1 > WebP > AVIF > GIF.
   • AVIF hakkında daha fazla ayrıntıyı Netflix'ten Aditya Mavlankar'ın Yeni Nesil Görüntü Kodlama konuşması için AVIF'te ve Cloudflare'den Kornel Lesinski'nin AVIF Görüntü Formatı konuşmasında bulabilirsiniz.
   • AVIF ile ilgili her şey için harika bir referans: Jake Archibald'ın AVIF hakkındaki kapsamlı yazısı geldi.

   Öyleyse gelecek AVIF mi? Jon Sneyers aynı fikirde değil: AVIF, Google ve Cloudinary tarafından geliştirilen başka bir ücretsiz ve açık biçim olan JPEG XL'den %60 daha kötü performans gösteriyor. Aslında, JPEG XL, pano genelinde çok daha iyi performans gösteriyor gibi görünüyor. Ancak, JPEG XL hala standardizasyonun yalnızca son aşamalarındadır ve henüz herhangi bir tarayıcıda çalışmamaktadır. (Microsoft'un eski Internet Explorer'dan 9 kez gelen JPEG-XR'si ile karıştırmamak için).

1. JPEG/PNG/SVG'ler uygun şekilde optimize edilmiş mi?
   Bir kahraman görüntüsünün son derece hızlı yüklenmesinin kritik önem taşıdığı bir açılış sayfasında çalışırken, JPEG'lerin aşamalı olduğundan ve mozJPEG (tarama düzeylerini değiştirerek başlangıç ​​oluşturma süresini iyileştirir) veya Google'ın açık kaynaklı Guetzli ile sıkıştırıldığından emin olun. Algısal performansa odaklanan ve Zopfli ve WebP'den öğrenilenleri kullanan kodlayıcı. Tek dezavantajı: yavaş işlem süreleri (megapiksel başına bir dakikalık CPU).

   PNG için Pingo kullanabiliriz ve SVG için SVGO veya SVGOMG kullanabiliriz. Ve bir web sitesindeki tüm SVG varlıklarını hızlı bir şekilde önizlemeniz ve kopyalamanız veya indirmeniz gerekiyorsa, svg-grabber bunu sizin için de yapabilir.

   Her bir görüntü optimizasyon makalesi bunu belirtir, ancak vektör varlıklarını temiz ve sıkı tutmak her zaman bahsetmeye değer. Kullanılmayan varlıkları temizlediğinizden, gereksiz meta verileri kaldırdığınızdan ve resimdeki (ve dolayısıyla SVG kodundaki) yol noktalarının sayısını azalttığınızdan emin olun. ( Teşekkürler Jeremy! )

   Bununla birlikte, yararlı çevrimiçi araçlar da mevcuttur:

   • Görüntüleri optimum sıkıştırma seviyelerinde (kayıplı veya kayıpsız) sıkıştırmak, yeniden boyutlandırmak ve değiştirmek için Squoosh'u kullanın,
   • JPEG görüntüleri Guetzli ile sıkıştırmak ve optimize etmek için Guetzli.it'i kullanın; bu, keskin kenarlı ve düz renkli görüntüler için iyi çalışır (ancak biraz daha yavaş olabilir).
   • Görüntü optimizasyonunu otomatikleştirmek için Duyarlı Görüntü Kesme Noktaları Oluşturucu'yu veya Cloudinary veya Imgix gibi bir hizmeti kullanın. Ayrıca, çoğu durumda srcset ve sizes tek başına kullanmak önemli faydalar sağlayacaktır.
   • Duyarlı işaretlemenizin verimliliğini kontrol etmek için, görüntüleme alanı boyutları ve cihaz piksel oranları genelinde verimliliği ölçen bir komut satırı aracı olan görüntüleme yığınını kullanabilirsiniz.
   • GitHub iş akışlarınıza otomatik görüntü sıkıştırma ekleyebilirsiniz, böylece hiçbir görüntü sıkıştırılmamış olarak üretime geçemez. Eylem, PNG'ler ve JPG'lerle çalışan mozjpeg ve libvips kullanır.
   • Depolamayı dahili olarak optimize etmek için, JPEG'leri ortalama %22 oranında kayıpsız sıkıştırmak için Dropbox'ın yeni Lepton biçimini kullanabilirsiniz.
   • Erken bir yer tutucu resmi göstermek istiyorsanız BlurHash kullanın. BlurHash bir görüntü alır ve size bu görüntünün yer tutucusunu temsil eden kısa bir dize (sadece 20-30 karakter!) verir. Dize, bir JSON nesnesinde bir alan olarak kolayca eklenebilecek kadar kısadır.

   

   Bazen görüntüleri tek başına optimize etmek işe yaramaz. Kritik bir görüntünün oluşturulmasını başlatmak için gereken süreyi iyileştirmek için, daha az önemli görüntüleri tembel olarak yükleyin ve kritik görüntüler zaten oluşturulduktan sonra tüm komut dosyalarının yüklenmesini erteleyin. En kurşun geçirmez yol, yerel tembel yükleme ve tembel yükleme kullandığımızda, kullanıcı etkileşimi yoluyla tetiklenen görünürlük değişikliklerini algılayan bir kitaplık (daha sonra keşfedeceğimiz IntersectionObserver ile) hibrit tembel yüklemedir. Bunlara ek olarak:

   • Bir tarayıcının onları çok geç keşfetmemesi için kritik görüntüleri önceden yüklemeyi düşünün. Arka plan görüntüleri için, bundan daha agresif olmak istiyorsanız, görüntüyü <img src> ile normal bir görüntü olarak ekleyebilir ve ardından ekrandan gizleyebilirsiniz.
   • Medya sorgularına bağlı olarak farklı görüntü görüntüleme boyutları belirleyerek Boyutlar Özniteliği ile Görüntüleri Değiştirmeyi düşünün, örneğin bir büyüteç bileşenindeki kaynakları değiştirmek için sizes değiştirmek için.
   • Ön plan ve arka plan görüntüleri için beklenmeyen indirmeleri önlemek için görüntü indirme tutarsızlıklarını inceleyin. Varsayılan olarak yüklenen ancak hiçbir zaman görüntülenemeyebilecek resimlere dikkat edin - örneğin atlıkarıncalarda, akordeonlarda ve resim galerilerinde.
   • Görüntülerde her zaman width ve height ayarladığınızdan emin olun. CSS'deki en aspect-ratio özelliğine ve resimler için en boy oranlarını ve boyutları ayarlamamıza izin verecek olan intrinsicsize boyut özelliğine dikkat edin, böylece tarayıcı, sayfa yükleme sırasında mizanpaj atlamalarını önlemek için önceden tanımlanmış bir mizanpaj yuvasını rezerve edebilir.

   

   Maceraperest hissediyorsanız, görüntüleri ağ üzerinden daha hızlı göndermek için temelde CDN'de yaşayan gerçek zamanlı bir filtre olan Edge çalışanlarını kullanarak HTTP/2 akışlarını kesebilir ve yeniden düzenleyebilirsiniz. Edge çalışanları, kontrol edebileceğiniz parçaları kullanan JavaScript akışlarını kullanır (temelde bunlar, akış yanıtlarını değiştirebilen CDN kenarında çalışan JavaScript'tir), böylece görüntülerin teslimini kontrol edebilirsiniz.

   Bir servis çalışanı ile, kabloda ne olduğunu kontrol edemediğiniz için çok geç, ancak Edge çalışanları ile çalışıyor. Böylece, belirli bir açılış sayfası için aşamalı olarak kaydedilen statik JPEG'lerin üzerinde kullanabilirsiniz.

   

   Yeterince iyi değil? Ayrıca, çoklu arka plan görüntüsü tekniğiyle görüntüler için algılanan performansı da artırabilirsiniz. Kontrastla oynamanın ve gereksiz ayrıntıları bulanıklaştırmanın (veya renkleri kaldırmanın) dosya boyutunu da küçültebileceğini unutmayın. Ah, kaliteden ödün vermeden küçük bir fotoğrafı büyütmeniz mi gerekiyor? Letsenhance.io'yu kullanmayı düşünün.

   

   Bu optimizasyonlar şu ana kadar yalnızca temel bilgileri kapsıyor. Addy Osmani, görüntü sıkıştırma ve renk yönetiminin çok derinlerine inen Temel Görüntü Optimizasyonu hakkında çok ayrıntılı bir kılavuz yayınladı. Örneğin, dosya boyutunu küçültmek için görüntünün gereksiz kısımlarını (bunlara bir Gauss bulanıklık filtresi uygulayarak) bulanıklaştırabilir ve sonunda, boyutu daha da küçültmek için renkleri kaldırmaya başlayabilir veya resmi siyah beyaza dönüştürebilirsiniz. . Arka plan görüntüleri için, fotoğrafları Photoshop'tan %0 ila %10 kalitede dışa aktarmak da kesinlikle kabul edilebilir.

   Smashing Magazine'de, resim adları için -opt son ekini kullanıyoruz - örneğin, brotli-compression-opt.png ; bir resim bu son eki içerdiğinde, ekipteki herkes resmin zaten optimize edildiğini bilir.

   Ah, ve web'de JPEG-XR kullanmayın - "JPEG-XR'lerin yazılım tarafında kod çözme işleminin CPU'da işlenmesi, özellikle SPA'lar bağlamında bayt boyutu tasarruflarının potansiyel olarak olumlu etkisini geçersiz kılar ve hatta daha ağır basar" (değil Cloudinary/Google'ın JPEG XL'si ile karıştırmak için).

1. Videolar uygun şekilde optimize edilmiş mi?
   Şimdiye kadar resimleri ele aldık, ancak eski güzel GIF'ler hakkında konuşmaktan kaçındık. GIF'lere olan sevgimize rağmen, onları tamamen terk etmenin zamanı geldi (en azından web sitelerimizde ve uygulamalarımızda). Hem oluşturma performansını hem de bant genişliğini etkileyen ağır animasyonlu GIF'ler yüklemek yerine, animasyonlu WebP'ye (GIF bir geri dönüş olmak üzere) geçmek veya bunları tamamen döngülü HTML5 videoları ile değiştirmek iyi bir fikirdir.

   Görüntülerden farklı olarak, tarayıcılar <video> içeriğini önceden yüklemez, ancak HTML5 videoları GIF'lerden çok daha hafif ve daha küçük olma eğilimindedir. Bir seçenek değil mi? En azından Kayıplı GIF, gifsicle veya giflossy ile GIF'lere kayıplı sıkıştırma ekleyebiliriz.

   Colin Bendell tarafından yapılan testler, Safari Teknoloji Önizlemesi'ndeki img etiketlerindeki satır içi videoların, dosya boyutunda bir kesir olmasının yanı sıra GIF eşdeğerinden en az 20 kat daha hızlı görüntülediğini ve 7 kat daha hızlı kod çözdüğünü gösteriyor. Ancak, diğer tarayıcılarda desteklenmez.

   İyi haberlerin ülkesinde, video formatları yıllar içinde büyük bir ilerleme kaydetti . Uzun bir süre boyunca, WebM'nin hepsine hükmedecek bir format olacağını ve WebP'nin (temelde WebM video konteynerinin içindeki bir hareketsiz görüntüdür) tarihli görüntü formatlarının yerini alacağını ummuştuk. Gerçekten de Safari artık WebP'yi destekliyor, ancak WebP ve WebM'nin bu günlerde destek kazanmasına rağmen, atılım gerçekten olmadı.

   Yine de, çoğu modern tarayıcı için WebM'yi kullanabiliriz:

   <!-- By Houssein Djirdeh. https://web.dev/replace-gifs-with-videos/ --> <!-- A common scenartio: MP4 with a WEBM fallback. --> <video autoplay loop muted playsinline> <source src="my-animation.webm" type="video/webm"> <source src="my-animation.mp4" type="video/mp4"> </video>

   Ama belki de tamamen tekrar gözden geçirebiliriz. 2018'de, Açık Medya İttifakı, AV1 adlı yeni bir gelecek vaat eden video formatı yayınladı. AV1, H.265 codec bileşenine (H.264'ün evrimi) benzer bir sıkıştırmaya sahiptir, ancak ikincisinden farklı olarak AV1 ücretsizdir. H.265 lisans fiyatlandırması, tarayıcı satıcılarını bunun yerine karşılaştırılabilir performans gösteren bir AV1'i benimsemeye itti: AV1 (tıpkı H.265 gibi) WebM'den iki kat daha iyi sıkıştırır .

   

   Aslında, Apple şu anda HEIF biçimini ve HEVC'yi (H.265) kullanır ve en son iOS'taki tüm fotoğraflar ve videolar JPEG yerine bu biçimlerde kaydedilir. HEIF ve HEVC (H.265) web'e (henüz?) uygun şekilde maruz kalmazken, AV1 - ve tarayıcı desteği kazanıyor. Bu nedenle, tüm tarayıcı satıcıları dahil olduğu için AV1 kaynağını <video> etiketinize eklemek mantıklıdır.

   Şu anda, en yaygın kullanılan ve desteklenen kodlama, MP4 dosyaları tarafından sunulan H.264'tür, bu nedenle dosyayı sunmadan önce MP4'lerinizin çoklu geçiş kodlamasıyla işlendiğinden, frei0r iirblur efektiyle (varsa) bulanıklaştırıldığından emin olun ve moov atom meta verileri, sunucunuz bayt sunumunu kabul ederken dosyanın başına taşınır. Boris Schapira, videoları maksimum düzeyde optimize etmek için FFmpeg için kesin talimatlar sağlar. Elbette alternatif olarak WebM formatının sağlanması da yardımcı olacaktır.

   Videoları daha hızlı oluşturmaya başlamanız gerekiyor ancak video dosyaları hala çok mu büyük ? Örneğin, bir açılış sayfasında büyük bir arka plan videonuz olduğunda? Kullanılacak yaygın bir teknik, ilk kareyi önce durağan bir görüntü olarak göstermek veya videonun bir parçası olarak yorumlanabilecek yoğun şekilde optimize edilmiş, kısa döngülü bir segment görüntülemek ve ardından video yeterince arabelleğe alındığında oynatmaya başlamaktır. gerçek video. Doug Sillars, bu durumda yardımcı olabilecek, arka plan video performansına ilişkin ayrıntılı bir kılavuza sahiptir. ( Teşekkürler, Guy Podjarny! ).

   Yukarıdaki senaryo için duyarlı poster resimleri sağlamak isteyebilirsiniz. Varsayılan olarak, video öğeleri poster olarak yalnızca tek bir resme izin verir ve bu mutlaka optimal değildir. Farklı ekranlar için farklı poster görüntüleri kullanmanıza olanak tanıyan ve aynı zamanda geçiş kaplaması ve video yer tutucularının tam stil kontrolünü eklemenize olanak tanıyan bir JavaScript kitaplığı olan Duyarlı Video Posteri'ni kullanabiliriz.

   Araştırma, video akışı kalitesinin izleyici davranışını etkilediğini gösteriyor. Aslında, başlatma gecikmesi yaklaşık 2 saniyeyi aşarsa izleyiciler videoyu terk etmeye başlar. Bu noktanın ötesinde, gecikmede 1 saniyelik bir artış, terk oranında kabaca %5.8'lik bir artışa neden olur. Bu nedenle, videoların %40'ında en az 1 duraklama ve %20'sinde en az 2 saniye duraklamalı video oynatımı ile ortalama video başlangıç ​​süresinin 12,8 sn olması şaşırtıcı değildir. Aslında, videolar ağın içerik sağlayabileceğinden daha hızlı oynatıldığından, 3G'de video durakları kaçınılmazdır.

   Çözüm nedir? Genellikle küçük ekranlı cihazlar, masaüstüne sunduğumuz 720p ve 1080p'yi kaldıramaz. Doug Sillars'a göre, videolarımızın daha küçük sürümlerini oluşturabilir ve bu cihazlarda hızlı ve sorunsuz bir oynatma sağlamak için daha küçük ekranların kaynağını tespit etmek için Javascript kullanabiliriz. Alternatif olarak, video akışı kullanabiliriz. HLS video akışları, cihaza uygun boyutta bir video ileterek farklı ekranlar için farklı videolar oluşturma ihtiyacını ortadan kaldırır. Ayrıca ağ hızıyla ilgili pazarlık yapacak ve video bit hızını kullandığınız ağın hızına göre ayarlayacaktır.

   Bant genişliği israfını önlemek için, yalnızca videoyu gerçekten iyi oynatabilen cihazlar için video kaynağı ekleyebiliriz. Alternatif olarak, autoplay özelliğini video etiketinden tamamen kaldırabilir ve daha büyük ekranlar için autoplay eklemek için JavaScript'i kullanabiliriz. Ek olarak, tarayıcıya, dosyaya gerçekten ihtiyaç duyana kadar herhangi bir video dosyasını indirmemesini söylemek için video preload="none" eklememiz gerekiyor:

   <!-- Based on Doug Sillars's post. https://dougsillars.com/2020/01/06/hiding-videos-on-the-mbile-web/ --> <video preload="none" playsinline muted loop width="1920" height="1080" poster="poster.jpg"> <source src="video.webm" type="video/webm"> <source src="video.mp4" type="video/mp4"> </video>

   Ardından, özellikle AV1'i destekleyen tarayıcıları hedefleyebiliriz:

   <!-- Based on Doug Sillars's post. https://dougsillars.com/2020/01/06/hiding-videos-on-the-mbile-web/ --> <video preload="none" playsinline muted loop width="1920" height="1080" poster="poster.jpg"> <source src="video.av1.mp4" type="video/mp4; codecs=av01.0.05M.08"> <source src="video.hevc.mp4" type="video/mp4; codecs=hevc"> <source src="video.webm" type="video/webm"> <source src="video.mp4" type="video/mp4"> </video>

   Daha sonra autoplay belirli bir eşiğin üzerine yeniden ekleyebiliriz (ör. 1000 piksel):

   /* By Doug Sillars. https://dougsillars.com/2020/01/06/hiding-videos-on-the-mbile-web/ */ <script> window.onload = addAutoplay(); var videoLocation = document.getElementById("hero-video"); function addAutoplay() { if(window.innerWidth > 1000){ videoLocation.setAttribute("autoplay",""); }; } </script>

   

   Video oynatma performansı başlı başına bir hikayedir ve ayrıntılara dalmak isterseniz, Doug Sillars'ın video teslim metrikleriyle ilgili ayrıntıları içeren The Current State of Video ve Video Delivery En İyi Uygulamaları konulu başka bir serisine göz atın. , video ön yükleme, sıkıştırma ve akış. Son olarak, Stream or Not ile video akışınızın ne kadar yavaş veya hızlı olacağını kontrol edebilirsiniz.

1. Web yazı tipi dağıtımı optimize edildi mi?
   Sormaya değer ilk soru, ilk etapta UI sistem yazı tiplerini kullanmaktan kurtulabilir miyiz - çeşitli platformlarda doğru göründüklerini iki kez kontrol etmemiz gerekiyor. Durum böyle değilse, sunduğumuz web yazı tiplerinin kullanılmayan glifler ve ekstra özellikler ve ağırlıklar içerme olasılığı yüksektir. Yazı tipi dökümhanemizden web yazı tiplerini alt kümelere ayırmasını isteyebiliriz veya açık kaynaklı yazı tiplerini kullanıyorsak bunları kendi başımıza Glyphhanger veya Fontsquirrel ile alt kümelere ayırabiliriz. Hatta en uygun web yazı tipi alt kümelerini oluşturmak için sayfanızı statik olarak analiz eden ve ardından bunları sayfalarımıza enjekte eden bir komut satırı aracı olan Peter Muller'in alt yazı tipi ile tüm iş akışımızı otomatikleştirebiliriz.

   WOFF2 desteği harikadır ve onu desteklemeyen tarayıcılar için WOFF'u yedek olarak kullanabiliriz veya belki de eski tarayıcılara sistem yazı tipleri sunulabilir. Web yazı tipi yükleme için pek çok, pek çok seçenek vardır ve Zach Leatherman'ın "Font Yükleme Stratejileri için Kapsamlı Kılavuz"daki stratejilerden birini seçebiliriz (kod parçacıkları Web yazı tipi yükleme tarifleri olarak da mevcuttur).

   Muhtemelen bugün dikkate alınması gereken daha iyi seçenekler, preload Critical FOFT ve "The Uzlaşma" yöntemidir. Her ikisi de web yazı tiplerini adım adım iletmek için iki aşamalı bir oluşturma kullanır - ilk önce sayfayı web yazı tipiyle hızlı ve doğru bir şekilde oluşturmak için küçük bir üst alt küme gerekir ve ardından ailenin geri kalanını eşzamansız olarak yükler. Aradaki fark, "Uzlaşma" tekniğinin çoklu dolguyu yalnızca yazı tipi yükleme olayları desteklenmiyorsa eşzamansız olarak yüklemesidir, bu nedenle varsayılan olarak çoklu dolguyu yüklemeniz gerekmez. Hızlı bir galibiyete mi ihtiyacınız var? Zach Leatherman, yazı tiplerinizi düzene sokmak için 23 dakikalık hızlı bir eğitime ve örnek olay incelemesine sahiptir.

   Genel olarak, yazı tiplerini önceden yüklemek için preload kaynak ipucunu kullanmak iyi bir fikir olabilir, ancak işaretlemenize kritik CSS ve JavaScript bağlantısından sonra ipuçlarını ekleyin. preload ile bir öncelik bulmacası vardır, bu nedenle DOM'a harici engelleme komut dosyalarından hemen önce rel="preload" öğelerini enjekte etmeyi düşünün. Andy Davies'e göre, "Bir komut dosyası kullanılarak enjekte edilen kaynaklar, komut dosyası yürütülene kadar tarayıcıdan gizlenir ve tarayıcı preload ipucunu keşfettiğinde bu davranışı geciktirmek için kullanabiliriz." Aksi takdirde, font yüklemesi ilk render zamanında size pahalıya mal olacaktır.

   

   Seçici olmak ve en önemli dosyaları seçmek iyi bir fikirdir, örneğin, oluşturma için kritik olanlar veya görünür ve rahatsız edici metin yeniden akışlarından kaçınmanıza yardımcı olacak olanlar. Genel olarak, Zach her aileden bir veya iki yazı tipinin önceden yüklenmesini önerir - ayrıca daha az kritik olan bazı yazı tiplerinin yüklenmesini geciktirmek de mantıklıdır.

   @font-face kuralında bir font-family tanımlarken local() değerini (adıyla yerel bir fontu ifade eder) kullanmak oldukça yaygın hale geldi:

    /* Warning! Not a good idea! */ @font-face { font-family: Open Sans; src: local('Open Sans Regular'), local('OpenSans-Regular'), url('opensans.woff2') format ('woff2'), url('opensans.woff') format('woff'); }

   Fikir makul: Open Sans gibi bazı popüler açık kaynaklı yazı tipleri, bazı sürücüler veya uygulamalarla önceden yüklenmiş olarak geliyor, bu nedenle yazı tipi yerel olarak mevcutsa, tarayıcının web yazı tipini indirmesi gerekmez ve yerel yazı tipini görüntüleyebilir. hemen yazı tipi. Bram Stein'ın belirttiği gibi, "yerel bir yazı tipi bir web yazı tipinin adıyla eşleşse de, büyük olasılıkla aynı yazı tipi değildir . Birçok web yazı tipi, "masaüstü" sürümlerinden farklıdır. Metin farklı şekilde oluşturulabilir, bazı karakterler düşebilir. diğer yazı tiplerine dönersek, OpenType özellikleri tamamen eksik olabilir veya satır yüksekliği farklı olabilir."

   Ayrıca, yazı biçimleri zaman içinde geliştikçe, yerel olarak yüklenen sürüm, karakterlerin çok farklı göründüğü web yazı tipinden çok farklı olabilir. Bu nedenle Bram'e göre, yerel olarak yüklenmiş yazı tiplerini ve web yazı tiplerini @font-face kurallarında asla karıştırmamak daha iyidir. Google Fonts, Roboto için Android istekleri dışındaki tüm kullanıcılar için CSS sonuçlarında local() işlevini devre dışı bırakarak aynı şeyi yaptı.

   İçeriğin görüntülenmesini beklemekten kimse hoşlanmaz. font-display CSS tanımlayıcısı ile, yazı tipi yükleme davranışını kontrol edebilir ve içeriğin hemen ( font-display: optional ) veya neredeyse anında (3 saniyelik bir zaman aşımıyla, yazı tipi başarıyla indirildiği sürece) okunabilir olmasını sağlayabiliriz. font-display: swap ). (Eh, bundan biraz daha karmaşık.)

   Ancak, metin yeniden akışlarının etkisini en aza indirmek istiyorsanız, Yazı Tipi Yükleme API'sini kullanabiliriz (tüm modern tarayıcılarda desteklenir). Spesifik olarak bu, her yazı tipi için bir FontFace nesnesi oluşturacağımız, ardından hepsini getirmeye çalışacağımız ve ancak daha sonra bunları sayfaya uygulayacağımız anlamına gelir. Bu şekilde, tüm yazı tiplerini eşzamansız olarak yükleyerek tüm yeniden boyamaları gruplandırıyoruz ve ardından yedek yazı tiplerinden web yazı tipine tam olarak bir kez geçiyoruz. Zach'in 32:15'ten başlayan açıklamasına ve kod parçacığına bir göz atın):

   /* Load two web fonts using JavaScript */ /* Zach Leatherman: https://noti.st/zachleat/KNaZEg/the-five-whys-of-web-font-loading-performance#sWkN4u4 */ // Remove existing @font-face blocks // Create two let font = new FontFace("Noto Serif", /* ... */); let fontBold = new FontFace("Noto Serif, /* ... */); // Load two fonts let fonts = await Promise.all([ font.load(), fontBold.load() ]) // Group repaints and render both fonts at the same time! fonts.forEach(font => documents.fonts.add(font));
   /* Load two web fonts using JavaScript */ /* Zach Leatherman: https://noti.st/zachleat/KNaZEg/the-five-whys-of-web-font-loading-performance#sWkN4u4 */ // Remove existing @font-face blocks // Create two let font = new FontFace("Noto Serif", /* ... */); let fontBold = new FontFace("Noto Serif, /* ... */); // Load two fonts let fonts = await Promise.all([ font.load(), fontBold.load() ]) // Group repaints and render both fonts at the same time! fonts.forEach(font => documents.fonts.add(font));

   Adrian Bece, Font Loading API kullanımdayken fontların çok erken getirilmesini başlatmak için, bölünmeyen bir boşluk nbsp; body kısmına yerleştirin ve aria-visibility: hidden ve bir .hidden sınıfı ile görsel olarak gizleyin:

   <body class="no-js"> <!-- ... Website content ... --> <div aria-visibility="hidden" class="hidden"> <!-- There is a non-breaking space here --> </div> <script> document.getElementsByTagName("body")[0].classList.remove("no-js"); </script> </body>
   <body class="no-js"> <!-- ... Website content ... --> <div aria-visibility="hidden" class="hidden"> <!-- There is a non-breaking space here --> </div> <script> document.getElementsByTagName("body")[0].classList.remove("no-js"); </script> </body>

   Bu, fontlar başarıyla yüklendikten sonra Font Yükleme API'si tarafından tetiklenen değişiklikle birlikte, farklı yükleme durumları için bildirilen farklı font ailelerine sahip CSS ile birlikte gider:

   body:not(.wf-merriweather--loaded):not(.no-js) { font-family: [fallback-system-font]; /* Fallback font styles */ } .wf-merriweather--loaded, .no-js { font-family: "[web-font-name]"; /* Webfont styles */ } /* Accessible hiding */ .hidden { position: absolute; overflow: hidden; clip: rect(0 0 0 0); height: 1px; width: 1px; margin: -1px; padding: 0; border: 0; }
   body:not(.wf-merriweather--loaded):not(.no-js) { font-family: [fallback-system-font]; /* Fallback font styles */ } .wf-merriweather--loaded, .no-js { font-family: "[web-font-name]"; /* Webfont styles */ } /* Accessible hiding */ .hidden { position: absolute; overflow: hidden; clip: rect(0 0 0 0); height: 1px; width: 1px; margin: -1px; padding: 0; border: 0; }

   Tüm optimizasyonlarınıza rağmen neden olduğunu merak ettiyseniz, Lighthouse hala oluşturmayı engelleyen kaynakları (yazı tipleri) ortadan kaldırmanızı önerir, aynı makalede Adrian Bece, Lighthouse'u mutlu etmek için birkaç teknik ile birlikte, performans gösteren bir asenkron yazı tipi olan Gatsby Omni Font Loader'ı sunar. Gatsby için yükleme ve Stilsiz Metin Flash (FOUT) işleme eklentisi.

   Artık çoğumuz web yazı tiplerini yüklemek için bir CDN veya üçüncü taraf bir sunucu kullanıyor olabiliriz. Genel olarak, mümkünse tüm statik varlıklarınızı kendi kendinize barındırmak her zaman daha iyidir; bu nedenle, Google Fonts'u kendi kendine barındırmanın sorunsuz bir yolu olan google-webfonts-helper'ı kullanmayı düşünün. Ve bu mümkün değilse, belki de Google Font dosyalarını sayfa kaynağı üzerinden proxy yapabilirsiniz.

   Google'ın kutunun dışında oldukça fazla iş yapıyor olmasına rağmen, bir sunucunun gecikmeleri önlemek için biraz ince ayar yapması gerekebilir ( teşekkürler, Barry! )

   Bu, özellikle Chrome v86'dan (Ekim 2020'de yayınlandı) bu yana, bölümlenmiş tarayıcı önbelleği nedeniyle yazı tipleri gibi siteler arası kaynaklar artık aynı CDN'de paylaşılamadığından oldukça önemlidir. Bu davranış, Safari'de yıllardır varsayılan bir davranıştı.

   Ancak bu hiç mümkün değilse, Harry Roberts'ın snippet'iyle mümkün olan en hızlı Google Fonts'a ulaşmanın bir yolu var:

   <!-- By Harry Roberts. https://csswizardry.com/2020/05/the-fastest-google-fonts/ - 1. Preemptively warm up the fonts' origin. - 2. Initiate a high-priority, asynchronous fetch for the CSS file. Works in - most modern browsers. - 3. Initiate a low-priority, asynchronous fetch that gets applied to the page - only after it's arrived. Works in all browsers with JavaScript enabled. - 4. In the unlikely event that a visitor has intentionally disabled - JavaScript, fall back to the original method. The good news is that, - although this is a render-blocking request, it can still make use of the - preconnect which makes it marginally faster than the default. --> <!-- [1] --> <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin /> <!-- [2] --> <link rel="preload" as="style" href="$CSS&display=swap" /> <!-- [3] --> <link rel="stylesheet" href="$CSS&display=swap" media="print" onload="this.media='all'" /> <!-- [4] --> <noscript> <link rel="stylesheet" href="$CSS&display=swap" /> </noscript>

   Harry'nin stratejisi, önce yazı tiplerinin kökenini önceden ısıtmaktır. Ardından, CSS dosyası için yüksek öncelikli, eşzamansız bir getirme işlemini başlatırız. Daha sonra, sayfaya ancak geldikten sonra uygulanan düşük öncelikli, eşzamansız bir getirme başlatırız (bir stil sayfası yazdırma hilesiyle). Son olarak, JavaScript desteklenmiyorsa, orijinal yönteme geri döneriz.

   Ah, Google Fonts'tan bahsetmişken: &text ile yalnızca ihtiyacınız olan karakterleri bildirerek Google Fonts isteklerinin boyutunun %90'ına kadar küçültebilirsiniz . Ayrıca, Google Fonts'a yazı tipi görüntüleme desteği de eklendi, böylece kutudan çıktığı gibi kullanabiliriz.

   Yine de hızlı bir uyarı. font-display: optional kullanırsanız, bu web yazı tipi isteğini erken tetikleyeceğinden (alınması gereken başka kritik yol kaynaklarınız varsa ağ tıkanıklığına neden olacağından) preload kullanmak da optimal olmayabilir. preconnect arası daha hızlı yazı tipi istekleri için ön bağlantıyı kullanın, ancak farklı bir kaynaktan gelen yazı tiplerini önceden preload ağ çekişmesine neden olacağından, önceden yükleme konusunda dikkatli olun. Bu tekniklerin tümü, Zach'in Web yazı tipi yükleme tariflerinde ele alınmıştır.

   Öte yandan, kullanıcı erişilebilirlik tercihlerinde Hareketi Azalt'ı etkinleştirdiyse veya Save-Data Tasarrufu Modu'nu seçtiyse web yazı tiplerini (veya en azından ikinci aşamada oluşturmayı) devre dışı bırakmak iyi bir fikir olabilir (bkz. veya kullanıcının bağlantısı yavaş olduğunda (Ağ Bilgi API'si aracılığıyla).

   Kullanıcı veri tasarrufu modunu seçtiyse, yazı tipi bildirimlerini tanımlamamak için prefers-reduced-data CSS ortam sorgusunu da kullanabiliriz (başka kullanım durumları da vardır). Ortam sorgusu, temel olarak, İstemci İpucu HTTP uzantısından Save-Data isteği başlığının CSS ile kullanıma izin vermek için açık/kapalı olup olmadığını ortaya çıkaracaktır. Şu anda yalnızca Chrome ve Edge'de bir bayrağın arkasında desteklenmektedir.

   Metrikler? Web yazı tipi yükleme performansını ölçmek için, Görünür Tüm Metin metriğini (tüm yazı tiplerinin yüklendiği ve tüm içeriğin web yazı tiplerinde görüntülendiği an), Gerçek İtalik Zamana Dönme Süresini ve ilk oluşturmadan sonra Web Yazı Tipi Yeniden Akış Sayısını göz önünde bulundurun. Açıkçası, her iki metrik de ne kadar düşükse, performans o kadar iyi olur.

   Değişken yazı tiplerine ne dersiniz? Değişken yazı tiplerinin önemli bir performans değerlendirmesi gerektirebileceğini fark etmek önemlidir. Tipografik seçimler için bize çok daha geniş bir tasarım alanı sağlıyorlar, ancak bir dizi bireysel dosya isteğine karşı tek bir seri isteğin maliyetine geliyor.

   Değişken yazı tipleri, yazı tipi dosyalarının toplam dosya boyutunu büyük ölçüde azaltırken, bu tek istek yavaş olabilir ve bir sayfadaki tüm içeriğin işlenmesini engelleyebilir. Bu yüzden yazı tipini alt gruplara ayırmak ve karakter kümelerine bölmek hala önemlidir. Yine de iyi tarafı, değişken bir yazı tipi yerindeyken, varsayılan olarak tam olarak bir yeniden akış elde edeceğiz, bu nedenle yeniden boyamaları gruplamak için JavaScript gerekmeyecek.

   Şimdi, kurşun geçirmez bir web yazı tipi yükleme stratejisi ne olurdu? Yazı tiplerini alt kümelere ayırın ve bunları 2 aşamalı işleme için hazırlayın, bir font-display tanımlayıcısı ile bildirin, yeniden boyamaları gruplamak ve yazı tiplerini kalıcı bir hizmet çalışanının önbelleğinde saklamak için Yazı Tipi Yükleme API'sini kullanın. İlk ziyarette, harici komut dosyalarını engellemeden hemen önce komut dosyalarının önceden yüklenmesini enjekte edin. Gerekirse Bram Stein'in Font Face Observer'ına geri dönebilirsiniz. Yazı tipi yükleme performansını ölçmekle ilgileniyorsanız, Andreas Marschke, Font API ve UserTiming API ile performans izlemeyi araştırıyor.

   Son olarak, büyük bir yazı tipini dile özgü daha küçük yazı tiplerine ayırmak için unicode-range dahil etmeyi unutmayın ve geri dönüş ile eski yazı tipi arasındaki boyut farklılıkları nedeniyle düzende sarsıcı bir kaymayı en aza indirmek için Monica Dinculescu'nun yazı tipi stili eşleştiricisini kullanın. web yazı tipleri.

   Alternatif olarak, bir geri dönüş yazı tipi için bir web yazı tipini taklit etmek üzere yazı tipi ölçümlerini geçersiz kılmak için @ yazı tipi-yüz tanımlayıcılarını kullanabiliriz (demo, Chrome 87'de etkinleştirilmiştir). (Yine de karmaşık yazı tipi yığınlarıyla ayarlamaların karmaşık olduğunu unutmayın.)

   Gelecek parlak görünüyor mu? Aşamalı yazı tipi zenginleştirme ile, sonunda "belirli herhangi bir sayfada yazı tipinin yalnızca gerekli bölümünü indirebiliriz ve bu yazı tipine yönelik sonraki istekler için orijinal indirmeyi, birbirini izleyen sayfada gerektiği gibi ek glif kümeleriyle dinamik olarak 'yama' ekleyebiliriz. görüşleri", Jason Pamental'in açıkladığı gibi. Artımlı Transfer Demosu zaten mevcut ve devam ediyor.

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