Kas tie resource hints ir kam jų reikia
Kai kuriate svetainę, greičiausiai daugiausia dėmesio skiriame funkcionalumui, dizainui, gal dar SEO optimizavimui. Bet yra viena sritis, kuri dažnai lieka nuošalyje – tai puslapio įkrovimo greitis ir būtent ta dalis, kuri vyksta dar prieš naršyklei pradedant kraunti turinį. Čia ir ateina į pagalbą resource hints – nedidelės HTML direktyvos, kurios sako naršyklei: „Ei, tuoj mums reikės šito resurso, gal galėtum pasiruošti iš anksto?”
dns-prefetch ir preconnect yra dvi iš tokių direktyvų, kurios leidžia optimizuoti tinklo užklausas dar prieš joms realiai įvykstant. Skamba kaip maža detalė, bet realybėje tai gali sutaupyti šimtus milisekundžių – o mobiliuose tinkluose ar lėtesnėse vietovėse tai jaučiama labai aiškiai.
Problema paprasta: kai naršyklė susiduria su išoriniu resursu (pavyzdžiui, Google Fonts, CDN, analytics skriptais), ji turi atlikti kelis žingsnius – DNS užklausą, TCP handshake, galbūt TLS derybas. Visa tai užtrunka. O jei galėtume tai padaryti fone, kol vartotojas dar skaito puslapio turinį? Būtent tam ir skirti šie hints.
DNS prefetch – greitas DNS užklausų sprendimas
Pradėkime nuo paprasčiausio – dns-prefetch. Šis hint’as sako naršyklei: „Matai šitą domeną? Pasiieškokime jo IP adreso iš anksto, kad vėliau nereiktų laukti.”
DNS užklausa gali atrodyti kaip smulkmena, bet realybėje ji gali užtrukti 20-120 milisekundžių, priklausomai nuo vartotojo interneto ryšio ir DNS serverio atsako greičio. Kai puslapyje turite 5-10 išorinių domenų (analytics, fontai, reklamos, CDN), tai sudeda į gana solidų vėlavimą.
Naudojimas itin paprastas:
„`html „`
Dėmesio – naudojame tik protokolo-nepriklausomą formatą su dviem pasviraisiais brūkšniais arba pilną URL su protokolu. Naršyklė automatiškai supras, kad reikia išspręsti DNS.
Kada naudoti dns-prefetch? Kai žinote, kad puslapyje tikrai bus naudojamas tam tikras domenas, bet gal ne iš karto. Pavyzdžiui, turite nuotrauką, kuri yra „below the fold” (matoma tik nusukus žemyn), arba turite išorinį skriptą, kuris įsikrauna vėliau. DNS prefetch padaro pasiruošimo darbą iš anksto.
Preconnect – pilnas ryšio užmezgimas
Jei dns-prefetch yra kaip paskambinti draugui ir paklausti „ar esi namie?”, tai preconnect yra kaip atvykti prie jo durų ir būti pasiruošusiam įeiti. Šis hint’as ne tik išsprendžia DNS, bet ir užmezga TCP ryšį, o jei reikia – atlieka SSL/TLS handshake.
„`html „`
Čia svarbu suprasti skirtumą: preconnect yra daug „sunkesnis” nei dns-prefetch. Jis sunaudoja daugiau resursų – atidaro TCP jungtį, kuri užima atminties, ir jei ta jungtis nebus panaudota per ~10 sekundžių, naršyklė ją uždarys ir visas darbas nueis veltui.
Todėl preconnect naudokite tik tiems domenams, kuriuos tikrai naudosite greitai – idealiu atveju per pirmąjį sekundę ar dvi po puslapio įkrovimo. Pavyzdžiui, jei jūsų hero sekcijoje yra nuotrauka iš CDN, arba jei critical CSS įsikelia iš išorinio šaltinio.
Crossorigin atributas ir CORS
Pastebėjote crossorigin atributą antrame pavyzdyje? Tai svarbu, kai resursas bus kraunamas su CORS (pavyzdžiui, fontai, kai kurie API). Jei nenurodysit crossorigin, naršyklė užmegs vieną ryšį preconnect fazėje, o paskui, kai realiai kraus resursą su CORS, turės užmegzti naują ryšį. Rezultatas – dvigubas darbas ir jokios naudos.
Taisyklė paprasta: jei resursas bus kraunamas su crossorigin atributu, pridėkite jį ir prie preconnect.
Realūs panaudojimo scenarijai
Teorija teorija, bet kur konkrečiai tai naudoti? Štai keletas situacijų iš tikro gyvenimo:
Google Fonts optimizavimas: Tai klasikinis atvejis. Google Fonts naudoja du domenus – fonts.googleapis.com (CSS failui) ir fonts.gstatic.com (patiems fontų failams). Optimali strategija:
„`html „`
Kodėl preconnect abiem? Nes fontai yra critical resursas – jie reikalingi iš karto teksto atvaizdavimui. Čia sutaupysime 100-300ms lengvai.
CDN turinys: Jei naudojate CDN statiniams resursams (nuotraukos, JS, CSS), ir tie resursai yra above the fold:
„`html „`
API endpointai: Jei jūsų SPA aplikacija iš karto po įsikrovimo daro API užklausą:
„`html „`
Analytics ir trečiųjų šalių skriptai: Čia jau atsargesni būkite. Jei analytics nėra kritinis funkcionalumui, geriau naudoti dns-prefetch:
„`html „`
Kiek jų galima naudoti ir ar yra per daug?
Čia prasideda įdomesnė dalis. Teoriškai galite prirašyti dešimtis dns-prefetch ir preconnect direktyvų, bet praktiškai tai taps kontraproduktyvus.
Naršyklės turi ribotą kiekį resursų. Jei prirašysite 20 preconnect direktyvų, naršyklė tiesiog ignoruos dalį jų arba, dar blogiau, sunaudos tiek resursų bandydama visus ryšius užmegzti, kad sulėtins patį puslapio įsikrovimą.
Praktinės rekomendacijos:
– preconnect: ne daugiau 3-4 domenų. Naudokite tik kritiniams resursams.
– dns-prefetch: galite naudoti daugiau, bet vis tiek būkite protingi – 6-10 maksimum.
Dar vienas niuansas – mobilieji įrenginiai. Jie turi ribotesnius resursus ir dažnai lėtesnį internetą. Per daug agresyvus preconnect gali faktiškai sulėtinti puslapį mobiliuose. Testai realiais įrenginiais yra būtini.
Kaip matuoti efektą ir ar tai veikia
Gerai, prirašėte resource hints, bet kaip suprasti, ar jie realiai padeda? Yra keletas būdų.
Chrome DevTools Network tab: Atidarykite DevTools, eikite į Network tab ir perkraukite puslapį. Pasižiūrėkite į „Timing” stulpelį – ten matysite DNS Lookup, Initial Connection, SSL laiką. Su teisingai pritaikytais hints šie skaičiai turėtų būti žymiai mažesni arba net 0ms kritiniams resursams.
WebPageTest: Šis įrankis puikiai parodo waterfall grafiką. Galite palyginti dvi versijas – su hints ir be jų. Ieškokite žalių/oranžinių juostų prieš mėlynas (tai DNS ir connection laikas) – jos turėtų sumažėti.
Lighthouse: Nors Lighthouse tiesiogiai nevertina resource hints, jis rodo bendrą „Time to Interactive” ir „First Contentful Paint” metrikos. Su teisingais hints šios metrikos turėtų pagerėti.
Praktinis patarimas: darykite A/B testus. Įdiekite hints vienoje puslapio versijoje, palikite kitą be jų, ir pamatuokite realių vartotojų metrikas per Google Analytics ar panašų įrankį. Core Web Vitals metrikos (LCP, FID, CLS) turėtų parodyti skirtumą.
Dažniausios klaidos ir kaip jų išvengti
Per kelerius metus matęs įvairiausių projektų, pastebėjau kelias tipines klaidas, kurias daro developeriai su resource hints.
Klaida #1: Preconnect viskam. Matau projektus, kur yra 15 preconnect direktyvų. Tai ne tik nepadeda, bet ir kenkia. Kaip minėjau, preconnect yra brangus – naudokite jį tik kritiniams resursams.
Klaida #2: Pamirštas crossorigin. Ypač su fontais. Prirašote preconnect be crossorigin, o paskui fontai kraunasi su CORS. Rezultatas – naršyklė užmezga du atskirus ryšius ir preconnect neduoda jokios naudos.
Klaida #3: Hints resursams, kurių nėra. Kartais po refactoringo lieka seni hints domenams, kurie jau nebėra naudojami. Naršyklė vis tiek bando užmegzti ryšį, eikvoja resursus veltui.
Klaida #4: Ignoravimas mobilių įrenginių. Tai, kas veikia puikiai desktop’e, gali būti per daug agresyvu mobile. Visada testuokite realiuose įrenginiuose ar bent jau Chrome DevTools su network throttling.
Klaida #5: Naudojimas su HTTP/2 push. Jei jau naudojate HTTP/2 server push tam tikriems resursams, preconnect jiems gali būti perteklinis. Suprantama, ne visada turite kontrolę virš serverio, bet jei turite – koordinuokite šias strategijas.
Fallback ir naršyklių palaikymas
Gera žinia – resource hints palaiko praktiškai visos modernios naršyklės. dns-prefetch palaiko net IE11 (jei dar kas nors tuo rūpinasi). preconnect palaiko visos naršyklės nuo ~2016 metų.
Dar geresnė žinia – jei naršyklė nepalaiko šių hints, ji tiesiog juos ignoruoja. Tai progressive enhancement klasikinis pavyzdys – pridedame optimizaciją, kuri pagerina patirtį modernėse naršyklėse, bet nieko nesulaužo senose.
Vienintelis niuansas – Safari. Iki Safari 11.1 versijos preconnect nebuvo palaikomas. Bet kadangi Apple agresyviai stumia updates, šiandien tai jau ne problema daugumai vartotojų.
Jei vis tiek norite būti atsargūs, galite naudoti kombinaciją:
„`html „`
Modernios naršyklės naudos preconnect, o senesnes – bent dns-prefetch. Tai neturi neigiamo efekto – naršyklė tiesiog ignoruoja antrą direktyvą, jei pirmoji suveikė.
Automatizavimas ir įrankiai, kurie padeda
Rankiniu būdu valdyti resource hints gali būti varginantis, ypač dideliuose projektuose. Laimei, yra įrankių, kurie gali padėti.
Webpack plugins: Yra keletas webpack pluginų, kurie automatiškai generuoja resource hints pagal jūsų bundle’ų priklausomybes. preload-webpack-plugin yra vienas populiariausių, nors jis daugiau orientuotas į preload/prefetch, bet gali būti pritaikytas ir preconnect.
Next.js: Jei naudojate Next.js, galite pridėti resource hints per custom _document.js:
„`javascript
import Document, { Html, Head, Main, NextScript } from ‘next/document’
class MyDocument extends Document {
render() {
return (
)
}
}
export default MyDocument
„`
WordPress: Jei dirbate su WordPress, galite pridėti hints per wp_head hook’ą:
„`php
function add_resource_hints() {
echo ”;
echo ”;
}
add_action(‘wp_head’, ‘add_resource_hints’, 1);
„`
Cloudflare: Jei naudojate Cloudflare, jie turi „Early Hints” funkciją (HTTP 103 status), kuri veikia panašiai kaip resource hints, bet dar efektyviau. Verta pasižiūrėti, jei jau naudojate jų paslaugas.
Kai hints tampa strategija, o ne tik technika
Pradėjus rimčiau naudoti resource hints, greitai suprantate, kad tai ne tik keletas papildomų HTML eilučių. Tai tampa dalimi bendros performance strategijos.
Pavyzdžiui, pradedame galvoti apie critical rendering path kitaip. Kurie resursai tikrai reikalingi iš karto? Kuriuos galime atidėti? Ar verta iškelti kai kuriuos resursus į CDN, kad galėtume efektyviau naudoti preconnect? Gal verta konsoliduoti kelis domenus į vieną, kad sumažintume preconnect poreikį?
Darbas su resource hints taip pat atskleidžia trečiųjų šalių skriptų problematiką. Kai matote, kiek domenų jūsų puslapyje yra tik dėl analytics, reklamos, social media widget’ų – pradedame klausti, ar tikrai visi jie reikalingi. Gal galime sumažinti? Gal galima įkelti lazy load būdu?
Performance budgeting tampa natūralia dalimi proceso. Jei žinome, kad galime efektyviai naudoti tik 3-4 preconnect, tai verčia prioritizuoti. Kas svarbiau – Google Fonts ar analytics? CDN ar trečiųjų šalių API? Šie sprendimai formuoja geresnę architektūrą.
Dar viena įdomi dimensija – monitoring. Kai pradedame rimtai optimizuoti su resource hints, norime matyti rezultatus. Tai skatina įdiegti RUM (Real User Monitoring) sprendimus, sekti Core Web Vitals, analizuoti performance metrikas. Ir tai yra gerai – duomenimis pagrįsti sprendimai visada geresni už spėliojimus.
Taip pat verta paminėti, kad resource hints yra tik viena dalis didesnio performance optimization puzzle. Jie puikiai veikia kartu su:
– Image optimization (WebP, AVIF, lazy loading)
– Code splitting ir dynamic imports
– Service Workers ir caching strategijos
– HTTP/2 ar HTTP/3 naudojimas
– Critical CSS inline’inimas
Visa tai kartu sukuria greitą, responsive svetainę, kuri teikia gerą vartotojo patirtį. Resource hints yra ta mažai matoma, bet svarbi detalė, kuri padaro skirtumą tarp „geros” ir „puikios” svetainės.
Taigi, ar verta skirti laiko dns-prefetch ir preconnect? Definityviai taip. Tai viena iš tų optimizacijų, kuri reikalauja minimalių pastangų, bet duoda matomas rezultatus. Kelios HTML eilutės gali sutaupyti šimtus milisekundžių – o greitis yra ne tik techninis parametras, bet ir verslo metrikos. Greitesni puslapiai reiškia geresnius conversion rates, mažesnius bounce rates, laimingesnį SEO.
Pradėkite nuo paprasto – identifikuokite 2-3 kritinius išorinius domenus jūsų projekte ir pridėkite jiems preconnect. Pamatuokite rezultatą. Paskui eksperimentuokite su dns-prefetch mažiau kritiniems resursams. Testuokite, matuokite, iteruokite. Performance optimization nėra vienkartinis darbas – tai nuolatinis procesas, bet resource hints yra puikus pradžios taškas.