Vă prezentăm scheduler.yield(): cel mai nou API Chrome pentru optimizarea INP

Nu există nicio îndoială că Google se ocupă de receptivitate în 2023.

Până acum, ei:

• S-a mutat Interacțiunea la Next Paint de la experimental la în așteptare;
• A anunțat că INP va înlocui First Input Delay ca noua valoare Core Web Vital pentru receptivitate în martie 2024;
• A început să semnalizeze problemele INP în Search Console și să trimită e-mailuri către site-uri web care scad pragul pentru o bună capacitate de răspuns.

Acum, echipa Chrome a anunțat că rulează în prezent o versiune de încercare de origine pentru un nou API de planificare – scheduler.yield() .

Scheduler.yield() este de așteptat să ajute dezvoltatorii să își îmbunătățească capacitatea de răspuns a site-urilor lor, oferindu-le o modalitate mai ușoară și mai bună de a reda controlul firului principal.

Citiți mai departe pentru a afla mai multe despre noul API și despre cum să îl încercați pe site-ul dvs. web.

O recapitulare rapidă asupra sarcinilor lungi și a firului principal

Dacă știți bine care sunt sarcinile lungi și firul principal, nu ezitați să omiteți această parte. Dacă nu, vă încurajăm să citiți această recapitulare rapidă, deoarece este fundamentală pentru înțelegerea scheduler.yield() și cum să-l implementați.

Tot ceea ce face browserul ca lucru este considerat o sarcină. Aceasta include randarea, analizarea HTML și CSS, rularea codului JavaScript pe care îl scrieți și alte lucruri asupra cărora este posibil să nu aveți control direct.

Firul principal este locul în care browserul face cea mai mare parte a muncii.

Din păcate, firul principal poateprocesa o singură sarcină la un moment dat .Și dacă o sarcină durează mai mult de 50 ms pentru a rula, este considerată o sarcină lungă.

Întâmpinarea unei sarcini lungi înseamnă că browserul o va rula atât timp cât este necesar pentru a o finaliza. Odată terminat, controlul este cedat înapoi firului principal, permițând browserului să proceseze următoarea sarcină din coadă.

Sarcinile lungi sunt sursa principală a răspunsului slab al paginii, deoarece întârzie capacitatea browserului de a răspunde la intrarea utilizatorului. În plus, JavaScript, cu modelul său de rulare până la finalizare, este principalul vinovat atunci când vine vorba de blocarea firului principal.

De aceea, este considerată o resursă care blochează randarea – atunci când browserul o întâlnește, trebuie să o descarce, să o analizeze și să o execute înainte de a face orice altceva.

Vestea bună este că doar pentru că codul dvs. lansează o sarcină în browser nu înseamnă că trebuie să așteptați până când acea sarcină este terminată înainte ca controlul să fie returnat la firul principal.

Puteți întrerupe sarcinile lungi cedând în mod explicit la o sarcină.

În termeni mai simpli, randamentul sarcinilor asigură că browserul nu este atât de implicat într-o sarcină încât să rateze sau să întârzie să răspundă la alte sarcini importante sau interacțiuni ale utilizatorului.

Din păcate, strategiile actuale de randament nu sunt perfecte...

De ce scheduler.yield(): Problema cu strategiile actuale de rentabilitate

A ceda firului principal nu este un concept nou. Dezvoltatorii au folosit diferite strategii de randament pentru a despărți sarcinile lungi de ceva timp:

1. setTimeout()

setTimeout() vă permite să programați o sarcină să ruleze după o întârziere specificată sau la intervale regulate. Acest lucru amână execuția callback-ului într-o sarcină separată, chiar dacă specificați un timeout de 0. Această metodă este eficientă atunci când aveți mai multe funcții care ar trebui să ruleze una după alta.

Dezavantaj: Precizia nu este garantată. Este posibil ca apelarea inversă să nu ruleze exact după întârzierea specificată din cauza altor sarcini din coadă. De asemenea, dacă procesați un set de date vast într-o buclă, sarcina ar putea deveni consumatoare de timp, mai ales cu milioane de intrări.

2. requestIdleCallback()

requestIdleCallback() vă permite să programați o sarcină pentru a rula în orice perioade de inactivitate pe care le-ar putea avea browserul. Este util pentru a efectua sarcini non-urgente fără a afecta experiența utilizatorului.

Dezavantaj: requestIdleCallback() programează sarcinile cu cea mai mică prioritate posibilă, ceea ce înseamnă că, dacă firul principal este aglomerat, sarcinile programate nu pot fi executate niciodată.

3. isInputPending()

isInputPending() poate fi executat oricând pentru a verifica dacă un utilizator încearcă să interacționeze cu un element de pe pagină. Dacă sunt, funcția returneazătrue; dacă nu, se întoarcefalse.

Imaginați-vă că aveți o serie de sarcini de executat, dar nu doriți să perturbați interacțiunile utilizatorilor. Puteți utiliza isInputPending() și funcția yieldToMain() pentru a vă asigura că introducerea utilizatorului nu este întârziată pe măsură ce interacționează cu pagina.

Dezavantaj: isInputPending() poate să nu returneze întotdeauna adevărat imediat după introducerea utilizatorului. Acest lucru se datorează faptului că este nevoie de timp pentru ca sistemul de operare să spună browserului că a avut loc interacțiunea. Aceasta înseamnă că alt cod poate să fi început deja să se execute.

Acestea sunt câteva dintre modalitățile populare de a ceda înapoi la firul principal. După cum puteți vedea, fiecare are propriile sale dezavantaje.

Dar cel mai important dezavantaj este că:

Când cedați firului principal prin amânarea codului pentru a rula într-o sarcină ulterioară, acel cod este adăugat chiar la sfârșitul cozii de sarcini.

De ce este asta o problemă?

Este un răspuns triplu:

• Șansă crescută de erori de logică: deoarece codul amânat este plasat la sfârșitul cozii de sarcini, pot exista și alte sarcini pe care browserul le execută înainte de a reveni la sarcina amânată. Acest lucru poate afecta ordinea în care funcțiile sunt executate și poate cauza erori logice sau comportament neașteptat.
  
• Întârziere în execuție : dacă există multe sarcini în coadă, ar putea dura o perioadă semnificativă de timp până când browserul ajunge și execută codul amânat.
  
• Imprevizibilitate: este greu de prezis cu exactitate când va rula sarcina amânată, deoarece depinde de numărul și natura sarcinilor deja în coadă. Această imprevizibilitate poate face ca depanarea și optimizarea performanței să fie dificile.

În rezumat, în timp ce utilizarea strategiilor actuale pentru a ceda firul principal poate ajuta la menținerea unei interfețe de utilizator receptivă, poate, de asemenea, introduce provocări în asigurarea executării la timp și ordonate a codului.

Vă prezentăm scheduler.yield()

Emoția că Chrome rulează o versiune de încercare de origine pentru scheduler.yield() este pentru că este un API de planificare care abordează toate dezavantajele celorlalte strategii de randament.

În plus, este o soluție care va permite atât dezvoltatorilor, cât și proprietarilor să obțină site-uri web receptive și scoruri INP bune, în timp ce execută fără probleme restul codului.

Deci, care este tot hype despre scheduler.yield() ?

Pentru început, scheduler.yield() este o funcție de randament dedicată. setTimeout(), de exemplu, este folosit pentru a întrerupe sarcinile lungi și a ceda firului principal, dar este mai mult un efect secundar al funcției decât o opțiune implicită.

În al doilea rând, scheduler.yield() trimite munca rămasă în partea de sus a cozii. Aceasta înseamnă că munca pe care doriți să o reluați imediat după ce ați cedat nu va trece pe un loc în spate față de sarcinile din alte surse.

Pune simplu:

scheduler.yield() vă oferă tot ce este mai bun din ambele lumi – puteți renunța pentru a îmbunătăți capacitatea de răspuns a site-ului și scorul INP și pentru a vă asigura că munca pe care ați vrut să o finalizați după ce ați renunțat nu este întârziată.

Cum să încercați noul API Scheduler

Începând cu Chrome 115, puteți testa pe cont propriu scheduler.yield.

Pentru a experimenta noul API, urmați instrucțiunile Google:

1. Dacă doriți să experimentați local cu scheduler.yield, introduceți și introduceți chrome://flags în bara de adrese a Chrome și selectați Activați din meniul drop-down din secțiunea Funcții platforme web experimentale. Acest lucru va face scheduler.yield (și orice alte caracteristici experimentale) disponibile numai în instanța dvs. de Chrome.
   
2. Dacă doriți să activați scheduler.yield pentru utilizatorii Chromium reali pe o origine accesibilă public, va trebui să vă înscrieți pentru versiunea de încercare de origine scheduler.yield. Acest lucru vă permite să experimentați în siguranță cu funcțiile propuse pentru o anumită perioadă de timp și oferă echipei Chrome informații valoroase despre modul în care aceste funcții sunt utilizate în domeniu. Pentru mai multe informații despre cum funcționează studiile de origine, citiți acest ghid.

Odată ce îl testați, puteți oferi și feedback despre cum poate fi îmbunătățit.

Testare sigură!

Cum poate ajuta NitroPack la deblocarea firului principal

Împărțirea sarcinilor lungi în bucăți mai mici este esențială pentru a oferi utilizatorilor o experiență rapidă.

Dar nu ar fi mai bine dacă ai putea optimiza preventiv o parte din JavaScript-ul greu?

Aici intervine NitroPack.

Cu cele peste 35 de funcții avansate de performanță web , NitroPack ajută peste 180.000 de site-uri web la nivel global să obțină o experiență excelentă de utilizator, valori vitale ale web de bază și rate de conversie.

Unul dintre cele mai semnificative avantaje ale NitroPack este modul său de a gestiona execuția JavaScript.

La instalarea NitroPack, serviciul nostru întârzie încărcarea resurselor necritice până când este detectată interacțiunea utilizatorului.

În plus, datorită mecanismului nostru proprietar de încărcare a resurselor , NitroPack poate rearanja modul în care resursele sunt alimentate în firul principal. Facem acest lucru pentru a profita de natura multi-core a procesorului modern prin descărcarea sarcinilor din firul principal.

În acest fel, putem garanta că firul dvs. principal rămâne deblocat și disponibil pentru a gestiona interacțiunile utilizatorilor.

Îmbunătățiți imediat capacitatea de răspuns a site-ului dvs. Obțineți NitroPack GRATUIT →