Analizăm blocajele tipice și procedura de eliminare folosind exemplul unui portal cu 200.000 de vizite pe zi.
Pe o pagină mică, scriptul suplimentar este ușor de ratat. Pe un portal mare, se încarcă din nou și din nou, ocupă timp în browser și poate întârzia deschiderea meniului, căutarea sau trimiterea formularelor.
În același timp, aceeași plângere „site-ul este lent” poate însemna probleme diferite. Pentru un vizitator, un articol durează mult să apară, pentru altul, căutarea se blochează, pentru al treilea, pagina nu se deschide în orele de vârf. Cumpărarea unui server mai scump îi va ajuta doar pe unii dintre ei.
Pentru analiză folosim un portal ipotetic cu 200.000 de vizite zilnice. Exemplele tehnice provin din lucrările noastre pe alt site: schimbarea prezentării articolelor, adăugarea paginilor conexe și dezactivarea modulelor inutile. Acesta nu este un raport despre accelerarea unui portal real cu acel trafic.
Mai întâi trebuie să înțelegi unde se pierde timpul
Înainte de a remedia, am împărți verificarea în trei părți:
- Răspunsul serverului. Cât timp trece până când pagina începe să fie primită.
- Apariția conținutului principal. Când vede vizitatorul articolul, imaginea sau alt bloc principal.
- Reacția la acțiuni. Cât de repede se deschid meniurile, căutarea și formularele.
Nu este suficientă măsurarea paginii principale. Articolele pot fi rapide, iar căutarea lentă. Utilizatorii autentificați pot avea timpi diferiți de cei ai vizitatorilor neautentificați.
Numărul de vizite zilnice nu definește singur încărcarea. Contează paginile văzute, solicitările către server și distribuția lor în timp. Un portal care primește jumătate din trafic într-o oră după o știre importantă este diferit de unul cu trafic uniform.
1. Pagina încarcă imagini prea grele
Coperta unui articol poate fi afișată la câteva sute de pixeli lățime și încărcată la dimensiunea sa originală. Dacă există mai multe astfel de imagini, vizitatorul descarcă date care nu oferă o îmbunătățire vizibilă a calității pe ecranul său.
Trebuie să verificați dimensiunea fișierelor și când browserul începe să le descarce. Coperta frontală ar trebui să apară la timp, iar imaginile aflate mai jos pe pagină pot fi încărcate pe măsură ce vă apropiați de ele. Nu ar trebui să întârziați fără discernământ încărcarea imaginii principale: acest lucru poate înrăutăți timpul de apariție al conținutului principal. Mai multe detalii despre această dependență pot fi găsite în Ghid de optimizare LCP.
În istoria noastră de lucru, designul a fost mai întâi schimbat pentru un articol, apoi extins la 300 de publicații. Acesta este un exemplu de ce este important un șablon comun: o decizie luată acolo se repetă pe sute de pagini. Dar actualizarea designului în sine nu dovedește accelerare.
Costul problemei. Să presupunem că pentru fiecare din 200.000 de vizite, browserul descarcă încă 1 MB de imagini. Adică aproximativ 200 GB de transfer de date inutile pe zi sau 6 TB în 30 de zile. Calculul este condiționat: volumul real depinde de vizualizări, memoria cache a browserului și re-descărcări. Taxele de date variază în funcție de planul dvs. de găzduire sau CDN.
Ce trebuie remediat. Pregătiți dimensiunile adecvate ale imaginii, configurați alegerea versiunii pentru ecran și ordinea de încărcare. Estimarea ar trebui să includă verificarea șabloanelor și a calității imaginilor după procesare, și nu doar compresia în masă a fișierelor.
2. Browserul este ocupat cu scripturi de care pagina nu are nevoie
Articolul este deja vizibil, dar meniul se deschide cu întârziere. Căutarea nu răspunde imediat, iar derularea devine neuniformă. În acest caz, problema poate fi în codul care rulează pe dispozitivul vizitatorului.
Motivul sunt widget-urile, unitățile de anunțuri, gestionarea evenimentelor și modulele conectate pe toate paginile, indiferent de nevoie. Diagnosticarea ar trebui să arate ce cod întârzie o anumită acțiune. Pentru a evalua capacitatea de răspuns, este utilizată metrica INP, descrisă în ghid de optimizare a interacțiunii.
Într-una dintre versiunile publicate am dezactivat un modul public. Am eliminat atât afișarea blocului, cât și stilurile, scripturile și ruta sa publică de programare. Simpla ascundere prin CSS ar fi păstrat o parte din munca inutilă.
Pe portal, aceeași întrebare ar trebui pusă pentru fiecare componentă: este necesar un player video pe un articol text, widget-ul trebuie încărcat înainte de deschidere de către utilizator, este folosită deloc această bibliotecă?
Costul problemei. Vizitatorul așteaptă ca interfața să reacționeze, deși pagina a fost deja încărcată. Cu toate acestea, un server mai puternic nu va elimina codul greu din browserul său.
Ce trebuie remediat. Eliminarea componentelor neutilizate, încărcarea codului numai pe paginile necesare și amânarea lucrărilor secundare. După modificări trebuie verificate funcțiile: scriptul eliminat putea deservi și un formular sau analitica.
3. Serverul repetă calculele, al căror rezultat rămâne aproape neschimbat
Pagina portalului poate conține colecții de materiale, link-uri pe subiect, evaluări și contoare. Dacă, de fiecare dată când deschideți un articol, sistemul caută din nou publicații conexe și efectuează multe interogări în baza de date, încărcarea crește odată cu vizualizările.
Trebuie să verificați timpul de execuție a unor interogări și funcții specifice. Numărul de pluginuri instalate singur nu explică latența: o componentă poate lucra mai mult decât alte câteva combinate.
În proiectul nostru, blocul paginilor conexe a apărut în 273 de publicații și conținea 539 de linkuri. Relațiile au fost pregătite din timp, iar site-ul consulta harta gata făcută la deschiderea paginii. Nu am adăugat selecție după cuvinte-cheie la fiecare solicitare și nici o nouă dependență de JavaScript.
Pentru portal, acest lucru se aplică colecțiilor care se modifică la editarea materialului. Recomandările personalizate necesită o abordare diferită.
Costul problemei. Calculele repetate ocupă CPU și baza de date. Pe măsură ce sarcina crește, cererile pot sta în coadă și costurile de infrastructură cresc.
Ce trebuie remediat. Găsiți operațiuni costisitoare, eliminați interogările duplicate, pregătiți în avans rezultate imuabile. Costul depinde dacă este suficient să schimbați un bloc sau dacă structura de căutare și de date va trebui reproiectată.
4. Cache-ul nu este folosit acolo unde ar putea ajuta
Dacă o mie de cititori deschid același articol public, serverul nu trebuie întotdeauna să asambleze aceeași pagină de o mie de ori.
Cache-ul vă permite să reutilizați rezultatul pregătit. Dar mai întâi trebuie să verificați ce solicitări primesc de fapt o copie pregătită și care rulează aplicația de fiecare dată. Memorarea în cache și setările bazei de date sunt incluse în Recomandări de performanță WordPress.
Trebuie verificat și ce se întâmplă după publicarea unei știri sau golirea cache-ului. Răspunsul rapid al paginilor deja pregătite în cache nu arată cum va suporta sistemul accesările simultane ale unui material încă nepregătit.
Paginile personale necesită reguli separate. Un cache partajat nu ar trebui să ofere unei persoane datele altui utilizator.
Costul problemei. Serverul repetă munca pentru aceleași solicitări. O eroare în direcția opusă este, de asemenea, costisitoare: vizitatorii pot vedea materiale învechite sau o stare incorectă a paginii.
Ce trebuie remediat. Stabilirea conținutului care poate fi păstrat în cache, a duratei și a momentelor de actualizare. Se verifică accesarea fără și cu autentificare, publicarea modificărilor și funcționarea după golirea cache-ului. Instalarea unui plugin fără aceste verificări nu încheie lucrarea.
5. Serverul sau unul dintre serviciile intermediare eșuează
Uneori, o aplicație chiar nu are suficiente resurse. Dar între vizitator și site poate exista un CDN, protecție împotriva atacurilor și alte servicii. Erorile lor trebuie distinse de problemele serverului principal.
În istoricul lucrărilor noastre, solicitările către un fișier CSS au primit temporar eroarea 502 la un serviciu intermediar de protecție. Verificarea ulterioară a reușit. Acest caz nu dovedește o încetinire permanentă a site-ului, dar arată de ce trebuie verificate și serviciile intermediare.
Trebuie exclusă și încărcarea străină de funcționarea normală. În proiectul inițial am găsit fișiere malițioase, dar nu am măsurat efectul lor asupra vitezei și nu putem atribui încetinirea acestora.
Costul problemei. În timpul orelor de vârf, întârzierile cresc sau apar erori. Proprietarul poate plăti pentru resurse suplimentare, deși motivul este un serviciu extern, o sarcină de fundal sau o solicitare specifică.
Ce trebuie remediat. Corelarea erorilor cu momentele de încărcare și verificarea procesorului, memoriei, discului și cozilor. Apoi se stabilește dacă ajută configurarea, corectarea codului sau extinderea resurselor. În timpul unui incident activ, o extindere temporară poate fi justificată înainte de încheierea investigației.
Cum estimezi costul economic al unui site lent
Fără analize, este imposibil să spunem că fiecare secundă în plus valorează un anumit procent din venit. Pentru un portal de publicitate, puteți începe cu numărul de vizualizări și venitul real la o mie de vizualizări.
Exemplu ipotetic, exprimat în ruble:
- portalul primește 200.000 de vizite pe zi;
- adâncimea medie de navigare a scăzut cu 0,2 pagini;
- Venitul mediu este de 100 de ruble la o mie de vizualizări de pagină.
Diferența ar fi de 40.000 de vizualizări pe zi sau 1,2 milioane în 30 de zile. La venitul indicat, ar echivala cu 120.000 de ruble pe lună.
Este un scenariu aritmetic, nu o estimare a pierderilor proiectului nostru. Pentru a atribui vitezei scăderea numărului de pagini văzute pe vizită trebuie verificate și sursele traficului, dispozitivele, conținutul și sezonalitatea. Venitul la o mie de pagini văzute nu trebuie confundat cu tariful la o mie de afișări publicitare.
În ce ordine ar trebui să remediați problemele?
Este mai bine să începeți cu măsurători pe mai multe tipuri de pagini: pagină principală, articol, categorie, căutare și cont personal, dacă aveți unul. Dispozitivele mobile și desktop trebuie vizualizate separat. Un test de laborator ajută la găsirea cauzei, iar datele din vizitele reale arată amploarea problemei.
Ordinea ulterioară depinde de rezultat:
- Erori și indisponibilitate. În primul rând, restabiliți funcționarea și eliminați amenințările confirmate.
- Răspuns lent al serverului. Înțelegeți interogările, dependențele externe, cache-ul și limitările resurselor.
- Conținutul apare lent. Verificarea imaginilor, stilurilor și ordinii de încărcare.
- Întârzieri în acțiune. Găsiți codul care interferează cu meniurile, căutarea și formularele.
- Verificați din nou. Comparați rezultatul în condiții comparabile și asigurați-vă că funcțiile sunt păstrate.
Aceasta nu este o listă de lucrări care trebuie finalizate în întregime pe orice site. Dacă întârzierea este cauzată de o singură solicitare externă, nu are rost să începem cu procesarea tuturor imaginilor.
Ce trebuie inclus în devizul pentru optimizarea vitezei
Formularea „vom accelera site-ul” este prea vagă pentru a conveni asupra unui buget. Înainte de a începe lucrul, este util să obțineți răspunsuri la patru întrebări:
- Unde a fost detectată întârzierea și cum a fost confirmată?
- Ce modificări sunt propuse?
- Prin ce indicatori vor fi verificate rezultatele?
- Ce este inclus în preț: diagnosticare, dezvoltare, testare, implementare și rollback?
Fără aceste date nu poate fi stabilit un preț universal pentru fiecare dintre cele cinci cauze. Ajustarea imaginilor într-un șablon existent și refacerea căutării unui portal mare sunt lucrări de amploare foarte diferită.
Pentru un portal cu 200.000 de vizite zilnice, primul rezultat util al diagnosticării trebuie să precizeze paginile și operațiunile lente, contribuția lor la întârziere și ordinea remedierilor, cu o estimare pentru fiecare etapă. Astfel, lucrările pot fi plătite pe etape, cu verificarea efectului înainte de următoarea investiție.