Îmi place să privesc performanța unui site cam cum privesc banii. Nu ca pe o obsesie, ci ca pe o forță care îți dă libertate sau ți-o ia. Banii au o direcție. Dacă îi lași să se împrăștie, nu te mai ajută cu nimic. Dacă îi pui la treabă, încep să lucreze pentru tine. Cu prefetching-ul e la fel, doar că „moneda” nu e dolarul sau leul, ci timpul. Niște milisecunde pe care nu le vezi, dar pe care utilizatorul le simte în degete.
Când cineva mă întreabă „Cum implementezi funcționalități de prefetching pe paginile critice SEO?”, eu aud de fapt altă întrebare, mai pragmatică: cum faci ca paginile care îți aduc vizibilitate și conversii să se miște bine, fără să îți sufoci serverul și fără să arunci trafic degeaba? Asta e miza.
Prefetching-ul nu e magie și nu e o rugăciune pentru Google. E o strategie de livrare. E un fel de a-ți pregăti terenul înainte să ajungă omul acolo, ca să nu îl lași să stea cu privirea în gol, așteptând o pagină care pare că se gândește prea mult.
Ce înseamnă prefetching, pe românește
Prefetching înseamnă să îi sugerezi browserului să aducă din timp niște resurse sau chiar documente, ca atunci când utilizatorul chiar are nevoie de ele să nu mai aștepte. Partea importantă e nuanța: nu înseamnă „încarcă tot, acum”. Prefetching-ul bun se face cu măsură.
Imaginează-ți că ai un magazin. Nu vrei rafturi goale, dar nici nu vrei să îți blochezi toți banii în stoc care nu se vinde. Exact așa e și aici. Dacă prefetch-uiești prea puțin, pierzi oportunități. Dacă prefetch-uiești prea mult, consumi bandă, CPU, cache, baterie, și începi să plătești pentru ceva ce nu folosește nimeni.
În termeni de performanță, prefetching-ul mută o parte din costul încărcării din momentul critic, cel în care utilizatorul apasă pe un link și se așteaptă să se întâmple ceva imediat, într-un moment mai relaxat, când pagina curentă este deja utilizabilă. Asta ajută mai ales la navigări între pagini, în fluxuri tipice.
Pentru SEO, partea interesantă e indirectă. Motoarele de căutare nu îți dau „puncte” fiindcă ai pus un tag de prefetch în HTML. Totuși, dacă site-ul se simte rapid și stabil, dacă oamenii nu pleacă nervoși, dacă revin și navighează mai departe, semnalele astea, în timp, se simt în rezultate. Nu e o linie perfectă, nu îți promit minuni. Dar e genul de diferență pe care o vezi când concurența e strânsă și fiecare secundă pare o taxă.
Paginile critice SEO sunt activele tale
Îți propun un mic schimb de limbaj. În loc să spui „avem pagini”, încearcă să spui „avem active”. Paginile critice SEO sunt acele active care aduc trafic constant, au intenție comercială sau informațională clară, și sunt adesea prima întâlnire dintre un om și brandul tău.
În e-commerce, de obicei e vorba despre pagini de categorie și despre produse care trag volum. În servicii, paginile de ofertă, prețuri, programări. În site-uri editoriale, articolele evergreen care adună trafic ani la rând, chiar dacă tu ai uitat când le-ai scris.
Prefetching-ul are sens când îl pui pe traseul utilizatorului, nu pe orgoliul nostru tehnic. Întrebarea utilă nu e „ce pot prefetch-ui?”, ci „ce urmează, cel mai probabil, după pagina asta?”. Dacă pe o categorie oamenii merg spre produs, pregătești produsul, sau măcar resursele lui. Dacă pe un articol oamenii merg spre o pagină de servicii, pregătești acea pagină. Dacă pe homepage cei mai mulți apasă pe o secțiune anume, te uiți acolo.
Mai e un lucru, mai „de viață”. Chiar și conținutul bun își pierde din putere dacă se livrează greoi. O pagină bună care se încarcă prost e ca o carte bună tipărită pe hârtie care se rupe când o atingi. Poți să ai idei excelente și să le pierzi în două secunde de așteptare.
De asta ajung să vorbesc despre conținut și performanță în aceeași respirație, fără să mi se pară forțat. Chiar și articole seo, dacă stau pe un site greoi, își pierd o parte din efect, fiindcă utilizatorul nu mai are răbdare să ajungă la ele.
Prefetching pentru conexiuni, resurse și pagini
În practică, prefetching-ul se manifestă în câteva forme, iar ele se pot combina. Uneori pregătești doar conexiunea către un domeniu extern. Alteori pregătești un fișier critic pentru următoarea pagină. În scenariile mai curajoase, pregătești chiar pagina următoare, în fundal.
Când ai multe resurse de la terți, gen fonturi, analytics, tag manager, video embed, câștigul rapid vine din felul în care browserul își pregătește drumul. Aici apar hint-uri precum dns-prefetch și preconnect. Primul îl ajută să rezolve DNS mai devreme. Al doilea îl ajută să pregătească și handshake-ul, inclusiv TLS, ca să nu înceapă de la zero când chiar ai nevoie de resursă.
Un exemplu simplu în HTML arată așa:
<link rel="dns-prefetch" href="//fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
Nu ai „prefetch-uit” un fișier. Ai prefăcut timpul de a începe să ceri fișierul.
Preload și prefetch, aceeași familie, momente diferite
Preload e pentru acum. Prefetch e pentru după. Diferența pare mică, dar e ca diferența dintre a plăti factura azi și a pune bani deoparte pentru luna viitoare. Ambele sunt sănătoase când sunt făcute la timp.
Preload se folosește când știi că o resursă e necesară pentru randarea inițială. De exemplu, o imagine hero care intră în LCP sau un font critic pentru titlu. Dacă lași browserul să descopere resursa târziu, pierzi timp degeaba.
<link rel="preload" href="/assets/hero.webp" as="image" fetchpriority="high">
Prefetch e pentru resurse care nu sunt critice pentru pagina curentă, dar sunt probabil necesare la următoarea navigare. Un chunk de JavaScript pentru pagina de produs, un CSS pentru checkout, un fișier de date care va fi cerut imediat după click.
<link rel="prefetch" href="/assets/product-page.chunk.js" as="script">
În mod normal, prefetch se descarcă cu prioritate joasă. Asta e bine. Doar că devine o capcană dacă îl transformi într-o avalanșă. Dacă abuzezi, browserul va încerca să fie politicos, dar tot vei consuma bandă și vei umple cache-ul cu lucruri pe care utilizatorul, de fapt, nu le vede.
Prerender, pariul mare
Prerender e un pas în plus față de prefetch. Nu doar descarci resursele, ci pregătești pagina în fundal, ca și cum ar fi deja deschisă, doar că încă nu e afișată. Când utilizatorul navighează, trecerea poate fi aproape instant.
Aici trebuie să fii atent. Prerender costă. Costă în rețea, în CPU și în memorie. Pe un laptop bun, poate trece neobservat. Pe un telefon mai vechi sau pe o conexiune slabă, îl simți ca pe o greutate în plus.
Eu tratez prerender-ul ca pe un împrumut mai mare. Îl folosești doar când probabilitatea e ridicată că următorul pas chiar se va întâmpla. De exemplu, într-un flux de checkout, când omul e deja în pașii finali.
Speculation Rules API, prefetching pentru pagini întregi
Dacă vrei prefetching sau prerender pentru pagini întregi, într-un mod mai „curat” decât tot felul de scripturi improvizate, există Speculation Rules API. Este o abordare declarativă, printr-un script special în pagină.
Nu funcționează perfect peste tot, dar pe browsere bazate pe Chromium poate aduce un salt real la navigare. Îți permite să spui „aceste URL-uri sunt candidate bune pentru prefetch sau prerender”, iar browserul decide când și cum, în funcție de semnale de intenție.
Un exemplu minimal de prefetch:
<script type="speculationrules">
{
"prefetch": [
{
"source": "list",
"urls": ["/categorie/telefoane", "/categorie/laptopuri"],
"eagerness": "moderate"
}
]
}
</script>
„Moderate” e o alegere bună ca punct de pornire, fiindcă nu sare direct să descarce tot, ci se sprijină pe semnale de intenție, de gen hover sau apropierea cursorului.
Pentru prerender, arată similar:
<script type="speculationrules">
{
"prerender": [
{
"source": "list",
"urls": ["/checkout/livrare"],
"eagerness": "eager"
}
]
}
</script>
Partea practică, și foarte importantă, este că poți detecta pe server cererile făcute în context de prefetch sau prerender, în funcție de header-ele pe care le trimit unele browsere. Asta te ajută să nu declanșezi efecte secundare. Nu vrei să înregistrezi o „vizită” în analytics ca și cum omul ar fi intrat, dacă totul s-a întâmplat în fundal.
Dacă ai pagini care trimit email-uri, creează sesiuni de plată, schimbă stocuri sau fac orice logică sensibilă la acces, ai de câștigat dacă tratezi request-urile de prefetch cu o grijă specială.
Prefetching pe paginile critice SEO, fără să faci prea mult zgomot
Pe paginile critice SEO, prefetching-ul are două obiective care, în realitate, se amestecă. Vrei să accelerezi următoarea navigare probabilă și vrei să păstrezi omul într-o stare bună, fără pauze enervante.
În scenarii reale, paginile critice sunt intrări într-un traseu. Utilizatorul intră din Google pe o categorie, apoi pe un produs, apoi pe coș. Sau intră pe un articol și ajunge, după câteva minute, la o pagină de servicii. Sau intră pe homepage și se duce la prețuri. Prefetching-ul bun se pune exact pe aceste treceri.
Categorie și listări, când intenția e la vedere
La listări ai un avantaj mare: link-urile sunt în fața ta. Nu trebuie să ghicești prea mult. Un model care funcționează bine este prefetch pe semnale de intenție, cum ar fi hover sau focus.
Dacă utilizatorul pune cursorul pe un produs sau ajunge cu tastatura pe un link, atunci pregătești pagina de produs. Dacă omul nu dă click, n-ai consumat prea mult. Dacă dă click, ai câștigat timp.
Dacă nu vrei să te bazezi pe Speculation Rules, poți face o variantă simplă în JavaScript. Important este să prefetch-uiești doar link-urile interne și, ideal, doar link-urile din zona relevantă a paginii.
function prefetchUrl(url) {
const link = document.createElement('link');
link.rel = 'prefetch';
link.href = url;
link.as = 'document';
document.head.appendChild(link);
}
document.addEventListener('mouseover', (e) => {
const a = e.target.closest('a[href]');
if (!a) return;
if (a.origin !== location.origin) return;
prefetchUrl(a.href);
}, { passive: true });
Aici îți recomand să nu fii „generos”. Dacă prefetch-uiești orice link de pe pagină, ajungi să arunci resurse. Când pui o regulă simplă, de exemplu prefetch doar pentru link-urile din listarea principală, te apropii de o strategie, nu de un reflex.
Pagini de produs, când următorul pas e aproape sigur
Pe produs, pasul următor este adesea coșul, login-ul sau o pagină de livrare. Dacă fluxul e clar și ai control asupra efectelor secundare, prerender pentru pasul următor poate să fie foarte eficient.
Eu aș evita să prerender-uiesc coșul imediat ce ai intrat pe produs. E prea devreme. În schimb, după ce utilizatorul a ales o variantă, o mărime, o culoare, după ce a interacționat, acolo deja ai un semn de intenție. Asta e diferența dintre a ghici și a observa.
Articole și pagini evergreen, când oamenii „alunecă” în lectură
Pe conținut editorial, traseul e mai greu de prezis. Oamenii sar, revin, deschid în tab-uri, se pierd. Aici merge bine un prefetch discret al următorului articol atunci când utilizatorul a trecut de o porțiune consistentă din text.
Un prag de scroll, să zicem pe la 60 la sută, poate fi un semn suficient de bun. Nu e o matematică perfectă. E o decizie practică. Dacă omul a rămas până acolo, probabil vrea să continue.
Prefetch condiționat, pentru lumea reală
Utilizatorii nu sunt toți pe fibră, pe laptop, cu încărcătorul în priză. Unii sunt pe conexiuni slabe, alții au modul de economisire de date activ, unii sunt pe telefon cu bateria pe roșu. Dacă prefetch-ui agresiv, tu crezi că ai făcut un site rapid, dar omul simte că i-ai mâncat traficul și i-ai încălzit telefonul. Nu e chiar genul de impresie pe care îl vrei.
De asta, prefetching-ul merită condiționat. În JavaScript există informații despre conexiune, cu suport variabil, dar suficient pentru o decizie rezonabilă.
function canPrefetch() {
const c = navigator.connection;
if (!c) return true;
if (c.saveData) return false;
const type = c.effectiveType;
return type === '4g';
}
Nu e perfect. Dar e un filtru bun. Dacă nu ai date, nu blochezi. Dacă ai un semnal clar că utilizatorul vrea să economisească, te oprești.
Mai e o condiție care, sincer, mi se pare foarte sănătoasă: nu prefetch-ui nimic până când utilizatorul nu a făcut un gest real. Un scroll mic, un click, orice. Înainte de asta, nu știi dacă omul chiar e acolo sau doar a deschis într-un tab din spate. Prefetching-ul e o investiție, iar investiția o faci după ce ai confirmat interesul, nu înainte.
Prefetch pentru date, nu doar pentru pagini
În multe site-uri moderne, pagina nu e doar HTML. Ai un shell, apoi vin datele din API. Acolo poți câștiga enorm dacă prefetch-uiești datele înainte de navigare.
Gândește-te la o pagină de produs care, după încărcare, cere recomandări, stoc, preț, livrare estimată. Dacă utilizatorul vine din listare și tu prefetch-uiești aceste endpoint-uri în fundal, când el ajunge pe produs ai deja răspunsul în cache, sau măcar ai început cererea.
Aici trebuie să respecți caching-ul. Dacă serverul trimite răspunsuri fără cache, vei face cereri repetate. Dacă trimite cache prea agresiv pentru date sensibile, vei afișa informații vechi. E un echilibru.
Strategii precum stale-while-revalidate pot fi excelente pe pagini critice: servești repede ceva din cache, apoi reîmprospătezi în fundal. Omul vede conținut imediat, iar tu păstrezi datele relativ proaspete.
Dacă folosești un client de date, gen React Query sau Apollo, multe au funcții de prefetch gândite exact pentru scenariul ăsta. Nu e un hack, e un mod oficial de a încălzi cache-ul.
Service Worker, când vrei control și consistență
Service Worker-ul e ca un manager de depozit. Nu face produsul mai bun, dar îți organizează livrarea. Dacă vrei să controlezi cache-ul coerent, pentru utilizatori recurenți, un Service Worker bine făcut poate schimba complet senzația site-ului.
Poți precache-ui resurse statice și poți face runtime caching pentru anumite endpoint-uri. Te apropii de o strategie de cache, nu doar de prefetching, dar efectul e similar: a doua pagină vine mai repede fiindcă multe piese sunt deja la client.
Aici apare partea grea. Invalidează corect. Cache-ul e o sabie cu două tăișuri. Dacă nu schimbi versiunile cum trebuie și nu expiri resursele, vei avea utilizatori care văd un site vechi și tu vei primi bug-uri „fantomă”.
Prefetching pe server, când nu vrei să lași totul pe client
Există și abordări server-side, de exemplu header-e de tip Link care spun browserului să preîncarce anumite resurse. În unele arhitecturi, e mai curat decât să presari link-uri în HTML.
Mai există și conceptul de Early Hints, răspunsul 103 care poate trimite hint-uri înainte ca răspunsul final să fie gata. Nu e ceva pe care îl adaugi fără să te uiți la infrastructură, dar în anumite cazuri scade latența percepută.
Dacă ai un CDN, s-ar putea să ai și optimizări care seamănă cu prefetching automat. Unele „încălzesc” cache-ul, altele încearcă predicții. Aici e ușor să te îndrăgostești de promisiuni. Eu prefer să mă uit la trasee reale și la mobile, fiindcă acolo se vede adevărul.
Prefetching și SEO, ce vede Google și ce vede omul
Apare o confuzie pe care o văd des. Unii cred că dacă prefetch-uiesc, Googlebot va descoperi mai repede paginile, ca și cum ai lăsa urme pe zăpadă. Realitatea e mai simplă: motoarele de căutare descoperă paginile în principal prin link-uri în HTML și sitemap. Prefetching-ul e o optimizare pentru browserul utilizatorului, nu un mecanism de descoperire pentru crawlere.
Chiar dacă Google randărează pagini cu un motor modern, nu te baza pe ideea că va „naviga” ca un om, cu hover și intenție. Uneori execută JavaScript, alteori îl execută parțial, iar când o face, o face după reguli proprii.
Prefetching-ul contează pentru SEO pe altă ușă. Contează prin experiență, prin viteza percepută, prin faptul că omul intră și se mișcă mai departe fără fricțiune. Acolo se câștigă.
Tot aici e și o capcană practică. Prefetching-ul agresiv îți poate schimba log-urile și îți poate strica analiza traficului. Serverul vede cereri, nu intenții. Dacă nu marchezi request-urile de prefetch, vei ajunge să crezi că ai mai multe pagini vizualizate decât ai în realitate. Iar dacă faci SEO tehnic pe baza log-urilor, asta te poate duce în direcții greșite.
Prefetching și Core Web Vitals, unde se simte impactul
Prefetching-ul ajută mult la tranziții, la a doua pagină, la fluxuri. Dar dacă prima pagină se încarcă greu, dacă imaginea principală vine târziu, dacă CSS-ul blochează tot, prefetching-ul nu îți repară acea experiență.
Pe paginile critice SEO, primul contact e vital. Acolo intră în joc LCP, INP și CLS. LCP e momentul în care omul simte „ok, am ajuns”. INP e sentimentul că site-ul răspunde când îl atingi. CLS e stabilitatea, adică pagina nu sare și nu te încurcă.
Dacă ai o imagine hero mare și o pui pe lazy, ai șanse să îți sabotezi LCP-ul chiar din start. Am văzut asta de zeci de ori și mereu e aceeași poveste: intenția e bună, execuția e invers. Pentru elementele critice, mergi pe preload și dimensiuni corecte.
INP se îmbunătățește adesea când preîncarci codul care urmează să fie folosit la o interacțiune. De exemplu, un modul de filtrare sau un drawer de coș. Dacă acel chunk de JavaScript e încălzit după primul semn de intenție, primul click nu mai devine o pauză.
CLS nu e rezolvat de prefetching, dar poate fi agravat dacă aduci mai repede conținut care intră fără spațiu rezervat. Dacă prefetch-ul îți face widget-ul să apară mai repede, rezervă spațiu, fixează dimensiuni, păstrează layout-ul stabil.
Framework-uri și prefetching, adevărul din spatele „merge singur”
Framework-urile moderne îți spun, uneori pe bună dreptate, că fac prefetching automat. Dar „automat” nu înseamnă „perfect pentru cazul tău”.
În Next.js, de exemplu, link-urile pot prefetch-ui rutele când intră în viewport. În multe site-uri e minunat. Într-o categorie cu listări uriașe, însă, poți ajunge să prefetch-uiești prea multe rute fără să îți dai seama. Pe desktop poate trece, pe mobile îl simți.
În Nuxt există mecanisme similare. În aplicații React cu code splitting, poți decide tu când să preîncarci rutele. În WordPress, unele plugin-uri încearcă prefetching predictiv. Unele sunt surprinzător de ok, altele sunt prea agresive.
Eu nu tratez framework-ul ca pe un părinte atotștiutor. Îl tratez ca pe un coleg bun. Te ajută, dar tot are nevoie de direcție.
O poveste scurtă, doi „tați” ai prefetching-ului
Când mă gândesc la prefetching, îmi vine în minte o scenă simplă. Într-o parte ai un „tată” care vrea să prefetch-ui tot. El crede că așa ești rapid. Deschide conexiuni la zece domenii, descarcă pagini, pregătește tot. Pare harnic.
În cealaltă parte ai un „tată” care nu vrea să prefetch-ui nimic. El spune că browserul știe mai bine, că orice control e complicat, că e suficient să ai un server bun. Pare rațional.
Realitatea, ca de obicei, e undeva între. Prefetching-ul sănătos nu e despre a controla tot, nici despre a lăsa totul la întâmplare. E despre a înțelege ce urmează, a alege câteva pariuri cu probabilitate mare și a le face în momentul potrivit.
Și, poate cel mai important, e despre a opri pariurile când vezi că nu dau randament.
Scenarii care apar des pe paginile critice SEO
Într-un site de servicii, pagina de intrare din Google e adesea o pagină de serviciu. Omul citește, se uită la un formular, apoi ajunge la prețuri sau la contact. Acolo, un prefetch discret al paginii de prețuri, declanșat după ce omul chiar a scrollat și a stat un pic, poate face tranziția să se simtă mai fluidă. Nu e spectaculos, dar se simte.
Într-un e-commerce, paginile de categorie sunt teren de luptă. Ai filtre, sortări, multe imagini. Aici câștigi dacă pregătești inteligent pagina de produs pe care omul pare că o vrea, nu tot ce mișcă. Dacă ai un modul de „quick view”, poți încălzi exact resursele lui, astfel încât primul click să nu fie o pauză.
Într-un site editorial, paginile de articol au două momente. La început, omul vrea să citească. Mai târziu, începe să se întrebe ce urmează. Dacă îi pregătești următoarea lectură la momentul potrivit, îl ții în flow.
Prefetching-ul, ca orice activ, are nevoie de disciplină
Dacă rămâi cu o idee, aș vrea să fie asta: prefetching-ul nu e un truc, e un obicei. Ca atunci când înveți să îți pui banii să muncească pentru tine, înveți și să îți pui site-ul să muncească pentru utilizator, înainte ca el să își dea seama că are nevoie.
Nu ai nevoie să prefetch-uiești tot. Ai nevoie să prefetch-uiești ce contează, pe paginile care contează, pentru oamenii care chiar sunt acolo, acum. Restul e zgomot. Iar zgomotul, în SEO și în performanță, are prostul obicei să îți consume energie fără să îți dea nimic înapoi.
Când tratezi paginile critice ca pe niște active, când măsori efectele și când rămâi calm în fața fiecărui „tweak” nou, prefetching-ul devine un avantaj real. Un avantaj care se simte în milisecunde, dar se vede în comportamentul oamenilor. Iar comportamentul oamenilor, dacă mă întrebi pe mine, e moneda care contează cu adevărat.
