5 Mituri Privind Optimizarea Vitezei
Există multe mituri privind optimizarea vitezei site-ului. Optimizarea pentru viteză poate fi o problemă complexă, în special pentru cei care nu sunt dezvoltatori. O mulțime de ghiduri și articole simplifică excesiv, oferind sfaturi ample care nu se aplică fiecărui site web și nu ar trebui luate în seamă la valoarea lor nominală. Iată câteva sfaturi frecvent răspândite care au nevoie de câteva clarificări.
1.„Nota” de Performanță Contează
Când utilizați unul dintre instrumentele populare de testare a vitezei, cum ar fi Google PageSpeed Insights, GTMetrix, Pingdom etc., site-ul dvs. primește o notă pentru performanța sa, împreună cu câteva recomandări. Clienții consideră adesea că, deoarece au un plugin de cache, ar trebui să obțină note aproape perfecte. Nu numai că nu este cazul, dar este și o pierdere de timp pentru a urmări o notă perfectă.
Concluzia – nota de performanță a site-ului dvs. nu contează!
Singura valoare care contează este timpul real de încărcare a paginii dvs.
De ce nota ta nu contează
Motivele principale pentru a avea un site mai rapid sunt:
- Pentru a îmbunătăți SEO
- Pentru a îmbunătăți experiența utilizatorului
- Pentru a crește conversiile
În niciunul dintre aceste scenarii nu contează nota dvs.
Când Googlebot vă vizitează site-ul, nu vă cunoaște nota dată de fiecare dintre instrumentele de testare a vitezei. Vede doar cât de repede se încarcă pagina dvs.
La ce este bună o notă?
Notele și recomandările pot fi utile pentru a oferi un ghid pentru cele mai bune practici și pentru a identifica eventualele semnale roșii sau blocaje pe site-ul dvs. Dar adevărul este că o notă mai mare nu echivalează cu un timp mai rapid de încărcare a paginii. Am văzut o mulțime de site-uri cu note mari, dar viteze mici.
De exemplu, acest site are un timp de încărcare de 30 de secunde – în mod clar ceva nu este în regulă, dar nota Pingdom este: 96/100:
În plus, fiecare instrument pe care îl utilizați va evalua site-ul dvs. diferit – care este „corect”? Așa că nu vă faceți griji cu privire la urmărirea notelor, concentrați-vă doar pe timpul real de încărcare.
Uneori, sugestiile care sunt făcute ajută la îmbunătățirea timpului de încărcare, dar uneori vor fi greu de implementat pentru un beneficiu mic sau deloc.
Un exemplu clasic în acest sens este atunci când Google PageSpeed sugerează mutarea fișierelor CSS și JS în subsol. Unele fișiere JS pot fi mutate în subsol, dar altele vă vor rupe site-ul dacă le mutați. De asemenea, dacă vă încărcați site-ul fără stiluri CSS, acesta va părea rupt și va oferi o experiență de utilizator groaznică.
2.Aveți Nevoie de Toate Tipurile de Cache
Există mai multe tipuri diferite de stocare în cache disponibile și unele articole vă vor sugera că trebuie să le implementați pe toate – cache pentru pagini, cache pentru baze de date, Memcached etc.
Pe un site fără cache, atunci când un vizitator accesează o pagină de pe site-ul dvs., serverul, prin PHP, trebuie să adune și să adune din baza de date diferitele componente și conținut ale paginii și să le trimită înapoi în browser, din mers. Asta necesită destul de mult timp și efort.
În schimb, păstrarea în cache a paginii (care este ceea ce fac WP Rocket și alte plugin-uri) generează fișiere HTML statice ale conținutului dvs., care este mai rapid de oferit vizitatorilor dvs. decât ca PHP să vă genereze paginile de la zero de fiecare dată.
Deci, aceasta înseamnă că, atunci când aveți cache de pagină și un vizitator vine pe site-ul dvs., acesta nici măcar nu atinge baza de date. Deci, în multe scenarii în care aveți stocarea în cache a paginii, nu este necesar să memorați și baza de date în cache. Acest lucru este valabil pentru multe site-uri web.
Există anumite circumstanțe în care stocarea în cache a bazei de date poate fi necesară, dar este posibil să nu fie site-ul obișnuit. De exemplu, dacă aveți un site foarte dinamic în care stocarea în cache a paginii nu este realistă, stocarea în cache a bazei de date ar fi utilă. Bloggerul obișnuit nu trebuie să-și facă griji pentru asta.
Unele forme de stocare în cache sunt executate la nivel de server, astfel încât este posibil să fiți restricționat la ceea ce puteți face dacă vă aflați pe o platformă de găzduire partajată sau gestionată – veți fi la cheremul gazdei dvs. Dar stocarea în cache a paginii poate fi implementată printr-un plugin WordPress, astfel încât este ușor de implementat de către proprietarul mediu al unui site.
3.Ai Nevoie Doar de un Plugin de Cache
Un plugin de stocare în cache este un instrument neprețuit din trusa dvs. pentru a crea un site web rapid. (Puteți obține WP Rocket acum și verificați singur valoarea pe care o poate oferi site-ului dvs.!)
Dar nu ar trebui să fie singurul. Pe un site WordPress există multe straturi care pot fi optimizate. Desigur, unele sunt mai ușor de optimizat decât altele de către dvs.
Un plugin de cache (atunci când este configurat corect) va ajuta întotdeauna, dar este ultimul strat în crearea unui site rapid. Poate fi doar un adjuvant dacă site-ul dvs. este ineficient în general.
Alte straturi care trebuie luate în considerare sunt:
Web Hosting
Aceasta este fundația, așa că investiți într-o găzduire excelentă! Dacă găzduirea dvs. este slabă, sunteți puțin condamnat și va exista întotdeauna un plafon la cât de repede va rula site-ul dvs. O găzduire web bună nu trebuie să fie neapărat și costisitoare.
Tema pe care o folosești
Cea mai mare parte a codului de pe site-ul tău provine din tema ta, așa că o temă codificată ineficient te va paraliza. Aceasta este o zonă care poate fi greu de rezolvat dacă nu sunteți dezvoltator, așa că, în unele cazuri, ar putea merita să angajați un specialist în optimizarea vitezei pentru a vă modifica tema pentru performanță.
(Am testat unele dintre cele mai rapide teme WordPress gratuite: verificați-le!)
Pluginurile dvs.
Contrar credinței populare, nu contează CANTITATEA de pluginuri pe care le aveți, ci calitatea. Este nevoie doar de un plugin prost scris pentru a vă încetini sau chiar opri site-ul. Desigur, ar trebui să fiți judicios în ceea ce privește pluginurile pe care le selectați și ar trebui să le ștergeți pe cele pe care nu le utilizați.
Concluzie
Dacă puneți o rachetă pe o mașină sport și o rachetă pe un rezervor, mașina sport va merge în continuare mai repede, deoarece este raționalizată și construită pentru viteză. Același lucru este valabil și pentru site-ul dvs.
Memorarea în cache nu poate remedia codul slab, poate doar atenua efectele într-o anumită măsură. Cu cât toate celelalte componente ale site-ului dvs. sunt mai bune, cu atât site-ul dvs. va fi mai bun și mai rapid.
4.Mai Puține Solicitări HTTP = site-ul web mai rapid
Un ghid comun este că ar trebui să reduceți numărul de solicitări HTTP pe care site-ul dvs. trebuie să le facă serverului pentru a reda pagina. În mare măsură, acest lucru este adevărat și ca ghid general, reducerea numărului de solicitări este o bună practică. Dar, ca și în toate, este puțin mai nuanțat decât atât.
Acest lucru apare de obicei în ceea ce privește minificarea. Majoritatea instrumentelor de minimizare preiau toate fișierele dvs. CSS și le adună împreună într-un singur fișier mare (concatenare). Deci, dacă ați avut inițial 8 fișiere CSS pe site-ul dvs., acum aveți 1. Deci este doar o solicitare HTTP în loc de 8. Mai bine, nu?
Ei bine, poate da poate nu. Browserele moderne pot descărca mai multe fișiere simultan în paralel. Deci, asta înseamnă că ar putea fi mai eficient și mai rapid ca browserul tău să descarce mai multe fișiere mai mici simultan, apoi un fișier mare. Rezultatele vor varia de la site la site, așa că va trebui să testați acest lucru pentru dvs.
HTTP/2 a schimbat jocul aici.
Iată o ilustrare a modului în care numărul de solicitări nu este cel mai bun indicator al eficienței.
Pe site-ul de testare a început cu asta – 43 de solicitări și un timp de încărcare de 639 ms:
Adăugând pur și simplu două imagini mari neoptimizate pe pagină, adaug doar 2 solicitări http, dar timpul de încărcare se dublează din cauza dimensiunii paginii:
Deci nu vă puteți concentra doar pe un singur indicator, ci trebuie să adoptați o abordare holistică a optimizării.
5.Un CDN este o Necesitate
Acesta este un alt sfat extrem de obișnuit, care nu ar trebui luat la valoarea lui nominală.
Ideea despre CDN-uri este că, în mod ideal, doriți să difuzați active (de exemplu, imagini, fișiere CSS, fișiere JS) vizitatorului dvs. din locația cea mai apropiată de ele, pentru a reduce latența.
Latența este timpul necesar serverului pentru a trimite conținut către browserul utilizatorului. Cu cât utilizatorul este mai departe de server, cu atât este nevoie de mai mult timp pentru a livra aceste active.
Imaginați-vă că aruncați o minge de baseball unui coechipier. Cu cât este mai departe coechipierul tău, cu atât îi ia mai mult mingii pentru a ajunge la el/ea. Cu un CDN, conținutul este distribuit între servere din întreaga lume, astfel încât să poată fi difuzat din cel mai apropiat punct de utilizator și prin urmare, utilizatorul îl vede mai repede.
Deci, un CDN chiar are sens doar dacă publicul tău este distribuit la nivel internațional, altfel poate fi inutil și o cheltuială inutilă.
De asemenea, trebuie să rețineți că, deoarece un CDN este un server extern, browserul trebuie să facă o căutare DNS pentru a ajunge la acel server extern și fiecare căutare durează puțin timp (aproximativ 200 ms).
Deci, trebuie să vă asigurați că câștigul de viteză pe care îl obțineți de la CDN depășește timpul de căutare și rezoluție DNS.
Optimizarea vitezei nu este cu siguranță un proces de tipul „unică pentru toate”. Este nevoie de răbdare și uneori încercări și erori pentru a găsi cea mai bună soluție pentru site-ul dvs. Orice sfat va trebui testat în circumstanța ta specifică pentru a vedea dacă va funcționa pentru tine. Am prezentat 5 Mituri Privind Optimizarea Vitezei site-ului dvs., nici un site nu este la fel!
