Korjaa "Avoid Chaining Critical Requests" Lighthousessa.

Miten latausprioritetti määritetään

Kriittiset pyynnöt ovat resursseja, jotka ladataan korkealla prioriteetilla sivun alkuperäisen latauksen aikana. Miten tämä prioriteetti määritetään?

Latausprioriteetin määrittää selain itse. Selain noudattaa sääntöjoukkoa kunkin resurssin prioriteetin määrittämiseksi. Se, mitkä elementit lopulta saavat korkeimman prioriteetin, riippuu sivun rakenteesta. Elementit, jotka selain katsoo tarpeellisiksi sivun ensimmäiseen renderöintiin, saavat korkeimman prioriteetin.

Selaimesi tekee aluksi koulutetun arvauksen siitä, mitkä elementit ovat tärkeimpiä. Yleisesti ottaen latausprioritetti toimii näin: HTML saa aina korkeimman prioriteetin, sitten tyylitiedostot, synkroninen JavaScript, fontit, Ajax-pyynnöt, sivun yläosan kuvat, sivun myöhemmät kuvat ja sitten asynkroniset JavaScript-tiedostot.

Voit itse nähdä, mitkä resurssit saavat korkean prioriteetin sivullasi. Avaa kehittäjäkonsoli painamalla Ctrl + Shift + J. Siirry verkko-välilehdelle, napsauta sarakkeiden nimiä hiiren oikealla painikkeella ja valitse 'Priority'

Miten kriittisten pyyntöjen ketju vaikuttaa sivun latausaikaan?

Sivua ladattaessa selain aloittaa 'display blocking' -tilassa. Tässä tilassa tärkeimmät resurssit ladataan korkealla prioriteetilla. Nämä ovat kriittiset resurssit.

Selain ei aloita sivun renderöintiä (täysin) ennen kuin kaikki kriittiset resurssit on ladattu. Mikä tahansa kriittinen resurssi voi siis estää sivun ensimmäisen renderöinnin.

Mitä vähemmän kriittisiä resursseja sivulla on, sitä vähemmän selaimen tarvitsee tehdä työtä ensimmäisen sisällön saamiseksi näytölle ja sitä vähemmän kilpailua on CPU:sta ja muista resursseista.

Miten korjata "Avoid Chaining Critical Requests" Lighthousessa?

Voit vähentää kriittisten pyyntöjen vaikutusta kolmella tavalla:

1. Vähennä kriittisten resurssien määrää . Muunna kriittiset resurssit ei-kriittisiksi poistamalla tai lykkäämällä niitä.
2. Vähennä kriittisten tavujen määrää . Se saattaa olla ilmeistä, mutta kriittisen polun resurssien tavumäärän vähentäminen nopeuttaa kriittisten resurssien lataamista. Esimerkiksi gzip-pakkauksen, JavaScript tree shakingin, kuvien optimoinnin tai font subsettingin avulla.
3. Paranna kriittisen polun latausjärjestystä . Käytä resurssivihjeleitä, kuten preloadia, ohittaaksesi resurssien löytämisen ja varmistaaksesi, että kriittiset resurssit ladataan mahdollisimman nopeasti.

Vaihtoehtoja on monia. Paras vaihtoehto riippuu resurssin tiedostotyypistä:

1. HTML

HTML, joka on käytännössä sivu jolla vierailet, ladataan aina korkeimmalla prioriteetilla. Sivu itse on aina osa kriittisten pyyntöjen ketjua. Siksi sivu itse on ensimmäinen asia, joka on otettava huomioon kriittisten pyyntöjen ketjua optimoitaessa..

Sisällön viivästetty lataaminen: Monet suuret sivustot, kuten Google itse, käyttävät tätä tekniikkaa kriittisten pyyntöjen ketjun vähentämiseksi. Esimerkiksi hakutulossivulla osia sisällöstä, joita ei heti tarvita, ladataan vasta myöhemmin AJAX-pyynnön kautta.

Minify: Pienempi on aina nopeampi, käytä HTML-minifiointia poistaaksesi kommentit, välilyönnit ja tyhjät rivit sivulta.

Pakkaus : Lopuksi on tärkeää pakata tyylitiedostot oikein Brotli- tai GZIP-pakkauksella

2. Tyylitiedostot

Sivun head-osassa olevat tyylitiedostot ovat aina kriittisiä. Ilman tyylejä selain ei tiedä, miltä sivu näyttää. Tyylitiedostot ovat siksi vakio-osa kriittisten pyyntöjen ketjua Lighthousessa.

Critical CSS: Tyylitiedostot voidaan tehdä ei-kriittisiksi yksinkertaisella tempulla, jossa tyylitiedosto esiladataan resurssivihjeleiden avulla ja lisätään tyylitiedostoksi esilatauksen jälkeen.
Lisää seuraava koodi sivulle: Selaimesi lataa nyt tyylitiedoston matalammalla prioriteetilla ja käsittelee CSS:n renderöintiä estämättömänä. Se aloittaa renderöinnin odottamatta CSS:ää.

<link rel="preload"
      href="css.css"
      type="text/css"
      as="style"
      onload="this.onload=null;this.rel='stylesheet';"/>

Huomaa, kuinka sivulla tapahtuu nyt jotain outoa. Ensin sivu näytetään ja vasta CSS:n lataamisen jälkeen tyylit otetaan käyttöön. Kaikki sisältö välähtää nyt tyylittömästä sisällöstä tyylitettyyn sisältöön. Voimme korjata tämän critical CSS:llä.
Critical CSS on kokoelma kaikista CSS-säännöistä, joita tarvitset sivun näkyvään osaan. Voit luoda critical CSS:n itse NodeJS:n tai useiden verkkotyökalujen avulla. Sijoita tämä critical CSS sivun head-osaan ja lataa loput CSS:stä matalammalla prioriteetilla.

Media queries : Lataa vain laitteesi tyylit. Sivullasi vieraillaan usein mobiililla. Sinun ei siis tarvitse ladata työpöytä- ja tulostustyylejä. Tämä säästää aikaa ja lyhentää siten kriittisten pyyntöjen ketjua Lighthousessa.

Käytä media-attribuuttia. Media-attribuutti varmistaa, että tyylitiedosto ladataan vain, jos median tyyppi ei vastaa käyttämääsi mediaa.

<link href="all.css" rel="stylesheet" media="all">
<link href="print.css" rel="stylesheet" media="print">
<link href="desktop.css" rel="stylesheet" media="screen and (min-device-width: 1024px)">

Minify: Poista käyttämätön CSS. Monet sivustot käyttävät CSS-kirjastoja, kuten bootstrapia. Nämä kirjastot ovat usein ylitäydellisiä eikä kaikkia tyylimäärittelyjä käytetä.
Näitä kirjastoja on helppo muokata CSS-esikäsittelijällä (kuten SASS ). Poista yksinkertaisesti käyttämättömät tyyliryhmät muuttamalla, mitä sisällytetään, jotta ne pienenevät huomattavasti. Nämä esikäsittelijät antavat myös mahdollisuuden minifioida CSS:n poistamalla kaikki välilyönnit ja rivinvaihdot.\">

Pakkaus : Lopuksi on tärkeää pakata tyylitiedostot oikein Brotli- tai GZIP-pakkauksella

3. JavaScript

Sivun head-osassa olevat Javascript-tiedostot ladataan oletuksena korkealla prioriteetilla ja estävät sivun renderöinnin latauksen ja suorituksen aikana. Javascript on siksi vakio-osa kriittisten pyyntöjen ketjua.

Defer ja Async : Säädä Javascript-tiedostojen prioriteettia lataamalla ne asynkronisesti async- tai defer-attribuutin kautta. Asynkroniset skriptitiedostot ladataan rinnakkain matalammalla prioriteetilla. Lykätyt JavaScript-tiedostot ladataan myös rinnakkain ja Javascript-tiedoston suoritus viivästyy, joten Javascript-suoritus ei myöskään estä sivun alkuperäistä lataamista.

// blocks loading and execution
<script src="normalscript.js">
// async does not block during load, but it does block during execution
<script  src="asyncscript.js">
// defer does not block both during load nor execution
<script  src="deferscript.js">

Koodin jakaminen ja esilataus: Jos sivu ei salli JavaScriptin asynkronista lataamista, voi olla hyvä idea jakaa JavaScript useisiin tiedostoihin. Sijoita sivun latauksen aikana kriittinen JavaScript-osa pieneen tiedostoon ja esilataa tämä tiedosto. Sijoita ei-kriittinen JavaScript toiseen tiedostoon ja anna sen latautua ja suorittautua lykätysti tai asynkronisesti.

Minify : Pienennä tavujen määrää kahdella tavalla Javascript Uglyfier -työkalulla. Tämä on älykäs työkalu, joka analysoi Javascriptin ja tekee siitä mahdollisimman pienen. \">

Pakkaus : Lisäksi vähennä tavujen määrää pakkaamalla Javascript Gzip- tai Brotli-pakkauksella.

4. Web-fontit

Web-fontit ovat yleensä viimeisinä ladattavat tiedostot kriittisten pyyntöjen ketjussa. Tämä johtuu siitä, että web-fontit perustuvat löytämiseen. Ne ladataan vasta, kun selain huomaa, että niitä tarvitaan. Tätä varten selaimen on ensin analysoitava HTML ja tarkistettava tyylitiedostosta, mitä fonttia käytetään.

Esilataus : Kun olet varma, että tulet käyttämään fonttia, on yleensä nopeampaa esiladata tämä fontti. Fontti ladataan tällöin mahdollisimman aikaisin, mikä minimoi vaikutuksen kriittisten pyyntöjen ketjuun. Esilataa fontti lisäämällä tämä koodi mahdollisimman aikaisin sivun head-osaan

<link rel="preload" href="font.woff2" as="font" type="font/woff2" crossorigin>

Fonttistrategia : Lisäksi on monia muita tapoja nopeuttaa fonttien lataamista.

• Käytä aina paikallisia web-fontteja äläkä koskaan etäisännöityjä fontteja, kuten Google-fontteja.
• Pienennä fonttia font subsettingillä
• Lataa ei-kriittiset fontit Javascriptin <a href="https://developer.mozilla.org/en-US/docs/Web/API/FontFace">fontface-rajapinnan</a> kautta
• Käytä display = swap -arvoa estääksesi fonttia estämästä alkuperäistä renderöintiä
• Anna selainten luoda omat fonttivarianttinsa fonttisynteesin avulla

Kuvat

Sivun latauksen aikana näkyvässä viewport-alueessa näkyvät kuvat voivat myös saada korkean prioriteetin ja häiritä kriittistä polkua. Kun olet varma, että kuva näkyy aina verkkosivuston näkyvässä osassa, voi olla hyödyllistä esiladata myös tämä kuva.

<link rel="preload" as="image" href="important-image.webp">

Kaikkien kuvien osalta, jotka eivät ole heti näkyvissä, ole varovainen ja käytä lazy load -latausta näille kuville. Käytä loading = "lazy" -attribuuttia viivästääksesi kuvan lataamista juuri ennen kuin kuva tulee näkyviin.

<img loading="lazy" src="lazy-image.webp" width="20" height="20" alt="...">

5. AJAX-pyynnöt

Ajax-pyynnöt saavat aina korkean prioriteetin. Siksi Ajax-pyynnöt kannattaa mieluiten lykätä, kunnes sivu on renderöity loppuun. Odota, kunnes sivu on lähettänyt "load"-tapahtuman.

Jos AJAX-pyynnön lykkääminen ei ole mahdollista, voit varmistaa Ajax-pyynnön saatavuuden selaimelle esilataamalla sen.

window.addEventListener('load', (event)=>{
  console.log('this is a good time for an AJAX request');
});

6. iframet

Iframet ladataan yleensä korkealla prioriteetilla. Koska iframe on käytännössä sivu sivun sisällä, iframe voi aiheuttaa erittäin merkittävän viiveen sivun latausajoissa. Iframen tarvitsemat resurssit voidaan myös ladata korkealla prioriteetilla ja ne muodostavat oman kriittisten pyyntöjen ketjunsa. Iframejen käyttö voi siksi vaikuttaa merkittävästi Lighthouse-pisteeseesi.

Voit viivästää iframen lataamista loading = "lazy" -attribuutilla. Tämä tekee usein eron, kun iframe ei ole heti näkyvissä latauksen aikana. Iframen syöttäminen sivulle JavaScriptin kautta on usein nopeampaa. Tämä antaa sinulle enemmän hallintaa ajoituksesta varmistaaksesi, ettei se päädy kriittisten pyyntöjen ketjuun.