Cele 10 concepții greșite privind performanța web

Publicat: 2023-07-07

La WP Rocket, misiunea noastră este de a educa utilizatorii despre importanța performanței web, făcându-l cât mai simplu și accesibil posibil. Este o provocare destul de mare: performanța web nu este un subiect ușor, iar optimizarea unui site web pentru a îmbunătăți performanța este și mai puțin ușor de explicat și de înțeles. În plus, găsirea de informații de încredere este dificilă – subiectul este complex și uneori subiectiv.

Acest articol evidențiază câteva concepte înșelătoare despre ceea ce contează atunci când se identifică acțiunile cheie de optimizare a performanței pentru a accelera un site web. Continuați să citiți și veți găsi o listă cu cele mai frecvente concepții greșite pe care le-am întâlnit. Vom explica de ce sunt incorecte și vom împărtăși cum abordăm provocările de performanță web cu pluginul nostru.

Care sunt cele mai comune concepții greșite privind performanța web?

Să descoperim concepțiile greșite pe care le considerăm mai relevante în ceea ce privește optimizarea performanței web.

1. Întârzie JavaScript

Optimizarea fișierelor JavaScript este una dintre cele mai dificile optimizări ale performanței web. Este, de asemenea, una dintre cele mai de impact pentru îmbunătățirea performanței și a parametrilor cheie, cum ar fi Core Web Vitals. Cu alte cuvinte, nu puteți evita optimizarea JavaScript dacă doriți un site web rapid. O modalitate eficientă este de a întârzia fișierele JS care nu trebuie să fie executate imediat. Drept urmare, pagina se va încărca mai repede, iar browserul va executa JavaScript numai atunci când este necesar de interacțiunea utilizatorului.

Concepția greșită este că toate fișierele JS ar trebui amânate. Adevărul este că acest lucru va afecta adesea experiența utilizatorului și ar putea chiar să distrugă funcționalitatea site-ului. JS critice nu ar trebui niciodată amânate, cum ar fi cele legate de resursele de deasupra paginii (de exemplu, meniul) și scripturile de urmărire (de exemplu, Google Analytics). Aceste resurse trebuie să fie disponibile la începutul încărcării paginii pentru a asigura o experiență fără probleme pentru utilizator.

Acum este ușor de înțeles de ce este crucial să știi ce fișiere JS ar trebui excluse de la amânare și cum să faci acest lucru.

De exemplu, WP Rocket vă permite să gestionați cu ușurință caracteristica de execuție Delay JS. Opțiunea facilitează întârzierea JS – o sarcină cheie de optimizare. În plus, WP Rocket vă permite să excludeți fișierele JavaScript atât manual, cât și datorită excluderii cu un singur clic lansată cu cea mai recentă versiune majoră, WP Rocket 3.13.

Întârzierea execuției JS - fila Optimizare fișier, WP Rocket
Întârzierea execuției JS – fila Optimizare fișier, WP Rocket

L-am întrebat pe Adam Silverstein, inginer de relații cu dezvoltatorii la Google , care e ideea despre întârzierea permanentă a JavaScript și impactul acestuia asupra performanței. El confirmă punctul nostru de vedere și adaugă: „În general, pentru site-urile redate pe server, cum sunt de obicei site-urile WordPress, majoritatea JavaScript poate fi amânat, cu excepția cazului în care este necesar la începutul ciclului paginii dintr-un anumit motiv. Un exemplu sunt scripturile de analiză în care doriți să capturați date cât mai curând posibil: aici, atributul asincron este mai potrivit. Un risc potențial legat de amânarea scripturilor este că, dacă alte scripturi sau script-uri inline depind de script-ul amânat (și nu sunt, de asemenea, amânate), dependența se poate rupe”.

Deci, este timpul să ne uităm la concepția greșită despre amânarea JavaScript.

2. Amână JavaScript

Aici, concepția greșită este că toate JS pot fi amânate.

Adevărul este că amânarea JavaScript este crucială atâta timp cât respectă dependențele. Cu alte cuvinte, amânarea JS fără a lua în considerare dependențe nu este recomandată.

De exemplu, un script inline care utilizează biblioteca jQuery va avea nevoie de jquery.js pentru a rula înainte de a putea fi executat fără să se blocheze. Dacă jquery.js este amânat, scriptul inline nu va găsi jQuery declarat și va solicita o eroare de consolă jQuery nu este definit, împiedicând rularea codului, întrerupând caracteristica aferentă și, eventual, întrerupând aspectul și funcționarea generală a paginii. de asemenea.

Adam Silverstein menționează o nouă propunere API de script WordPress aproape de a fi lansată. Va ajuta strategia de amânare prin definirea tacticilor de încărcare și prevenirea problemelor de dependență.

Adam explică: În abordarea propusă pentru core, gestionăm automat cazurile de amânare cu abordarea de bază a strategiei de script – inclusiv verificarea că scripturile dependente sunt, de asemenea, amânabile și gestionarea execuției întârziate a scripturilor inline care depind de un script amânat”.

Când vine vorba de amânarea JavaScript, WP Rocket are o mulțime de excluderi automate pentru a preveni conflictele. De exemplu, când Avada este activat, WP Rocket exclude automat biblioteca jQuery și scriptul extern Google Maps.

Noul Script API va permite pluginului nostru să extindă în continuare biblioteca de excluderi. Ca urmare, va fi din ce în ce mai puțin probabil ca site-ul dvs. să se rupă atunci când amânați JavaScript.

3. Reduceți CSS folosit

Pe lângă optimizarea JavaScript, reducerea CSS utilizată este una dintre cele mai eficiente modalități de a crește performanța site-ului dvs. Există două moduri de a gestiona o astfel de optimizare:

  • Introducerea fișierelor CSS, ceea ce înseamnă integrarea CSS pe aceeași pagină folosind o etichetă `style`.
  • Utilizați fișiere externe separate.

Concepția greșită este că livrarea CSS-ului utilizat în fișiere separate este întotdeauna cea mai bună modalitate de a aborda o astfel de optimizare.

Adevărul este că inlining CSS este perfect și are două avantaje importante din punct de vedere al performanței și al experienței utilizatorului:

  • Este un proces mai rapid, deoarece browserul va face doar o mică solicitare pentru a verifica prospețimea paginii. Dacă pagina nu s-a schimbat, ceea ce este în general cazul, browserul va difuza o copie în cache a paginii. Din acest motiv, CSS utilizat inline va îmbunătăți performanța: browserul nu va încărca și nu va analiza un fișier CSS, ci va procesa direct CSS-ul inline de pe pagină.
  • Integrarea întregului CSS al paginii previne probleme precum FOUC (Flash of unstyled content) și nu afectează experiența utilizatorului, așa cum ar putea face utilizarea Critical Path CSS în plus față de un fișier separat. Pentru a preveni înrăutățirea altor valori, ar trebui să fie necesară existența CSS-ului Cale critică atunci când CSS-ul utilizat este livrat folosind un fișier.

De aceea, WP Rocket integrează CSS și permite oricui să profite de o funcție avansată, cum ar fi eliminarea CSS neutilizate cu doar un clic:

Eliminați CSS neutilizat - WP Rocket
Eliminați CSS neutilizat – WP Rocket

Încă o dată, Adam Silverstein de la Google ne împărtășește punctul de vedere. L-am întrebat care este cel mai eficient mod de a livra CSS-ul folosit. El spune: „Mă aștept ca pentru dimensiuni mai mici CSS, cel puțin, integrarea va fi mai rapidă prin reducerea necesității de a încărca fișierul CSS suplimentar. „Penalizarea” pentru aceasta poate varia în funcție de condiții – de exemplu, dispozitivul și rețeaua pe care utilizatorul le folosește”.

4. Găzduiește fonturi local

Dacă rulați un site web WordPress, este posibil să știți deja că găzduirea locală a fonturilor poate fi o altă alegere bună pentru îmbunătățirea performanței. În plus, găzduirea fonturilor locale este esențială pentru a respecta regulile GDPR.

În ceea ce privește fonturile Google, este important să controlați de unde vor fi trimise fișierele, astfel încât acestea să nu depindă de Google Fonts CDN – mai ales dacă nu funcționează bine pentru o mare parte a audienței.

O concepție greșită comună este că găzduirea acestora va îmbunătăți automat timpul de încărcare a site-ului dvs.

Adevărul este că fonturile Google vor fi mai rapide doar dacă sunt afișate în aceeași zonă în care se află vizitatorul.

Dacă site-ul web folosește un CDN, fonturile Google vor fi mai rapide numai dacă acoperirea CDN-ului este mai bună decât a fonturilor Google – ceea ce depinde foarte mult de locația vizitatorului.

Am efectuat teste pentru a valida această ipoteză și am constatat că fonturile găzduite au fost cele mai puțin performante pentru vizitatorii îndepărtați în ceea ce privește Time to First Byte, o măsură cheie pentru a crește viteza site-ului dvs.

Aceste date de performanță sunt importante deoarece vor influența direct elementul LCP dacă este un text care utilizează fonturi Google.

Rezultatele testului fonturilor găzduite
Rezultatele testului fonturilor găzduite
Rezultatele testului CDN pentru fonturi Google
Rezultatele testului CDN pentru fonturi Google
Rezultatele testului Cloudflare
Rezultatele testului Cloudflare – Fonturi

Cealaltă concepție greșită despre găzduirea locală a fonturilor este că WP Rocket nu poate preîncărca fonturile Google. Acest lucru este fals: pluginul nostru poate preîncărca fonturile Google automat atunci când este activat de opțiunea Eliminare CSS neutilizat.

5. Sugestie de resurse Fetchpriority

Sugestia de prioritate a preluarii este un atribut care spune browserului prioritatea resurselor de descoperit și descărcat, astfel încât pagina să se poată încărca cât mai repede posibil. În prezent, utilizarea sa este încă limitată la puțin mai puțin de 70% dintre utilizatorii din întreaga lume.

Concepția greșită este că ar trebui să utilizați întotdeauna indicația de resursă fetchpriority. Adevărul este că un indiciu de resurse poate suna ca un lucru obligatoriu, dar nu este atât de simplu pe cât pare.

În timp ce fetchpriority hint face resursele critice disponibile la timp, poate deteriora performanța dacă resursele sunt preluate fără prioritatea potrivită. Aceasta este o sarcină foarte complexă de optimizare a performanței – și este dificil să o implementați fără a testa sau analiza paginile.

În același timp, impactul acestei sarcini asupra performanței este limitat la ceea ce poate fi automat prioritizat sau deprioritizat.

Am enumerat câteva exemple pentru a explica modul în care fetchpriority depinde de mai mulți factori.

  • Logo și imagine LCP : acest lucru este ușor - aceste elemente sunt candidați evidenti cu o prioritate ridicată de preluare.
  • Glisoare : începe să devină complicat.

    Imaginile unui glisor deasupra sau în apropierea pliului vor avea o prioritate subiectivă de preluare, în funcție de dacă cauzează o problemă.

    Dacă glisorul este aproape de pliu, dar este considerat critic pentru experiența utilizatorului, prima sa imagine ar trebui să aibă o prioritate ridicată.

    Dacă un glisor este întârziat, nu este necesar să prioritizați preluarea imaginilor sale, chiar dacă este deasupra pliului.
  • Resurse CSS, JS și terțe părți : numai dezvoltatorii lor respectivi pot evalua dacă ar trebui să fie prioritizate sau deprioritizate. Și chiar și cu intrarea lor și atunci când amestecați mai multe plugin-uri și resurse, prioritatea de preluare ar fi bazată pe cazuri.

Puteți vedea la ce ne referim când spunem că sugestiile de resurse nu sunt atât de ușoare pe cât ați putea presupune.

De aceea, WP Rocket nu include încă o astfel de caracteristică, deși fetchpriority poate afecta pozitiv viteza site-ului dvs. dacă este utilizat corect. Fiți siguri că pluginul nostru vă ajută să obțineți performanțe optime datorită altor funcții puternice și avansate.

Am întrebat, de asemenea, echipa Google care este părerea lor despre utilizarea unei priorități ridicate de preluare pentru toate imaginile de deasupra pliului și a uneia scăzute pentru toate imaginile de sub pliază.

Adam Silverstein explică: „În general, scopul ar trebui să fie de a adăuga fetchpriority=high doar imaginilor critice, deoarece adăugarea acesteia la mai multe imagini va anula, în general, beneficiile. De obicei, doriți ca imaginea LCP să fie setată cu acest atribut, dar gândiți-vă bine înainte de a o folosi pe multe alte resurse. Această pagină este cea mai bună resursă pentru înțelegerea priorității de încărcare. În general, toate imaginile încep cu o prioritate scăzută. Imaginile din fereastra de vizualizare încep cu prioritate „jos” și apoi la momentul aspectului, pe măsură ce browserul își dă seama că se află în fereastra de vizualizare, sunt mărite la „înaltă”. Etichetându-l în marcaj folosind fetchpriority="high", pot începe imediat la „high” și se pot încărca mult mai repede. Dacă etichetați prea multe imagini ca prioritate ridicată, acestea vor concura pentru aceleași resurse. O posibilă excepție ar fi încercarea de a eticheta imaginea LCP atât pentru punctele de întrerupere desktop, cât și pentru dispozitive mobile (care ar putea fi o imagine diferită). Caracteristica „experimente” WebPageTest este o modalitate excelentă de a testa acest lucru”.

Vorbind despre fetchpriority, este interesant de subliniat faptul că Core Performance Team a propus să adauge atributul fetchpriority=”high” imaginilor LCP din core WordPress pentru a îmbunătăți performanța LCP.

Alertă spoiler : am lucrat la o modalitate automată de a adăuga prioritatea de preluare pe elementul LCP, făcând ca utilizatorii noștri să beneficieze cât mai ușor de această opțiune. Puteți vedea despre ce vorbim într-una dintre următoarele lansări.

6. Lazy Load imagini de fundal

Încărcarea leneră este o altă tehnică importantă de optimizare a performanței web. Permite browserului să încarce imagini doar atunci când este necesar, astfel încât nu toate imaginile să fie încărcate simultan, iar pagina să poată fi redată și afișată rapid.

De aceea, încărcarea leneșă a imaginilor de fundal poate scuti solicitările de imagini inutile sub pliază, îmbunătățind astfel performanța.

Concepția greșită este că imaginile de fundal adăugate pe fișierele CSS interne (eticheta `style`) și CSS pot fi încărcate leneș. Adevărul este că WordPress, bibliotecile lazyload și native lazyload nu permit această optimizare – care trebuie să fie precisă și nu este atât de simplă pe cât ar părea.

La WP Rocket, am lucrat la o caracteristică specifică pentru a face această optimizare ușoară și automatizată, în același timp cu precizie.

7. Imagini LCP vs. Imagini de deasupra paginii

Vorbind de încărcare leneșă și de atributul de prioritate de preluare, o altă concepție greșită este că tot ceea ce este deasupra foldului ar trebui să fie setat la o valoare ridicată (fetchpriority=high).

Adam Silverstein explică: „Optimizările Fetchpriority ar trebui, în mod ideal, să fie aplicate numai imaginii LCP. În același timp, toate imaginile de mai sus ar trebui să evite încărcarea leneșă”.

Și adaugă un exemplu: „Să presupunem că există șase imagini deasupra pliului și o imagine LCP. Apoi, cea mai bună abordare ar fi să omiteți încărcarea leneșă din toate imaginile și să aplicați fetchpriority imaginii LCP”.

8. Excludeți imaginile de deasupra plierii din încărcare leneră

Dacă sunteți familiarizat cu cele mai bune practici de optimizare a performanței web, este posibil să știți că excluderea imaginilor de deasupra paginii de la încărcarea leneră este o modalitate bună de a accelera performanța site-ului dvs.

Aceasta este parțial o concepție greșită, deoarece depinde în principal de modul în care instrumentele actuale o gestionează.

Deși excluderea imaginilor de mai sus poate crește viteza site-ului dvs., poate duce la omiterea imaginilor suplimentare din încărcarea leneșă dacă nu este implementată pentru imaginile incluse în prezent deasupra plierii. Ca rezultat, pagina se va încărca mai lent în loc de invers.

În plus, numărul de imagini de exclus va diferi de obicei de la o fereastră de vizualizare la alta, ceea ce face optimizarea performanței mai dificil de gestionat.

O astfel de optimizare necesită auditare pentru a găsi imagini precise pentru a omite de la încărcare leneșă.

Soluțiile actuale nu sunt automatizate și se bazează mai degrabă pe o „ghicire”, decât pe excluderea imaginilor reale. De aceea, am dezvoltat cea mai simplă soluție posibilă pentru a permite oricui să se ocupe de această optimizare a performanței.

Am făcut câteva teste și am obținut rezultate interesante. Când este implementat corect și excluzând numărul exact de imagini de deasupra pliurilor de la încărcare leneră, poate îmbunătăți valori precum First Contentful Paint, Greatest Contentful Paint și Speed ​​Index. În plus, poate aborda auditurile PageSpeed ​​Insights, cum ar fi Evitarea încărcărilor utile enorme de rețea și Menținerea numărului de solicitări scăzut și dimensiunile de transfer mici.

Între timp, WP Rocket vă permite să o abordați cu un plugin de ajutor.

9. Imagine de previzualizare Iframe YouTube

S-ar putea să ai dreptate dacă crezi că activarea imaginii de previzualizare iframe YouTube va crește viteza site-ului tău. Această soluție evită încărcarea scripturilor YouTube și începe încărcarea videoclipului numai dacă utilizatorul face clic pe butonul de redare.

Cu toate acestea, în acest moment al articolului, ar trebui să fii familiarizat cu conceptul de: depinde.

Implementarea imaginii de previzualizare iframe YouTube pentru a optimiza performanța nu va funcționa pentru toate site-urile web. Ar putea cauza probleme dacă elementul părinte care deține videoclipul stilează imaginile într-un mod inutilizabil. Dacă da, imaginea de previzualizare nu va fi afișată corect și ar putea avea nevoie de ceva CSS suplimentar pentru a anula stilul conflictual al elementului părinte.

Iframe-ul se va încărca probabil în același mod, deoarece va fi reinjectat odată ce se face clic pe imaginea de previzualizare.

Am efectuat câteva teste și am validat presupunerea că auto-găzduirea imaginii de previzualizare YouTube nu dă întotdeauna rezultate mai bune. Datele de performanță mai bune se aplică numai publicului local sau dacă este utilizat un CDN.

Testele noastre arată că CDN-ul YouTube încă are cele mai bune performanțe și are cel mai scăzut TTFB, influențând cât de repede este preluată imaginea.

Luarea în considerare a acestui rezultat este esențială deoarece astfel de date de performanță influențează elementul LCP dacă imaginea de previzualizare face parte din acesta.

Rezultatele testului Cloudflare - CDN
Rezultatele testului Cloudflare – CDN
Rezultatele testului YouTube CDN
Rezultatele testului YouTube CDN
Rezultatele testelor auto-găzduite
Rezultatele testelor auto-găzduite

10. Utilizarea unui CDN

Ultima concepție greșită pe care vrem să o acoperim este utilizarea constantă a unui CDN pentru a îmbunătăți performanța. Deși este adevărat că un CDN vă va face site-ul mai rapid dacă publicul dvs. este la nivel mondial, nu este corect să spuneți că va ajuta întotdeauna performanța site-ului dvs.

Depinde de locația vizitatorului și de distanța dintre utilizator și bunurile solicitate.

Să vă dăm câteva exemple pentru a fi mai clar.

  • Public local : conduceți o afacere locală în Franța, iar site-ul dvs. este deja găzduit pe un server local. Folosirea unui CDN care nu are un PoP (Points of Presence) în Franța sau aproape de acesta va înrăutăți experiența utilizatorului, deoarece pagina și activele sale vor fi expediate dintr-un centru de date îndepărtat, să spunem, New York. Pe de altă parte, distanța va fi mai mică dacă utilizați doar serverul de origine.
  • Regiune sau public din întreaga lume : conduceți o afacere regională în toată Europa. Alegerea unui CDN cu o prezență puternică în Europa va da rezultate mai bune decât alegerea unui CDN care are doar unul sau două PoP-uri în Europa.

Pe scurt, atunci când alegeți un CDN, trebuie să vă asigurați că acoperirea lor PoP se potrivește cu locațiile audienței.

Încheierea

Optimizarea performanței web nu este deloc ușoară – iar acest articol o demonstrează încă o dată. Sperăm că a aruncat puțină lumină asupra unor concepții greșite despre subiecte cheie, cum ar fi optimizarea JavaScript și CSS și încărcarea leneșă.

La WP Rocket, ne străduim să facem pluginul nostru de performanță cel mai ușor, oferind în același timp cele mai avansate funcții pentru a crește performanța site-ului dvs. Știm despre ce vorbim și vom încerca întotdeauna să explicăm cât mai simplu posibil. Între timp, încercați WP Rocket și vedeți cât de ușor și puternic este!