Smashing Podcast Episodul 34 cu Harry Roberts: Care este starea performanței web?

În acest episod, vorbim despre Performanța Web. Cum arată peisajul performanței în 2021? Am vorbit cu expertul Harry Roberts pentru a afla.

Afișați note

Harry desfășoară un atelier Web Performance Masterclass cu Smashing în mai 2021. La momentul publicării, sunt încă disponibile reduceri mari earlybird.

• Harry pe Twitter
• Site-ul de consultanță al lui Harry CSS Wizardry
• Curs video Tot ce am făcut pentru a face CSS Wizardry Fast, inclusiv 15% reducere
• Întrebări pentru consultanți eBook inclusiv 15% reducere
• Ghid Web.dev pentru Web Vitals
• Batătorul de ouă OXO GoodGrips preferat al lui Drew

Actualizare săptămânală

• Web Design Trends 2021: Raportul scris de Suzanne Scacca
• Utilizarea aplicațiilor Grommet In React scrise de Fortune Ikechi
• Cum să construiți un API Node.js pentru Ethereum Blockchain scris de John Agbanusi
• Cum am îmbunătățit performanța SmashingMag scris de Vitaly Friedman
• Când să spui nu proiectelor independente scrise de Becca Kennedy

Transcriere

Drew McLellan: Este consultant independent inginer de performanță web din Leeds, Marea Britanie. În rolul său, el ajută unele dintre cele mai mari și mai respectate organizații din lume să furnizeze experiențe mai rapide și mai de încredere clienților lor. Este un expert în dezvoltatori Google invitat, un expert în dezvoltatori media Cloudinary, un dezvoltator premiat și un vorbitor internațional. Așa că știm că își cunoaște lucrurile când vine vorba de performanța web, dar știai că are 14 brațe și șapte picioare? Prietenii mei Smashing, vă rog bun venit lui Harry Roberts. Bună Harry, ce mai faci?

Harry Roberts: Hei, zdrobesc, mulțumesc foarte mult. Evident, cele 14 brațe, șapte picioare... își mai pun problemele obișnuite. Imposibil de cumpărat pantaloni.

Drew: Și biciclete.

Harry: Da. Ei bine, am trei biciclete și jumătate.

Drew: Așa că am vrut să vorbesc cu tine astăzi, nu despre biciclete, din păcate, deși asta ar fi distractiv în sine. Am vrut să vă vorbesc despre performanța web. Este un subiect care mă pasionează personal, dar este unul dintre acele domenii în care îmi fac griji, când îmi iau ochii de la minge și mă implic într-un fel de altă muncă și apoi revin la un pic de muncă de performanță, Îmi fac griji că cunoștințele cu care lucrez sunt depășite foarte repede... Performanța web se mișcă la fel de rapid în zilele noastre pe cât percep eu?

Harry: Asta este... Nici măcar nu spun asta doar ca să fiu drăguț cu tine, asta e o întrebare atât de bună pentru că m-am gândit destul de mult la asta în ultima vreme și aș spune că sunt două jumătăți. Un lucru pe care aș încerca să le spun clienților este că de fapt nu se mișcă atât de repede. Predominant pentru că, și acesta este sunetul pe care îl folosesc mereu, poți paria pe browser. Browserele nu au voie să schimbe în mod fundamental modul în care funcționează, pentru că, desigur, există două decenii de moștenire pe care trebuie să le susțină. Deci, în general, dacă pariezi pe browser și știi cum funcționează acele elemente interne și TCP/IP nu se schimbă niciodată... Deci anumite lucruri care sunt destul de puse în piatră, ceea ce înseamnă că cele mai bune practici vor fi, în general, întotdeauna cea mai bună practică în ceea ce privește fundamentele.

Harry: Unde devine mai interesant este... Lucrul pe care îl văd din ce în ce mai mult este că ne desenăm în colțuri când vine vorba de problemele legate de viteza site-ului. Deci, de fapt, ne creăm o mulțime de probleme pentru noi înșine. Deci, ceea ce înseamnă în mod realist este performanța... este stâlpul de poartă, presupun. Cu cât peisajul sau topografia web se schimbă mai mult și modul în care este construit și modul în care lucrăm, ne punem noi provocări. Așadar, apariția de a lucra mult mai mult la client pune probleme de performanță diferite decât am fi rezolvat acum cinci ani, dar acele probleme de performanță încă se referă la elementele interne ale browserului care, în general, nu s-au schimbat în cinci ani. Deci, multe depind... Și aș spune că sunt cu siguranță două părți clare... Îmi încurajez clienții să se sprijine pe browser, să se bazeze pe standarde, pentru că nu pot fi doar modificate, stâlpii de poartă nu se mișcă cu adevărat . Dar, desigur, asta trebuie să se îmbine cu practicile de dezvoltare mai moderne și, poate ceva mai interesante. Așa că ține-ți... Ei bine, aveam de gând să spun „Un picior în ambele tabere”, dar cu cele șapte picioare ale mele, ar trebui să... patru și trei.

Drew: Ați menționat că elementele fundamentale nu se schimbă și lucruri precum TCP/IP nu se schimbă. Unul dintre lucrurile care s-au schimbat în... Eu zic „în ultimii ani”, probabil că acesta se întoarce puțin acum, dar este HTTP, prin faptul că aveam acest protocol stabilit HTTP pentru comunicarea între clienți și servere, iar asta s-a schimbat și apoi avem H2 care este atunci totul binar și diferit. Și asta a schimbat mult... Din motive de performanță, a fost pentru a elimina unele dintre limitările existente, dar asta a fost o schimbare și s-a schimbat modul în care trebuia să ne optimizăm pentru acel protocol. Acum este stabil? Sau se va schimba din nou, sau...

Harry: Deci un lucru despre care mi-ar plăcea să aflu mai multe este a doua jumătate a întrebării, schimbarea din nou. Trebuie să mă uit mai mult la QUIC și H3, dar este puțin prea departe pentru a fi util clienților mei. Când vine vorba de H2, lucrurile s-au schimbat destul de mult, dar cred cu adevărat că H2 este o promisiune falsă și cred că a fost repezit peste linie, ceea ce este remarcabil având în vedere că H1 a fost lansat... Și vreau să spun 1.1, a fost 1997, deci avem mult timp să lucrăm la H2.

Harry: Bănuiesc că beneficiul principal este dezvoltatorii web care îl înțeleg sau percep că este nelimitat în cererile de zbor acum. Deci, mai degrabă decât șase solicitări expediate și/sau șase în timpul zborului, potențial nelimitate, infinite. Aduce totuși probleme cu adevărat interesante pentru că... este destul de greu de descris fără ajutoare vizuale, dar aveți încă aceeași cantitate de lățime de bandă disponibilă, indiferent dacă rulați H1 sau H2, protocolul nu vă face conexiunea mai rapidă. Deci, este foarte posibil să puteți inunda rețeaua solicitând 24 de fișiere deodată, dar nu aveți suficientă lățime de bandă pentru asta. Deci, de fapt, nu ajungi mai repede pentru că poți gestiona, poate, doar o fracțiune din asta la un moment dat.

Harry: Și, de asemenea, la ce trebuie să te gândești este cum răspund fișierele. Și acesta este un alt sfat pro prin care trec la atelierele clienților și cetera. Oamenii se vor uita la o cascadă H2 și vor vedea că, în loc de cele șase solicitări tradiționale de expediere, ar putea vedea 24. Trimiterea a 24 de solicitări nu este de fapt atât de utilă. Ceea ce este util este atunci când acele răspunsuri sunt returnate. Și ceea ce veți observa este că ați putea trimite 24 de solicitări, astfel încât partea stângă a cascadei dvs. arată foarte bine și abruptă, dar toate revin într-o manieră destul de eșalonată, secvențială, deoarece trebuie să limitați cantitatea de lățime de bandă, astfel încât nu poți îndeplini toate răspunsurile în același timp.

Harry: Ei bine, celălalt lucru este că dacă ai îndeplini toate răspunsurile în același timp, ai intercala răspunsurile. Deci seara primești primii 10% din fiecare fișier și următorii 20%... 20% dintr-un fișier JavaScript este inutil. JavaScript nu este utilizabil până când nu a ajuns 100% din el. Deci, ceea ce veți vedea este, de fapt, modul în care o cascadă H2 se manifestă atunci când vă uitați la răspuns... Seamănă mult mai mult cu H1 oricum, este mult mai eșalonat. Deci, H2, cred că a fost supravândut, sau poate că inginerii nu au fost făcuți să creadă că există limite cu privire la cât de eficient ar putea fi. Pentru că veți vedea oameni care își sparg prea mult activele și ar putea avea douăzeci... să păstrăm numărul 24. În loc să aveți două fișiere JS mari, este posibil să aveți 24 de pachete mici. Se vor întoarce în continuare destul de secvenţial. Nu vor sosi toate în același timp pentru că nu v-ați creat mai multă lățime de bandă.

Harry: Și cealaltă problemă este că fiecare cerere are o latență constantă. Deci, să presupunem că solicitați două fișiere mari și este o sută de milisecunde dus-întors și o descărcare de 250 de milisecunde, adică de două ori 250 de milisecunde. Dacă înmulțiți până la 24 de solicitări, aveți încă o latență constantă, pe care noi am decis 100 de milisecunde, așa că acum aveți 2400 de milisecunde de latență și de 24 de ori... în loc de descărcare de 250 de milisecunde, să spunem descărcarea de 25 de milisecunde, de fapt, durează mai mult pentru că latența rămâne constantă și doar înmulți acea latență cu mai multe solicitări. Așa că voi vedea clienți care vor fi citit că H2 este acest glonț magic. Se vor sparge... Oh! Nu au putut simplifica procesul de dezvoltare, nu trebuie să facem grupare sau concatenare etc., etc. Și, în cele din urmă, va ajunge mai lent, deoarece ați reușit să vă răspândiți cererile, ceea ce a fost promisiunea, dar latența dvs. rămâne constantă, așa că de fapt aveți doar de n ori mai multă latență în browser. După cum am spus, foarte greu, probabil inutil să încerc să explic asta fără imagini, dar este remarcabil cum se manifestă H2 în comparație cu ceea ce oamenii speră că ar putea face.

Drew: Mai există beneficii în acel proces de fragmentare în sensul că, bine, pentru a obține întregul lot încă mai necesită aceeași perioadă de timp, dar până când primiți 100% din primul pe 24, puteți începe să lucrați la el și puteți începeți să îl executați înainte ca data de 24 să fie încheiată.

Harry: O, omule, o altă întrebare grozavă. Deci, absolut, dacă lucrurile merg corect și se manifestă într-un răspuns cu aspect mai H1, ideea ar fi fișierul unu returnează mai întâi, doi, trei, patru și apoi se pot executa în ordinea în care sosesc. Deci, puteți scurta timpul total, asigurându-vă că lucrurile ajung în același timp. Dacă ne uităm la o pagină web în loc de cascadă și observați că solicitările sunt intercalate, aceasta este o veste proastă. Pentru că, așa cum am spus, 10% dintr-un fișier JavaScript este inutil.

Harry: Dacă serverul își face treaba corect și trimite, trimite, trimite, trimite, trimite, atunci va deveni mai rapid. Și apoi aveți beneficii secundare ale strategiei dvs. de stocare în cache pot fi mai granulare. Așa că ar fi foarte enervant să actualizați dimensiunea fontului pe widget-ul dvs. de selectare a datei. În lumea H1, trebuie să stocați în cache aproximativ 200 de kilowați din CSS-ul larg al site-ului dvs. În timp ce acum, pur și simplu memorați cache bust datepicker.css. Așa că avem beneficii ca acestea, care sunt cu siguranță, cu siguranță foarte valoroase.

Drew: Bănuiesc că, în scenariul în care în mod magic ți-ai primit toate cererile înapoi odată, asta, evident, ar împotmoli clientul, nu-i așa?

Harry: Da, posibil. Și apoi, ceea ce s-ar întâmpla de fapt este că clientul ar trebui să facă o mulțime de planificare a resurselor, astfel încât ceea ce ați avea este o cascadă în care toate răspunsurile dvs. revin în același timp, atunci ați avea un decalaj destul de mare între sosirea ultimului răspuns și capacitatea sa de a executa. Deci, în mod ideal, când vorbim despre JavaScript, ați dori ca browserul să le solicite pe toate în ordinea solicitării, practic în ordinea în care le-ați definit, serverul să le returneze pe toate în ordinea corectă, astfel încât browserul să poată executa ele în ordinea corectă. Pentru că, după cum spuneți, dacă toate s-au întors în același timp, aveți doar un JavaScript masiv de rulat simultan, dar încă trebuie programat. Deci, ați putea avea o dubiu de până la o secundă între sosirea unui fișier și devine util. Deci, de fapt, H1... Cred că, în mod ideal, ceea ce căutați este programarea cererilor H2, răspunsuri în stil H1, astfel încât lucrurile să poată fi utile pe măsură ce sosesc.

Drew: Deci, practic, cauți o cascadă de răspuns care să pară că ai putea schia.

Harry: Da, exact.

Drew: Dar nu ai nevoie de o parașuta.

Harry: Da. Și este foarte dificil... cred că să o spun cu voce tare sună foarte banal, dar având în vedere modul în care a fost vândut H2, mi se pare că nu este o provocare pentru că asta îl face pe clientul meu să sune... prost... dar este destul de un lucru de explicat pentru ei... dacă te gândești la cum funcționează H1, nu a fost chiar așa de rău. Și dacă primim răspunsuri care arată așa și „Oh, da, pot să văd acum”. A trebuit să predau inginerii de performanță asta înainte. Oameni care fac ceea ce fac eu. A trebuit să-i învăț pe inginerii de performanță că nu ne deranjează prea mult când au fost făcute solicitări, ne pasă foarte mult când răspunsurile devin utile.

Drew: Unul dintre motivele pentru care lucrurile par să evolueze destul de repede, mai ales în ultimii cinci ani, este că performanța este un subiect important pentru Google. Și când Google pune greutate în spatele unui astfel de lucru, atunci câștigă tracțiune. În esență, performanța este un aspect al experienței utilizatorului, nu-i așa?

Harry: Oh, adică... acesta este un podcast foarte bun, mă gândeam la asta acum o jumătate de oră, îți promit că mă gândeam la asta acum o jumătate de oră. Performanța este accesibilitatea aplicată. Garantiți sau creșteți șansele ca cineva să vă poată accesa conținutul și cred că accesibilitatea este întotdeauna doar... Oh, sunt cititoare de ecran, nu? Sunt oameni fără vedere. Deciziile de a construi un site web mai degrabă decât o aplicație... deciziile sunt accesul mai mult la un public. Deci da, performanța este accesibilitatea aplicată, care este, prin urmare, experiența utilizatorului. Și această experiență de utilizator s-ar putea reduce la „Ar putea cineva să experimenteze site-ul tău” punct. Sau ar putea fi „A fost acea experiență încântătoare? Când am făcut clic pe un buton, acesta a răspuns în timp util?”. Deci sunt 100% de acord și cred că acesta este o mare parte din motivul pentru care Google pune pondere pe asta, este pentru că afectează experiența utilizatorului și dacă cineva va avea încredere în rezultatele căutării, vrem să încercăm să oferim acelei persoane un site care nu vor ura.

Drew: Și este... tot ceea ce te gândești, toate beneficiile la care te gândești, experiența utilizatorului, lucruri precum implicarea sporită, este cu siguranță adevărat, nu-i așa? Nu există nimic care să îndepărteze utilizatorul de un site mai repede decât o experiență lentă. Este atât de frustrant, nu-i așa? Folosind un site în care știi că poate navigarea nu este atât de clară și dacă dai clic pe un link și te gândești „Este asta vreau? Nu este?" Și doar costul de a face acel clic, doar de așteptare, și apoi trebuie să faceți clic pe butonul înapoi și apoi pe acea așteptare, și este doar... renunțați.

Harry: Da, și are sens. Dacă ar fi să mergi la supermarket și ai vedea că este absolut plin de oameni, vei face minim. Nu vei cheltui mulți bani acolo, e ca „Oh, am nevoie doar de lapte”, în și afară. În timp ce, dacă este o experiență plăcută, ai „Oh, ei bine, cât timp sunt aici, voi vedea dacă... Oh, da, au asta... Oh, o să gătesc asta mâine seară” sau orice altceva. Cred că încă, trei decenii în web, chiar și oamenii care construiesc pentru web se luptă, pentru că este intangibil. Ei se chinuie să creadă cu adevărat că ceea ce te-ar enerva într-un magazin adevărat te-ar enerva online, și o face, iar statisticile arată că așa a fost.

Drew: Cred că în primele zile, mă gândesc la sfârșitul anilor 90, arătând vârsta mea aici, când construiam site-uri web ne-am gândit foarte mult la performanță, dar ne-am gândit la performanță din punctul de vedere al conexiunilor pe care oamenii le aveau. folosirea a fost atât de lentă. Vorbim despre dial-up, modemuri, linii telefonice, modemuri 28K, 56K și a existat o tendință la un moment dat cu imaginile de stil pe care orice altă linie a imaginii le-ar scoate cu o culoare solidă pentru a da asta... dacă îți poți imagina că se uită printr-o jaluză la imagine. Și am făcut asta pentru că a ajutat la compresie. Pentru că orice altă linie algoritmul de compresie ar putea-

Harry: Prăbușește într-un singur indicator.

Drew: Da. Și așa ți-ai redus semnificativ dimensiunea imaginii, în timp ce poți obține... Și a devenit un element de design. Toată lumea o făcea. Cred că poate Jeffrey Zeldman a fost unul dintre primii care a inițiat această abordare. Dar la ce ne gândeam acolo era, în primul rând, cât de repede am putea să punem lucrurile la capăt. Nu pentru experiența utilizatorului, pentru că nu ne-am gândit la... Adică, cred că a fost experiența utilizatorului pentru că nu am vrut ca oamenii să părăsească site-urile noastre, în esență. Dar ne-am gândit să nu optimizăm lucrurile pentru a fi cu adevărat rapide, ci să încercăm să evităm ca acestea să fie cu adevărat lente, dacă asta are sens.

Harry: Da, da.

Drew: Și apoi, cred că, pe măsură ce viteze precum liniile ADSL au devenit mai răspândite, am încetat să ne gândim în acești termeni și am început să nu ne gândim deloc la asta. Și acum suntem în situația în care folosim dispozitive mobile și au conexiuni limitate și poate procesoare mai lente și trebuie să ne gândim din nou la asta, dar de data aceasta în ceea ce privește obținerea unui avantaj. Pe lângă experiența utilizatorului, poate avea beneficii reale de afaceri în ceea ce privește costurile și capacitatea de a obține profit. Nu-i așa?

Harry: Da, extraordinar. Adică, nu sunt sigur cum să o spun. Nu mă împușc în picior aici, dar un lucru pe care îl încerc și să le subliniez clienților este că viteza site-ului vă va oferi un avantaj competitiv, dar este doar un lucru care vă poate oferi un avantaj competitiv. Dacă aveți un produs pe care nimeni nu vrea să-l cumpere, atunci nu contează cât de rapid este site-ul dvs. Și, în egală măsură, dacă cineva își dorește cu adevărat cel mai rapid site web din lume, trebuie să ștergeți imaginile, să ștergeți CSS-ul, să ștergeți JavaScript și apoi să vedeți câte produse spuneți, pentru că vă garantez că viteza site-ului nu a fost factorul. Dar studiile au arătat că există beneficii uriașe de a fi rapid, de ordinul a milioane. Lucrez cu un client în timp ce vorbim. Am stabilit pentru ei că, dacă ar putea reda o anumită pagină cu o secundă mai rapid, sau mai degrabă cel mai mare conținut pentru vopsea a fost cu o secundă mai rapid, valorează 1,8 milioane pe an, adică... acesta este un număr mare.

Drew: Asta aproape că ți-ar plăti taxa.

Harry: Hei! Da, aproape. Le-am spus: „Uite, după doi ani, totul va fi plătit. Vei ajunge la pragul de rentabilitate”. Eu doresc. Dar da, aspectul orientat spre client... Îmi pare rău, aspectul orientat către clienți, dacă aveți un site E-Com, vor cheltui mai mulți bani. Dacă sunteți editor, ei vor citi mai multe articole sau vor vedea mai multe minute de conținut sau orice ați face, acesta este KPI-ul dvs. pe care îl măsurați. S-ar putea să fie pe site-ul Smashing, s-ar putea ca ei să nu sări, de fapt au dat clic pe mai multe articole pentru că am făcut-o foarte ușor și rapid. Și apoi site-urile mai rapide sunt mai ieftin de rulat. Dacă ți-ai rezolvat strategia de stocare în cache, vei ține oamenii departe de serverele tale. Dacă îți optimizezi activele, orice trebuie să provină de la serverul tău va cântări mult mai puțin. Mult mai ieftin de rulat.

Harry: Chestia este că există un cost pentru a ajunge acolo. Cred că Scott Jehl a spus probabil unul dintre cele mai multe... Și l-am auzit mai întâi de la el, așa că voi presupune că a venit cu asta, dar zicala este „Este ușor să faci un site rapid, dar este dificil să faci un site web. rapid". Și asta este atât de succint. Deoarece motivul pentru care performanța web ar putea fi împinsă în jos din lista de lucruri de făcut este că ați putea spune unui client „Dacă vă fac site-ul cu o secundă mai rapid, veți câștiga 1,8 milioane în plus pe an” sau poate fi „Dacă tocmai ați adăugat Apple Pay la checkout, veți câștiga încă cinci milioane.” Deci nu este totul despre performanța web și nu este factorul decisiv, este o parte a unei strategii mult mai mari, în special pentru E-Com online. Dar dovezile sunt că l-am măsurat direct cu clienții mei de retail, clienții mei E-Com. Cazul este chiar acolo, ai perfectă dreptate. Este un avantaj competitiv, vă va face mai mulți bani.

Drew: În vremuri, din nou, mă întorc la vremuri trecute, dar oameni precum Steve Souders au fost printre primii oameni care au început cu adevărat să scrie și să vorbească despre performanța web. Și oameni ca Steve spuneau practic „Uită de infrastructura backend, unde toate câștigurile care trebuie obținute sunt în browser, în front end, acolo se întâmplă totul lent”. Mai este cazul peste 15 ani?

Harry: Da, da. A repetat testul între atunci și acum, iar decalajul s-a mărit de fapt, așa că de fapt este mai costisitor peste fir. Dar există un contracar pentru asta, și anume, dacă ai performanță backend cu adevărat proastă, dacă ieși încet de pe poartă, există doar atât de multe pe care le poți recupera pe front. Am un client în acest moment, timpul lor până la primul octet este de 1,5 secunde. Prin urmare, nu vom putea reda niciodată mai repede de 1,5 secunde, așa că va fi o limită. Încă putem recupera timpul înapoi pe front-end, dar dacă aveți un moment foarte, foarte prost până la primul octet, aveți încetiniri ale backend-ului, există o limită cu cât de mult vă pot duce eforturile de performanță front-end. Dar absolut.

Harry: Totuși, asta se schimbă pentru că... Ei bine, nu, nu se schimbă, cred că se înrăutățește. Impingem mai mult asupra clientului. Odinioară era un caz de „Serverul tău este la fel de rapid, dar după aceea avem o grămadă de semne de întrebare.” pentru că aud asta tot timpul „Toți utilizatorii noștri rulează pe WiFi. Toți au computere desktop pentru că toate lucrează de la biroul nostru.” Ei bine, nu, acum toți lucrează de acasă. Nu poți alege. Deci, acolo apar toate semnele de întrebare, unde se întâmplă încetinirile, unde nu o poți controla cu adevărat. După aceea, faptul că acum avem tendința să punem mai mult pe client. Prin asta vreau să spun, timpi întregi de rulare pe client. Oricum, ați mutat toată logica aplicației de pe un server, așa că timpul dvs. pentru primul octet ar trebui să fie foarte, foarte minim. Ar trebui să fie un caz de trimitere a unor pachete de la un CDM la meu... dar ați trecut de la posibilitatea de a specifica propriile servere la speranța că cineva nu are Netflix să ruleze pe aceeași mașină pe care încearcă să vă vadă site-ul web .

Drew: Este o idee foarte bună despre felul în care proiectăm site-uri și cred că cea mai bună practică tradițională a fost întotdeauna că ar trebui să încercați să răspundeți pentru tot felul de browsere, tot felul de viteze de conexiune, tot felul de dimensiuni de ecran, pentru că nu nu știu la ce se va aștepta utilizatorul. Și, așa cum ați spus, aveți aceste scenarii în care oamenii spun „Oh, nu, știm că toți utilizatorii noștri sunt pe computerul lor de serviciu, rulează acest browser, este cea mai recentă versiune, sunt conectați în LAN” dar apoi se întâmplă lucrurile. Unul dintre marile beneficii ale aplicațiilor web este că putem face lucruri precum distribuirea forței de muncă dintr-o dată înapoi la casele lor și ei pot continua să lucreze, dar acest lucru este valabil doar dacă calitatea ingineriei a fost de așa natură încât atunci cineva care se învârte. să își monteze mașina de acasă care ar putea avea IE11 pe el sau orice altceva, indiferent dacă calitatea lucrării este acolo, ceea ce înseamnă de fapt că web-ul își îndeplinește potențialul de a fi un mediu cu adevărat accesibil.

Drew: După cum spuneți, există această tendință de a muta tot mai multe lucruri în browser și, desigur, atunci, dacă browserul este lent, acolo se întâmplă încetineala. Trebuie să vă întrebați „Este acesta o tendință bună? Ar trebui să facem asta?” Am un site la care mă gândesc în mod special, am observat că este randat aproape 100% pe server. Există foarte puțin JavaScript și este fulgerător. De fiecare dată când merg la el mă gândesc „Oh, asta e rapid, cine a scris asta?” Și apoi îmi dau seama „Oh, da, eu am fost”.

Harry: Asta pentru că ești pe localhost, nu e de mirare că se simte rapid. Este site-ul dvs. de dezvoltare.

Drew: Atunci, slujba mea de zi cu zi, construim aplicația noastră cu o singură pagină și deplasăm lucrurile de pe server, deoarece serverul este blocajul în acest caz. Poti spune doar ca este mai performant sa fii in browser? Sau mai performant pentru a fi pe server? Este doar un caz de măsurare și luare de la caz la caz?

Harry: Cred că trebuie să fii foarte, foarte, foarte conștient de contextul tău și... sincer cred că o eroare este... narcisismul în care oamenii cred „Oh, blogul meu merită să fie redat în browserul cuiva. Blogul meu cu o rată de respingere de 89% are nevoie de propriul său timp de rulare în browser, pentru că am nevoie de navigarea ulterioară pentru a fi rapid, vreau doar să aduc o... practic o diferență a datelor.” Oricum, nimeni nu dă clic pe următorul tău articol, prietene, nu împinge un timp de rulare în jos. Deci trebuie să fii foarte conștient de contextul tău.

Harry: Și știu că... dacă Jeremy Keith ascultă asta, probabil că o să mă lovească, dar există, aș spune, o diferență între un site web și o aplicație web și definiția acesteia este foarte, foarte tulbure. Dar dacă aveți o aplicație de citire și scriere foarte intensă, atunci ceva în care introduceți date, manipulați date etc. Practic, site-ul meu nu este o aplicație web, este un site web, este numai pentru citire, pe care l-aș pune ferm în tabăra site-ului. Ceva de genul software-ului meu de contabilitate este o aplicație web, aș spune că este o aplicație web și sunt pregătit să suport puțin costul de pornire, pentru că știu că voi fi acolo timp de 20 de minute, o oră, indiferent. Deci, ai nevoie de puțin context și, din nou, poate narcisismul este puțin dur, dar trebuie să ai un adevărat „Trebuie să facem din acest ziar o aplicație pentru client?” Nu, nu. Nu, nu. Oamenii au activat blocarea reclamelor, oricum oamenilor nu le plac site-urile de ziare pentru navetiști. Probabil că nici nu vor citi articolul și nu vor dezvălui despre el pe Facebook. Doar nu construiți așa ceva ca o aplicație redată de client, nu este potrivită.

Harry: Așa că cred că există cu siguranță un punct în care te-ar ajuta să te muți mai mult pe client și atunci ai mai puțină sensibilitate la abandon. Deci orice tip de comunicație, de exemplu, fac un audit pentru un moment pentru un site care... Cred că este un site E-Com dar este 100% pe client. Dezactivați JavaScript și nu vedeți nimic, doar un div id=“app” gol. E-Com este... ești foarte sensibil la orice problemă. Fluxul dvs. de plată este chiar subtil greșit, am plecat în altă parte. E prea lent, plec în altă parte. Nu aveți contextul în care cineva este dispus să se culce cu acea aplicație pentru o perioadă.

Harry: Photoshop. Deschid Photoshop și sunt destul de fericit să știu că va dura 45 de secunde de splash screen pentru că voi fi acolo pentru... practic cele 45 de secunde merită cele 45 de minute. Și este atât de greu de definit, motiv pentru care chiar mă chinui să-i conving pe clienți „Te rog, nu face asta”, pentru că nu pot spune doar „Cât timp crezi că va fi utilizatorul tău acolo”. Și îl puteți aproxima de la... dacă rata de respingere este de 89% nu se optimizează pentru o a doua vizualizare a paginii. Reduceți mai întâi rata de respingere. Cred că există cu siguranță o despărțire, dar ceea ce aș spune este că majoritatea oamenilor cad de partea greșită a acelei linii. Majoritatea oamenilor pun în client lucruri care nu ar trebui să fie acolo. CNN, de exemplu, nu puteți citi un singur titlu pe site-ul CNN până când nu este pornită complet o aplicație JavaScript. Singurul lucru redat de server este antetul și subsolul, care este singurul lucru de care oamenilor nu le pasă.

Harry: Și simt că asta este doar... Nu știu cum ajungem în acel moment. Nu va fi niciodată opțiunea mai bună. Trimiteți o pagină care este efectiv inutilă, care apoi trebuie să spună „Fine, mă duc să aduc ceea ce ar fi fost o aplicație web, dar o vom rula în browser, apoi mă voi duce și voi cere un titlu. , atunci poți începe să... oh, ai plecat.” Asta chiar, chiar mă enervează.

Harry: Și nu este vina nimănui, cred că este începutul acestui tip de ecosistem JavaScript, hype-ul din jurul lui și, de asemenea, asta va suna foarte dur, dar... Practic este multă implementare naivă. Sigur, Facebook a inventat React și orice, funcționează pentru ei. De nouă ori din 10 nu lucrezi la scara Facebook, de 95 de ori din 100 probabil că nu ești cei mai deștepți ingineri Facebook, și asta este cu adevărat, foarte crud și sună oribil de spus, dar poți doar să obții... Nici unul dintre aceste lucruri sunt rapide implicit. Aveți nevoie de o implementare foarte, foarte elegantă a acestor lucruri pentru a le face corecte.

Harry: Aveam această discuție cu bătrânul meu... era inginer principal al echipei la care am fost acum 10 ani la Sky. Vorbeam cu el zilele trecute despre asta și a trebuit să muncească foarte mult pentru a face o aplicație redată rapidă de client, în timp ce pentru a face o aplicație redată pe server rapid, nu trebuie să faci nimic. Trebuie doar să nu încetinești din nou. Și simt că există o mulțime de ochelari nuanțați de trandafir, naivitate, marketing... Sun atât de sumbru, că trebuie să mergem mai departe înainte să încep să pierd oameni aici.

Drew: Crezi că avem tendința, ca industrie, să ne concentrăm uneori mai mult pe experiența dezvoltatorului decât pe experiența utilizatorului?

Harry: Nu în ansamblu, dar cred că problema apare într-un loc la care te-ai aștepta. Dacă te uiți la disparitate... Nu știu dacă ai văzut asta, dar o să presupun că ai făcut-o, se pare că ai foarte mult degetul pe puls, disparitatea dintre datele arhivei HTTP despre ce cadre și Bibliotecile JavaScript sunt folosite în sălbăticie față de sondajul despre starea JavaScript, dacă urmați sondajul despre starea JavaScript, ar spune „Oh, da, 75% dintre dezvoltatori folosesc React”, în timp ce mai puțin de 5% dintre site-uri folosesc React. Așadar, simt că, în masă, nu cred că este o problemă, dar cred că în zonele la care te-ai aștepta, loialitatea față de un cadru, de exemplu, experiența dezvoltatorului este... evanghelizată, probabil, înaintea utilizatorului. Nu cred că trebuie trecută cu vederea experiența dezvoltatorului, adică totul are un cost de întreținere. Mașina ta. A fost o decizie când s-a proiectat că „Ei bine, dacă ascundem această cheie, acea funcționalitate, unui mecanic, îi va dura mult mai mult timp pentru a o repara, deci nu facem așa ceva”. Deci, trebuie să existe un echilibru între ergonomie și utilizare, cred că este important. Cred că concentrarea în primul rând pe experiența dezvoltatorului este pur și simplu derutant pentru mine. Nu optimiza pentru tine, optimizează pentru clientul tău, clientul tău te plătește, nu invers.

Drew: Deci camera de eco online nu este exact reprezentativă pentru realitate când vezi pe toți spunând „Oh, ar trebui să folosești asta, ar trebui să faci asta”, atunci acesta este de fapt doar un procent foarte mic de oameni.

Harry: Corect, și ăsta e un lucru bun, este liniștitor. Camera de ecou... nu este sănătos să ai un asemenea tip de monocultură, poate, dacă vrei să-i spui așa. Dar, de asemenea, simt că... și am văzut asta în multe din propria mea muncă, mulți dezvoltatori... Ca consultant, lucrez cu o mulțime de companii diferite. Mulți oameni fac o muncă uimitoare în WordPress. Și WordPress alimentează 24% din web. Și cred că ar putea fi destul de ușor pentru un astfel de dezvoltator care lucrează în ceva de genul WordPress sau PHP pe backend, cod personalizat, oricare ar fi acesta, să se simtă un pic ca „Oh, cred că toată lumea folosește React și noi nu suntem. ” dar de fapt, nu. Toată lumea vorbește despre React, dar tot mergi cu fluxul, încă ești cu majoritatea. Este destul de liniştitor să găseşti majoritatea tăcută.

Drew: Tendința către generatoare de site-uri statice și apoi găzduirea site-urilor în întregime pe un CDN, un fel de abordare JAMstack, cred că atunci când vorbim despre acele tipuri de site-uri de tip publicare, mai degrabă decât site-uri de tip software, cred că este o tendință cu adevărat sănătoasă , ai crede?

Harry: Îmi place asta, absolut. Îți amintești când obișnuiam să numim SSG „fișier clapă”, nu?

Drew: Da.

Harry: Deci, am construit CSS Wizardry pe Jekyll, când Jekyll era numit un site web cu fișiere flap. But now we service our generator, huge, huge fan of that. There's no disadvantage to it really, you pay maybe a slightly larger up front compute cost of pre-compiling the site but then your compute cost is… well, Cloudflare fronts it, right? It's on a CDN so your application servers are largely shielded from that.

Harry: Anything interactive that does need doing can be done on the client or, if you want to get fancy, what one really nice approach, if you are feeling ambitious, is use Edge Side Includes so you can keep your shopping cart server rendered, but at the edge. You can do stuff like that. Tremendous performance benefits there. Not appropriate for a huge swathe of sites, but, like you say, if we're thinking publishing… an E-Com site it wouldn't work, you need realtime stock levels, you need… search that doesn't just… I don't know you just need far more functionality. But yeah, I think the Smashing site, great example, my site is an example, much smaller than Smashing but yeah, SSG, flap filers, I'm really fond of it.

Drew: Could it work going deeper into the JAMstack approach of shifting everything into the client and building an E-Commerce site? I think the Smashing E-Commerce site is essentially using JavaScript in the client and server APIs to do the actual functionality as service functions or what have you.

Harry: Yeah. I've got to admit, I haven't done any stuff with serverless. But yeah, that hybrid approach works. Perhaps my E-Commerce example was a bit clunky because you could get a hybrid between statically rendering a lot of the stuff, because most things on an E-Com site don't really change. You filter what you can do on the client. Search, a little more difficult, stock levels does need to go back to an API somewhere, but yeah you could do a hybrid for a definite, for an E-Com site.

Drew: Okay, so then it's just down to monitoring all those performance metrics again, really caring about the network, about latency, about all these sorts of things, because you're then leaning on the network a lot more to fetch all those individual bits of data. It hosts a new set of problems.

Harry: Yeah, I mean you kind of… I wouldn't say “Robbing Peter to pay Paul” but you are going to have to keep an eye on other things elsewhere. I've not got fully to the bottom of it, before anyone tweets it at us, but a client recently moved to an E-Commerce client. I worked with them two years ago and that site was already pretty fast. It was built on… I can't remember which E-Com platform, it was .net, hosted on IIS, server rendered, obviously, and it was really fast because of that. It was great and we just wanted to maintain, maybe find a couple of hundred milliseconds here and there, but really good. Half way through last year, they moved to client side React for key pages. PP… product details page, product listing page, and stuff just got marketable slower lower, much slower. To the point they got back in touch needing help again.

Harry: And one of the interesting things I spotted when they were putting a case for “We need to actually revert this”. I was thinking about all the…what's slower, obviously it's slower, how could doing more work ever be faster, blah blah blah. One of their own bullet points in the audit was: based on projections, their yearly hosting costs have gone up by a factor of 10 times. Because all of a sudden they've gone from having one application server and a database to having loads of different gateways, loads of different APIs, loads of different microservers they're calling on. It increased the surface area of their application massively. And the basic reason for this, I'll tell you exactly why this happened. The developer, it was a very small team, the developer who decided “I'm going to use React because it seems like fun” didn't do any business analysis. It was never expected of them to actually put forward a case of how much is it going to cost the dude, how much is it going to return, what's the maintenance cost of this?

Harry: And that's a thing I come up against really frequently in my work and it's never the developer's fault. It's usually because the business keeps financials away from the engineering team. If your engineers don't know the cost or value of their work then they're not informed to make those decisions so this guy was never to know that that was going to be the outcome. But yeah, interestingly, moving to a more microservice-y approach… And this is an outlier, and I'm not going to say that that 10 times figure is typical, it definitely seems atypical, but it's true that there is at least one incident I'm aware of when moving to this approach, because they just had to use more providers. It 10x'ed their… there's your 10 times engineer, increased hosting by 10 times.

Drew: I mean, it's an important point, isn't it? Before starting out down any particular road with architectural changes and things about doing your research and asking the right questions. If you were going to embark on some big changes, say you've got a really old website and you're going to structure it and you want it to be really fast and you're making all your technology choices, I mean it pays, doesn't it, to talk to different people in the business to find out what they want to be doing. What sort of questions should you be asking other people in the business as a web developer or as a performance engineer? Who should you be talking to you and what should you be asking them?

Harry: I've got a really annoying answer to the “Who should you be talking to?” And the answer is everyone should be available to you. And it will depend on the kind of business, but you should be able to speak to marketing “Hey, look, we're using this AB testing tool. How much does that cost as a year and how much do you think it nets as a year?” And that developer should feel comfortable. I'm not saying developers need to change their attitude, what I mean is the company should make the developers able to ask those kind of questions. How much does Optimizely cost as a year? Right, well that seems like a lot, does it make that much in return? Okay, whatever we can make a decision based on that. That's who you should be talking to and then questions you should ask, it should be things like…

Harry: The amount of companies I work will, they won't give their own developers to Google Analytics. How are you meant to build a website if you don't know who you're building it for? So the question should be… I work a lot with E-Com clients so every developer should things like “What is our average order value? What is our conversion rate? What is our revenue, how much do we make?” These things mean that you can at least understand that “Oh, people spend a lot of money on this website and I'm responsible for a big chunk of that and I need to take that responsibility.”

Harry: Beyond that, other things are hard to put into context, so for me, one of things that I, as a consultant, so this is very different to an engineer in the business, I need to know how sensitive you are to performance. So if a client gives me the average order value, monthly traffic, and their conversion rate, I can work out how much 100 milliseconds, 500 a second will save them a year, or return them, just based on those three numbers I can work out roughly “Well a second's worth 1.8 mil”. It's a lot harder for someone in the business to get all the back information because as a performance engineer it's second nature to me. But if you can work that kind of stuff out, it unlocks a load of doors. Okay, well if a second's work this much to us, I need to make sure that I never lose a second and if I can, gain a second back. And that will inform a lot of things going forward. A lot of these developers are kept quite siloed. “Oh well, you don't need to know about business stuff, just shut up and type”.

Drew: I've heard you say, it is quite a nice soundbite, that nobody wants a faster website.

Harry: Yeah.

Drew: What do you mean by that?

Harry: Well it kind of comes back to, I think I've mentioned it already in the podcast, that if my clients truly wanted the world's fastest website, they would allow me to go in and delete all their JavaScript, all their CSS, all their images. Give that customer a Times New Roman stack.

Harry: But fast for fast sake is… not chasing the wrong thing but you need to know what fast means to you, because, I see it all the time with clients. There's a point at which you can stop. You might find that your customer's only so sensitive to web perf that it might mean that getting a First Contentful Paint from four seconds to two seconds might give you a 10% increase in revenue, but getting from that two to a one, might only give you a 1% increase. It's still twice as fast, but you get minimal gains. So what I need to do with my clients is work out “How sensitive are you? When can we take our foot off the gas?” And also, like I said, towards the top of the show… You need to have a product that people want to buy.

Harry: If people don't want to buy your product, it doesn't matter how quickly you show them it, it'll just disgust them faster, I guess. Is your checkout flow really, really, really seamless on mobile, for example. So there's a number of factors. For me, and my clients, it'll be working out a sweet spot, to also working out “If getting from here to here is going to make you 1.8 mil a year, I can find you that second for a fraction of that cost.” If you want me to get you an additional second on top of that, it's going to get a lot harder. So my cost to you will probably go up, and that won't be an extra 1.8, because it's not lineal, you don't get 1.8 mil for every one second.

Harry: It will tail off at some point. And clients will get to a point where… they'll still be making gains but it might be a case of your engineering effort doubles, meaning your returns halve, you can still be in the green, hopefully it doesn't get more expensive and you're losing money on performance, but there's a point where you need to slow down. And that's usually things that I help clients find out because otherwise they will just keep chasing speed, speed, speed and get a bit blinkered.

Drew: Yeah, it is sort of diminishing returns, isn't it?

Harry: That's what I was look for-

Drew: Da.

Harry: … diminishing returns, that's exactly it. Yeah, exactly.

Drew: And in terms of knowing where to focus your effort… Say you've got the bulk of your users, 80% of your users are getting a response within two, three seconds, and then you've got 20% who may be in the long-tail that might end up with responses five, ten seconds. Is it better to focus on that 80% where the work's really hard, or is it better to focus on the 20% that's super slow, where the work might be easier, but it's only 20%. How do you balance those sorts of things?

Harry: Drew, can you write all podcast questions for everyone else? This is so good. Well, a bit of a shout out to Tim Kadlec, he's done great talks on this very topic and he calls it “The Long-Tail of Web Performance” so anyone listening who wants to look at that, Tim's done a lot of good firsthand work there. The 80, 20, let's just take those as good example figures, by the time you're dealing with the 80th percentile, you're definitely in the edge cases. All your crooks and web file data is based around 75th percentile. I think there's a lot of value investing in that top 20th percentile, the worst 20%. Several reasons for this.

Harry: First thing I'm going to start with is one of the most beautiful, succinct soundbites I've ever heard. And the guy who told me it, I can guarantee, did not mean it to be this impactful. I was 15 years old and I was studying product design, GCSE. Finally, a project, it was a bar stool so it was a good sign of things to come. And we were talking about how you design furniture. And my teacher basically said… I don't know if I should… I'm going to say his name, Mr. Brocklesby.

Harry: A impus respect, dar era unul dintre băieți, cu toții ne-a plăcut foarte mult. Dar era masiv în toate dimensiunile. Înălțime de peste 6 picioare, dar doar un băiat mare. Mare, mare, mare, mare om. Și ne-a spus „Dacă ar fi să proiectați o ușă, ați proiecta-o pentru o persoană obișnuită?” Și creierul de 15 ani spune „Ei bine, da, dacă toată lumea are aproximativ 5’9, atunci da” El a spus „Ei bine, imediat, Harry nu poate folosi ușa aia”. Nu proiectezi pentru omul obișnuit, proiectezi pentru extremități pentru că vrei să fie util celor mai mulți oameni. Dacă ai proiectat un scaun pentru omul obișnuit, domnul Brocklesby nu avea să se potrivească în el. Așa că m-a învățat de la o vârstă cu adevărat, cu adevărat, design până la extremitățile tale.

Harry: Și unde asta devine cu adevărat interesant în perfecțiunea web este... Dacă îți imaginezi o scară și o ridici de bot... Bine, tocmai mi-am dat seama că metafora mea ar putea... O să rămân cu ea și poți râde de el. eu dupa aceea. Imaginați-vă o scară și ridicați scara de treptele de jos. Și acestea sunt cele mai rele experiențe ale tale. Alegeți treapta de jos a scării pentru a o ridica. Toată scara vine cu ea, ca și cum o maree în creștere plutește toate bărcile. Motivul pentru care metafora nu funcționează este că dacă ridici o scară de treapta de sus, se ridică și ea, este o scară. Și metafora nici măcar nu funcționează dacă o transform într-o scară de frânghie, pentru că atunci o scară de frânghie, ridici treapta de jos și nu se întâmplă nimic, dar... Ideea mea este că dacă poți îmbunătăți experiența pentru percentila 90, trebuie să ridică asta pentru a 10-a ta percentila, nu?

Harry: Și de aceea le spun clienților, ei îmi vor spune lucruri precum „Ei bine, majoritatea utilizatorilor noștri sunt pe 4G pe iPhone”, așa că în regulă, bine, și începem să testăm 3G pe Android, cum ar fi „Nu, nu, majoritatea utilizatorilor noștri sunt iPhone-uri” bine... asta înseamnă că utilizatorul tău obișnuit va avea o experiență mai bună, dar oricine nu se află deja în percentila 50 este lăsat mai mult în urmă. Așa că setați ștacheta destul de sus pentru dvs., stabilind așteptările destul de scăzute.

Harry: Îmi pare rău, am un obicei prost de a da răspunsuri foarte lungi la întrebări scurte. Dar a fost o întrebare fantastică și, pentru a încerca să închei, cu siguranță sunt 100% de acord cu tine că vrei să te uiți la acea coadă lungă, vrei să te uiți la asta... a 80-a percentila pentru că dacă iei toate experiențele pe site-ul și uită-te la mediană și o îmbunătățești, asta înseamnă că ai făcut-o și mai bună pentru oamenii care erau deja destul de mulțumiți. 50% dintre oameni care sunt ignorați efectiv nu este abordarea corectă. Și da, întotdeauna se întoarce la domnul Brocklesby care îmi spune „Nu proiectați pentru o persoană obișnuită, pentru că atunci Harry nu poate folosi ușa”. Oh, pentru oricine mă ascultă, am 193 de centimetri, deci sunt destul de lejer, asta este.

Drew: Și toate acele brațe și picioare.

Harry: Da. Iată și un altul bun. Prietena mea a descoperit recent setările de accesibilitate în iOS... așa că toată lumea are telefonul pe silent, nu? Nimeni nu are de fapt un telefon care să sune cu adevărat, toată lumea îl are pe silent. Ea a descoperit că „O, știi, poți să-l setezi astfel încât atunci când primești un mesaj, blițul să clipească. Și dacă atingeți de două ori partea din spate a telefonului, va face o captură de ecran.” Și acestea sunt setări de accesibilitate, acestea sunt concepute pentru acea percentila 95. Cu toate acestea, ea spune „Oh, asta este cu adevărat util”.

Harry: La fel cu OXO Good Grips. OXO Good Grips, ustensilele de bucătărie. Am o grămadă de ele în bucătărie. Sunt concepute pentru că soția fondatorului avea artrită și el dorea să facă ustensile mai confortabile. El a proiectat pentru a 99-a percentila, majoritatea oamenilor nu au artrită. Dar, proiectând pentru a 99-a percentila, din neatenție, toți ceilalți sunt de genul „O, Doamne, de ce nu pot fi toți curățatorii de cartofi atât de confortabili?” Și simt că este într-adevăr, într-adevăr... Îmi place un sentiment de bine sau o anecdotă pe care îmi place să o fac în astfel de scenarii. Dar da, dacă optimizezi pentru ei... Ei bine, o maree în creștere plutește toate bărcile și, prin urmare, optimizează coada oamenilor și vei atrage mulți clienți și mai fericiți peste asta.

Drew: Aveți telul manual de mână OXO Good Grips?

Harry: Eu nu. Eu nu, este bine?

Drew: Uită-te la asta. E așa de bine.

Harry: Am feliatorul de mandolină OXO Good Grips care mi-a luat capătul degetului săptămâna trecută.

Drew: Da, nu mă voi apropia de una dintre ele.

Harry: Da, este propria mea vină stupidă.

Drew: Un alt exemplu din propria mea experiență cu catering pentru acea coadă lungă este că, în proiectul la care lucrez în acest moment, acea coadă lungă este chiar la sfârșit, aveți oameni cu cea mai lentă performanță, dar dacă se dovedește că, dacă te uiți la cine sunt acești clienți, ei sunt cei mai valoroși clienți pentru afacere...

Harry: Bine.

Drew: … pentru că sunt cele mai mari organizații cu cea mai mare cantitate de date.

Harry: Corect.

Drew: Și astfel se lovesc de blocaje pentru că au atât de multe date de afișat pe o pagină și acele pagini trebuie să fie puțin refactorizate pentru a ajuta acest caz de utilizare. Deci au cea mai lentă experiență și, când vine vorba de asta, plătesc cei mai mulți bani și fac o diferență mult mai mare decât toți oamenii care au o experiență foarte rapidă, deoarece sunt utilizatori gratuiti cu o cantitate mică de date și totul funcționează bine și este rapid.

Harry: Este o dimensiune fascinantă, nu-i așa? De fapt, am avut un impact asemănător... Nu aveam nici un fel de impact asupra afacerii ca ceea ce tocmai ai descris, dar am lucrat cu un client în urmă cu câțiva ani, iar CEO-ul lor a luat legătura pentru că site-ul lor era lent. Ca, încet, încet, încet. De asemenea, un tip foarte drăguț, este doar un tip cu adevărat drăguț, dar este îndrumat, ca un bogat. Și are cel mai recent iPhone, își poate permite asta. Este un multimilionar, își petrece mult timp zburând între Australia, de unde este, și Estonia, unde își are sediul acum.

Harry: Și zboară la clasa întâi, bineînțeles că este. Dar înseamnă că cea mai mare parte a timpului său pe iPhone-ul său frumos și strălucitor 12 Pro Max, orice, indiferent, este prin WiFi din avion, ceea ce este îngrozitor. Și a fost această juxtapunere cu adevărat uimitoare în care deține site-ul și îl folosește foarte mult, este un site pe care îl folosește. Și el a fost împins... Vreau să spun cu ușurință cel mai bogat client al lor a fost CEO-ul lor. Și se află în această poziție ciudat de privilegiată în care se află într-o conexiune mai proastă decât Joe Public, pentru că se află undeva deasupra Singapore, cu un zbor Quantas, și i se toarnă șampanie pe gât și se luptă. Și asta a fost o perspectivă cu adevărat fascinantă că... Da, pentru că ai 95-a percentila, poate merge în orice direcție.

Drew: Da, atunci când începi să optimizezi pentru a folosi un site cu un pahar de șampanie într-o mână, te gândești „Poate că începem să pierdem puțin drumul.”

Harry: Da, exact.

Drew: Am vorbit puțin despre măsurarea performanței și, din propria mea experiență cu munca de performanță, este cu adevărat esențial să măsoare totul. faci ceva diferit și cât de mult faci diferența. Cum ar trebui să măsurăm performanța site-urilor noastre? Ce instrumente putem folosi și de unde ar trebui să începem?

Harry: O, omule, o altă întrebare grozavă. Deci, există o gamă de răspunsuri în funcție de cât timp, resurse, înclinație există pentru fixarea vitezei site-ului. Deci, ceea ce voi încerca să fac cu clientul este... Anumite valori de la raft sunt foarte bune. Timp de încărcare, nu-ți mai pasă de asta. Este foarte, foarte, foarte... Adică, este un proxy bun dacă timpul tău de încărcare este de 120 de secunde, o să ghicesc că nu ai un site web foarte rapid, dar este prea obscur și nu este cu adevărat orientat spre client. De fapt, cred că elementele vitale sunt un pas foarte bun în direcția corectă, deoarece măsoară experiența utilizatorului, dar se bazează pe contribuții tehnice. Cea mai mare vopsea de conținut este un lucru foarte drăguț pentru vizual, dar elementele tehnice de acolo vă deblochează calea critică, asigurați-vă că imaginile eroilor ajung rapid și asigurați-vă că strategia dvs. de fonturi web este decentă. Există un curent subteran tehnic pentru aceste valori. Acestea sunt foarte bune de pe raft.

Harry: Cu toate acestea, dacă clienții au timp, de obicei este timpul, pentru că doriți să capturați datele, dar aveți nevoie de timp pentru a captura datele efectiv. Așa că ceea ce încerc să fac cu clienții este să mergem „Uite, nu putem lucra împreună în următoarele trei luni pentru că sunt plin de rezervă. Deci, ceea ce putem face este să vă configurați rapid cu o încercare gratuită a Speedcurve, să configurați niște valori personalizate”, astfel încât pentru un client editor, un ziar, aș măsura „Cât de repede a fost titlul articol redat? Cât de repede a fost redată imaginea principală pentru articol?” Pentru un client de comerț electronic vreau să măsoare, pentru că, evident, măsori lucruri precum începerea redării pasiv. De îndată ce începeți să utilizați orice software de monitorizare a performanței, vă capturați gratuit valorile reale de performanță. Deci, prima vopsea plină de conținut, cel mai mare conținut de conținut etc. Ceea ce vreau cu adevărat să surprind sunt lucruri care contează pentru ei ca afacere.

Harry: Deci, lucrând cu un client E-Com în momentul în care suntem capabili să corelăm... Cu cât porniți mai rapid randarea, care este probabilitatea de a adăuga la coș. Dacă le puteți arăta un produs mai devreme, este mai probabil să-l cumpere. Și acesta este mult efort de configurat, acesta este un fel de obiectiv extensiv pentru clienții care sunt cu adevărat ambițioși, dar orice doriți să măsurați cu adevărat, pentru că, așa cum am spus, nu doriți să măsurați cu adevărat ceea ce este cel mai mare. Contentful Paint înseamnă că doriți să vă măsurați veniturile și a fost influențat de Large Contentful Paint? Deci obiectivul extins, lucrul suprem, ar fi orice ați vedea ca un KPI pentru acea afacere. S-ar putea să fie, în ziare, cât de jos a derulat cineva articolul? Și se corelează în vreun fel cu întârzierea primei intrări? Oamenii au citit mai multe articole dacă CLS era mai scăzut? Dar, înainte de a începe să facem valori personalizate, cred sincer că web vitals este un loc foarte bun pentru a începe și a fost, de asemenea, destul de bine normalizat. Devine un... Nu știu care este cuvântul. Cel mai mic numitor comun, cred, în cazul în care toată lumea din industrie acum poate discuta despre performanță pe aceste condiții de concurență echitabile.

Harry: O problemă pe care o am și, de fapt, trebuie să organizez o întâlnire cu echipa de elemente vitale, este că și eu cred că Lighthouse este grozav, dar CLS reprezintă 33% din elementele vitale web. Ai LCP, FID, CLS. CLS reprezintă 33% din elementele tale vitale. Vitals este ceea ce merge în mod normal în fața echipei dvs. de marketing, departamentului dvs. de analiză, deoarece apare în consola de căutare, este menționat în contextul paginilor cu rezultatele căutării, în timp ce este vorba despre vitals, aveți o pondere mare, 33%, o treime de vitale este CLS, este doar 5% din scorul nostru Lighthouse. Deci, ceea ce veți obține sunt dezvoltatori care construiesc în jurul Lighthouse, deoarece poate fi integrat în instrumente, este o măsurătoare de laborator. Vitals sunt date de teren, este rom.

Harry: Deci ai această deconectare masivă în care echipa ta de marketing spune „CLS este foarte rău” și dezvoltatorii se gândesc „Ei bine, este 5% din scorul Lighthouse pe care mi-l oferă DevTools, este 5% din scor. acel Lighthouse CLI ne oferă în CircleCI” sau orice folosiți, dar pentru echipa de marketing este 33% din ceea ce le pasă. Așadar, problema este o oarecare deconectare, deoarece cred că Lighthouse este foarte valoros, dar nu știu cum se împacă acea diferență destul de masivă în care în punctele vitale, CLS este 33% din scorul tău... ei bine, nu scorul pentru că tu nu prea am unul, iar Lighthouse este de doar 5% și lucruri de genul ăsta trebuie încă rezolvate înainte de a putea face această discuție fără întreruperi.

Harry: Dar, din nou, răspuns lung la o întrebare scurtă. Vitals este foarte bun. LCP este o măsură bună pentru experiența utilizatorului, care se poate reduce la soluții tehnice, la fel și cu CLS. Deci cred că este un punct de plecare foarte bun. Dincolo de asta, sunt valori personalizate. Ceea ce încerc să-mi aduc clienții este un punct în care nu le pasă cât de repede este site-ul lor, le pasă doar că câștigă mai mulți bani de ieri, iar dacă a făcut asta este pentru că mergea repede? Dacă a făcut mai puțin, este pentru că mergea mai încet? Nu vreau ca ei să urmărească un LCP mistic de două secunde, vreau să urmărească LCP-ul optim. Și dacă asta se dovedește de fapt a fi mai lent decât crezi, atunci orice, e bine.

Drew: Așadar, pentru dezvoltatorul web care este doar interesat de... nu au buget de cheltuit pentru instrumente precum Speedcurve și altele, evident că pot rula instrumente precum Lighthouse chiar în browserul lor, pentru a obține o măsurătoare bună... Sunt lucruri precum Google Analytics util pentru acel nivel?

Harry: Sunt și pot fi mai utile. Analytics, de mulți ani, a captat informații rudimentare de performanță. Și acesta va fi timpul DNS, TCP și TLS, timpul până la primul octet, timpul de descărcare a paginii, care este un proxy... ei bine, indiferent, doar timpul de descărcare a paginii și timpul de încărcare. Deci metrice destul de greoaie. Dar este un punct de plecare bun și, în mod normal, fiecare proiect pe care îl încep cu un client, dacă nu are New Relic sau Speedcurve sau orice altceva, voi spune doar „Ei bine, lasă-mă să arunc o privire la analizele tale”, pentru că pot la cel puțin proxy situația de acolo. Și nu va fi niciodată la fel de bun ca ceva de genul Speedcurve sau New Relic sau Dynatrace sau orice altceva. Puteți trimite valori personalizate cu adevărat, foarte, foarte ușor către analize. Dacă cineva care ascultă vrea să poată trimite... site-ul meu de exemplu. Am valori precum „Cât de repede poți citi titlul unuia dintre articolele mele? În ce moment a fost redată imaginea paginii Despre? În ce moment a fost apelul la acțiune care te imploră să mă angajezi? Cât de curând este redat pe ecran?” Cu adevărat banal să captezi aceste date și aproape la fel de banal să le trimiți la analize. Deci, dacă cineva dorește să vadă sursa pe site-ul meu, să deruleze în jos până la eticheta de închidere a corpului și să găsească fragmentul de analiză, veți vedea cât de ușor îmi este să captez date personalizate și să le trimit la analize. Și, în interfața de utilizare de analiză, nu trebuie să faceți nimic. În mod normal, ar trebui să configurați rapoarte personalizate și să extrageți datele și să le faceți prezentabile. Aceștia sunt cetățeni de primă clasă în Google Analytics. Deci, în momentul în care începeți să capturați analize personalizate, există o întreagă secțiune a tabloului de bord dedicată acesteia. Nu există nicio configurare, nicio sarcină grea în GA în sine, așa că este cu adevărat banal și, dacă clienții au un buget real sau poate vreau să le arăt puterea monitorizării personalizate, nu vreau să spun „Oh, da, promit. va fi foarte bine, pot avea doar 24 de mii pentru Speedcurve?” Pot începe prin a spune „Uite, asta este rudimentar. Să vedem aici posibilitățile, acum poate te putem convinge să faci upgrade la ceva de genul Speedcurve.”

Drew: Am descoperit adesea că instinctul meu cu privire la cât de repede ar trebui să fie ceva sau ce impact ar trebui să aibă o schimbare poate fi greșit. Voi face o schimbare și voi crede că fac lucrurile mai repede și apoi o voi măsura și, de fapt, am făcut lucrurile mai încet. Sunt doar eu o prostie la performanța web?

Harry: Deloc. Am un exemplu cu adevărat pertinent în acest sens. Preîncărcare... o introducere foarte rapidă pentru oricine nu a auzit de preîncărcare, încărcarea anumitor active pe web este în mod inerent foarte lentă și cei doi candidați principali aici sunt imagini de fundal în CSS și fonturi web, deoarece înainte de a putea descărca o imagine de fundal, trebuie pentru a descărca HTML, care apoi descarcă CSS, iar apoi CSS spune „Oh, acest div de pe pagina de pornire are nevoie de această imagine de fundal”. Deci, este în mod inerent foarte lent, deoarece aveți toată acea bucată de timp CSS între ele. Cu preîncărcare, puteți pune o linie în HTML în eticheta head care spune „Hei, încă nu știți, dar credeți-mă, veți avea nevoie de această imagine foarte, foarte, foarte curând.” Deci, puteți pune o preîncărcare în HTML care declanșează preventiv această descărcare. În momentul în care CSS-ul are nevoie de imaginea de fundal, este de genul „Oh, bine, am primit-o deja, e rapid.” Și acest lucru este promovat ca acest Mesia perfecționat web... Iată chestia, și vă promit, am postat pe Twitter săptămâna trecută și mi s-a dovedit că am dreptate de două ori de atunci. Oamenii aud despre preîncărcare și promisiunea pe care o oferă și, de asemenea, este foarte puternic împins de Lighthouse, în teorie, vă face site-ul mai rapid. Oamenii se căsătoresc atât de mult cu ideea de preîncărcare încât chiar și atunci când pot dovedi că nu funcționează, nu o vor scoate din nou. Pentru că „Nu, dar Lighthouse a spus”. Acum, acesta este unul dintre acele lucruri în care teoria este solidă. Dacă trebuie să așteptați fontul dvs. web, în ​​loc să îl descărcați mai devreme, veți vedea lucrurile mai repede. Problema este că, când te gândești la modul în care funcționează de fapt web-ul, la orice pagină pe care ai accesat prima dată, la orice domeniu nou-nouț pe care îl atingi, ai o lățime de bandă limitată și browserul cheltuiește corect acea lățime de bandă. Acesta va căuta foarte repede prin HTML și va face o listă de cumpărături. Cel mai important lucru este CSS, apoi este acest jQuery, apoi este acesta... și apoi următoarele câteva lucruri sunt acestea, acestea și acestea mai puțin prioritare. De îndată ce începi să încarci HTML-ul cu preîncărcări, îi spui browserului „Nu, nu, nu, aceasta nu mai este lista ta de cumpărături, amice, aceasta este a mea. Trebuie să mergi și să iei astea.” Acea cantitate finită de lățime de bandă este încă finită, dar nu este cheltuită pe mai multe active, așa că totul devine puțin mai lent. Și a trebuit să huiduiesc asta de două ori în ultima săptămână și totuși oamenii spun „Da, dar nu, pentru că se descarcă mai devreme”. Nu, este solicitat mai devreme, dar fură lățime de bandă din CSS. Puteți vedea literalmente că fonturile dvs. web fură lățime de bandă din CSS. Deci este unul dintre acele lucruri în care trebuie, trebuie, trebuie să urmezi cifrele. Am mai făcut-o pe un client la scară largă. Dacă ascultați asta, ați auzit de acest client și am fost destul de insistent că „Nu, nu, etichetele dvs. de cap sunt în ordinea greșită, pentru că așa ar trebui să fie și trebuie să le aveți în asta. comandă pentru că teoretic indică asta...” Chiar și în ceea ce eram pentru client, știam că mă pregătesc pentru un prost. Din cauza modului în care funcționează browserele, trebuie să fie mai rapid. Așa că fac trucul, această schimbare... pentru multe milioane de oameni și a devenit mai lent. A devenit mai lent. Și eu stând acolo, insistând indignat „Nu, dar browserele funcționează așa” este inutil pentru că nu funcționează. Și am revenit și am spus: „Îmi pare rău! Vă fac în continuare factura pentru asta!” Deci nu ești tu deloc.

Drew: Urmărește aceste numere.

Harry: Da, exact. „De fapt, trebuie să te taxez mai mult, pentru că mi-am petrecut timp să-l revin, mi-a luat mai mult.” Dar da, ai perfectă dreptate, nu ești tu, este unul dintre acele lucruri în care... Am făcut-o de câteva ori la o scară mult mai mică, unde voi spune „Ei bine, asta teoretic trebuie să funcționeze” și nu 't. Trebuie doar să urmărești ce se întâmplă în lumea reală. De aceea, monitorizarea este cu adevărat importantă.

Drew: Pe măsură ce peisajul se schimbă și se dezvoltă tehnologia, Google lansează noi tehnologii care ne ajută să facem lucrurile mai repede, există o modalitate bună de a ține pasul cu schimbările? Există resurse pe care ar trebui să ne uităm pentru a ne menține abilitățile la zi când vine vorba de performanța web?

Harry: Ca să abordez rapid întregul „creare Google”... Știu că este ușor gura, dar mă voi concentra pe asta. Cred că chiar la început, pariază pe browser. Lucruri precum AMP, de exemplu, sunt în cel mai bun caz o soluție după gândire. Nu există un înlocuitor pentru construirea unui site rapid, iar în momentul în care începi să folosești lucruri precum AMP, trebuie să te ții de acele standarde nestandard, mila echipei AMP răzgândindu-se. Am avut un client să cheltuiască o avere licențiând un font de la un furnizor de fonturi autorizat AMP, apoi, la un moment dat, AMP a decis „Oh, de fapt, nu, fontul a fost furnizat, le vom bloca lista acum” Așa că am avut un client care a investit foarte mult în AMP și acest furnizor de fonturi și a trebuit să aleagă „Ei bine, anulăm toată munca AMP sau pur și simplu irosim acest număr foarte mare pe an pe fontul web” bla, bla, bla. Așa că aș fi foarte precaut față de oricine... Sunt un expert Google Developer, dar nu știu despre nicio ordine de nădejde... Pot fi critic și aș spune... evit lucrurile care sunt salutate ca fiind unice -soluție potrivită pentru toate, lucruri precum AMP.

Harry: Și pentru a arunca pe altcineva pentru o secundă, Cloudflare are un lucru numit Rocket Loader, care este AMP în efortul său. Este conceput ca „Oh, doar porniți chestia asta pe CDN-ul dvs., vă va face site-ul mai rapid.” Și, de fapt, este doar un înlocuitor pentru construirea corectă a site-ului dvs., în primul rând. Așa că... pentru a aborda acest aspect, încercați să rămâneți cât mai independenți posibil, știți cum funcționează browserele, ceea ce înseamnă imediat că monocultură Chrome, vă întoarceți în poala Google, dar știți cum funcționează browserele, rămâneți la câteva ideologii fundamentale. Când construiți un site, uitați-vă pe pagină. Fie că este în Figma, sau Sketch, sau oriunde ar fi, uită-te la design și spune „Ei bine, asta este ceea ce un utilizator vrea să vadă mai întâi, așa că nu voi pune nimic în cale. Nu voi încărca leneș această imagine principală pentru că este o prostie, de ce aș face asta?” Așa că gândește-te doar la „Ce ai vrea ca utilizatorul să fie primul?” Pe un site E-Com, va fi acea imagine a produsului, probabil nav în același timp, dar recenzii despre produs, Q și A ale produsului, leneș încărcă asta. Pune-l în spatele JavaScript.

Harry: Anumite moduri fundamentale de lucru care vă vor servi corect, indiferent de tehnologia pe care citiți, și anume „Prioritizează ceea ce prioritizează clientul tău”. A lucra mai mult la asta ar fi mai rapid, așa că nu pune lucrurile în calea asta, ci apoi lucruri mai tactice pe care oamenii să le cunoască, să fie la curent cu... și din nou, direct înapoi la Google, dar web.dev se dovedește a fi o resursă fenomenală pentru informații agnostice de cadru, agnostice de stivă... Deci, dacă doriți să aflați despre elementele vitale, doriți să aflați despre PWA, așa că web.dev este cu adevărat grozav.

Harry: De fapt, există foarte puține publicații centrate pe performanță. E-mail-ul lui Calibre este, cred că e-mail-ul său de performanță pentru două săptămâni este pur și simplu fenomenal, este un rezumat foarte bun. Fiți cu ochii pe platforma web în general, așa că există Grupul de lucru pentru performanță, au o mulțime de lucruri despre propunerile GitHub. Din nou, înapoi la Google, dar nimeni nu știe despre acest site web și fenomenul său: chromestatus.com. Îți spune exact la ce lucrează Chrome, care sunt semnalele de la alte browsere, așa că, dacă vrei să vezi care este lucrul cu indicațiile prioritare, poți să obții linkuri către toate instrumentele de urmărire a erorilor relevante. Stare Chrome vă arată repere pentru fiecare... „Acesta apare în MAT8, acesta a fost lansat în ’67” sau orice altceva, este un lucru foarte bun pentru informații destul de tehnice.

Harry: Dar tot revin la chestia asta și știu că probabil sună ca „Omul bătrân strigă la Cloud”, dar rămân la elementele de bază, aproape fiecare liră sau dolar, euro pe care l-am câștigat vreodată, a învățat clienții că „Știi că browserul face asta deja, corect” sau „Știi că acest lucru nu ar putea fi mai rapid” și asta sună cu adevărat corect din partea mea... Nu am câștigat niciodată un cent din vânzarea de tehnologie suplimentară. Fiecare bucată de bani pe care o câștig este despre eliminarea, scăderea. Dacă adaugi lucruri pentru a-ți face site-ul mai rapid, ești în direcția greșită.

Harry: Ca exemplu, nu voi numi... marea companie de publicitate/motoare de căutare/browser deloc, nu le voi numi și nu voi numi cadrul JavaScript, dar sunt în prezent în discuții cu un cadru JavaScript foarte, foarte mare și foarte popular despre eliminarea a ceva care dăunează activ sau, opțional, eliminarea a ceva care ar dăuna performanței unui număr masiv de site-uri web. Și au fost de genul „Oh, vom intra în buclă...” cineva de la această companie mare, pentru că a făcut niște cercetări... și este de genul „Avem nevoie de o opțiune pentru a elimina acest lucru pentru că puteți vedea aici, și aici, și iată că face acest site mai lent.” Iar soluția lor a fost să adauge mai multe, de genul „Oh, dar dacă faci și asta, atunci poți ocoli asta” și este ca „Nu, nu, adăugarea mai mult pentru a face un site mai rapid trebuie să fie soluția greșită. Cu siguranță puteți vedea că vă îndreptați în direcția greșită dacă este nevoie de mai mult cod pentru a ajunge la un site mai rapid.”

Harry: Pentru că a fost rapid la început și tot ceea ce adaugi este ceea ce îl face mai lent. Și ideea de a adăuga mai multe pentru a face mai rapid, deși... s-ar putea manifesta într-un site web mai rapid, este o modalitate greșită. Este o cursă spre fund. Îmi pare rău, mă încinge foarte tare, vă puteți da seama că nu m-am deranjat de ceva vreme. Deci, acesta este celălalt lucru, dacă adaugi funcții pentru a face un site mai rapid, probabil că te îndrepți în direcția greșită, este mult mai eficient să faci un mai rapid eliminând lucruri decât să le adaugi.

Drew: Ați creat un curs video numit „Tot ce am făcut pentru a face CSS Wizardry rapid”.

Harry: Da!

Drew: Este puțin diferit de cursurile video tradiționale online, nu-i așa?

Harry: Este. Voi fi sincer, este parțial... Nu vreau să spun lene din partea mea, dar nu am vrut să elaborez un curriculum care trebuia să fie foarte rigid și să te ducă de la zero la erou, deoarece timpul implicat în a face asta este enorm și timp nu știam dacă voi avea. Așadar, ceea ce îmi doream a fost să am material gata de utilizare, doar să mă filmez vorbind despre el, astfel încât să nu înceapă cu „Iată un browser și iată cum funcționează”, așa că trebuie să fii cel puțin conștient de elementele fundamentale ale performanței web, dar sunt hack-uri și sfaturi pro și exemple din viața reală.

Harry: Și pentru că nu aveam nevoie să fac un curriculum complet, am reușit să scad prețul. Deci, nu este un curs mare de 10 ore care te va duce de la zero la erou, ci se întâlnește și se iese după cum crezi de cuviință. Practic este doar să mă uit la site-ul meu, care este un loc de joacă excelent pentru lucruri care sunt instabile sau... este un risc foarte scăzut pentru mine să experimentez acolo. Așa că tocmai am făcut serii video. A fost foarte distractiv să înregistrez. Doar să-mi dărâm propriul site și să vorbesc despre „Ei bine, așa funcționează și iată cum l-ați putea folosi”.

Drew: Cred că este foarte grozav cum se împarte în rezolvarea diferitelor probleme. Dacă vreau să aflu mai multe despre optimizarea imaginilor sau orice altceva, mă pot gândi „Bine, ce are de spus prietenul meu Harry despre asta?”, accesează videoclipul despre imagini și plec. Este într-adevăr accesibil în acest fel, nu trebuie să stai peste ore și ore de lucru, poți doar să mergi la partea pe care o dorești și să înveți ceea ce trebuie să înveți și apoi să ieși.

Harry: Cred că am încercat să-l păstrez mai mult... Avantajul de a nu face un curriculum rigid este că nu trebuie să vizionezi mai întâi un anumit videoclip, nu există o introducere, este doar „Du-te și uită-te în jur și vezi ce ți se pare interesant” ceea ce însemna că cineva care suferă de probleme cu LTP este de genul „Oh, bine, trebuie să merg în acest folder aici” sau dacă suferă de probleme CSS, poate merge în acel folder. Evident că nu am statistici, dar îmi imaginez că există o rată mare de abandon pe cursuri, pur și simplu pentru că trebuie să treci cu greu prin trei ore de intro în cazul în care ratezi ceva și este de genul „Oh, știi ce, nu pot. continuă să faci asta în fiecare zi”, iar oamenii ar putea să abandoneze o mulțime de cursuri. Așa că gândul meu a fost doar să te scufundi, nu trebuie să fi văzut ultimele trei ore, poți să mergi și să găsești tot ce vrei. Și feedback-ul a fost cu adevărat, într-adevăr... De fapt, ceea ce voi face este că nu există încă, dar o voi face imediat după apel, oricine folosește codul de reducere SMASHING15, va primi 15% reducere din ea.

Drew: Așa că este aproape ca și cum ați optimiza performanța cursului în sine, pentru că puteți merge direct la partea dorită și nu trebuie să faceți toată negocierea și...

Harry: Da, neintenționat, dar îmi voi lua meritul pentru asta.

Drew: Deci, am învățat totul despre performanța web, despre ce ai învățat în ultima vreme, Harry?

Harry: Chestii tehnice... nu chiar. Am multe pe lista mea „de învățat”, așa că QUIC, H3 fel de chestii aș dori să obțin mai multe cunoștințe de lucru despre asta, dar am scris o carte electronică în timpul primei blocări în Marea Britanie, așa că am învățat cum să fac cărți electronice, ceea ce a fost foarte distractiv pentru că sunt doar HTML și CSS și știu cum să o fac, așa că a fost foarte distractiv. Am învățat editare video foarte rudimentară pentru curs și ceea ce mi-a plăcut la acestea nu este o lucrare conceptuală. Evident, învățând un limbaj de programare, trebuie să te lupți cu concepte, în timp ce învățarea unei cărți electronice a fost doar fluxuri de lucru și... lucruri pe care nu le-am mai chinuit până acum, așa că a fost interesant de învățat, dar nu a necesitat o schimbare de carieră. , deci a fost destul de frumos.

Harry: Și apoi, chestii netehnice... merg pe o mulțime de biciclete, cad de pe o mulțime de biciclete... și pentru că nu am mai călătorit deloc din martie trecut, aproape un an acum, am făcut mult mai multe mersul cu bicicleta și concentrarea mult mai mult pe... îmbunătățirea asta. Așa că am făcut o mulțime de cercetări în ceea ce privește puterile de ieșire și puterile de prag funcționale, fac un program de antrenament în acest moment, așa că picioarele epuizate în mod constant, în mod constant, dar învăț multe despre fiziologia ciclismului. Nu știu de ce, pentru că nu am de gând să fac altceva cu ea decât să continui să călăresc. A fost cu adevărat fascinant. Simt că am fost foarte norocos în timpul blocajelor, la plural, dar am reușit să rămân activ. Mulți oameni vor pierde lucruri simple, cum ar fi o navetă zilnică la birou, o șansă bună de a se întinde picioarele. În Marea Britanie, după cum știți, ciclismul a fost foarte susținut, așa că m-am chinuit mult mai mult cu a afla mai multe despre mersul pe bicicletă dintr-un aspect mai fiziologic, ceea ce înseamnă... nu știu, doar să fiu un tocilar. altceva pentru schimbare.

Drew: Poate că nu există atât de multă diferență între optimizarea performanței pe web și optimizarea performanței în ciclism, toate sunt câștiguri marginale, nu?

Harry: Da, exact. Și numărul de grafice la care m-am uitat pe bicicletă... Am date de putere de la bicicletă, voi ieși într-o plimbare și mă voi întoarce de genul „Oh, dacă aș mai avea cinci wați aici, dar apoi aș economisi 10 wați acolo, aș putea face asta, asta și asta cel mai rapid din toate timpurile” și... am fost un anorac masiv în legătură cu asta. Dar da, ai dreptate. Știi ce, cred că te-ai lovit de ceva cu adevărat interesant acolo. Cred că genul ăsta de lucruri este un sport/distracție bun pentru cineva care este puțin obsesiv, căruia îi place să urmărească numerele. Sunt lucruri, adică vei ști asta, dar, Strava, ai KOM-urile tale. Am luat 19 dintre ele anul trecut, ceea ce este, pentru mine, o cantitate fenomenală. Și aproape totul este obsedat de datele disponibile și uitându-mă la „Tipul ăsta pe care încerc să-l înving, făcea 700 de wați în acest moment, dacă aș putea ajunge până la 1000 și apoi să mă opresc” și bla, bla, bla. … este să fii obsesiv. Tocilar. Dar ai dreptate, cred că este un gen de lucru similar, nu-i așa? If you could learn where you afford to tweak things from or squeeze last little drops out…

Drew: And you've still got limited bandwidth in both cases. You've got limited energy and you've got limited network connection.

Harry: Exactly, you can't just magic some more bandwidth there.

Drew: If you, the listener, would like to hear more from Harry, you can find him on Twitter, where he's @csswizardty, or go to his website at csswizardry.com where you'll find some fascinating case studies of his work and find out how to hire him to help solve your performance problems. Harry's E-Book, that he mentioned, and video course we'll link up from the show notes. Thanks for joining us today, Harry, do you have any parting words?

Harry: I'm not one for soundbites and motivation quotes but I heard something really, really, really insightful recently. Everyone keeps saying “Oh well we're all in the same boat” and we're not. We're all in the same storm and some people have got better boats than others. Some people are in little dinghies, some people have got mega yachts. Oh, is that a bit dreary to end on… don't worry about Corona, you'll be dead soon anyway!

Drew: Keep hold of your oars and you'll be all right.

Harry: Da. I was on a call last night with some web colleagues and we were talking about this and missing each other a lot. The web is, by default, remote, that's the whole point of the web. But… missing a lot of human connection so, chatting to you for this hour and a bit now has been wonderful, it's been really nice. I don't know what my parting words really are meant to be, I should have prepared something, but I just hope everyone's well, hope everyone's making what they can out of lockdown and people are keeping busy.