Bendraudami su „DebugBear“ atstovu Mattu Zeunertu, jis lyg tarp kitko paminėjo dalyką, vadinamą „Tight“ režimu, apibūdindamas, kaip naršyklės gauna ir nustato išteklių prioritetus. Norėjome pritariamai linktelėti, lyg žinotume, apie ką jis kalba, bet galiausiai turėjome paklausti: Kas per velnias yra tas „Tight“ režimas?
Gavome du artefaktus, vienas iš jų – šis vaizdo įrašas, kuriame „Akamai“ interneto našumo ekspertas Robinas Marxas kalba „We Love Speed“ renginyje Prancūzijoje prieš kelias savaites:
Kitas artefaktas yra „Google“ dokumentas, kurį iš pradžių 2015 m. paskelbė Patrickas Meenanas, bet kuris buvo atnaujintas palyginti neseniai, 2023 m. lapkritį. Patricko tinklaraštis neaktyvus nuo 2014 m., todėl tiesiog paliksime jums nuorodą į „Google“ dokumentą peržiūrai.
Tai viskas, ką turime ir ką galime rasti internete apie šį dalyką, vadinamą „Tight“ režimu, kuris, atrodo, turi tiek daug įtakos interneto veikimui. Robinas savo pristatyme pripažino informacijos trūkumą, o jo kalboje pateiktų asmeninių tyrimų kiekis yra vertas dėmesio ir paminėjimo, nes bandoma aprašyti ir iliustruoti, kaip skirtingos naršyklės gauna skirtingus išteklius su skirtingais prioritetais. Atsižvelgiant į medžiagos trūkumą šia tema, nusprendėme pasidalinti tuo, ką pavyko suprasti iš Robino tyrimų ir Patricko atnaujinto straipsnio.
Tai pirmoji iš dviejų fazių
Faktas, kad Patricko originali publikacijos data yra 2015 m., nenuostabu, kad kalbame apie kažką, kas šiuo metu yra maždaug 10 metų senumo. 2023 m. atnaujinimas jau yra gana senas „interneto metais“, tačiau „Tight“ režimo vis dar niekur nerandame, kai bandome ieškoti.
Taigi, kaip apibrėžti „Tight“ režimą? Štai kaip tai paaiškina Patrickas:
„Chrome“ įkelia išteklius 2 fazėmis. „Tight“ režimas yra pradinė fazė ir riboja žemesnio prioriteto išteklių įkėlimą, kol<body>yra prijungtas prie dokumento (iš esmės, po to, kai įvykdyti visi blokuojantys scenarijai<head>dalyje).“
— Patrick Meenan
Gerai, taigi turime šį dviejų dalių procesą, kurį „Chrome“ naudoja ištekliams iš tinklo gauti, o pirmoji dalis sutelkta į viską, kas nėra „žemesnio prioriteto išteklius“. Turime būdų, kaip nurodyti naršyklėms, kurie ištekliai, mūsų manymu, yra žemo prioriteto, pavyzdžiui, „Fetch Priority“ API ir atidėtojo įkėlimo (angl. lazy-loading) technikos, kurios asinchroniškai įkelia išteklius, kai jie patenka į matomą sritį slenkant – visa tai Robinas aptaria savo pristatyme. Tačiau „Tight“ režimas turi savo būdą nustatyti, kuriuos išteklius įkelti pirmiausia.
„Tight“ režimas diskriminuoja išteklius, imdamas viską, kas pažymėta aukštu ir vidutiniu prioritetu. Visa kita yra apribota ir paliekama laukti, kol <body> bus tvirtai prijungtas prie dokumento, signalizuojant, kad blokuojantys scenarijai buvo įvykdyti. Būtent tada ištekliai, pažymėti žemu prioritetu, yra įleidžiami per duris antrosios įkėlimo fazės metu.
Yra didelė išlyga, bet prie jos prieisime. Svarbu pažymėti, kad…
„Chrome“ ir „Safari“ taiko „Tight“ režimą
Taip, tiek „Chrome“, tiek „Safari“ fone veikia tam tikra „Tight“ režimo forma. Paskutinis paveikslėlis iliustruoja „Chrome“ „Tight“ režimą. Dabar pažiūrėkime į „Safari“ ir palyginkime juos.
Pažiūrėkite! „Safari“ pradiniame gavime diskriminuoja aukšto prioriteto išteklius, kaip ir „Chrome“, tačiau gauname labai skirtingą įkėlimo elgseną tarp dviejų naršyklių. Atkreipkite dėmesį, kaip „Safari“, atrodo, neįtraukia pirmųjų penkių PNG paveikslėlių, pažymėtų vidutiniu prioritetu, o „Chrome“ juos leidžia. Kitaip tariant, „Safari“ verčia visus vidutinio ir žemo prioriteto išteklius laukti eilėje, kol baigsis visi aukšto prioriteto elementų įkėlimai, nors dirbame su lygiai tokiu pačiu HTML. Galima sakyti, kad „Safari“ elgesys yra logiškiausias, nes paskutiniame paveikslėlyje matote, kad „Chrome“, atrodo, neįtraukia kai kurių aukšto prioriteto išteklių iš „Tight“ režimo. Akivaizdu, kad ten vyksta kažkokie keisti dalykai, prie kurių dar prieisime.
O kur „Firefox“ visame tame? Ji nesiima jokių papildomų sugriežtinimo priemonių vertindama išteklių prioritetą puslapyje. Galėtume tai laikyti „klasikiniu“ krioklio metodu ištekliams gauti ir įkelti.
„Chrome“ ir „Safari“ skirtingai aktyvuoja „Tight“ režimą
Robinas tai labai aiškiai parodo savo kalboje. „Chrome“ ir „Safari“ abi yra „Tight“ režimo šalininkės, tačiau aktyvuoja jį skirtingomis aplinkybėmis, kurias galime apibūdinti taip:
Atkreipkite dėmesį, kad „Chrome“ žiūri tik į dokumento <head> dalį nustatydama išteklių prioritetus, ir tik kai tai susiję su „JavaScript“. Tuo tarpu „Safari“ žiūri ir į „JavaScript“, ir į CSS, ir į bet kurią vietą, kur šie dalykai gali būti dokumente – nesvarbu, ar tai <head>, ar <body> dalis. Tai padeda paaiškinti, kodėl „Chrome“ neįtraukia paveikslėlių, pažymėtų aukštu prioritetu, 2 paveiksle iš savo „Tight“ režimo įgyvendinimo – šiame kontekste jai rūpi tik „JavaScript“.
Taigi, net jei „Chrome“ dokumento <body> dalyje aptinka scenarijaus failą su fetchpriority="high", failas nelaikomas „aukšto“ prioriteto ir bus įkeltas po visų kitų elementų. Tuo tarpu „Safari“ gerbia fetchpriority bet kurioje dokumento vietoje. Tai padeda paaiškinti, kodėl 2 paveiksle „Chrome“ palieka du scenarijus, o „Safari“, atrodo, juos įkelia „Tight“ režimo metu.
Tai nereiškia, kad „Safari“ savo procese nedaro nieko keisto. Esant šiam žymėjimui:
<head>
<script src="script-1.js"></script>
<script src="script-1.js"></script>
<script src="script-3.js" defer></script>
<script src="script-4.js" defer></script>
</head>
<body>
<img src="image-1.jpg">
<img src="image-2.jpg">
<img src="image-3.jpg">
<img src="image-4.jpg">
<img src="image-5.jpg">
</body>…galima tikėtis, kad „Safari“ atidės dviejų žemo prioriteto scenarijų <head> dalyje įkėlimą, kol bus atsiųsti penki paveikslėliai <body> dalyje. Bet taip nėra. Vietoj to, „Safari“ įkelia tuos du scenarijus savo „Tight“ režimo versijos metu.
„Chrome“ ir „Safari“ išimtys
Anksčiau minėjome, kad žemo prioriteto ištekliai įkeliami antrosios įkėlimo fazės metu, po to, kai baigiasi „Tight“ režimas. Bet taip pat minėjome, kad yra didelė išlyga. Dabar apie tai ir pakalbėkime.
Pagal Patricko straipsnį, žinome, kad „Tight“ režimas yra „pradinė fazė ir riboja žemesnio prioriteto išteklių įkėlimą, kol <body> yra prijungtas prie dokumento (iš esmės, po to, kai įvykdyti visi blokuojantys scenarijai <head> dalyje).“ Bet yra antra šio apibrėžimo dalis, kurią praleidome:
„Tight“ režime žemo prioriteto ištekliai įkeliami tik tuo atveju, jei jų aptikimo metu vykdoma mažiau nei dvi užklausos.“
A-ha! Taigi, yra būdas žemo prioriteto ištekliams įsikelti „Tight“ režime. Tai įvyksta, kai aptikimo metu vykdoma mažiau nei dvi „vykdomos“ (angl. in-flight) užklausos.
Palaukite, ką išvis reiškia „vykdomos“?
Tai reiškia, kad užklausiama mažiau nei du aukšto ar vidutinio prioriteto elementai. Robinas tai demonstruoja lygindamas „Chrome“ su „Safari“ tomis pačiomis sąlygomis, kai yra tik du aukšto prioriteto scenarijai ir dešimt įprastų paveikslėlių:
<head>
<script src="script-1.js"></script>
<script src="script-1.js"></script>
</head>
<body>
<img src="image-1.jpg">
<img src="image-2.jpg">
<img src="image-3.jpg">
<img src="image-4.jpg">
<img src="image-5.jpg">
<img src="image-10.jpg">
</body>Pirmiausia pažiūrėkime, ką daro „Safari“, nes tai yra paprasčiausias metodas:
Nieko sudėtingo, tiesa? Du aukšto prioriteto scenarijai atsiunčiami pirmiausia, o iškart po jų seka 10 paveikslėlių. Dabar pažiūrėkime į „Chrome“:
Turime du aukšto prioriteto scenarijus, įkeltus pirmiausia, kaip ir tikėtasi. Bet tada „Chrome“ nusprendžia įleisti pirmuosius penkis paveikslėlius su vidutiniu prioritetu, o paskui neįtraukia paskutinių penkių paveikslėlių su žemu prioritetu. Kas. Per. Velnias.
Priežastis yra kilni: „Chrome“ nori įkelti pirmuosius penkis paveikslėlius, nes, tikėtina, Didžiausio turinio elemento atvaizdavimas (LCP) dažnai bus vienas iš tų paveikslėlių, ir „Chrome“ lažinasi, kad internetas bus greitesnis apskritai, jei ji automatiškai tvarkys dalį tos logikos. Vėlgi, tai kilnus argumentas, net jei jis nebus 100 % tikslus. Tačiau tai sujaukia vandenis ir apsunkina „Tight“ režimo supratimą, kai matome, kad vidutinio ir žemo prioriteto elementai traktuojami kaip aukšto prioriteto piliečiai.
Dar labiau viską sujaukia tai, kad „Chrome“, atrodo, priima tik iki dviejų vidutinio prioriteto išteklių šiame diskriminaciniame procese. Likę yra pažymimi žemu prioritetu.
Būtent tai turime omenyje sakydami „mažiau nei dvi vykdomos užklausos“. Jei „Chrome“ mato, kad į „Tight“ režimą patenka tik vienas ar du elementai, tada ji automatiškai suteikia prioritetą iki pirmųjų penkių nekritinių paveikslėlių kaip LCP optimizavimo pastangą.
Tiesą sakant, „Safari“ daro kažką panašaus, bet kitame kontekste. Užuot priėmusi žemo prioriteto elementus, kai yra mažiau nei dvi vykdomos užklausos, „Safari“ priima tiek vidutinio, tiek žemo prioriteto elementus „Tight“ režime ir iš bet kurios dokumento vietos, nesvarbu, ar jie yra <head> dalyje, ar ne. Išimtis yra bet koks asinchroninis ar atidėtas scenarijus, nes, kaip matėme anksčiau, jie vis tiek įkeliami iš karto.
Kaip manipuliuoti „Tight“ režimu?
Tai galėtų būti puiki tema tęsiniui, bet čia nukreipsime jus tiesiai į Robino vaizdo įrašą, nes jo asmeninis tyrimas vertas tiesioginio vartojimo. Bet štai esmė:
Turime šias aukšto lygio funkcijas, kurios gali padėti paveikti prioritetą, įskaitant išteklių užuominas (t. y., preload ir preconnect), „Fetch Priority“ API ir atidėtojo įkėlimo technikas.
Galime nurodyti fetchpriority="high" ir fetchpriority="low" elementams.
<img src="lcp-image.jpg" fetchpriority="high">
<link rel="preload" href="defer.js" as="script" fetchpriority="low">Naudojant fetchpriority="high", galime įtraukti elementus, esančius žemiau šaltinio kode, į „Tight“ režimą. Naudojant fetchpriority="low", galime pašalinti elementus, esančius aukščiau šaltinio kode, iš „Tight“ režimo.
- „Chrome“ atveju, tai veikia paveikslėliams, asinchroniniams/atidėtiems scenarijams ir scenarijams, esantiems
<body>pabaigoje. - „Safari“ atveju, tai veikia tik paveikslėliams.
Vėlgi, pažiūrėkite Robino kalbą, kad sužinotumėte visą istoriją, pradedant nuo maždaug 28:32 žymos.
Štai toks tas „Tight“... režimas
Mums nesuvokiama, kad internete sklando tiek mažai informacijos apie „Tight“ režimą. Tikėtumėmės, kad kažkas panašaus būtų gerai dokumentuota, tikrai „Chrome Developers“ ar panašioje vietoje, bet viskas, ką turime, yra lengvas „Google“ dokumentas ir išsamus pristatymas, piešiantis vaizdą, kaip dvi iš trijų pagrindinių naršyklių gauna ir nustato išteklių prioritetus. Praneškite, jei turite papildomos informacijos, kurią paskelbėte ar radote – mielai įtrauktume ją į diskusiją.
