Cum faci site-ul tău web mai rapid: o listă practică de verificare

Ca să faci un site web mai rapid, măsoară-l întâi cu PageSpeed Insights, apoi repară cea mai mare cauză pe care o indică — de obicei imagini supradimensionate, prea mult JavaScript, fonturi grele sau scripturi terțe. Ține ca obiectiv țintele „bune” Core Web Vitals ale Google: conținutul principal vizibil în 2,5 secunde, reacții la atingere în 200 de milisecunde și aproape nicio deplasare a layout-ului. Majoritatea site-urilor ajung acolo cu câteva schimbări, nu cu o rescriere.

Măsoară înainte să schimbi ceva

A ghici înseamnă timp pierdut. Două unelte gratuite acoperă aproape pe toată lumea:

• PageSpeed Insights (pagespeed.web.dev) — lipește un URL live. Arată date de teren de la utilizatori reali de Chrome (dacă site-ul are suficient trafic) și date de laborator dintr-o încărcare simulată, plus o listă cu probleme concrete.
• Lighthouse în DevTools-ul Chrome — același test de laborator, rulat pe orice pagină pe care o poți deschide, inclusiv o previzualizare. Testează în modul mobil; pe telefoane și pe rețele mai lente apar problemele.

Numerele care contează sunt Core Web Vitals ale Google. Din septembrie 2026, documentația Google de pe web.dev dă aceste praguri „bune”, măsurate la percentila 75 a încărcărilor de pagină:

INP a înlocuit metrica mai veche First Input Delay în 2024. Dacă o unealtă mai raportează FID, este depășită.

Noteaza valorile de pornire. După fiecare reparație, testează din nou, ca să știi ce a ajutat.

Unde se duce timpul: opțiuni și compromisuri

Fiecare cauză frecventă are o remediere, iar fiecare remediere are un cost. Începe cu cele de sus — sunt cele mai ieftine și cele mai comune.

Imagini

Imaginile sunt cea mai comună problemă și cea mai ușor de reparat. O fotografie de 4.000 de pixeli afișată la 800 de pixeli obligă fiecare vizitator să descarce de cinci ori mai mult decât vede.

• Servește imaginile la dimensiunea la care sunt afișate, cu dimensiuni srcset responsive pentru telefoane și desktop.
• Folosește formate moderne (WebP sau AVIF) și o compresie rezonabilă.
• Setează width și height pe fiecare imagine, ca browserul să rezerve spațiul. Asta singur repară majoritatea deplasărilor de layout.
• Încarcă lazy imaginile de sub linia de pliere cu loading="lazy".
• Nu face lazy-load imaginii principale de sus a paginii. Ghidul Google pentru LCP este clar în privința asta: lazy-loading-ul imaginii LCP o întârzie mereu. Dă-i fetchpriority="high" în schimb.

JavaScript

Multe site-uri construite cu AI sunt aplicații de tip single-page (SPA): browserul descarcă un pachet JavaScript și abia apoi desenează pagina. Cu cât pachetul este mai mare, cu atât ecranul alb durează mai mult. Reparații, în ordinea efortului:

1. Elimină ce nu folosești. Cere o listă de dependențe și scoate bibliotecile adăugate o dată și uitate — o bibliotecă de date pentru o singură dată, un pachet întreg de pictograme pentru cinci pictograme.
2. Împarte pe rută. Încarcă codul panoului de administrare doar când cineva îl deschide, nu pe pagina de pornire.
3. Pre-randează paginile publice. O pagină de marketing livrată ca HTML real apare înainte ca vreun JavaScript să ruleze. Asta ajută și motoarele de căutare; vezi SEO pentru site-uri web construite cu AI.

INP lent înseamnă de obicei o singură sarcină lungă care blochează pagina — filtrarea unei liste uriașe la fiecare tastă sau re-randarea unui tabel întreg când se schimbă o celulă. Panoul Performance din DevTools-ul Chrome arată care.

Fonturi

Fiecare familie de font și fiecare greutate este un alt fișier. Două familii și trei sau patru greutăți sunt de obicei suficiente. Precarcă fontul folosit deasupra liniei de pliere, folosește font-display: swap ca textul să apară imediat și găzduiește fonturile singur dacă serviciul extern de fonturi este lent pentru vizitatorii tăi.

Scripturi terțe

Widgeturile de chat, analiza, hărțile de căldură, pixelii de reclame, videoclipurile încorporate și fluxurile sociale încarcă cod de pe alte servere. Fiecare pare mic; împreună sunt adesea partea cea mai lentă a paginii. Păstrează-le doar pe cele pe care chiar le folosești. Încarcă restul după ce pagina devine interactivă și înlocuiește embed-urile grele (un player YouTube, o hartă) cu o previzualizare ușoară, care încarcă lucrul real la click.

Răspunsul serverului

Time to first byte (TTFB) — cât durează până când serverul începe să răspundă — stă sub fiecare altă metrică. Paginile statice servite dintr-un CDN (o rețea de servere aproape de vizitatori; vezi ce este un CDN) sunt rapide aproape peste tot. Paginile construite de un server la fiecare cerere depind de acel server și de baza lui de date. Caching pentru munca repetată și indecșii de bază de date pentru interogările lente sunt reparațiile obișnuite.

Prompturi care funcționează

Fii specific: numește pagina, metrica și constrângerea. Lipește constatările PageSpeed Insights dacă le ai.

PageSpeed Insights raportează un LCP de 4,8 s pe mobil pentru pagina de pornire, iar elementul LCP este imaginea principală. Redimensionează și convertește imaginea principală în WebP, servește dimensiuni responsive, setează width și height, dă-i fetchpriority="high" și asigură-te că nu este lazy-loaded. Fă lazy-load fiecărei imagini de sub linia de pliere. Nu schimba designul.

Auditează dependențele acestei aplicații. Listează fiecare pachet, ce îl folosește și cât adaugă aproximativ la pachetul JavaScript. Elimină cele neutilizate și împarte rutele /admin și /settings în bucăți separate care se încarcă doar când sunt vizitate.

Caseta de căutare de pe /products pare lentă. Pune un debounce pe filtrare, evită re-randarea întregii liste la fiecare tastă și paginează sau virtualizează lista dacă are mai mult de 200 de elemente.

Pas cu pas

1. Testează pagina live în PageSpeed Insights pe mobil. Notează LCP, INP și CLS și primele trei probleme listate.
2. Repară întâi imaginile: dimensiuni, formate, dimensiuni explicite, lazy loading sub linia de pliere, prioritate pentru imaginea principală.
3. Taie scripturile terțe pe care nu le folosești și amână restul.
4. Redu fonturile la ce are nevoie designul.
5. Micșorează JavaScript-ul: elimină pachetele neutilizate, împarte pe rută.
6. Pre-randează paginile publice dacă sunt încă randate pe client și LCP este încă lent.
7. Verifică serverul: caching, indecși de bază de date, găzduire statică pentru conținutul care se schimbă rar.
8. Publică din nou și retestează. Datele de teren din PageSpeed Insights se actualizează în următoarele săptămâni, pe măsură ce vin vizite reale, așa că judecă rezultatele timpurii după datele de laborator.

Greșeli frecvente

• Să testezi doar pe un laptop rapid. Vizitatorii tăi sunt pe telefoane de clasă medie și pe date mobile instabile. Testează în modul mobil.
• Să urmărești un 100 perfect. Scorul de laborator este un ghid. Odată ce Core Web Vitals sunt în zona bună, conținutul și utilizabilitatea contează mai mult decât ultimele puncte.
• Să faci lazy-load la tot, inclusiv la imaginea principală. Asta înrăutățește LCP.
• Să adaugi o bibliotecă sau un plugin de viteză peste. Eliminarea greutății bate aproape întotdeauna adăugarea de cod ca să o gestionezi.
• Să optimizezi previzualizarea, nu site-ul live. Previzualizările de dezvoltare rulează build-uri neoptimizate. Măsoară URL-ul publicat.
• Să repari viteza o singură dată. Fiecare widget, imagine și funcție nouă adaugă greutate. Retestează după schimbări mari.

Listă de verificare pentru viteză

• LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1 pe mobil
• Imagini redimensionate, comprimate, în format modern, cu width și height
• Imaginea principală nu este lazy-loaded; imaginile de sub linia de pliere sunt lazy-loaded
• Fără biblioteci JavaScript neutilizate; rutele grele sunt separate
• Două familii de fonturi sau mai puține, fontul principal precărcat
• Doar scripturile terțe pe care le folosești, încărcate târziu
• Paginile publice pre-randate sau statice, acolo unde se poate
• Retestat pe URL-ul live după publicare

Viteza și layout-ul pentru mobil merg împreună; vezi cum faci un site web responsiv pentru mobil. Pentru o trecere completă înainte de lansare, cum duci un prototip AI în producție acoperă restul.

Viteza pe Mythex

Pe Mythex faci aceste schimbări cerându-le în chat sau în editorul de cod, pe Pro. Verifică URL-ul publicat, nu Preview, pentru că Preview rulează un server de dezvoltare. Front-end-urile statice se implementează ca site-uri statice când publici (site-uri statice), ceea ce se potrivește paginilor de conținut. Aplicațiile cu server se scalează la zero: adorm când sunt inactive și se trezesc la următoarea vizită, așa că prima cerere după o perioadă liniștită este mai lentă, iar o bază de date atașată adoarme după 5 minute de inactivitate (limitele de găzduire). Dacă o pagină publică este lentă doar la prima vizită, aceasta este cauza probabilă. Păstrarea paginilor de marketing statice ajută. După modificări, publică din nou și fă un hard refresh.

Întrebări