Auditul performanței și al Core Web Vitals

Faza P3 · Etapa A — Înțelege
Durată estimată: 4–8 ore pentru un audit reprezentativ; 2–5 zile lucrătoare pentru o investigație la nivel de șablon cu trasări inginerești. Validarea de teren pe 28 de zile are loc după remedieri și nu extinde durata estimată inițială a auditului.
Responsabil: liderul SEO tehnic deține domeniul de aplicare și acceptarea. Un inginer de performanță sau un inginer front-end senior deține diagnosticarea; proprietarii platformei, CDN-ului, analiticelor, designului și produsului contribuie acolo unde sistemele lor creează întârziere sau instabilitate.

Această fază transformă dovezile de teren ale utilizatorilor reali și testele de laborator reproductibile într-un registru de remedieri legat de URL-uri, șabloane, metrici, responsabili și teste de finalizare — nu un scor generic de viteză.

De ce această fază și de ce aici

Performanța aparține etapei A deoarece o pagină care expiră este o problemă de crawl înainte de a fi o problemă de experiență a utilizatorului. Un crawler sau un agent de regăsire are un buget finit de cereri. Dacă originea întârzie, redirecționează repetat sau returnează un răspuns incomplet, clientul poate abandona pagina înainte de a putea evalua conținutul. Titluri mai rapide, text mai bun și o schemă mai puternică nu pot ajuta un conținut care nu este regăsit în mod fiabil.

P3 consumă host-urile canonice, șabloanele indexabile intenționate, călătoriile prioritare, dovezile privind codurile de stare și constatările de infrastructură nerezolvate din auditul de bază tehnic . Această ordine previne diagnosticarea falsă. De exemplu, o „încărcare a paginii" de cinci secunde cauzată de o buclă de redirecționare nu este o sarcină de optimizare a imaginilor, iar un test rapid al unei pagini de eroare din cache nu este o promovare. P2 stabilește că URL-ul corect poate fi solicitat și selectat; P3 stabilește că acesta poate fi livrat și utilizat în limite acceptabile de timp și stabilitate.

Derularea acestei faze târziu creează reluări. O echipă de conținut poate publica într-un șablon al cărui hero este întotdeauna cel mai lent element sau poate aproba un spațiu promoțional care deplasează fiecare card de produs. Defectul se multiplică apoi pe noile pagini.

Intrări și ieșiri

Intrările fac eșantionul reprezentativ. Ieșirile formează contractul cu următoarea fază: exact ce pagini sunt disponibile în mod fiabil, ce condiții rămân slabe și ce limitări de performanță trebuie să califice măsurătorile ulterioare.

Datele de teren și datele de laborator sunt dovezi diferite

Datele de teren descriu ce au experimentat efectiv utilizatorii Chrome eligibili. Chrome User Experience Report, de obicei prescurtat CrUX, agregă măsurători din vizite reale și raportează percentila 75: valoarea la sau sub care se situează 75% dintre experiențele înregistrate. Include complexitatea dispozitivelor reale, rețelelor, locațiilor, cache-urilor, instrumentelor de consimțământ, sesiunilor și interacțiunilor. Folosește-l pentru a decide dacă utilizatorii trec de pragurile publicate și dacă o modificare livrată a îmbunătățit în cele din urmă populația.

Datele de laborator descriu o încărcare sau interacțiune controlată a unei pagini în condiții declarate. Lighthouse este un test de laborator care aplică simularea dispozitivului și rețelei, captează o trasare și explică cauzele probabile. Folosește-l pentru a reproduce o problemă, a compara două versiuni în aceeași configurație, a inspecta lanțurile de cereri și a identifica munca necesară. Un scor de laborator este o dovadă utilă, dar nu dovedește că utilizatorii reali promovează.

Cele două surse pot fi în dezacord fără ca vreuna să fie greșită. O rulare rapidă de laborator poate folosi o locație apropiată, un CDN încălzit și fără interacțiuni semnificative, în timp ce vizitatorii de teren includ telefoane mai vechi și rețele îndepărtate. Înregistrează dezacordul și investighează condițiile sale; nu face niciodată media valorilor și nu alege-o pe cea care pare mai sănătoasă.

Lista de verificare

Completează aceste verificări în ordine. Fiecare element specifică acțiunea, motivul, metoda, instrumentul și condiția de acceptare, astfel încât să poată fi atribuit și retestat.

1. Îngheață matricea URL-urilor și condițiilor reprezentative

Ce: definește URL-urile, șabloanele, profilele de dispozitive, geografiile, stările de consimțământ și stările cache de testat. De ce: un audit doar al paginii de pornire poate promova în timp ce șablonul de produs, articol sau checkout eșuează. Cum: îmbină inventarul P2 cu datele de trafic și prioritățile de business; selectează exemple tipice, grele și critice pentru conversie. Instrument: analitice, inventar crawl, registru de lansări și o foaie de test partajată. Finalizat când: fiecare șablon prioritar are un eșantion de producție aprobat de responsabil și fiecare test înregistrează ipotezele despre dispozitiv, rețea, locație, autentificare, consimțământ și cache.

2. Captează baza de teren CrUX

Ce: înregistrează valorile de teren p75 disponibile la nivel de URL și, separat, la nivel de origine. De ce: originea poate ascunde un șablon slab, în timp ce un URL individual cu trafic redus poate să nu aibă date publicabile. Cum: folosește aceeași dată de observare și fereastră de 28 de zile, etichetează explicit URL vs. origine și înregistrează valorile goale ca „date insuficiente." Instrument: AmICited Web Vitals și CrUX. Finalizat când: fiecare URL eșantionat are valori LCP, INP, CLS, FCP și TTFB sau o stare necunoscută documentată; nivelul sursei și fereastra sunt neambigue.

3. Verifică fiabilitatea răspunsului înainte de a puncta pixelii

Ce: repetă cererile și înregistrează statusul, redirecționările, Time to First Byte (TTFB), timeout-urile și răspunsurile inconsistente. TTFB este intervalul de la începutul cererii până la sosirea primului octet de răspuns. De ce: o pagină nu poate fi randată înainte ca HTML-ul său să înceapă să sosească, iar o defecțiune intermitentă este mai gravă decât o încetinire cosmetică. Cum: testează comportamentul cache rece și cald din regiunile relevante, inspectează sincronizarea serverului și corelează anomaliile cu logurile CDN și ale originii. Instrument: monitor de cereri, panoul de rețea al browserului, observabilitate CDN/origine și waterfall Lighthouse. Finalizat când: URL-urile prioritare returnează răspunsul 200 intenționat fără hopuri neașteptate sau timeout-uri și fiecare răspuns lent sau eșuat are o constatare înregistrată cu un responsabil.

4. Diagnostichează Largest Contentful Paint

Ce: identifică elementul Largest Contentful Paint (LCP) și descompune timpul său în întârziere de server, descoperirea resursei, descărcarea resursei și întârziere de randare. LCP măsoară momentul în care cel mai mare bloc de text sau imagine vizibilă termină randarea. De ce: comprimarea unei imagini face puțin atunci când browserul o descoperă târziu, iar modificările front-end nu pot șterge o așteptare lentă a originii. Cum: inspectează trasarea și waterfall-ul, compară rulările cu cache și fără cache, verifică prioritatea preload, dimensiunile responsive ale imaginilor, resursele care blochează randarea, comportamentul fonturilor și randarea client-side. Instrument: Lighthouse, instrumente de performanță ale browserului, waterfall de cereri și inspectarea imaginilor. Finalizat când: elementul LCP real și subpartea dominantă sunt numite pentru fiecare șablon eșuat, cu o măsurătoare înainte reproductibilă și o ipoteză de remediere specifică.

5. Diagnostichează Interaction to Next Paint

Ce: testează calea Interaction to Next Paint (INP) pentru acțiuni reale, cum ar fi deschiderea meniului, filtrarea, adăugarea în coș, introducerea în formulare și închiderea consimțământului. INP măsoară întârzierea de la o interacțiune a utilizatorului până când browserul afișează următoarea actualizare vizuală, folosind o interacțiune cu latență ridicată din vizită. De ce: o pagină poate părea completă, dar poate ignora utilizatorul în timp ce JavaScript ocupă firul principal. Cum: reproduce acțiunile importante, inspectează sarcinile lungi și gestionarii de evenimente, testează scripturile terțe și separă întârzierea de intrare, timpul de procesare și întârzierea de prezentare. Instrument: CrUX, trasare de performanță a browserului, profilare a interacțiunilor și un dispozitiv realist. Finalizat când: fiecare interacțiune importantă a fost executată, interacțiunea lentă și sarcina responsabilă sunt identificate pentru șabloanele eșuate, iar remedierea are un test de interacțiune reproductibil.

6. Diagnostichează Cumulative Layout Shift

Ce: localizează mișcarea neașteptată care contribuie la Cumulative Layout Shift (CLS). CLS este un scor fără unitate care reprezintă mișcarea vizuală neașteptată pe durata de viață a paginii. De ce: un banner târziu, o imagine fără dimensiuni, un font schimbat, un anunț sau o componentă hidratată pot muta linkul pe care utilizatorul urmează să îl apese și pot modifica locul unde extracția automatizată găsește conținutul. Cum: folosește regiunile de deplasare a layout-ului și un filmstrip, testează activele întârziate și stările de consimțământ și inspectează elementele fără dimensiuni rezervate. Instrument: CrUX, trasare Lighthouse, diagnosticări de randare ale browserului și captură de regresie vizuală. Finalizat când: fiecare deplasare semnificativă are un element sursă, un declanșator și o remediere de spațiu rezervat sau de randare; mișcarea așteptată cauzată imediat de o acțiune a utilizatorului este documentată separat.

7. Folosește FCP pentru a separa întârzierea ecranului gol

Ce: măsoară First Contentful Paint (FCP), timpul până când browserul randează primul text, imagine, canvas sau conținut SVG. De ce: FCP distinge un semn timpuriu de progres de o pagină care rămâne goală, chiar dacă nu dovedește că conținutul principal este gata. Cum: compară FCP cu TTFB și LCP, apoi inspectează CSS-ul blocant, fonturile, scripturile, marcajul randat pe server și comportamentul de streaming. Instrument: CrUX, Lighthouse și trasarea rețelei/performanței. Finalizat când: fiecare FCP lent este atribuit întârzierii de server, blocării randării, randării exclusiv client-side sau unei alte cauze dovedite, nu descris doar ca „pagina se simte lentă."

8. Clasifică constatările după severitate, acoperire și dependență

Ce: ordonează backlog-ul în funcție de banda de eșec, traficul și șabloanele afectate, criticitatea pentru business și dependența ascendentă. De ce: remedierea a cinci scoruri galbene poate consuma sprintul, în timp ce o singură defecțiune TTFB roșie întârzie fiecare pagină de pe origine. Cum: plasează eșecurile de fiabilitate pe primul loc, apoi metricele slabe înaintea celor care necesită îmbunătățiri; în aceeași severitate, remediază cauzele partajate de platformă și TTFB înainte de munca LCP din aval. Instrument: registru de constatări, analitice, inventar de șabloane și estimare inginerească. Finalizat când: fiecare constatare are o severitate, un număr de URL-uri afectate sau un domeniu de șablon, dovezi, responsabil, efort, dependență și prioritate explicită.

9. Validează implementarea în laborator

Ce: compară versiunea modificată cu baza înregistrată în condiții identice. De ce: datele de teren nu pot oferi feedback imediat de lansare, iar o rulare „după" nereproductibilă nu poate stabili că modificarea de cod a cauzat diferența. Cum: rulează mai multe eșantioane controlate, compară medianele în locul celei mai bune rulări unice, inspectează trasarea pentru regresii și testează interacțiunile și layout-urile critice. Instrument: Lighthouse, instrumente de performanță ale browserului, lansare în staging sau producție controlată și monitorizare a cererilor. Finalizat când: cauza intenționată este eliminată, metrica țintă depășește bugetul de laborator convenit în rulări repetate, nicio altă metrică critică nu regresează, iar dovezile sunt atașate constatării.

10. Adnotează lansarea și așteaptă confirmarea de teren

Ce: înregistrează momentul implementării, domeniul, metrica așteptată și datele de validare. De ce: CrUX este o fereastră mobilă de 28 de zile, astfel încât vizitele anterioare lansării rămân în percentila raportată și după ce remedierea este livrată. Cum: monitorizează erorile imediat, verifică mișcarea direcțională a datelor de teren pe măsură ce sosesc date noi și fă comparația finală doar când suficiente zile post-lansare reprezintă fereastra. Instrument: jurnal de implementare, AmICited Web Vitals, CrUX și monitorizare. Finalizat când: verificările tehnice imediate sunt promovate, adnotarea lansării este vizibilă și există un responsabil numit și o dată pentru confirmarea de teren; constatarea nu este marcată „verificată" doar pe baza dovezilor de laborator.

Instrumente în AmICited

Deschide https://app.amicited.com/audit/web-vitals pentru a compara domeniul tău cu concurenții monitorizați, folosind date reale ale utilizatorilor din CrUX. Auditul plasează LCP, INP, CLS, FCP și TTFB într-un singur tabel, marchează domeniul tău și face vizibile datele de teren lipsă, în loc să le transforme într-un zero înșelător. Folosește comparația pentru a răspunde la două întrebări: dacă domeniul depășește pragurile publicate și dacă un concurent care deservește același public a demonstrat un rezultat de teren semnificativ mai bun.

Funcția Performance Impact conectează performanța la nivel de pagină cu poziția de citare și probabilitatea. Tratează relația ca dovadă de prioritizare, nu ca dovadă că viteza a cauzat singură o modificare a citării. Dacă o pagină lentă citată și o pagină rapidă ne-citată diferă în autoritate, relevanță sau conținut, performanța este doar o variabilă. Semnalul util este că o pagină afectată este suficient de valoroasă pentru a fi remediată și monitorizată.

Pentru operarea produsului, urmează Cum să verifici Core Web Vitals în AmICited . Acest playbook definește domeniul auditului, deciziile și predarea; tutorialul acoperă click-urile și citirile, astfel încât duplicarea lor aici ar crea două instrucțiuni care se pot diverge.

Reguli de decizie: cum arată răul

Judecă Core Web Vitals din datele de teren la percentila 75. „Bun" înseamnă că valoarea p75 este la sau sub limita de bun. O valoare la limită aparține benzii mai bune; de exemplu, un LCP de exact 2,5 secunde este bun. Pragurile suport FCP și TTFB ghidează diagnosticarea și acceptarea, dar nu fac parte din evaluarea de promovare a celor trei metrici Core Web Vitals.

Folosește aceste reguli de prioritizare:

1. Cererile eșuate, timeout-urile și răspunsurile invalide au prioritate față de scoruri. Fiabilitatea este poarta de livrare.
2. Remediază benzile slabe înaintea benzilor care necesită îmbunătățiri. Roșu este o experiență proastă demonstrată, nu o oportunitate de lustruire.
3. Remediază TTFB înainte de LCP atunci când TTFB eșuează. LCP nu poate avea loc înainte ca răspunsul să înceapă, astfel încât întârzierea backend-ului consumă bugetul LCP înainte ca browserul să poată randa ceva.
4. Preferă cauzele partajate în locul simptomelor izolate. O singură reparație a politici de cache pe patru șabloane are prioritate față de patru ajustări separate ale imaginilor cu acoperire mai mică.
5. Folosește valoarea traficului și a călătoriei în aceeași severitate. Un INP slab la checkout sau un LCP al unui articol cu trafic ridicat are prioritate față de o arhivă cu trafic redus în aceeași bandă.
6. Nu considera o valoare CrUX goală drept bună. Este necunoscută. Folosește dovezi de laborator reproductibile și un șablon comparabil până când există volum de teren.
7. Nu promite mișcare instantanee pe teren. Validează implementarea acum, apoi permite ferestrei mobile să înlocuiască experiențele mai vechi înainte de a accepta sau respinge rezultatul de teren.

Livrabil: registrul de remedieri al performanței

Predă un registru plus dosarul său de dovezi. O foaie de calcul, un tracker de sarcini sau un tabel de proiect structurat este acceptabil dacă păstrează aceste câmpuri și permite filtrarea după șablon, severitate, responsabil și status:

ID și constatare:
URL-uri și șabloane afectate:
Călătorie prioritară și context de trafic:
Metrică și bandă de teren:
Nivel CrUX, valoare p75 și fereastră de 28 de zile:
Configurație de laborator și bază repetată:
Cauză observată și referință dovezi:
Condiție așteptată și țintă:
Modificare recomandată:
Severitate și rațiune de prioritate:
Responsabil, dependență și efort:
Dată lansare și adnotare:
Rezultat imediat de acceptare în laborator:
Dată confirmare teren și rezultat:
Status: Deschis | Planificat | Acceptat în laborator | Verificat pe teren | Risc acceptat

Atașează matricea URL-urilor, exportul CrUX, trasările de laborator, waterfall-urile, filmstrip-urile, înregistrările interacțiunilor, dovezile de deplasare a layout-ului și adnotările de lansare. Deducplica după cauză: dacă aceeași interogare a originii fără cache creează un TTFB slab pe trei șabloane, creează o constatare părinte cu trei domenii afectate, nu trei diagnostice concurente.

„Risc acceptat" necesită un aprobator numit, motiv, domeniu afectat, dată de expirare sau revizuire și condiție de monitorizare. Nu este un substitut pentru un responsabil. Predarea este completă atunci când un inginer poate reproduce eșecul și responsabilul fazei următoare poate identifica ce rezultate rămân limitate de performanță.

Ce merge prost

Tratarea Lighthouse ca verdict. Un scor de 100 într-o singură rulare de laborator nu anulează datele de teren slabe p75. Păstrează Lighthouse ca dovadă de diagnostic și CrUX ca dovadă populațională.

Testarea doar a paginii de pornire. Eșantionează fiecare șablon de mare valoare plus un exemplu greu, altfel defectele șabloanelor vor scăpa auditului.

Optimizarea imaginii LCP înainte de a verifica TTFB. Activul poate fi mic, în timp ce originea petrece două secunde generând HTML. Descompune LCP în componentele sale și remediază mai întâi timpul din amonte.

Folosirea celei mai rapide rulări unice. Încălzirea cache-ului, activitatea de fundal și variația rețelei pot crea o valoare outlier flatantă. Menține configurația fixă și compară medianele rulărilor repetate.

Declararea victoriei în ziua de după lansare. Laboratorul poate dovedi că codul și livrarea s-au schimbat imediat; fereastra de teren de 28 de zile nu poate. Adnotează lansarea și programează acceptarea pe teren.

Marcarea datelor CrUX lipsă ca zero. Fără date înseamnă că pragul de eligibilitate sau trafic nu a fost atins. Nu spune nimic despre calitatea performanței.

Urmărirea scorului compozit în locul experienței eșuate. Un scor sumar se poate îmbunătăți în timp ce o interacțiune de checkout încă se blochează sau un hero încă se deplasează. Acceptă metrici și călătorii numite, nu mișcare cosmetică a scorului.

Eliminarea funcționalității utile pentru a câștiga un test. Ștergerea consimțământului, personalizării, analiticelor sau comportamentului de accesibilitate din varianta de laborator produce un rezultat pe care utilizatorii nu îl primesc niciodată. Optimizează cerința de producție sau ia o decizie explicită de produs.

Ignorarea regresiilor în afara metricii țintă. Amânarea scripturilor poate îmbunătăți LCP, dar poate crea un INP slab la prima interacțiune; rezervarea dimensiunilor greșite poate înlocui o întârziere de încărcare cu CLS. Retestează toate cele cinci metrici și călătoria critică.

Faza următoare: accesibilitatea AI și pregătirea pentru agenți

Faza Accesibilitatea AI și pregătirea pentru agenți primește matricea reprezentativă de URL-uri, dovezile de fiabilitate a răspunsului, distribuția TTFB, constatările de performanță nerezolvate și o declarație privind ce conținut este prezent în răspunsul inițial. Responsabilul său folosește aceste dovezi pentru a distinge o defecțiune a politicii de acces de o defecțiune de livrare și pentru a reproduce condițiile reale în care un agent preia pagina.

Faza următoare poate continua atunci când URL-urile critice răspund fiabil și nicio defecțiune de performanță nerezolvată nu face dovezile de regăsire neinterpretabile. Poate continua cu o limitare scrisă atunci când o metrică care necesită îmbunătățiri afectează utilizatorii, dar nu împiedică accesul stabil. Ar trebui să facă o pauză pentru șabloanele afectate atunci când cererile expiră, returnează erori intermitente sau răspunsul principal depășește în mod regulat pragul critic convenit.

Predarea este completă atunci când următorul responsabil știe ce URL-uri reprezintă fiecare șablon, condițiile de test, defecțiunile de livrare rămase și dacă dovezile P3 explică deja o preluare lentă de către agent.

FAQ

Întrebări frecvente