Evoluția tacticilor Core Web Vitals folosind Cloudflare și WebpageTest

În ghidul nostru pentru tacticile Core Web Vitals folosind Cloudflare și WebpageTest, am subliniat cerințele de bază pentru utilizarea Cloudflare ca proxy invers pentru testarea modificărilor tactice HTML cu WebpageTest. Versiunea noastră a testului este simplificată din conceptul original al lui Patrick Meenan, care utilizează HTMLRewriter() pentru a selecta un element și a modifica codul.

Mergem în profunzime cu acest tutorial, dar dacă doar cauți scriptul Cloudflare Worker, îl poți găsi aici.

Prima noastră tranșă a menționat că nu va ține pasul cu schimbările de la Search Engine Land. LCP a fost codificat și am avea nevoie de el pentru a interacționa cu o pagină dinamică și cu valorile acesteia. În timp ce WebpageTest are, la momentul publicării, cea mai bine gândită diagramă în cascadă și mai multe detalii decât vă puteți imagina, nu este cea mai rapidă modalitate de a obține rezultate.

Far de la linia de comandă

Rularea programului Lighthouse CLI (Command Line Interpreter) cu --extra-headers necesare testului ne permite, de asemenea, să simulăm setările standard pentru Core Web Vitals așa cum am făcut-o cu WebpageTest. Va trebui să lucrați de la un emulator de terminal.

Cel mai simplu mod de a instala Lighthouse este cu NPM (Node Package Manager). Odată instalat, executați următoarea instrucțiune:

$ lighthouse https://sel.deckart.workers.dev \
--extra-headers "{\"x-host\":\"searchengineland.com\", \"x-bypass-transform\":\"false\"}" \
--form-factor=mobile \
--throttling.cpuSlowdownMultiplier=4 \
--only-categories=performance \
--view

Evoluția testbedului nostru

Scopul nostru este de a demonstra o evoluție de la un concept original pentru un banc de testare la un proiect potrivit pentru evenimentele și articolele noastre viitoare. Patul de testare nu ar trebui să se limiteze la rularea evaluărilor de performanță; tocmai de aici vom începe. Dar, trebuie să funcționeze destul de bine pentru o serie de situații cu site-uri web și acest lucru se poate dovedi destul de dificil. Vom furniza metode de ajutor.

De exemplu, site-urile folosesc adesea căi relative către resursele active, mai degrabă decât absolute (cu protocolul HTTP și tot). Vom furniza un bloc care să se potrivească cu acestea, astfel încât HTML va funcționa în general. După aplicarea acestui lucru, atunci când lucrurile încă nu funcționează, schimbarea referințelor neplăcute între numele de gazdă a subiectului de testare și cel al subiectului de testare face deseori șmecheria, chiar și pentru încălcările politicii CORS.

Acolo strălucește cu adevărat frumusețea HTMLRewriter() de la Cloudflare. Materialele la nivel de site sunt de obicei încărcate ca elemente copil HEAD ale paginii. Cu o potrivire flexibilă precum jQuery, chiar și cu o sintaxă similară, putem selecta elemente secundare ale HEAD atunci când este necesar. Puteți utiliza selectoare XPath și expresii regulate. Să rămânem simplu și să căutăm căi relative care încep cu „/” pentru atributele src sau href :

 return new HTMLRewriter() .on('link', { element: el => { const link_href = el.getAttribute('href'); if (link_href && link_href.startsWith('/')) { el.setAttribute('href', 'https://' + host + link_href); } } }) .on('script', { element: el => { const script_src = el.getAttribute('src'); if (script_src && script_src.startsWith('/')) { el.setAttribute('src', 'https://' + host + script_src); } } }) .on('img', { element: el => { const img_src = el.getAttribute('src'); if (img_src && img_src.startsWith('/')) { el.setAttribute('src', 'https://' + host + img_src); } } })

Profităm de puterea (și rentabilitatea) Edge Computing pentru a efectua teste foarte utile. Modificați antetul solicitării x-host pentru a încărca diferite site-uri în patul de testare și deschideți DevTools. S-ar putea să nu fie necesare transformări, dar kilometrajul dvs. va varia. Experiența front-end vă oferă o impresie.

Blocurile de comentarii precum comutatoarele vor eșua și vor necesita puțină experimentare (care poate fi tot ce aveți nevoie). De exemplu, unele referințe de active pot fi scrise fără două puncte HTTP. Ar trebui să scrieți un alt condiționat pentru a verifica căile în care href sau src începe cu „//” și apoi modificați valoarea elementului selectat în script. Încercați să nu aveți erori de consolă pe care site-ul actual nu le are.

Lighthouse vă oferă LCP

Este relativ ușor să regăsiți referințe LCP folosind Lighthouse, PageSpeed ​​Insights sau WebpageTest. Presupunând că LCP se califică pentru preîncărcare, cum ar fi atunci când nu este un <div> sau un <p> , și când nu este deja preîncărcat, furnizați scriptului nostru valoarea href prin structura URL „query param” (sau returnați HTML cu un formular) pentru a testa modificările la sincronizarea LCP a unei pagini cu preîncărcare.

Majoritatea practicienilor tehnici SEO sunt la îndemână la modificarea parametrilor de interogare a cererii pentru a procesa diferite lucruri în programele de pe partea serverului, cum ar fi rezultatele căutării Google. Folosind aceeași interfață, scriptul nostru va preîncărca LCP folosind calea pe care o aplicați în valoarea parametrului „lcp” și îl va transmite unei funcții numită addPreloadAfter() pentru interpolarea HTML pentru test.

 async function handleRequest(request) { const { searchParams } = new URL(request.url); let lcpHref = searchParams.get("lcp"); return new HTMLRewriter() .on('title', addPreloadAfter(lcpHref)) .transform(newResponse); }

Funcția addPreloadAfter() preia valoarea noastră „lcpHref” din searchParams.get() și o procesează ca „href” pentru a construi HTML.

 const addPreloadAfter = (href) => ({ element: (el) => { el.after(`<link rel="preload" href="${href}" />`, { html: true }); } });

Observați opțiunea „html: true”? Aceasta este o setare de opțiune pe care Cloudflare o cere pentru siguranță atunci când utilizați metodele API Workers cu HTMLRewriter() care scriu HTML. Veți dori să aflați capacitățile și constrângerile sale pentru codificarea propriilor teste.

KV lui Cloudflare

Dacă vrem să facem ceva la distanță interesant, avem nevoie de o modalitate de a stoca date persistente între execuțiile de script. Din fericire, Cloudflare oferă, de asemenea, un mic mecanism de stocare a datelor, numit KV, pe care îl putem lega de lucrătorii noștri pentru a stoca un câmp mic de „ value ” de date, accesibil prin „ key ” sa. Este surprinzător de ușor de înțeles și implementat. Pentru a demonstra cum să-l folosim, vom scrie un scurt număr de lovituri.

 const counter = parseInt(await KV.get('counter') || 0); if (!host || counter > 1000) { return new Response('hit limit exceeded or x-host missing', {status: 403}); } else { await KV.put("counter", counter + 1); }

Găsiți elementul de meniu de navigare KV sub Lucrători.

După ce ați creat un spațiu de nume („SEL” este folosit în exemplul de mai sus), utilizați interfața de utilizare a tabloului de bord KV pentru a crea prima cheie („ counter ” în cazul de mai sus) și alocați o value de pornire . Odată configurat, navigați înapoi la tabloul de bord Worker pentru interfața necesară pentru a lega noul nostru spațiu de nume KV cu lucrătorii Cloudflare, astfel încât aceștia să poată accesa cheile și valorile stocate asociate.

Legați spațiile de nume KV la lucrători

Alegeți lucrătorul cu care doriți să vă legați și faceți clic pe meniul Setări pentru a găsi submeniul pentru Variabile (direct sub General). Observați că puteți defini variabile de mediu, Legături de obiecte durabile (pe care le vom explora într-o ediție viitoare) și, în sfârșit, Legături KV Namespace. Faceți clic pe Editare variabile și adăugați variabila pe care doriți să o utilizați în script.

În următorul caz, puteți vedea variabila noastră „ KV ” numită redundant pe care o vom folosi în scriptul Worker asociat, cel din care am navigat. Utilizarea de către noi a „ KV ” a fost denumită în scopuri ilustrative. Selectați-l din meniul derulant, salvați-l și veți putea imediat să utilizați variable în script. Creați câte scripturi și combinații de spații de nume KV doriți.

Trucul este să vă amintiți să legați o variabilă pe care doriți să o utilizați în Worker. Este atât de flexibil încât poți să te simți liber să faci mizerie la început. Probabil că veți putea să-l organizați în ceva coeziv la o dată ulterioară, ceea ce este exact ceea ce doriți pentru a putea crea aplicații prototip sau crea microservicii pentru a fi utilizate în aplicațiile dvs.

După ce v-ați configurat serviciul KV și valorile de pornire, navigați înapoi la Worker și deschideți „Editare rapidă” încorporată. Înlocuiți ceea ce este acolo cu această idee actualizată, care include contorul de hit-uri și tot ce este scris în această postare. Faceți clic pe „Salvați și implementați” și ar trebui să aveți serviciul în funcțiune la adresa URL demo-ului pentru lucrători, disponibilă public.

De ce ne pasă

Ghidul nostru original a fost menit să vă trezească pofta de mâncare, să vă facă entuziasmat să începeți și să vă entuziasmeze pentru o învățare mai valoroasă. Pentru a furniza acest lucru, avem o platformă gratuită și o combinație de cod suficient de simplă pentru a fi înțeles de la sine, cuplată cu un proces care ar trebui să fie suficient de ușor de urmat și de a obține un rezultat al testului.

Standardizarea testării site-urilor web pentru a demonstra SEO pentru dezvoltatori nu ar trebui să necesite înțelegerea codului atunci când puteți copia și lipi scriptul în Cloudflare, urmați pașii și testați anumite tactici SEO. Testele Core Web Vitals sunt aproximativ la fel de fiabile pe cât vom obține pentru îmbunătățirea scorurilor de performanță RUM (Real User Metrics) pentru o creștere a clasamentului, având în vedere cât de dependentă este de valori.

Vrei mai mult SEO pentru dezvoltatori? Alăturați-vă nouă la antrenamentul SMX Master Class, condus de Detlef Johnson, în perioada 8-9 martie 2022.