Ön Uç Performansı 2021: Ortamın Tanımlanması

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.

Çevreyi Tanımlamak

1. Oluşturma araçlarınızı seçin ve ayarlayın.
   Bugünlerde güya havalı olan şeylere çok fazla dikkat etmeyin. Grunt, Gulp, Webpack, Parcel veya bir araç kombinasyonu olsun, inşa etmek için ortamınıza bağlı kalın. İhtiyacınız olan sonuçları aldığınız ve yapım sürecinizi sürdürmekte sorun yaşamadığınız sürece, gayet iyi gidiyorsunuz.

   Derleme araçları arasında, Rollup çekiş kazanmaya devam ediyor, Snowpack de öyle, ancak Webpack, yapılarınızın boyutunu optimize etmek için kelimenin tam anlamıyla yüzlerce eklenti ile en yerleşik olanı gibi görünüyor. Webpack Yol Haritası 2021'e dikkat edin.

   Son zamanlarda ortaya çıkan en dikkate değer stratejilerden biri, yinelenen kodu en aza indirmek için Next.js ve Gatsby'de Webpack ile Granüler yığınlamadır. Varsayılan olarak, her giriş noktasında paylaşılmayan modüller, onu kullanmayan rotalar için talep edilebilir. Bu, gerekenden daha fazla kod indirildiğinden bir ek yük haline gelir. Next.js'deki parçalı yığınlama ile, farklı giriş noktaları tarafından hangi çıktı alınan parçaların kullanıldığını belirlemek için bir sunucu tarafı derleme bildirim dosyası kullanabiliriz.

   

   SplitChunksPlugin ile, çoğaltılmış kodun birden çok rotada alınmasını önlemek için bir dizi koşula bağlı olarak birden çok bölünmüş parça oluşturulur. Bu, gezinmeler sırasında sayfa yükleme süresini ve önbelleğe almayı iyileştirir. Next.js 9.2 ve Gatsby v2.20.7'de gönderilir.

   Yine de Webpack'i kullanmaya başlamak zor olabilir. Yani Webpack'e dalmak istiyorsanız, orada bazı harika kaynaklar var:

   • Webpack belgeleri - açıkçası - iyi bir başlangıç ​​noktasıdır ve Webpack - Raja Rao'dan The Confusing Bits ve Andrew Welch'ten An Annotated Webpack Config.
   • Sean Larkin'in Webpack'te ücretsiz bir kursu var: The Core Concepts ve Jeffrey Way, Webpack'te herkes için harika bir ücretsiz kurs yayınladı. Her ikisi de Webpack'e dalmak için harika tanıtımlardır.
   • Webpack Fundamentals, Sean Larkin ile FrontendMasters tarafından yayınlanan 4 saatlik çok kapsamlı bir kurstur.
   • Web paketi örnekleri, konuya ve amaca göre kategorize edilmiş yüzlerce kullanıma hazır Web paketi yapılandırmasına sahiptir. Bonus: Temel bir yapılandırma dosyası oluşturan bir Webpack yapılandırma yapılandırıcısı da vardır.
   • harika-webpack, makaleler, videolar, kurslar, kitaplar ve Angular, React ve çerçeveden bağımsız projeler için örnekler dahil olmak üzere faydalı Webpack kaynakları, kitaplıkları ve araçlarının derlenmiş bir listesidir.
   • Webpack ile hızlı üretim varlıkları oluşturma yolculuğu, Etsy'nin, ekibin RequireJS tabanlı JavaScript derleme sistemini kullanmaktan Webpack'i kullanmaya nasıl geçiş yaptığına ve ortalama olarak 13.200'den fazla varlığı 4 dakikada yöneterek yapılarını nasıl optimize ettiğine ilişkin vaka çalışmasıdır.
   • Webpack performans ipuçları, Ivan Akulov'un özellikle Webpack'e odaklananlar da dahil olmak üzere performans odaklı birçok ipucu içeren bir altın madeni dizisidir.
   • harika-webpack-perf, performans için kullanışlı Web paketi araçları ve eklentileri içeren bir altın madeni GitHub deposudur. Ayrıca Ivan Akulov tarafından yapılmaktadır.

1. Aşamalı geliştirmeyi varsayılan olarak kullanın.
   Yine de, bunca yıldan sonra, aşamalı geliştirmeyi ön uç mimarinizin ve dağıtımınızın yol gösterici ilkesi olarak tutmak güvenli bir bahistir. Önce temel deneyimi tasarlayın ve oluşturun, ardından esnek deneyimler yaratarak yetenekli tarayıcılar için gelişmiş özelliklerle deneyimi geliştirin. Web siteniz, yetersiz bir ağda zayıf bir tarayıcıda zayıf bir ekrana sahip yavaş bir makinede hızlı çalışıyorsa, yalnızca iyi bir ağda iyi bir tarayıcıya sahip hızlı bir makinede daha hızlı çalışır.

   Aslında, uyarlamalı modül hizmetiyle, aşamalı geliştirmeyi başka bir düzeye taşıyor, düşük kaliteli cihazlara "hafif" çekirdek deneyimler sunuyor ve ileri teknoloji cihazlar için daha karmaşık özelliklerle zenginleştiriyor gibiyiz. Aşamalı geliştirmenin yakın zamanda kaybolması pek olası değildir.

2. Güçlü bir performans temel çizgisi seçin.
   Yüklemeyi etkileyen pek çok bilinmeyenle – ağ, termal kısıtlama, önbellek tahliyesi, üçüncü taraf komut dosyaları, ayrıştırıcı engelleme kalıpları, disk G/Ç, IPC gecikmesi, yüklü uzantılar, virüsten koruma yazılımı ve güvenlik duvarları, arka plan CPU görevleri, donanım ve bellek kısıtlamaları, L2/L3 önbelleğe alma, RTTS - JavaScript, varsayılan olarak oluşturmayı engelleyen web yazı tiplerinin ve genellikle çok fazla bellek tüketen görüntülerin yanında, deneyimin en ağır maliyetine sahiptir. Performans darboğazlarının sunucudan istemciye kaymasıyla birlikte geliştiriciler olarak tüm bu bilinmeyenleri çok daha detaylı olarak ele almamız gerekiyor.

   Halihazırda kritik yol HTML/CSS/JavaScript, yönlendirici, durum yönetimi, yardımcı programlar, çerçeve ve uygulama mantığını içeren 170 KB'lık bir bütçeyle, ağ aktarım maliyetini, ayrıştırma/derleme süresini ve çalıştırma zamanı maliyetini kapsamlı bir şekilde incelememiz gerekiyor. bizim seçimimizin çerçevesi. Neyse ki, son birkaç yılda tarayıcıların komut dosyalarını ne kadar hızlı ayrıştırıp derleyebileceği konusunda büyük bir gelişme gördük. Yine de JavaScript'in yürütülmesi hala ana darboğazdır, bu nedenle komut dosyası yürütme süresine ve ağa çok dikkat etmek etkili olabilir.

   Tim Kadlec, modern çerçevelerin performansı hakkında harika bir araştırma yaptı ve bunları "JavaScript çerçevelerinin bir maliyeti var" makalesinde özetledi. Sıklıkla bağımsız çerçevelerin etkisi hakkında konuşuruz, ancak Tim'in belirttiği gibi, pratikte birden fazla çerçevenin kullanımda olması nadir değildir. Belki de, Angular'ın eski bir sürümünü kullanan birkaç eski uygulamayla birlikte, yavaş yavaş modern bir çerçeveye taşınan eski bir jQuery sürümü. Bu nedenle, üst düzey cihazlarda bile kullanıcı deneyimlerini zorlukla kullanılabilir hale getirebilecek JavaScript baytlarının kümülatif maliyetini ve CPU yürütme süresini araştırmak daha mantıklıdır.

   Genel olarak, modern çerçeveler daha az güçlü cihazlara öncelik vermez , bu nedenle telefondaki ve masaüstündeki deneyimler performans açısından genellikle önemli ölçüde farklı olacaktır. Araştırmaya göre, React veya Angular'a sahip siteler CPU'ya diğerlerinden daha fazla zaman harcıyor (tabii ki bu, React'in CPU'da Vue.js'den daha pahalı olduğunu söylemek zorunda değil).

   Tim'e göre, bir şey açıktır: "Sitenizi oluşturmak için bir çerçeve kullanıyorsanız, en iyi senaryolarda bile, başlangıç ​​performansı açısından bir ödünleşme yapıyorsunuz demektir."

1. Çerçeveleri ve bağımlılıkları değerlendirin.
   Şimdi, her projenin bir çerçeveye ihtiyacı yoktur ve tek sayfalık bir uygulamanın her sayfasının bir çerçeve yüklemesi gerekmez. Netflix'in durumunda, "React, birkaç kitaplık ve ilgili uygulama kodunun istemci tarafından kaldırılması, toplam JavaScript miktarını 200 KB'nin üzerinde azaltarak, çıkış yapılan ana sayfa için Netflix'in Etkileşim Süresinde %50'nin üzerinde bir azalmaya neden oldu. " Ekip daha sonra, kullanıcıların giriş yapma olasılığı yüksek olan sonraki sayfalar için React'i önceden getirmek için açılış sayfasında harcanan süreyi kullandı (ayrıntılar için okumaya devam edin).

   Peki, kritik sayfalardaki mevcut bir çerçeveyi tamamen kaldırırsanız ne olur? Gatsby ile, Gatsby tarafından oluşturulan tüm JavaScript dosyalarını statik HTML dosyalarından kaldıran gatsby-plugin-no-javascript'i kontrol edebilirsiniz. Vercel'de, belirli sayfalar için üretimde çalışma zamanı JavaScript'inin devre dışı bırakılmasına da izin verebilirsiniz (deneysel).

   Bir çerçeve seçildikten sonra, en az birkaç yıl onunla kalacağız, bu yüzden birini kullanmamız gerekirse, seçimimizin bilgili ve iyi düşünülmüş olduğundan emin olmalıyız - ve bu özellikle bizim kullandığımız temel performans ölçütleri için geçerlidir. önemsemek.

   Veriler, varsayılan olarak çerçevelerin oldukça pahalı olduğunu gösteriyor: React sayfalarının %58,6'sı 1 MB JavaScript'in üzerinde gönderiyor ve Vue.js sayfa yüklemelerinin %36'sının First Contentful Paint'i 1,5 saniyeden az. Ankur Sethi tarafından yapılan bir araştırmaya göre, "Ne kadar optimize ederseniz edin, React uygulamanız Hindistan'daki ortalama bir telefonda asla yaklaşık 1,1 saniyeden daha hızlı yüklenmeyecek . Angular uygulamanızın açılması her zaman en az 2,7 saniye sürecektir. Vue uygulamanızın kullanıcılarının, kullanmaya başlamadan önce en az 1 saniye beklemesi gerekecek." Zaten birincil pazarınız olarak Hindistan'ı hedef almıyor olabilirsiniz, ancak sitenize yetersiz ağ koşullarıyla erişen kullanıcılar benzer bir deneyime sahip olacaktır.

   SPA'ları hızlı yapmak elbette mümkün , ancak kutudan çıktığı gibi hızlı değiller, bu yüzden onları hızlı yapmak ve tutmak için gereken zaman ve çabayı hesaba katmamız gerekiyor. Erkenden hafif bir temel performans maliyeti seçmek muhtemelen daha kolay olacaktır.

   Peki bir çerçeveyi nasıl seçeceğiz ? Bir seçenek belirlemeden önce en azından boyut + ilk uygulama sürelerinin toplam maliyetini göz önünde bulundurmak iyi bir fikirdir; Preact, Inferno, Vue, Svelte, Alpine veya Polymer gibi hafif seçenekler, işi gayet iyi halledebilir. Temelinizin boyutu, uygulamanızın kodunun kısıtlamalarını tanımlayacaktır.

   Seb Markbage tarafından belirtildiği gibi, çerçeveler için başlangıç ​​maliyetlerini ölçmenin iyi bir yolu, önce bir görünümü oluşturmak, ardından silmek ve ardından çerçevenin nasıl ölçeklendiğini size söyleyebileceği için yeniden oluşturmaktır . İlk oluşturma, daha büyük bir ağacın ölçeklendiğinde yararlanabileceği, tembelce derlenmiş bir grup kodu ısıtma eğilimindedir. İkinci oluşturma, temel olarak, bir sayfada kodun yeniden kullanımının, sayfa karmaşıklığı arttıkça performans özelliklerini nasıl etkilediğinin bir öykünmesidir.

   Özellikleri, erişilebilirliği, kararlılığı, performansı, paket ekosistemini , topluluğu, öğrenme eğrisini, belgeleri, araçları, geçmiş performansı keşfederek adaylarınızı (veya genel olarak herhangi bir JavaScript kitaplığını) Sacha Greif'in 12 noktalı puanlama sisteminde değerlendirebilecek kadar ileri gidebilirsiniz. , ekip, uyumluluk, örneğin güvenlik.

   

   Ayrıca, web'de daha uzun bir süre boyunca toplanan verilere de güvenebilirsiniz. Örneğin, Perf Track, çerçeve performansını geniş ölçekte izleyerek Angular, React, Vue, Polymer, Preact, Ember, Svelte ve AMP'de oluşturulmuş web siteleri için kökene dayalı Temel Web Verileri puanlarını gösterir. Hatta Gatsby, Next.js veya Create React App ile oluşturulmuş web sitelerinin yanı sıra Nuxt.js (Vue) veya Sapper (Svelte) ile oluşturulmuş web sitelerini belirtebilir ve karşılaştırabilirsiniz.

   İyi bir başlangıç ​​noktası, uygulamanız için iyi bir varsayılan yığın seçmektir. Gatsby (React), Next.js (React), Vuepress (Vue), Preact CLI ve PWA Başlangıç ​​Kiti, ortalama mobil donanımda kutudan çıkar çıkmaz hızlı yükleme için makul varsayılanlar sağlar. ​​Ayrıca, React ve Angular için web.dev çerçevesine özel performans kılavuzuna bir göz atın ( teşekkürler Phillip! ).

   Ve belki de, tek sayfalı uygulamaları tamamen oluşturmak için biraz daha canlandırıcı bir yaklaşım benimseyebilirsiniz: Görünümleri oluşturmak için JSON yerine HTML kullanan 15 KB'lık bir JavaScript kitaplığı olan Turbolinks. Bu nedenle, bir bağlantıyı takip ettiğinizde, Turbolinks otomatik olarak sayfayı getirir, <body> içinde yer değiştirir ve <head> ile birleştirir, tüm bunlar tam sayfa yükleme maliyetine maruz kalmaz. Yığınla (Hotwire) ilgili hızlı ayrıntıları ve tam belgeleri kontrol edebilirsiniz.

1. İstemci tarafı oluşturma mı yoksa sunucu tarafı oluşturma mı? İkisi birden!
   Bu oldukça hararetli bir konuşma. Nihai yaklaşım, bir tür aşamalı önyükleme ayarlamak olacaktır: Hızlı bir First Contenful Paint elde etmek için sunucu tarafı oluşturmayı kullanın, ancak etkileşim süresini First Contentful Paint'e yakın tutmak için gerekli minimum JavaScript'i de ekleyin. JavaScript FCP'den sonra çok geç geliyorsa, tarayıcı geç keşfedilen JavaScript'i ayrıştırırken, derlerken ve yürütürken ana iş parçacığını kilitler, dolayısıyla sitenin veya uygulamanın etkileşimini kelepçeler.

   Bunu önlemek için, işlevlerin yürütülmesini her zaman ayrı, eşzamansız görevlere ayırın ve mümkünse requestIdleCallback kullanın. WebPack'in dinamik import() desteğini kullanarak kullanıcı arayüzünün parçalarını tembelce yüklemeyi düşünün, kullanıcılar gerçekten ihtiyaç duyana kadar yükleme, ayrıştırma ve derleme maliyetinden kaçının ( teşekkürler Addy! ).

   Yukarıda bahsedildiği gibi, Etkileşim Süresi (TTI) bize navigasyon ve etkileşim arasındaki süreyi söyler. Ayrıntılı olarak, metrik, hiçbir JavaScript görevinin 50 ms'den uzun sürmediği ( Uzun Görevler ) ilk içerik oluşturulduktan sonraki ilk beş saniyelik pencereye bakılarak tanımlanır. 50 ms'nin üzerinde bir görev meydana gelirse, beş saniyelik bir pencere araması baştan başlar. Sonuç olarak, tarayıcı önce Interactive'e ulaştığını varsayar, yalnızca Frozen'a geçmek için, yalnızca sonunda Interactive'e geri dönmek için.

   Interactive'e ulaştığımızda, isteğe bağlı olarak veya zamanın izin verdiği ölçüde uygulamanın zorunlu olmayan bölümlerini önyükleyebiliriz. Ne yazık ki, Paul Lewis'in fark ettiği gibi, çerçevelerin tipik olarak geliştiricilere gösterilebilecek basit bir öncelik kavramı yoktur ve bu nedenle aşamalı önyüklemenin çoğu kitaplık ve çerçeve ile uygulanması kolay değildir.

   Yine de oraya geliyoruz. Bu günlerde keşfedebileceğimiz birkaç seçenek var ve Houssein Djirdeh ve Jason Miller Web'de İşleme ve Jason'ın ve Addy'nin Modern Ön Uç Mimarileri hakkındaki yazılarında bu seçeneklere mükemmel bir genel bakış sunuyor. Aşağıdaki genel bakış, yıldız çalışmalarına dayanmaktadır.

   • Tam Sunucu Tarafı Oluşturma (SSR)
     WordPress gibi klasik SSR'de tüm istekler tamamen sunucuda işlenir. İstenen içerik tamamlanmış bir HTML sayfası olarak döndürülür ve tarayıcılar onu hemen işleyebilir. Bu nedenle, örneğin SSR uygulamaları DOM API'lerini gerçekten kullanamaz. First Contentful Paint ve Time to Interactive arasındaki boşluk genellikle küçüktür ve HTML tarayıcıya aktarılırken sayfa hemen oluşturulabilir.

     Bu, tarayıcı yanıt almadan önce işlendiğinden, istemcide veri alma ve şablon oluşturma için ek gidiş dönüşleri önler. Ancak, daha uzun sunucu düşünme süresi ve dolayısıyla İlk Bayt Süresi ile sonuçlanıyor ve modern uygulamaların duyarlı ve zengin özelliklerinden yararlanmıyoruz.

   • Statik İşleme
     Ürünü tek sayfalık bir uygulama olarak oluşturuyoruz, ancak tüm sayfalar, oluşturma adımı olarak minimum JavaScript ile statik HTML'ye önceden işleniyor. Bu, statik oluşturma ile, birçok uygulamanın karşılayamayacağı bir şey olan, mümkün olan her URL için önceden ayrı HTML dosyaları ürettiğimiz anlamına gelir. Ancak, bir sayfanın HTML'sinin anında oluşturulması gerekmediğinden, sürekli olarak hızlı bir İlk Bayt Süresine ulaşabiliriz. Böylece, bir açılış sayfasını hızlı bir şekilde görüntüleyebilir ve ardından sonraki sayfalar için bir SPA çerçevesi önceden getirebiliriz. Netflix, yüklemeyi ve Etkileşim Süresini %50 azaltan bu yaklaşımı benimsemiştir.

   • (Yeniden)Hidrasyonlu Sunucu Tarafı İşleme (Evrensel İşleme, SSR + CSR)
     Her iki dünyanın da en iyisini - SSR ve KSS yaklaşımlarını - kullanmayı deneyebiliriz. Karışımdaki hidrasyon ile, sunucudan döndürülen HTML sayfası ayrıca tam teşekküllü bir istemci tarafı uygulamasını yükleyen bir komut dosyası içerir. İdeal olarak, bu hızlı bir First Contentful Paint (SSR gibi) elde eder ve ardından (yeniden) hidrasyon ile işlemeye devam eder. Ne yazık ki, bu nadiren olur. Daha sık olarak, sayfa hazır görünüyor, ancak kullanıcının girişine yanıt veremiyor, öfkeli tıklamalar ve terkler üretiyor.

     React ile, Express gibi bir Node sunucusunda ReactDOMServer modülünü kullanabilir ve ardından üst düzey bileşenleri statik bir HTML dizesi olarak işlemek için renderToString yöntemini çağırabiliriz.

     Vue.js ile, renderToString kullanarak bir Vue örneğini HTML'ye dönüştürmek için vue-server-renderer'ı kullanabiliriz. Angular'da, istemci isteklerini tamamen sunucu tarafından oluşturulan HTML sayfalarına dönüştürmek için @nguniversal kullanabiliriz. Next.js (React) veya Nuxt.js (Vue) ile kullanıma hazır, tamamen sunucu tarafından oluşturulmuş bir deneyim de elde edilebilir.

     

     Yaklaşımın dezavantajları vardır. Sonuç olarak, sunucu tarafında daha hızlı oluşturma sağlarken, istemci tarafı uygulamalarda tam esneklik elde ediyoruz, ancak aynı zamanda First Contentful Paint ile Etkileşim Süresi arasında daha uzun bir boşluk ve artırılmış İlk Giriş Gecikmesi ile sonuçlanıyoruz. Rehidrasyon çok pahalıdır ve Time To Interactive'i büyük ölçüde geciktirdiği için genellikle bu strateji tek başına yeterince iyi olmayacaktır.

   • Aşamalı Nemlendirme (SSR + CSR) ile Akış Sunucusu Tarafında İşleme
     Time To Interactive ve First Contentful Paint arasındaki boşluğu en aza indirmek için, aynı anda birden fazla istekte bulunur ve içeriği oluşturuldukça parçalar halinde göndeririz . Bu nedenle, tarayıcıya içerik göndermeden önce HTML'nin tam dizesini beklemek zorunda değiliz ve bu nedenle İlk Bayt Süresini iyileştiriyoruz.

     React'te, renderToString() yerine, yanıtı yönlendirmek ve HTML'yi parçalar halinde göndermek için renderToNodeStream() kullanabiliriz. Vue'da, aktarılabilen ve aktarılabilen renderToStream() kullanabiliriz. React Suspense ile asenkron oluşturmayı da bu amaç için kullanabiliriz.

     İstemci tarafında, tüm uygulamayı bir kerede başlatmak yerine, bileşenleri aşamalı olarak başlatıyoruz. Uygulamaların bölümleri, önce kod bölme ile bağımsız komut dosyalarına bölünür ve ardından kademeli olarak (önceliklerimize göre) hidratlanır. Aslında, kritik bileşenleri önce hidratlayabiliriz, geri kalanı daha sonra hidratlanabilir. İstemci tarafı ve sunucu tarafı oluşturmanın rolü daha sonra bileşen başına farklı şekilde tanımlanabilir. Daha sonra, bazı bileşenlerin hidrasyonunu, bunlar görüntülenene veya kullanıcı etkileşimi için gerekli olana veya tarayıcı boştayken de erteleyebiliriz .

     Vue için Markus Oberlehner, kullanıcı etkileşiminde hidrasyonun yanı sıra görünürlük veya belirli kullanıcı etkileşiminde bileşen hidrasyonunu sağlayan erken aşama bir eklenti olan vue-lazy-hidrasyon kullanarak SSR uygulamalarının Etkileşim Süresini azaltma konusunda bir kılavuz yayınladı. Angular ekibi, Ivy Universal ile aşamalı nemlendirme üzerinde çalışıyor. Preact ve Next.js ile de kısmi nemlendirme uygulayabilirsiniz.

   • Trizomorfik İşleme
     Hizmet çalışanları yerinde olduğunda, ilk/JS olmayan gezinmeler için akış sunucusu oluşturmayı kullanabilir ve ardından hizmet çalışanının yüklendikten sonra gezinmeler için HTML oluşturmayı üstlenmesini sağlayabiliriz. Bu durumda, hizmet çalışanı içeriği önceden oluşturur ve aynı oturumda yeni görünümler oluşturmak için SPA tarzı gezinmeleri etkinleştirir. Sunucu, istemci sayfası ve hizmet çalışanı arasında aynı şablonlama ve yönlendirme kodunu paylaşabildiğinizde iyi çalışır.

   

   • Önceden Oluşturma ile CSR
     Önceden oluşturma, sunucu tarafı oluşturmaya benzer, ancak sayfaları sunucuda dinamik olarak oluşturmak yerine, uygulamayı derleme zamanında statik HTML'ye dönüştürürüz. Statik sayfalar, çok fazla istemci tarafı JavaScript olmadan tamamen etkileşimli olsa da, önceden oluşturma farklı şekilde çalışır . Temel olarak, istemci tarafı uygulamasının ilk durumunu derleme sırasında statik HTML olarak yakalar, önceden oluşturma ile sayfaların etkileşimli olması için uygulamanın istemcide başlatılması gerekir.

     Next.js ile, bir uygulamayı statik HTML'ye önceden oluşturarak statik HTML dışa aktarımını kullanabiliriz. Gatsby'de, React kullanan bir açık kaynaklı statik site oluşturucu, derlemeler sırasında renderToStaticMarkup yöntemi yerine renderToString yöntemini kullanır, ana JS yığını önceden yüklenir ve gelecekteki rotalar, basit statik sayfalar için gerekli olmayan DOM öznitelikleri olmadan önceden getirilir.

     Vue için aynı hedefe ulaşmak için Vuepress'i kullanabiliriz. Webpack ile prerender-loader'ı da kullanabilirsiniz. Navi, statik işleme de sağlar.

     Sonuç, Time To First Byte ve First Contentful Paint için daha iyi bir zamandır ve Time To Interactive ile First Contentful Paint arasındaki boşluğu azaltıyoruz. İçeriğin çok değişmesi bekleniyorsa bu yaklaşımı kullanamayız. Ayrıca, tüm sayfaları oluşturmak için tüm URL'lerin önceden bilinmesi gerekir. Bu nedenle, bazı bileşenler önceden oluşturma kullanılarak oluşturulabilir, ancak dinamik bir şeye ihtiyacımız varsa, içeriği almak için uygulamaya güvenmemiz gerekir.

   • Tam İstemci Taraflı İşleme (CSR)
     Tüm mantık, oluşturma ve önyükleme istemcide yapılır. Sonuç genellikle Time To Interactive ve First Contentful Paint arasında büyük bir boşluktur. Sonuç olarak, herhangi bir şeyi oluşturmak için tüm uygulamanın istemcide başlatılması gerektiğinden uygulamalar genellikle yavaş hisseder .

     JavaScript'in bir performans maliyeti olduğundan, JavaScript miktarı bir uygulama ile büyüdükçe, JavaScript'in etkisini azaltmak için agresif kod bölme ve JavaScript'i erteleme kesinlikle zorunlu olacaktır. Bu gibi durumlarda, fazla etkileşim gerekmediğinde sunucu tarafı oluşturma genellikle daha iyi bir yaklaşım olacaktır. Bu bir seçenek değilse, Uygulama Kabuğu Modelini kullanmayı düşünün.

     Genel olarak, SSR, CSR'den daha hızlıdır. Yine de, oradaki birçok uygulama için oldukça sık bir uygulamadır.

   Yani, istemci tarafı mı yoksa sunucu tarafı mı? Genel olarak, tamamen istemci tarafı çerçevelerin kullanımını kesinlikle bunları gerektiren sayfalarla sınırlamak iyi bir fikirdir. Gelişmiş uygulamalar için, yalnızca sunucu tarafında işlemeye güvenmek de iyi bir fikir değildir. Kötü yapılırsa hem sunucu oluşturma hem de istemci oluşturma bir felakettir.

   İster CSR'ye ister SSR'ye yöneliyor olun, önemli pikselleri mümkün olan en kısa sürede oluşturduğunuzdan emin olun ve bu oluşturma ile Etkileşim Süresi arasındaki boşluğu en aza indirin. Sayfalarınız fazla değişmiyorsa önceden oluşturmayı düşünün ve mümkünse çerçevelerin başlatılmasını erteleyin. Sunucu tarafı oluşturma ile parçalar halinde HTML akışı gerçekleştirin ve istemci tarafı oluşturma için aşamalı hidrasyon uygulayın - ve her iki dünyanın da en iyisini elde etmek için görünürlük, etkileşim veya boşta kalma süresi boyunca sulayın.

1. Statik olarak ne kadar hizmet verebiliriz?
   İster büyük bir uygulamada ister küçük bir sitede çalışıyor olun, anında dinamik olarak oluşturulmak yerine hangi içeriğin bir CDN'den (yani JAM Yığını) statik olarak sunulabileceğini düşünmeye değer. Binlerce ürününüz ve çok sayıda kişiselleştirme seçeneğine sahip yüzlerce filtreniz olsa bile, yine de kritik açılış sayfalarınızı statik olarak sunmak ve bu sayfaları seçtiğiniz çerçeveden ayırmak isteyebilirsiniz.

   Çok sayıda statik site oluşturucu vardır ve oluşturdukları sayfalar genellikle çok hızlıdır. İstek anında bir sunucuda veya istemcide sayfa görünümleri oluşturmak yerine önceden ne kadar çok içerik oluşturabilirsek, o kadar iyi performans elde ederiz.

   Markus Oberlehner, Kısmen Nemlendirilmiş, Aşamalı Olarak Geliştirilmiş Statik Web Siteleri Oluşturma'da, aşamalı geliştirme ve minimum JavaScript paket boyutu elde ederken statik site oluşturucu ve SPA ile web sitelerinin nasıl oluşturulacağını gösterir. Markus, araçları olarak Eleventy ve Preact'i kullanıyor ve baştan sona araçların nasıl kurulacağını, kısmi hidrasyon, tembel hidrasyon, istemci giriş dosyası ekleneceğini, Preact için Babel'in nasıl yapılandırılacağını ve Preact ile Rollup'ın nasıl paketleneceğini gösteriyor.

   Bu günlerde büyük sitelerde kullanılan JAMStack ile yeni bir performans düşüncesi ortaya çıktı: derleme süresi . Aslında, her yeni dağıtımla binlerce sayfa oluşturmak bile dakikalar alabilir, bu nedenle WordPress, Contentful, Drupal, Netlify CMS gibi popüler CMS çözümleriyle entegrasyon ile Gatsby'de yapım sürelerini 60 kat artıran artımlı yapılar görmek umut verici. ve diğerleri.

   

   Ayrıca Next.js, çalışma zamanında yeni statik sayfalar eklememize ve mevcut sayfaları oluşturulduktan sonra trafik geldikçe arka planda yeniden oluşturarak güncellememize olanak tanıyan önceden ve artımlı statik üretimi duyurdu. .

   Daha da hafif bir yaklaşıma mı ihtiyacınız var? Eleventy, Alpine ve Tailwind: hafif bir Jamstack'e yönelik konuşmasında Nicola Goutay, CSR, SSR ve aradaki her şey arasındaki farkları açıklıyor ve daha hafif bir yaklaşımın nasıl kullanılacağını gösteriyor — yaklaşımı gösteren bir GitHub deposuyla birlikte uygulamada.

2. PRPL desenini ve uygulama kabuğu mimarisini kullanmayı düşünün.
   Farklı çerçevelerin performans üzerinde farklı etkileri olacaktır ve farklı optimizasyon stratejileri gerektirecektir, bu nedenle güveneceğiniz çerçevenin tüm somunlarını ve cıvatalarını açıkça anlamanız gerekir. Bir web uygulaması oluştururken, PRPL modeline ve uygulama kabuğu mimarisine bakın. Fikir oldukça basittir: İlk rotanın hızlı bir şekilde oluşturulması için etkileşimli hale gelmek için gereken minimum kodu itin, ardından kaynakları önbelleğe almak ve önbelleğe almak için hizmet çalışanını kullanın ve ardından ihtiyaç duyduğunuz rotaları eşzamansız olarak tembel olarak yükleyin.

1. API'lerinizin performansını optimize ettiniz mi?
   API'ler, bir uygulamanın verileri uç noktalar aracılığıyla dahili ve üçüncü taraf uygulamalara sunması için iletişim kanallarıdır. Bir API tasarlarken ve oluştururken, sunucu ile üçüncü taraf istekleri arasındaki iletişimi sağlamak için makul bir protokole ihtiyacımız var. Temsili Durum Aktarımı ( REST ) köklü, mantıklı bir seçimdir: geliştiricilerin içeriği performanslı, güvenilir ve ölçeklenebilir bir şekilde erişilebilir kılmak için izlediği bir dizi kısıtlamayı tanımlar. REST kısıtlamalarına uyan web servislerine RESTful web servisleri denir.

   Eski iyi HTTP isteklerinde olduğu gibi, bir API'den veri alındığında, sunucu yanıtındaki herhangi bir gecikme son kullanıcıya yayılacak ve dolayısıyla oluşturmayı geciktirecektir . Bir kaynak bir API'den bazı verileri almak istediğinde, ilgili uç noktadan verileri istemesi gerekir. Her yorumda yorumlar ve yazar fotoğrafları içeren bir makale gibi çeşitli kaynaklardan gelen verileri işleyen bir bileşenin, oluşturulmadan önce tüm verileri getirmesi için sunucuya birkaç gidiş geliş yapması gerekebilir. Ayrıca, REST aracılığıyla döndürülen veri miktarı, genellikle bu bileşeni oluşturmak için gerekenden daha fazladır.

   Birçok kaynak bir API'den veri gerektiriyorsa, API bir performans darboğazı haline gelebilir. GraphQL, bu sorunlara performanslı bir çözüm sunar. Kendi başına GraphQL, API'niz için bir sorgu dili ve verileriniz için tanımladığınız bir tür sistemi kullanarak sorguları yürütmek için sunucu tarafı çalışma zamanıdır. REST'ten farklı olarak, GraphQL tüm verileri tek bir istekte alabilir ve yanıt, tipik olarak REST'te olduğu gibi fazla veya eksik veri getirmeden tam olarak gerekli olan şeydir.

   Ek olarak, GraphQL şema (verinin nasıl yapılandırıldığını söyleyen meta veri) kullandığından, verileri zaten tercih edilen yapıya göre düzenleyebilir, bu nedenle, örneğin GraphQL ile durum yönetimi ile uğraşmak için kullanılan JavaScript kodunu kaldırabiliriz. istemcide daha hızlı çalışan daha temiz bir uygulama kodu.

   GraphQL'yi kullanmaya başlamak veya performans sorunlarıyla karşılaşmak istiyorsanız, bu makaleler oldukça yardımcı olabilir:

   • Bir GraphQL Primer: Neden Yeni Bir API Türüne İhtiyacımız Var, Eric Baer,
   • Bir GraphQL Primer: API Tasarımının Evrimi, Eric Baer,
   • Leonardo Losoviz tarafından optimum performans için bir GraphQL sunucusu tasarlama,
   • Wojciech Trocki tarafından açıklanan GraphQL performansı.

1. AMP veya Hızlı Makaleler mi kullanacaksınız?
   Kuruluşunuzun önceliklerine ve stratejisine bağlı olarak, Google'ın AMP'sini veya Facebook'un Anında Makalelerini veya Apple'ın Apple Haberlerini kullanmayı düşünebilirsiniz. Bunlar olmadan iyi performans elde edebilirsiniz, ancak AMP ücretsiz içerik dağıtım ağı (CDN) ile sağlam bir performans çerçevesi sağlarken Hızlı Makaleler Facebook'ta görünürlüğünüzü ve performansınızı artıracaktır.

   Bu teknolojilerin kullanıcılar için görünüşte bariz faydası garantili performanstır , bu nedenle bazen "normal" ve potansiyel olarak şişirilmiş sayfalar yerine AMP-/Apple News/Anında Sayfa bağlantılarını tercih edebilirler. Çok sayıda üçüncü taraf içeriğiyle uğraşan yoğun içerikli web siteleri için bu seçenekler, oluşturma sürelerini önemli ölçüde hızlandırmaya yardımcı olabilir.

   Yapmadıkları sürece. Tim Kadlec'e göre, örneğin, "AMP belgeleri emsallerinden daha hızlı olma eğilimindedir, ancak bunlar mutlaka bir sayfanın performanslı olduğu anlamına gelmez. Performans açısından en büyük farkı yaratan şey AMP değildir."

   Web sitesi sahibi için bir avantaj açıktır: bu biçimlerin ilgili platformlarda keşfedilebilirliği ve arama motorlarında artan görünürlük.

   Eh, en azından eskiden böyleydi. AMP artık En Çok Okunan Haberler için bir gereklilik olmadığından, yayıncılar bunun yerine AMP'den geleneksel bir yığına geçebilir ( teşekkürler, Barry! ).

   Yine de, AMP'leri PWA'nız için veri kaynağı olarak yeniden kullanarak aşamalı web AMP'leri oluşturabilirsiniz. Dezavantaj? Açıkça görülüyor ki, duvarlarla çevrili bir bahçedeki varlık, geliştiricileri içeriklerinin ayrı bir sürümünü üretip sürdürebilecek ve Anında Makaleler ve Apple News söz konusu olduğunda gerçek URL'ler olmadan (teşekkürler Addy, Jeremy!) konumlandırıyor.

2. CDN'nizi akıllıca seçin.
   Yukarıda bahsedildiği gibi, ne kadar dinamik veriye sahip olduğunuza bağlı olarak, içeriğin bir kısmını statik bir site oluşturucuya "dış kaynaklı olarak" verebilir, onu bir CDN'ye itebilir ve ondan statik bir sürüm sunabilirsiniz, böylece isteklerden kaçınabilirsiniz. sunucu. Aslında, bu oluşturuculardan bazıları aslında birçok otomatik optimizasyona sahip web sitesi derleyicileridir. Derleyiciler zamanla optimizasyonlar ekledikçe, derlenen çıktı zamanla küçülür ve hızlanır.

   CDN'lerin dinamik içerik de sunabileceğine (ve yükleyebileceğine) dikkat edin. Bu nedenle, CDN'nizi statik varlıklarla sınırlamak gerekli değildir. CDN'nizin sıkıştırma ve dönüştürme (örneğin görüntü optimizasyonu ve uçta yeniden boyutlandırma) gerçekleştirip gerçekleştirmediğini, sunucu çalışanları için destek sağlayıp sağlamadığını, A/B testinin yanı sıra sayfaların statik ve dinamik bölümlerini bir araya getiren kenar tarafı içermelerini iki kez kontrol edin. CDN'nin ucunda (yani kullanıcıya en yakın sunucu) ve diğer görevler. Ayrıca, CDN'nizin QUIC (HTTP/3) üzerinden HTTP'yi destekleyip desteklemediğini kontrol edin.

   Katie Hempenius, iyi bir CDN'nin nasıl seçileceği , nasıl ince ayar yapılacağı ve bir CDN'yi değerlendirirken akılda tutulması gereken tüm küçük şeyler hakkında fikir veren harika bir CDN kılavuzu yazdı. Genel olarak, içeriği olabildiğince agresif bir şekilde önbelleğe almak ve Brotli, TLS 1.3, HTTP/2 ve HTTP/3 gibi CDN performans özelliklerini etkinleştirmek iyi bir fikirdir.

   Not : Patrick Meenan ve Andy Davies tarafından yapılan araştırmaya dayalı olarak, HTTP/2 önceliklendirmesi birçok CDN'de etkin bir şekilde bozulur, bu nedenle bir CDN seçerken dikkatli olun. Patrick, HTTP/2 Önceliklendirme konusundaki konuşmasında daha fazla ayrıntıya sahiptir ( teşekkürler, Barry! ).

   

   Bir CDN seçerken, özelliklerine ayrıntılı bir genel bakış sunan bu karşılaştırma sitelerini kullanabilirsiniz:

   • CDN Karşılaştırması, Cloudfront, Aazure, KeyCDN, Fastly, Verizon, Stackpach, Akamai ve diğerleri için bir CDN karşılaştırma matrisi.
   • CDN Perf, her gün 300 milyon testi toplayıp analiz ederek CDN'ler için sorgu hızını ölçer ve tüm sonuçlar tüm dünyadaki kullanıcılardan gelen RUM verilerine dayanır. Ayrıca DNS Performans karşılaştırmasını ve Bulut Performans Karşılaştırmasını kontrol edin.
   • CDN Gezegen Kılavuzları, Eski Servis Etme, Temizleme, Başlangıç ​​Kalkanı, Ön Getirme ve Sıkıştırma gibi belirli konular için CDN'lere genel bir bakış sağlar.
   • Web Almanak: CDN Kabulü ve Kullanımı, en iyi CDN sağlayıcıları, RTT ve TLS yönetimi, TLS anlaşma süresi, HTTP/2 benimseme ve diğerleri hakkında bilgi sağlar. (Ne yazık ki, veriler yalnızca 2019'dandır).

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