Prietenii noștri de la WP Engine au lansat recent o nouă pagină de pornire frumoasă, construită cu Beaver Builder. Am distribuit un link către pagină în Grupul Facebook Beaver Builders și câțiva oameni au remarcat că timpul general de încărcare a paginii a fost destul de mare. Bunul nostru prieten și extraordinarul dezvoltator WordPress, Jon Brown, a venit în ajutor cu o explicație grozavă.

Conversația pe Facebook

Permiteți-mi să parafrazez conversația de aici foarte repede:

Concerned Beaver Builder: Am făcut un test de încărcare a paginii cu instrumentul de testare XYZ și a durat aproape 10 secunde pentru a încărca!

Jon: Viteza și performanța sunt o alegere de design și sunt esențiale pentru conversiile vânzărilor, dar asta nu înseamnă că nu este un compromis față de alte instrumente MAI valoroase.

Văd că oamenii se uită adesea la notele literelor și la timpul total de încărcare fără să înțeleagă cascada. Asta te va duce în rătăcire, dacă nu te uiți pe site-uri foarte simple...

Acele clase de instrumente de testare sunt cu adevărat brute și ignoră o mulțime de realități practice. Ei vor spune să evitați redirecționările atunci când acestea sunt pentru anunțuri, scripturi de urmărire și alte lucruri care funcționează neapărat în acest fel. Ei ignoră adesea HTTP/2 și recomandă reducerea solicitărilor și concatenarea activelor care nu ar conta și chiar ar putea dăuna... Ei nu se concentrează pe indexul de viteză și pe randarea deasupra pliului...

Încărcarea reală a paginii este <1,5s

Să săpăm mai adânc

L-am întrebat pe Jon dacă ar mai primi câteva întrebări pe tema performanței și a fost de acord cu bunăvoință. Acestea sunt întrebările mele (ale lui Robby) cu răspunsurile lui Jon.

Oh, ți-am menționat că Jon conduce un magazin de dezvoltare personalizat numit 9seeds, așa că este disponibil pentru angajare pentru a te ajuta să-ți ajustezi performanța site-ului WordPress!

1. Ai menționat „cascada”. Puteți explica puțin mai multe despre ce este cascada?

Există o mulțime de instrumente pentru a evalua performanța site-ului. Multe dintre acestea oferă un raport care include o notă de litere ușor de înțeles. Aceste note sunt totuși instrumente destul de clare și, deși este frumos când obții toate, nu este deosebit de perspicace, darămite de ajutor, atunci când nu vezi drept Ca. Singurul grad de litere pe care îl găsesc util este pentru compresia imaginii, care este o soluție ușoară, du-te să-ți rulezi imaginile printr-un optimizator.

De prea multe ori văd dezvoltatorii laici și începători orbiți de litere. Există o mulțime de factori care intră în performanța web frontend și trebuie să ne uităm la „cascada”, care este doar un grafic care arată toate solicitările HTTP, când au început, când s-au finalizat. Folosesc WebPageTest.org pentru a le genera.

„Cascada” este locul în care „vedeți” care este activul specific care durează prea mult pentru a se încărca și/sau care blochează încărcarea altor lucruri.

În cele din urmă, recunoașteți că drept As poate necesita alegeri de design (cum ar fi eliminarea glisoarelor) și eliminarea activelor terțelor părți (cum ar fi Google Analytics, HotJar etc.), care sunt mai valoroase pentru proprietarul site-ului decât obținerea unui A. Nu orice site poate fi făcut să îndreptă-te Ca fără sacrificii dureroase.

2. Ați recomandat WebPageTest ca instrument de testare preferat. De ce îl preferi și prin ce diferă de instrumente precum Pingdom, GTmetrix (și/sau Google Page Speed?)?

Personal, nu am găsit niciodată ceva mai bun și mai flexibil în a face acestea decât WebPageTest.org. Cu toate acestea, am folosit GTMetrix, Pingdom, Google Page Speed ​​și altele în trecut și sunt foarte bune. Unele dintre cele noi, cum ar fi Lighthouse, sunt foarte bune pentru aplicațiile web progresive (nu 99% dintre site-urile WordPress). Cu siguranță nu le spun oamenilor să schimbe instrumentele, să folosească instrumentul pe care îl cunoașteți și pe care îl înțelegeți. Dacă nu cunoașteți niciun instrument, WPT este un instrument gratuit excelent pentru a învăța. Doar treceți dincolo de notele de litere și începeți să înțelegeți ce cauzează acele note de litere.

3. În ceea ce privește „reducerea cererii și concatenarea activelor”, aceasta nu mai este o bună practică? De ce?

Pe vremea când majoritatea site-urilor erau HTTP, spre deosebire de HTTPS, iar serverele web utilizau toate protocolul HTTP/1.1, serverele web puteau trimite doar atât de multe active în paralel. Fiecare material (imagine, script, foaie de stil) a fost trimis separat și fiecare a avut propria sa overhead, care a încetinit lucrurile. Concatenarea a tot ceea ce era posibil a redus numărul de solicitări HTTP și a avut beneficii uriașe de performanță.

În ultimii doi ani, a existat un impuls uriaș către HTTPS peste tot, iar serverele web au început să accepte noul protocol HTTP/2. HTTP/2 are beneficii uriașe, cum ar fi pre-preluare și pre-încărcare, dar poate trimite și toate acele active mici în paralel, deci nu este nevoie să le concatenați. De fapt, poate fi mai bine să nu o faci, astfel încât fiecare activ mic să poată fi stocat în cache independent.

Este important să rețineți că acest lucru intră în joc doar dacă serverul dvs. web acceptă HTTP/2 și acest lucru este posibil numai dacă site-ul dvs. este HTTPS.

Acestea fiind spuse, toate site-urile pe care lucrăm în aceste zile sunt HTTPS și rulează pe servere capabile HTTP/2, așa că sunt în punctul în care nici nu mă mai gândesc la concatenarea activelor și cu siguranță nu-mi lipsesc!

4. Există alte „mituri” sau recomandări de performanță învechite împotriva cărora le-ați recomanda?

Cel mai important este pur și simplu că fiecare site poate fi corect, fără a face concesii dureroase, cum ar fi modificări de design sau eliminarea activelor terțelor pe care nu le controlați. Cu toate acestea, este într-adevăr OK pentru că ar trebui să începi să te uiți la ceva numit Speed ​​Index! WPT are o idee bună despre asta, dar practic ia în considerare momentul în care „deasupra pliului” este perceput ca fiind complet încărcat de către utilizator. Este vorba despre experiența utilizatorului de viteză, mai degrabă decât ca pagina să fie cu adevărat completă. Acesta a fost unul dintre lucrurile legate de noul design pentru prima pagină a WP Engine, indicele de viteză a fost minunat. Scripturile amânate erau încărcate și finalizate cu mult timp.

5. Aveți alte instrumente de performanță, sfaturi sau trucuri pe care le-ați recomanda cuiva?

Instrumente pe care am ajuns să mă bazez de-a lungul anilor:

• WebPageTest.org – Preferatul meu!
• ImageOptim – aplicație desktop pentru comprimarea fișierelor JPG/PNG
• ImageAlpha – aplicație desktop pentru comprimarea PNG-urilor (mai ales prin reducerea numărului de culori)
• CloudFlare – gratuit ca un CDN global masiv și WAF de bază. Plus caracteristici pro plătite impresionante, cum ar fi optimizarea imaginii din zbor, optimizarea rutei și multe altele.

Pluginuri:

• WP Rocket – Chiar și pe WP Engine, folosim WP Rocket, pur și simplu funcționează.
• Imagify.io – Optimizare de imagine bazată pe WordPress/Cloud.
• BeaverBuilder – Nu am fost plătit să spun asta! Suntem chemați să facem audituri de performanță pe o mulțime de site-uri și vedem adesea probleme majore de front-end și backend cu alți constructori de pagini populari pe care nu îi voi spune pe nume, dar nu cu Beaver Builder, motiv pentru care îl folosim pe propriul nostru site ca bine!

Mulțumim din nou, Jon, pentru că ți-ai acordat timp pentru a ne ghida printr-o abordare mai modernă a performanței. Am vrut să dau un ultim dop agenției lui Jon, 9seeds. Dacă sunteți în căutarea de ajutor cu orice fel de dezvoltare personalizată WordPress, spuneți-le!

Despre Jon Brown

Rătăcitor. Dezvoltator WordPress. Fotograf. Ficatul Vieții.