Preload, prefetch ja preconnect: milloin niistä oikeasti on hyötyä
Resource hints ovat hyödyllisiä, kun ne vastaavat todellisiin selaimen pullonkauloihin. Sokeasti käytettyinä ne lisäävät prioriteettikohinaa ja voivat joskus hidastaa sivuja.
Sisällysluettelo
- Resource hints eivät ole taikuutta
- Mitä selain tekee jo hyvin
- Preload: nykyisen sivun resursseille, jotka löytyvät liian myöhään
- Preload ja LCP-kuvat
- Prefetch: seuraavalle sivulle, ei tälle
- Preconnect: kalliille yhteyksille tärkeisiin origineihin
- DNS-prefetch: kevyempi serkku
- Miten päättää: käytännön työnkulku
- 1. Tunnista pullonkaula
- 2. Lisää yksi vihje kerrallaan
- 3. Tarkista prioriteetin sivuvaikutukset
- 4. Varmista otsakkeet ja välimuisti
- Yleiset virheet
- Liian monen asian preloadaaminen
- Prefetchin käyttäminen pakollisiin resursseihin
- Preconnect jokaiseen kolmanteen osapuoleen
- Mobiiliolosuhteiden unohtaminen
- Yksinkertainen päätöstaulukko
- Rauhallinen sääntö
Resource hints eivät ole taikuutta
preload, prefetch ja preconnect nähdään usein suorituskyvyn tarkistuslistana. Lisää muutama tagi <head>-osioon, aja Lighthouse uudelleen ja tunne olosi paremmaksi. Ne eivät toimi niin.
Nämä vihjeet ovat ohjeita selaimen latausputkelle. Ne voivat auttaa, kun tiedät jotain, mitä selain ei voi havaita riittävän aikaisin. Ne voivat haitata, kun arvaat, ylipriorisoit ei-kriittistä työtä tai lämmität yhteyksiä, joita käyttäjät eivät koskaan tarvitse.
Lyhyt versio:
- Käytä
preload-vihjettä nykyisen sivun tarvitsemiin resursseihin, jotka löytyvät liian myöhään. - Käytä
prefetch-vihjettä todennäköisiin tulevan navigoinnin resursseihin, älä nykyisen sivun välttämättömiin resursseihin. - Käytä
preconnect-vihjettä tärkeisiin kolmannen osapuolen origineihin, joissa yhteyden muodostaminen on todellinen viive.
Käytännön kysymys ei ole ”mikä vihje on nopein?” Se on ”mitä selain odottaa, ja voiko tämä vihje poistaa odotuksen?”
Mitä selain tekee jo hyvin
Nykyaikaiset selaimet eivät ole passiivisia tiedostojen lataajia. Ne jäsentävät HTML:ää, skannaavat eteenpäin resursseja varten, määrittävät prioriteetteja, käyttävät yhteyksiä uudelleen, lykkäävät työtä, joka ei ole näkyvää, ja mukautuvat verkko-olosuhteisiin.
Siksi resource hints -vihjeitä kannattaa käyttää valikoivasti. Jos stylesheet, script, kuva tai fontti löydetään jo aikaisin ja sille annetaan oikea prioriteetti, vihjeen lisääminen ei välttämättä tee mitään. Pahempaa on, että se voi kilpailla tärkeämpien resurssien kanssa.
Ennen vihjeiden lisäämistä katso waterfall-jälkeä DevToolsissa tai laboratorioraportissa. Jos käytät Lighthousea, aloita diagnostiikasta pisteiden sijaan; meillä on erillinen opas Lighthouse-raportin lukemiseen ilman paniikkia — mutta huomaa, että oikea URL on kirjainkoon suhteen tarkka, joten käytä tarvittaessa sivustosi navigaatiosta löytyvää linkitettyä artikkelia.
Todellinen näyttö näkyy yleensä kolmessa paikassa:
- Kriittinen resurssi alkaa myöhään, koska selain löytää sen myöhään.
- Yhteys tärkeään originiin vie huomattavasti aikaa ennen ensimmäistä pyyntöä.
- Seuraavan sivun resurssi on hyvin ennustettava ja halpa hakea joutoajalla.
Jos mikään näistä ei pidä paikkaansa, vihje on todennäköisesti koristelua.
Preload: nykyisen sivun resursseille, jotka löytyvät liian myöhään
preload kertoo selaimelle: ”Hae tämä resurssi nyt, koska nykyinen sivu tarvitsee sitä.”
Tyypillinen esimerkki on CSS:n sisällä viitattu web font. Selaimen täytyy ladata HTML, löytää CSS, ladata CSS, jäsentää se, löytää fontti ja pyytää sitten fonttia. Jos fontti on tärkeä above-the-fold-tekstille, löytyminen voi olla niin myöhäistä, että se aiheuttaa layout shift -muutoksia tai viivästyttää tekstin renderöintiä.
Preload voi aikaistaa tätä pyyntöä:
<link rel='preload' href='/fonts/inter-var.woff2' as='font' type='font/woff2' crossorigin>as-attribuutilla on merkitystä. Se kertoo selaimelle, millaisesta resurssista on kyse, mikä vaikuttaa prioriteettiin, välimuistiin, content security policyyn ja pyyntöotsakkeisiin. Fontit tarvitsevat yleensä myös crossorigin-attribuutin, vaikka ne tarjottaisiin samalta sivustolta, koska fonttien haku käyttää CORS-tilaa.
Hyviä preload-ehdokkaita ovat:
- Ensisijainen web font, jota käytetään näkyvässä tekstissä.
- Hero image, joka on Largest Contentful Paint -elementti eikä löydy aikaisin.
- Epäsuorasti ladattu kriittinen CSS-tiedosto.
- Module tai script, jota tarvitaan hyvin aikaisin mutta joka on piilossa toisen scriptin takana.
Huonoja preload-ehdokkaita ovat:
- Jokainen design systemin fonttipaino.
- Kuvat below the fold -alueella.
- Scriptit, joita ei tarvita alkuperäiseen renderöintiin.
- Resurssit, jotka selain löytää jo ensimmäisestä HTML-palasta.
Preload on tehokas, koska se vaikuttaa nykyisen sivun prioriteettiin. Juuri siksi sitä on myös helppo käyttää väärin. Jos preloadaat viisi suurta assettia, et enää auta selainta. Väittelet sen kanssa.
Fontit ovat klassinen tapaus. Yhden ensisijaisen fonttitiedoston preload voi auttaa. Kuuden painon ja kursiivien preload yleensä pahentaa tilannetta. Jos fontit ovat pullonkaulasi, korjaa ensin fonttijoukko; oppaamme siitä, miksi web fonts ovat edelleen helpoin suorituskykyvoitto useimmilla sivustoilla, käsittelee tätä siivousta tarkemmin.
Preload ja LCP-kuvat
LCP-kuvan preload voi olla hyödyllinen, kun kuva ei näy alkuperäisessä HTML:ssä. Yleisiä syitä ovat CSS-taustakuvat, client-rendered-komponentit tai responsive image -logiikka, joka ilmestyy myöhään.
Mutta jos hero image on jo HTML:ssä <img>-elementtinä, jossa on järkevä srcset, sizes, mitat eikä lazy loadingia, selain löytää sen todennäköisesti nopeasti. Tällöin fetchpriority='high' voi olla preloadia sopivampi ratkaisu sivusta riippuen.
Hyvä testi: jos kuvan pyyntö alkaa waterfallissa myöhään ja kuvasta tulee LCP-elementti, harkitse preloadia. Jos se alkaa aikaisin mutta latautuu hitaasti, ongelma on koko, formaatti, CDN:n käyttäytyminen tai palvelimen viive — ei löytyminen. Kuvaformaattipäätöksiin auttaa artikkeli milloin AVIF voittaa WebP:n ja milloin ei.
Prefetch: seuraavalle sivulle, ei tälle
prefetch kertoo selaimelle: ”Tätä resurssia saatetaan tarvita pian, mutta sitä ei tarvita juuri nyt.”
Tämä ero on tärkeä. Prefetch on tarkoituksella matalan prioriteetin toiminto. Selain voi hakea sen joutoajalla ja tallentaa myöhempää käyttöä varten. Se voi myös ohittaa sen heikoilla yhteyksillä, data-saving-tiloissa tai muistipaineessa.
Käytä prefetchiä, kun käyttäjän aikomus on riittävän vahva, jotta seuraava resurssi on todennäköinen.
Hyviä prefetch-ehdokkaita ovat:
- Monisivuisen checkoutin seuraava vaihe.
- Hakutulokset sen jälkeen, kun käyttäjä alkaa kirjoittaa kyselyä, jos seuraava route on ennustettava.
- Sisällysluettelosta linkitetyt dokumentaatiosivut, kun käyttäjä lukee aktiivisesti lähellä olevaa sisältöä.
- Route chunkit single-page appissa sen jälkeen, kun käyttäjä vie hiiren navigointikohteen päälle tai kohdistaa siihen.
Huonoja prefetch-ehdokkaita ovat:
- Koko navigaatiopuusi.
- Suuret videot tai kuvagalleriat.
- Kolmannen osapuolen scriptit ”varmuuden vuoksi”.
- Sivut, joille käyttäjät harvoin siirtyvät seuraavaksi.
Prefetchissä pidättyvyys palkitaan. Haettu mutta käyttämättä jäänyt resurssi ei ole ilmainen. Se kuluttaa kaistanleveyttä, palvelinkapasiteettia, energiaa ja mahdollisesti käyttäjän dataa. Mobiiliverkoissa spekulatiivinen haku voi olla aktiivisesti epäystävällistä.
Monilla sivustoilla paras prefetch-strategia perustuu aikomukseen. Älä prefetchaa hinnastosivua heti, kun etusivu latautuu. Prefetchaa se, kun käyttäjä avaa hinnastovalikon, vie hiiren hinnastolinkin päälle tai vierittää lähelle call-to-actionia, joka ennustaa vahvasti navigointia.
Muista myös, että selainten käyttäytyminen vaihtelee. Jotkin selaimet ovat prefetchin kanssa konservatiivisia; jotkin tietosuoja-asetukset vähentävät tai poistavat spekulatiivisen lataamisen käytöstä. Kohtele prefetchiä opportunistisena parannuksena, ei oikeellisuusmekanismina.
Preconnect: kalliille yhteyksille tärkeisiin origineihin
preconnect kertoo selaimelle: ”Aloita yhteyden muodostaminen tähän originiin nyt.”
Tähän voi sisältyä DNS-haku, TCP-yhteys ja TLS-neuvottelu. Kolmannen osapuolen origineissa tämä valmistelu voi kestää satoja millisekunteja, erityisesti korkean latenssin verkoissa. Jos sivu tarvitsee pian kriittisen pyynnön kyseisestä originista, preconnect voi nopeuttaa myöhempää pyyntöä.
Esimerkki:
<link rel='preconnect' href='https://fonts.gstatic.com' crossorigin>Hyviä preconnect-ehdokkaita ovat:
- Fonttiorigin, jota käytetään render-blocking-tekstissä.
- Kriittinen API-origin, jota tarvitaan alkuvaiheen vuorovaikutuksessa.
- CDN-origin, joka palvelee above-the-fold-assetteja.
- Maksu- tai identiteettipalvelu, jota tarvitaan heti käyttäjän toiminnon jälkeen.
Huonoja preconnect-ehdokkaita ovat:
- Analytics- ja mainospäätteet, jotka eivät ole käyttäjän kannalta kriittisiä.
- Originit, joita käytetään vain joissakin sessioissa.
- Pitkät listat kolmansista osapuolista.
- Same-origin-resurssit, joihin selaimella on jo yhteys tai joihin se avaa yhteyden pian.
Preconnectilla on ylläpitokustannus. Avoimet socketit kuluttavat muistia ja verkkoresursseja. Selaimet sulkevat käyttämättömiä yhteyksiä, mutta se ei tee tarpeettomista preconnecteista harmittomia.
Hyödyllinen sääntö: preconnectaa sivulla korkeintaan yhteen tai kahteen korkean varmuuden kolmannen osapuolen originiin. Jos tunnet houkutusta lisätä enemmän, kolmannen osapuolen arkkitehtuurisi tarvitsee luultavasti tarkastelua enemmän kuin vihjeesi laajentamista.
DNS-prefetch: kevyempi serkku
Saatat nähdä myös dns-prefetch-vihjeen:
<link rel='dns-prefetch' href='https://example-cdn.com'>Tämä selvittää vain verkkotunnuksen nimen. Se ei avaa TCP- tai TLS-yhteyttä. Se on preconnectia halvempi, mutta myös vähemmän hyödyllinen.
DNS-prefetch voi olla järkevä matalamman varmuuden kolmannen osapuolen origineille, joissa täysi preconnect tuntuu liian aggressiiviselta. Käytännössä, jos origin on kriittinen ja sitä käytetään varmasti pian, suosi preconnectia. Jos se on vain mahdollinen, käytä joko DNS-prefetchiä tai älä tee mitään.
Miten päättää: käytännön työnkulku
Aloita mittauksesta, älä tageista.
1. Tunnista pullonkaula
Avaa performance trace ja etsi myöhäistä löytymistä. Alkoiko fontin, hero imagen tai scriptin pyyntö vasta sen jälkeen, kun toinen tiedosto oli ladattu ja jäsennetty? Se on preload-ehdokas.
Jos pyyntö alkaa vasta pitkän DNS/TCP/TLS-valmistelun jälkeen kolmannen osapuolen originiin, se on preconnect-ehdokas.
Jos nykyinen sivu on kunnossa mutta seuraava navigointi on ennustettavasti hidas, prefetch voi auttaa.
2. Lisää yksi vihje kerrallaan
Resource hints -vihjeet vaikuttavat toisiinsa. Lisää yksi, testaa se ja pidä se vain, jos waterfall paranee eivätkä käyttäjälle näkyvät metriikat heikkene.
Preloadin kohdalla seuraa, käytetäänkö vihjattua resurssia todella pian. Chrome voi varoittaa, kun preloadattua resurssia ei käytetä pian latauksen jälkeen. Suhtaudu varoitukseen vakavasti.
3. Tarkista prioriteetin sivuvaikutukset
Preload voi viedä kaistanleveyttä pois CSS:ltä, JavaScriptiltä tai kuvilta, joilla on enemmän merkitystä. Preconnect voi varata yhteyspaikan. Prefetch voi lisätä taustaliikennettä.
Oikea lopputulos ei ole ”vihjattu tiedosto alkaa aikaisemmin”. Oikea lopputulos on ”sivu paranee käyttäjien kannalta merkityksellisesti”. Katso LCP:tä, INP:tä, CLS:ää ja mahdollisuuksien mukaan real-user monitoringia.
4. Varmista otsakkeet ja välimuisti
Vihjeet voidaan lähettää HTML:ssä tai HTTP Link -otsakkeissa. Otsakkeet ovat hyödyllisiä, kun palvelin tietää aikaisin, mitä sivu tarvitsee, mutta niitä on vaikeampi tarkastaa rennosti. Jos debuggaat, onko vihje todella mukana tuotannossa, raaoilla otsakkeilla on merkitystä; tämä on juuri sellainen tilanne, jota käsitellään oppaassamme redirectien ja HTTP-otsakkeiden debuggaamiseen.
Myös välimuistilla on merkitystä. Resurssin preload väärillä tunnistetiedoilla, väärällä as-arvolla tai eri URL-parametreilla voi aiheuttaa kaksoislatauksia. Se on yksi yleisimmistä tavoista, joilla hyvää tarkoittavasta preloadista tulee suorituskykybugi.
Yleiset virheet
Liian monen asian preloadaaminen
Jos kaikki on kriittistä, mikään ei ole. Rajaa preload resursseihin, joita tarvitaan alkuperäiseen renderöintiin tai välittömään interaktiivisuuteen. Tyypillisellä sivulla pitäisi olla nollasta kolmeen preloadia, ei kahtakymmentä.
Prefetchin käyttäminen pakollisiin resursseihin
Prefetch on matalan prioriteetin ja valinnainen. Älä käytä sitä assetteihin, joita nykyinen sivu tarvitsee. Jos sivu tarvitsee sitä nyt, harkitse preloadia tai normaalia HTML-löytymistä.
Preconnect jokaiseen kolmanteen osapuoleen
Kolmannen osapuolen kuormittamilla sivuilla on usein kymmenen tai useampia ulkoisia origineja. Preconnect kaikkiin niistä luo kohinaa. Valitse se yksi tai kaksi, jotka ovat sekä kriittisiä että ennustettavasti käytössä.
Mobiiliolosuhteiden unohtaminen
Resource hints -vihjeet ovat arvokkaimpia hitaammilla yhteyksillä, mutta myös vaarallisimpia siellä. Hukattu prefetch nopealla työpöytäyhteydellä on pyöristysvirhe. Rajoitetussa mobiililiittymässä se on huono vaihtokauppa.
Yksinkertainen päätöstaulukko
| Situation | Best hint | Why | |---|---:|---| | CSS:n kautta löytyvä kriittinen fontti | preload | Nykyinen sivu tarvitsee sitä, löytyminen on myöhäistä | | CSS:n tai client renderingin taakse piilotettu hero image | preload | Voi parantaa LCP:tä, jos kuva alkaa myöhään | | Todennäköinen seuraava route käyttäjän aikomuksen jälkeen | prefetch | Auttaa tulevaa navigointia estämättä nykyistä sivua | | Kriittinen kolmannen osapuolen fontti-/API-origin | preconnect | Poistaa yhteyden muodostamisen kriittiseltä polulta | | Mahdollinen mutta epävarma kolmannen osapuolen origin | dns-prefetch tai ei mitään | Alempi kustannus, alempi varmuus | | Below-the-fold-kuva | none | Anna lazy loadingin ja selaimen prioriteetin toimia |
Rauhallinen sääntö
Resource hints toimivat parhaiten, kun ne ovat tylsiä ja täsmällisiä. Yksi fontti. Yksi LCP-kuva. Yksi tärkeä kolmannen osapuolen origin. Yksi todennäköinen seuraava route aikomuksen jälkeen.
Ne toimivat huonosti, kun niitä käytetään optimismina: ehkä käyttäjä tarvitsee tätä, ehkä selaimen pitäisi hakea tuo, ehkä useampi vihje tarkoittaa enemmän nopeutta.
Selaimet optimoivat jo aggressiivisesti. Tehtäväsi ei ole mikromanageroida jokaista pyyntöä. Tehtäväsi on korjata ne harvat tapaukset, joissa selaimelta puuttuu tieto oikealla hetkellä.
Usein kysytyt kysymykset
Pitäisikö minun preloadata kaikki fonttini?
Onko prefetch turvallista ottaa käyttöön jokaiselle sisäiselle linkille?
Mitä eroa on preconnectilla ja dns-prefetchillä?
Voivatko resource hints parantaa Core Web Vitals -mittareita?
Pitäisikö resource hints lisätä HTML:ään vai HTTP-otsakkeisiin?
Lähteet ja lisälukeminen
