Comerț electronic: percepția vitezei site-ului face diferența

Publicat: 2017-05-25

Știm cu toții că vitezele site-ului web pot face o diferență uriașă pentru rata de conversie și persistența unui site de comerț electronic.

Un studiu de caz realizat de SOASTA a susținut că îmbunătățirea vitezei de încărcare a paginii mobile a crescut rata de conversie cu peste 25%. În efortul său constant de a pune utilizatorul pe primul loc, Jeff Bezos, fondatorul și CEO-ul Amazon, este obsedat de viteza de încărcare a paginii și își determină constant angajații să reducă viteza paginii site-ului Amazon.

Creșterea dominației mobile a amplificat nevoia unei viteze mai rapide de încărcare a paginii, deoarece utilizatorii vor naviga adesea pe site-uri cu conexiuni mai lente.

Există o mulțime de instrumente care vă ajută să îmbunătățiți viteza paginilor web, cum ar fi Yslow sau Google Pagespeed Insights, și există diverse bune practici, cum ar fi minimizarea și îmbinarea css și js, utilizarea sprite-urilor CSS și minimizarea solicitărilor de rețea care un dezvoltator front end ar trebui să urmeze pentru a se asigura că viteza paginii este maximizată.

Problema pe care o avem este că, odată ce urmați cele mai bune practici standard și realizați marile câștiguri, veți începe în curând să observați o scădere a randamentelor eforturilor de îmbunătățire a vitezei generale a paginii.

Puteți petrece mult timp făcând îmbunătățiri din ce în ce mai mici, iar acesta va fi un proces costisitor și consumator de timp. Dezvoltatorii front-end cu abilitățile și experiența necesare pentru a lucra la acest nivel sunt surprinzător de puțini și de scumpi.

Există unele lucruri pe care nu le puteți controla, cum ar fi latența rețelei sau vitezele conexiunii mobile, deci există o limită a ceea ce poate fi atins cu viteza brută a paginii. Pe o conexiune 3G, între 600ms și 1s este consumată de supraîncărcările de rețea obligatorii, despre care nu puteți face nimic. Pe baza unui timp dorit de încărcare a paginii de 2 secunde, aceasta ne oferă doar 1 secundă pentru a ne juca. Nu e foarte mult.

Nu se poate nega faptul că viteza paginii brute este foarte importantă și toți dezvoltatorii ar trebui să urmeze cele mai bune practici standard.

Acest articol, totuși, nu va discuta cum să faci pagina ta să se încarce mai rapid. Există o mulțime de articole despre asta și totul este puțin tehnic.

Acest articol se va concentra pe percepția vitezei paginii.
Ce este mai important: cât de repede se încarcă pagina sau cât de repede percepe utilizatorul că se încarcă?

Cu siguranță percepția este ceea ce contează cel mai mult pentru utilizator.

Faceți clic, faceți clic, cumpărați: tendințele comerțului electronic din 2021 conduse de DTC, mobil, social

Tendințele comerțului electronic din 2021 reflectă o societate care sa schimbat pentru totdeauna. Mărcile trebuie să se concentreze pe DTC, mobil, social ca instrument de căutare și date. Tendințele comerțului electronic din 2021 reflectă o societate care sa schimbat pentru totdeauna. Mărcile trebuie să se concentreze pe DTC, mobil, social ca instrument de căutare și date.

Viteza site-ului: primele impresii

Să ne concentrăm pe pagina de pornire a site-ului dvs. Este probabil să conțină o navigare de sus, o bară de căutare, un banner erou, poate link-uri către categorii cheie, un carusel și ceva conținut. Paginile de pornire tind să fie destul de grele de conținut, iar încărcarea rapidă a întregului conținut pe o conexiune mobilă va fi o mare provocare.

Cheia aici este să prioritizați încărcarea conținutului critic mai întâi, înaintea altui conținut - oferiți utilizatorului ceva important de văzut cât de repede puteți.

În timp ce procesează aceste informații critice, puteți începe apoi să încărcați următorul nivel de conținut.

Pe un dispozitiv mobil, o mare parte din conținut va începe sub pliază și, prin urmare, ar trebui să fie încărcat după conținutul care se află deasupra pliului. Este o practică obișnuită să îmbinați și să reduceți JavaScript. Acest lucru este privit în mod normal ca cea mai bună practică, dar vă poate împiedica să acordați prioritate încărcării JavaScript critice înaintea codului mai puțin critic. În schimb, ați putea lua în considerare împărțirea JavaScript-ului dvs. comprimat și îmbinat și să îl încărcați progresiv pe măsură ce este necesar. Nu este nevoie să încărcați JavaScript-ul necesar pentru a efectua o căutare chiar înainte de a încărca caseta de căutare. Utilizatorii nu vor introduce caractere în câmpul de căutare pentru cel puțin câteva secunde la încărcarea unei pagini.

Să ne uităm la un site care face acest lucru foarte bine. Amazon a împărțit livrarea activelor și a conținutului pentru a se asigura că utilizatorului i se oferă conținut critic cât mai curând posibil și apoi încarcă progresiv activele în ordinea priorității.

Acest test a fost rulat pe un simulator iPhone 6 cu o conexiune 3G bună și cache-ul a fost dezactivat. După ce pagina a fost încărcată inițial, am inițiat o reîmprospătare.

În puțin peste 600 ms am ceva care începe să se încarce cu numele meu în antet. Veți observa, de asemenea, că au fost efectuate doar 6 apeluri în rețea și s-au încărcat 5 active (3 fișiere css și 2 imagini).

Doar 50 ms mai târziu văd acum componente cheie ale antetului, precum și bannerul eroului principal. Am deja percepția vitezei, deoarece conținutul cheie îmi este livrat foarte repede și există ceva de procesat pentru ochii și creierul meu în timp ce conținutul suplimentar este încărcat.

După doar 1 secundă, navigarea principală este încărcată. Veți observa că nu este nicio bară de defilare vizibilă în această etapă. Aceasta înseamnă că în prezent nu există conținut sub fold. Nu a fost pierdut timp prețios la încărcarea acestui conținut pe care utilizatorul nu-l poate vedea. De asemenea, veți observa că au fost făcute doar 13 solicitări până acum.

În puțin mai puțin de 2 secunde, am acum o nouă secțiune de conținut important.

În mai puțin de 3 secunde, acum percep că pagina s-a încărcat în întregime, în timp ce pagina a durat de fapt puțin mai puțin de 5 secunde pentru a se încărca în întregime. Acest lucru sugerează că percep site-ul ca fiind complet încărcat atunci când de fapt este încărcat doar 60%.

Momentul real de livrare a conținutului va varia de la o persoană la alta, dar acest lucru ilustrează foarte clar modul în care Amazon prioritizează încărcarea conținutului mobil pentru a se asigura că conținutul critic este încărcat cât mai repede posibil și că utilizatorii percep site-ul ca începând să se încarce foarte repede.

Acum să ne uităm la un site web care nu face asta atât de bine. Acest test a fost rulat folosind exact aceleași instrumente și viteză de rețea ca și testul Amazon anterior. În timp ce site-ul Charles Tyrwhitt prioritizează anumite conținuturi, sunt multe de făcut pentru a se apropia de optimizarea Amazon.

Nu văd niciun conținut timp de aproape 7,5 secunde. Imediat am percepția că acest site este lent pe dispozitivul meu mobil. Deși site-ul prioritizează conținutul antetului, precum și un banner erou, puteți vedea că au fost făcute peste 90 de solicitări până în acest moment și, după cum văd bara de defilare, este clar că conținutul trebuie să fi fost încărcat sub fold.

După 8,5 secunde văd că un carusel începe să se încarce. Numărul de solicitări nu s-a modificat, ceea ce sugerează că cea mai mare parte a solicitărilor legate de conținut sunt făcute chiar la începutul încărcării paginii.

Abia după aproape 22 de secunde am perceput că site-ul s-a încărcat complet. De fapt, pagina a durat un total de 28,4 secunde pentru a se încărca complet. Acest lucru sugerează că percep că pagina a fost complet încărcată când de fapt a fost încărcată în proporție de 77%.

Este ușor să vezi diferența clară dintre cele 2 experiențe. În timp ce pagina de pornire mobilă Amazon se încarcă semnificativ mai rapid decât pagina de pornire a lui Charles Tyrwhitt, s-au depus eforturi pentru a se asigura că utilizatorii percep că aceasta este și mai rapidă. Utilizatorul începe să vadă ceva care se încarcă în 12,5% din timpul total de încărcare a paginii, în timp ce utilizatorii site-ului web Charles Tyrwhitt văd ceva ce se întâmplă doar în 26% din timpul total de încărcare a paginii. Pagina de pornire Amazon a făcut 6 solicitări de rețea înainte ca utilizatorul să vadă progrese, în timp ce pagina de pornire a lui Charles Tyrwhitt a făcut 90 de solicitări.

Acest lucru nu este menit să fie excesiv de critic la adresa lui Charles Tyrwhitt, deoarece nu sunt, în niciun caz, unici în modul în care și-au construit site-ul. Cele mai bune practici acceptate au fost urmate în mai multe domenii, dar se pare că s-ar putea face mult mai mult pentru a îmbunătăți percepția vitezei, precum și a vitezei reale.

Exemple de M-commerce: 3 mărci care îl zdrobesc absolut

m-commerce.jpg Comerțul mobil sau m-commerce crește rapid, pe măsură ce mai mulți cumpărători fac cumpărături, plătesc și fac activități bancare pe micile lor ecrane, cu așteptări pentru aceleași experiențe perfecte la care au ajuns să se aștepte atunci când cumpără de pe laptopurile și desktopurile lor.

Îmbunătățiți viteza site-ului prin prioritizarea CSS

Este destul de obișnuit ca dezvoltatorii front-end să plaseze majoritatea css-ului unui site web într-o mână de fișiere și să folosească întotdeauna css extern, mai degrabă decât inline. Problema pe care o cauzează este că un fișier CSS mare trebuie să fie încărcat înainte ca orice conținut să poată fi afișat unui utilizator.

O soluție la aceasta este să împărțiți fișierele CSS și să le încărcați în ordine cu conținutul critic. Dacă ne uităm la exemplul Amazon, ei încarcă un fișier css care are o dimensiune de doar 6,5k ca una dintre cele 6 solicitări inițiale. Acest fișier conține CSS care este necesar pentru a stila conținutul critic de pe pagina lor de pornire. De fapt, dimensiunea totală a tuturor fișierelor CSS care sunt solicitate înainte ca utilizatorul să vadă conținutul pe pagina de pornire mobilă Amazon este sub 40k, în timp ce este peste 500k pe pagina principală Charles Tyrwhitt.

Această practică vă permite să furnizați conținut critic utilizatorului foarte rapid și ajută la consolidarea percepției vitezei.

Faceți același lucru cu JavaScript

Pe lângă prioritizarea css, ar trebui să luați în considerare modul în care faceți acest lucru și cu JavaScript. Aproape toate site-urile de comerț electronic se vor baza în mare măsură pe JavaScript pentru a funcționa. Acest lucru este ok atâta timp cât acel JavaScript nu blochează încărcarea conținutului critic. Dacă iau din nou exemplul site-ului web Charles Tyrwhitt și dezactivez JavaScript în browserul meu, acum văd conținutul care se încarcă în 4,5 secunde. Aceasta este o schimbare masivă în percepția mea asupra vitezei acelui site și a JavaScript-ului care s-a încărcat înainte de conținutul critic nu a avut niciun impact asupra acelui conținut și, prin urmare, nu există niciun motiv pentru care JavaScript nu s-ar putea încărca după acel conținut.

Există multe pe care dezvoltatorii web le pot învăța din modul în care site-ul web, cum ar fi Amazon, se concentrează pe percepția asupra vitezei site-ului lor, precum și asupra vitezei reale. Deși site-ul lor este în mod clar foarte rapid, utilizatorii îl percep ca și mai rapid datorită modului în care prioritizează afișarea conținutului esențial utilizatorului înainte de orice.

S-a făcut mult despre impactul pe care viteza îl poate avea asupra ratei dvs. de conversie, iar comercianții cu amănuntul ar trebui să ia în considerare investițiile în optimizarea performanței percepute pe site-ul lor, împreună cu viteza reală a site-ului.