Smashing Podcast Episodio 34 con Harry Roberts: qual è lo stato delle prestazioni sul Web?

In questo episodio parliamo di Web Performance. Come appare il panorama delle prestazioni nel 2021? Ho parlato con l'esperto Harry Roberts per scoprirlo.

Mostra note

Harry terrà un seminario Web Performance Masterclass con Smashing a maggio 2021. Al momento della pubblicazione, sono ancora disponibili grandi sconti earlybird.

• Harry su Twitter
• Sito di consulenza di Harry CSS Wizardry
• Video corso Tutto quello che ho fatto per rendere veloce la magia CSS incluso il 15% di sconto
• Domande per Consulenti eBook con 15% di sconto
• Guida Web.dev a Web Vitals
• Il frullatore per uova OXO GoodGrips preferito di Drew

Aggiornamento settimanale

• Web Design Trends 2021: The Report scritto da Suzanne Scacca
• Utilizzo di Grommet In React Applicazioni scritte da Fortune Ikechi
• Come creare un'API Node.js per la blockchain di Ethereum scritta da John Agbanusi
• Come abbiamo migliorato le prestazioni di SmashingMag scritto da Vitaly Friedman
• Quando dire di no ai progetti freelance scritti da Becca Kennedy

Trascrizione

Drew McLellan: È un consulente indipendente per le prestazioni Web di Leeds nel Regno Unito. Nel suo ruolo, aiuta alcune delle organizzazioni più grandi e rispettate del mondo a fornire esperienze più rapide e affidabili ai propri clienti. È un Google Developer Expert invitato, un Cloudinary Media Developer Expert, uno sviluppatore pluripremiato e un oratore internazionale. Quindi sappiamo che sa il fatto suo quando si tratta di performance sul web, ma lo sapevi che ha 14 braccia e sette gambe? Miei amici Smashing, vi prego di dare il benvenuto a Harry Roberts. Ciao Harry, come stai?

Harry Roberts: Ehi, sono strepitoso grazie mille. Ovviamente le 14 braccia, le sette gambe… che pongono ancora i soliti problemi. Impossibile acquistare i pantaloni.

Drew: E le biciclette.

Harry: Sì. Bene, ho tre biciclette e mezzo.

Drew: Quindi volevo parlarti oggi, purtroppo non di biciclette, anche se sarebbe divertente di per sé. Volevo parlarti delle prestazioni web. È un argomento che personalmente mi appassiona molto, ma è una di quelle aree in cui mi preoccupo, quando distolgo lo sguardo dalla palla e vengo coinvolto in una sorta di altro lavoro e poi ritorno a fare un po' di lavoro performativo, Temo che le conoscenze con cui sto lavorando non siano aggiornate molto rapidamente... Le prestazioni del Web sono in rapido movimento in questi giorni come percepisco?

Harry: Questo è... non lo dico nemmeno solo per essere gentile con te, è una bella domanda perché ci ho pensato un po' ultimamente e direi che ce ne sono due metà. Una cosa che proverei a dire ai clienti è che in realtà non si muove così velocemente. Prevalentemente perché, e questo è il soundbite che uso sempre, puoi scommettere sul browser. I browser non possono davvero cambiare radicalmente il modo in cui funzionano, perché, ovviamente, ci sono due decenni di eredità che devono mantenere. Quindi, in genere, se scommetti sul browser e sai come funzionano quei componenti interni e TCP/IP che non cambia mai... Quindi alcune cose che sono abbastanza scolpite nella pietra, il che significa che le migliori pratiche, in generale, saranno sempre best practice per quanto riguarda i fondamenti.

Harry: Il punto in cui diventa più interessante è... La cosa che vedo sempre di più è che ci stiamo dipingendo negli angoli quando si tratta di problemi di velocità del sito. Quindi in realtà creiamo molti problemi per noi stessi. Quindi ciò che significa realisticamente è la prestazione... è il palo mobile, suppongo. Più cambia il panorama o la topografia del web, il modo in cui è costruito e il modo in cui lavoriamo, ci poniamo nuove sfide. Quindi l'avvento di fare molto più lavoro sul client pone problemi di prestazioni diversi rispetto a quelli che avremmo risolto cinque anni fa, ma quei problemi di prestazioni riguardano ancora gli interni del browser che, in generale, non sono cambiati in cinque anni. Quindi molto dipende... E direi che ci sono sicuramente due aspetti chiari... Incoraggio i miei clienti ad appoggiarsi al browser, ad appoggiarsi agli standard, perché non possono essere semplicemente modificati, i pali non si muovono davvero . Ma, ovviamente, ciò deve fondersi con pratiche di sviluppo più moderne e, forse leggermente più interessanti. Quindi mantieni il tuo... Beh, stavo per dire "Un piede in entrambi i campi", ma con i miei sette piedi, dovrei... quattro e tre.

Drew: Hai detto che i fondamenti non cambiano e cose come TCP/IP non cambiano. Una delle cose che è cambiata in... dico "anni recenti", in realtà probabilmente sta tornando un po' indietro ora, ma è HTTP in quanto avevamo questo protocollo HTTP stabilito per la comunicazione tra client e server, e quello è cambiato e poi abbiamo H2 che è quindi tutto binario e diverso. E questo ha cambiato molto del... Era per motivi di prestazioni, era per eliminare alcune delle limitazioni esistenti, ma quello è stato un cambiamento e il modo in cui dovevamo ottimizzare per quel protocollo è cambiato. Adesso è stabile? O cambierà di nuovo, o...

Harry: Quindi una cosa su cui vorrei saperne di più è la seconda metà della domanda, il cambiamento di nuovo. Ho bisogno di guardare più in QUIC e H3, ma è un po' troppo dietro l'angolo per essere utile ai miei clienti. Quando si tratta di H2, le cose sono cambiate parecchio, ma penso sinceramente che H2 sia un sacco di false promesse e credo che sia stato affrettato oltre il limite, il che è notevole considerando che H1 è stato lanciato ... E intendo 1.1, era il 1997, quindi abbiamo molto tempo per lavorare su H2.

Harry: Immagino che il vantaggio principale siano gli sviluppatori web che lo capiscono o percepiscono che ora le richieste di volo sono illimitate. Quindi, anziché sei richieste inviate e/o sei in volo alla volta, potenzialmente illimitate, infinite. Porta problemi davvero interessanti perché... è abbastanza difficile da descrivere senza ausili visivi ma hai ancora la stessa quantità di larghezza di banda disponibile, sia che tu stia eseguendo H1 o H2, il protocollo non rende la tua connessione più veloce. Quindi è del tutto possibile che tu possa inondare la rete richiedendo 24 file contemporaneamente, ma non hai abbastanza larghezza di banda per quello. Quindi in realtà non diventi più veloce perché puoi gestirne, forse, solo una frazione alla volta.

Harry: E anche quello a cui devi pensare è come rispondono i file. E questo è un altro consiglio professionale che eseguo sui workshop dei clienti ecc. Le persone guarderanno una cascata H2 e vedranno che invece delle tradizionali sei richieste di invio potrebbero vederne 24. L'invio di 24 richieste in realtà non è così utile. Ciò che è utile è quando vengono restituite quelle risposte. E quello che noterai è che potresti inviare 24 richieste, quindi il tuo lato sinistro della tua cascata sembra davvero bello e ripido, ma ritornano tutte in modo abbastanza sfalsato e sequenziale perché devi limitare la quantità di larghezza di banda così non puoi soddisfare tutte le risposte contemporaneamente.

Harry: Beh, l'altra cosa è che se dovessi soddisfare tutte le risposte allo stesso tempo, saresti le risposte intrecciate. Quindi la notte ottieni il primo 10% di ogni file e il 20% successivo... Il 20% di un file JavaScript è inutile. JavaScript non è utilizzabile fino a quando non è arrivato il 100%. Quindi quello che vedrai è, in realtà, il modo in cui una cascata di H2 si manifesta quando guardi la risposta... Ad ogni modo sembra molto più simile a H1, è molto più sfalsato. Quindi, H2, penso che sia stato ipervenduto, o forse gli ingegneri non sono stati indotti a credere che ci siano limiti a quanto potrebbe essere efficace. Perché vedrai persone che partizionano eccessivamente le loro risorse e potrebbero averne venti... manteniamo il numero 24. Invece di avere due grandi file JS, potresti avere 24 piccoli bundle. Torneranno comunque in modo abbastanza sequenziale. Non arriveranno tutti allo stesso tempo perché non ti sei magico più larghezza di banda.

Harry: E l'altro problema è che ogni richiesta ha una quantità costante di latenza. Quindi supponiamo che tu stia richiedendo due file di grandi dimensioni ed è un viaggio di andata e ritorno di cento millisecondi e 250 millisecondi di download, ovvero due volte 250 millisecondi. Se moltiplichi fino a 24 richieste, hai ancora una latenza costante, che abbiamo deciso 100 millisecondi, quindi ora hai 2400 millisecondi di latenza e 24 volte... invece di 250 millisecondi di download diciamo 25 millisecondi di download, in realtà ci è voluto più tempo perché la latenza rimane costante e si moltiplica semplicemente quella latenza per più richieste. Quindi vedrò clienti che avranno letto che H2 è questa bacchetta magica. Si scheggiano... Oh! Non potrebbero semplificare il processo di sviluppo, non abbiamo bisogno di fare bundling o concatenazione eccetera, eccetera. E alla fine finirà per essere più lento perché sei riuscito a diffondere le tue richieste, che era la promessa, ma la tua latenza rimane costante, quindi in realtà hai solo n volte più latenza nel browser. Come ho detto, è davvero difficile, probabilmente inutile, cercare di spiegarlo senza elementi visivi, ma è straordinario come H2 si manifesti rispetto a ciò che le persone sperano possa fare.

Drew: C'è ancora un vantaggio in quel processo di sharding in quanto, ok, per ottenere l'intero lotto ci vuole ancora la stessa quantità di tempo ma quando ottieni il 100% del primo 24esimo indietro puoi iniziare a lavorarci e puoi inizia a eseguirlo prima che il 24 sia finito.

Harry: Oh, amico, un'altra grande domanda. Quindi, assolutamente, se le cose vanno correttamente e si manifesta in una risposta dall'aspetto più H1, l'idea sarebbe che il file uno restituisca prima, due, tre, quattro e quindi possano essere eseguiti nell'ordine in cui arrivano. Quindi puoi effettivamente ridurre il tempo aggregato assicurandoti che le cose arrivino nello stesso momento. Se diamo un'occhiata a una pagina Web anziché a una cascata e noti che le richieste sono intercalate, questa è una cattiva notizia. Perché come ho detto, il 10% di un file JavaScript è inutile.

Harry: Se il server fa il suo lavoro correttamente e invia, invia, invia, invia, invia, allora diventerà più veloce. E poi hai i vantaggi a catena della tua strategia di memorizzazione nella cache che può essere più granulare. Sarebbe davvero fastidioso aggiornare la dimensione del carattere sul widget di selezione della data. Nel mondo H1 devi memorizzare nella cache forse 200 kilowatt dell'ampio CSS del tuo sito. Mentre ora, metti semplicemente nella cache il busto datepicker.css. Quindi abbiamo vantaggi di derivazione del genere, che sono decisamente, decisamente molto preziosi.

Drew: Immagino che nello scenario in cui hai magicamente ricevuto indietro tutte le tue richieste in una volta, ciò ovviamente impantanerebbe potenzialmente il cliente, vero?

Harry: Sì, potenzialmente. E quindi ciò che accadrebbe effettivamente è che il client dovrebbe eseguire un carico di pianificazione delle risorse, quindi ciò che ti ritroverebbe è una cascata in cui tutte le tue risposte ritornano contemporaneamente, quindi avresti un divario abbastanza grande tra il ultima risposta in arrivo e sua capacità di esecuzione. Quindi, idealmente, quando parliamo di JavaScript, vorresti che il browser li richieda tutti nell'ordine di richiesta, in pratica l'ordine in cui li hai definiti, il server li restituisca tutti nell'ordine corretto in modo che il browser possa eseguire loro nell'ordine corretto. Perché, come dici tu, se sono tornati tutti contemporaneamente, hai solo un enorme JavaScript da eseguire contemporaneamente ma deve ancora essere pianificato. Quindi potresti avere un dubbio fino a un secondo tra un file che arriva e diventa utile. Quindi, in realtà, H1 ... Immagino, idealmente, quello che stai cercando è la pianificazione delle richieste H2, risposte in stile H1, quindi le cose possono essere rese utili non appena arrivano.

Drew: Quindi stai fondamentalmente cercando una cascata di risposta che sembri che potresti scendere con gli sci.

Harry: Sì, esattamente.

Drew: Ma non avresti bisogno di un paracadute.

Harry: Sì. Ed è davvero difficile... Penso che a dirlo ad alta voce suoni davvero banale, ma dato il modo in cui H2 è stato venduto, lo trovo piuttosto... non impegnativo perché questo fa sembrare il mio cliente... stupido... ma è abbastanza da spiegare per loro... se pensi a come funziona H1, non era poi così male. E se riceviamo risposte che assomigliano a quella e "Oh sì, ora posso vederlo". Ho dovuto insegnare questo agli ingegneri delle prestazioni prima. Persone che fanno quello che faccio io. Ho dovuto insegnare agli ingegneri delle prestazioni che non ci importa troppo quando vengono fatte le richieste, ci interessa davvero quando le risposte diventano utili.

Drew: Uno dei motivi per cui le cose sembrano andare avanti abbastanza rapidamente, specialmente negli ultimi cinque anni, è che le prestazioni sono un argomento importante per Google. E quando Google dà peso a qualcosa del genere, guadagna terreno. In sostanza, però, le prestazioni sono un aspetto dell'esperienza dell'utente, vero?

Harry: Oh, voglio dire... questo è davvero un buon podcast, ci stavo pensando mezz'ora fa, ti giuro che ci stavo pensando mezz'ora fa. Le prestazioni sono accessibilità applicata. Stai garantendo o aumentando le possibilità che qualcuno possa accedere ai tuoi contenuti e penso che l'accessibilità sia sempre solo... Oh, sono gli screen reader, giusto? Sono le persone senza vista. Le decisioni di creare un sito Web piuttosto che un'app... le decisioni sono l'accesso a un pubblico più ampio. Quindi sì, le prestazioni sono l'accessibilità applicata, che è quindi l'esperienza dell'utente. E quell'esperienza utente potrebbe ridursi a "Qualcuno potrebbe anche sperimentare il tuo sito" punto e basta. Oppure potrebbe essere "E' stata un'esperienza deliziosa? Quando ho cliccato su un pulsante, ha risposto in modo tempestivo?”. Quindi sono d'accordo al 100% e penso che questo sia uno dei motivi per cui Google ci sta dando peso, è perché influisce sull'esperienza dell'utente e se qualcuno si fiderà dei risultati di ricerca, vogliamo provare a dare a quella persona un sito che non odieranno.

Drew: Ed è... tutto ciò a cui pensi, tutti i vantaggi a cui pensi, l'esperienza dell'utente, cose come un maggiore coinvolgimento, è decisamente vero, no? Non c'è niente che allontana l'utente da un sito più rapidamente di un'esperienza lenta. È così frustrante, vero? Utilizzando un sito in cui sai che forse la navigazione non è molto chiara e se fai clic su un link e pensi “È quello che voglio? Non è?" E solo il costo di fare quel clic, solo aspettare, e poi devi fare clic sul pulsante Indietro e poi quell'attesa, ed è solo... ti arrendi.

Harry: Sì, e ha senso. Se dovessi fare un salto al supermercato e vedi che è assolutamente pieno di gente, farai il minimo indispensabile. Non spenderai molti soldi lì, è come "Oh, ho solo bisogno di latte", dentro e fuori. Considerando che se è una bella esperienza, hai "Oh, beh, mentre sono qui vedrò se ... Oh, sì hanno questo ... Oh, lo cucinerò domani sera" o qualsiasi altra cosa. Penso che ancora, dopo tre decenni nel web, anche le persone che costruiscono per il web siano in difficoltà, perché è intangibile. Lottano per pensare davvero che ciò che ti infastidirebbe in un vero negozio ti infastidirebbe online, e lo fa, e le statistiche mostrano che è così.

Drew: Penso che nei primissimi giorni, stavo pensando alla fine degli anni '90, mostrando la mia età qui, quando costruivamo siti Web pensavamo molto alle prestazioni ma pensavamo alle prestazioni da un punto di vista che le connessioni che le persone erano l'uso era così lento. Stiamo parlando di dial-up, modem, linee telefoniche, modem 28K, 56K, e a un certo punto c'era una tendenza con lo stile delle immagini che ogni altra riga dell'immagine sarebbe stata cancellata con un colore solido per dare questo... se puoi immaginarlo come guardare attraverso una veneziana l'immagine. E lo abbiamo fatto perché ha aiutato con la compressione. Perché ogni altra riga l'algoritmo di compressione potrebbe-

Harry: Riduci in un solo puntatore.

Drew: Sì. E così hai ridotto significativamente le dimensioni dell'immagine pur essendo in grado di ottenere... Ed è diventato un elemento di design. Tutti lo stavano facendo. Penso che forse Jeffrey Zeldman sia stato uno dei primi ad aver aperto la strada a questo approccio. Ma quello a cui stavamo pensando era principalmente quanto velocemente avremmo potuto mettere le cose in ordine. Non per l'esperienza dell'utente, perché non stavamo pensando a... Voglio dire, immagino fosse l'esperienza dell'utente perché non volevamo che le persone lasciassero i nostri siti, essenzialmente. Ma stavamo pensando di non ottimizzare le cose in modo che fossero davvero veloci, ma di cercare di evitare che fossero molto lente, se questo ha un senso.

Harry: Sì, sì.

Drew: E poi, penso che quando velocità come le linee ADSL sono diventate più diffuse, abbiamo smesso di pensare in questi termini e abbiamo iniziato a non pensarci affatto. E ora siamo nella situazione in cui stiamo utilizzando dispositivi mobili e hanno connessioni limitate e forse CPU più lente e dobbiamo pensarci di nuovo, ma questa volta in termini di vantaggio. Oltre al lato dell'esperienza dell'utente, può avere reali vantaggi aziendali in termini di costi e capacità di realizzare profitti. Non è vero?

Harry: Sì, tremendamente. Voglio dire, non sono sicuro di come dirlo. Non mi tiro ai piedi qui, ma una cosa che cerco di sottolineare con i clienti è che la velocità del sito ti darà un vantaggio competitivo, ma è solo una cosa che potrebbe darti un vantaggio competitivo. Se hai un prodotto che nessuno vuole acquistare, non importa quanto sia veloce il tuo sito. E allo stesso modo, se qualcuno vuole davvero il sito Web più veloce del mondo, devi eliminare le tue immagini, eliminare il tuo CSS, eliminare il tuo JavaScript e quindi vedere quanti prodotti racconti, perché garantisco che la velocità del sito non era il fattore. Ma gli studi hanno dimostrato che ci sono enormi vantaggi nell'essere veloci, nell'ordine di milioni. Sto lavorando con un cliente mentre parliamo. Abbiamo calcolato per loro che se potevano renderizzare una determinata pagina un secondo più velocemente, o meglio il loro contenuto più grande per la pittura era un secondo più veloce, valeva 1,8 milioni all'anno, il che è... è un numero grande.

Drew: Questo quasi ti pagherebbe la quota.

Harry: Ehi! Sì, quasi. Ho detto loro “Guarda, dopo due anni sarà tutto ripagato. Sarai in pareggio”. Spero che. Ma sì, l'aspetto rivolto al cliente... scusa, l'aspetto rivolto al cliente se hai un sito E-Com, spenderanno più soldi. Se sei un editore, leggerà più di un articolo o visualizzerà più minuti di contenuto, o qualunque cosa tu faccia, è il tuo KPI che misuri. Potrebbe essere sul sito di Smashing, potrebbe essere che non siano rimbalzati, in realtà hanno fatto clic su qualche altro articolo perché l'abbiamo reso davvero facile e veloce. E poi i siti più veloci sono più economici da gestire. Se hai ordinato la tua strategia di memorizzazione nella cache, manterrai le persone lontane dai tuoi server. Se ottimizzi le tue risorse, tutto ciò che deve provenire dal tuo server peserà molto meno. Molto più economico da correre.

Harry: Il fatto è che arrivarci ha un costo. Penso che Scott Jehl abbia probabilmente detto uno dei più ... E l'ho sentito prima da lui, quindi presumo che l'abbia inventato, ma il detto è "È facile creare un sito Web veloce ma è difficile creare un sito Web veloce". Ed è così conciso. Perché il motivo per cui Web perf potrebbe essere spinto in basso nell'elenco delle cose da fare è perché potresti essere in grado di dire a un cliente "Se rendo il tuo sito un secondo più veloce, guadagnerai 1,8 milioni in più all'anno" oppure può essere "Se hai appena aggiunto Apple Pay al tuo checkout, guadagnerai cinque milioni in più". Quindi non si tratta solo di prestazioni web e non è il fattore decisivo, è una parte di una strategia molto più ampia, specialmente per E-Com online. Ma l'evidenza è che l'ho misurato in prima persona con i miei clienti al dettaglio, i miei clienti E-Com. Il caso è proprio lì, hai assolutamente ragione. È un vantaggio competitivo, ti farà guadagnare di più.

Drew: In passato, ancora una volta, sto tornando indietro nel tempo, ma persone come Steve Souders sono state alcune delle prime persone a iniziare davvero a scrivere e parlare di performance sul web. E persone come Steve fondamentalmente dicevano "Dimentica l'infrastruttura di back-end, dove tutti i guadagni da ottenere sono nel browser, nel front-end, è lì che succede tutto lentamente". È ancora così dopo 15 anni?

Harry: Sì, sì. Ha ripetuto il test tra allora e oggi, e il divario si era effettivamente allargato, quindi in realtà è più costoso sul filo. Ma c'è un contro a questo, che è che se hai prestazioni di back-end davvero pessime, se esci lentamente dal cancello, c'è solo così tanto che puoi recuperare sull'estremità anteriore. Ho un cliente al momento, il loro tempo per il primo byte è di 1,5 secondi. Pertanto, non possiamo mai renderizzare più velocemente di 1,5 secondi, quindi sarà un limite. Possiamo ancora recuperare il tempo sul front-end, ma se hai un tempo davvero, davvero brutto per il primo byte, hai rallentamenti del back-end, c'è un limite a quanto più velocemente potrebbero portarti i tuoi sforzi per le prestazioni del front-end. Ma assolutamente.

Harry: Questo è, tuttavia, cambiare perché... beh, no, non sta cambiando, immagino, sta peggiorando. Stiamo spingendo di più sul cliente. Era un caso di "Il tuo server è veloce come lo è, ma poi abbiamo un sacco di punti interrogativi". perché sento questo tutto il tempo “Tutti i nostri utenti girano su WiFi. Hanno tutti macchine desktop perché lavorano tutti dal nostro ufficio". Beh, no, ora lavorano tutti da casa. Non puoi scegliere. Quindi, è qui che arrivano tutti i punti interrogativi, che è dove si verificano i rallentamenti, dove non puoi davvero controllarlo. Dopodiché, il fatto che ora tendiamo a puntare di più sul cliente. Con ciò intendo, interi tempi di esecuzione sul client. Hai comunque spostato tutta la logica dell'applicazione da un server, quindi il tuo tempo per il primo byte dovrebbe essere molto, molto minimo. Dovrebbe trattarsi di inviare alcuni bundle da un CDM al mio... ma sei passato dall'essere in grado di specificare i tuoi server a sperare che qualcuno non abbia Netflix in esecuzione sulla stessa macchina su cui stanno cercando di visualizzare il tuo sito web .

Drew: È davvero un buon punto del modo in cui progettiamo i siti e penso che la migliore pratica tradizionale sia sempre stata che dovresti provare a soddisfare tutti i tipi di browser, tutti i tipi di velocità di connessione, tutti i tipi di dimensioni dello schermo, perché non Non so cosa si aspetta l'utente. E, come hai detto, hai questi scenari in cui le persone dicono "Oh no, sappiamo che tutti i nostri utenti si trovano sulla loro macchina desktop assegnata al lavoro, stanno eseguendo questo browser, è l'ultima versione, sono cablati nella LAN" ma poi le cose accadono. Uno dei grandi vantaggi dell'avere app Web è che possiamo fare cose come distribuire la nostra forza lavoro improvvisamente a casa loro e loro possono continuare a lavorare, ma questo è vero solo se la qualità dell'ingegneria è tale che qualcuno che sta girando sulla loro macchina di casa che potrebbe avere IE11 su di esso o altro, se la qualità del lavoro è lì, ciò significa effettivamente che il web realizza il suo potenziale essendo un mezzo veramente accessibile.

Drew: Come hai detto, c'è questa tendenza a spostare sempre più cose nel browser e, ovviamente, se il browser è lento, è lì che si verifica la lentezza. Devi chiederti “È una buona tendenza? Dovremmo farlo?" Ho un sito a cui penso particolarmente, ho notato che è reso quasi al 100% dal server. C'è pochissimo JavaScript ed è velocissimo. Ogni volta che ci vado penso "Oh, è veloce, chi l'ha scritto?" E poi mi rendo conto "Oh sì, sono stato io".

Harry: Questo perché sei su localhost, non c'è da stupirsi che sia veloce. È il tuo sito di sviluppo.

Drew: Quindi, il mio lavoro quotidiano, stiamo costruendo la nostra applicazione a pagina singola e spostando le cose dal server perché il server è il collo di bottiglia in quel caso. Puoi solo dire che è più performante essere nel browser? O più performante per essere sul server? Si tratta solo di misurare e prendere caso per caso?

Harry: Penso che tu debba essere molto, molto, molto consapevole del tuo contesto e… sinceramente penso che un errore sia… il narcisismo in cui le persone pensano “Oh, il mio blog merita di essere visualizzato nel browser di qualcuno. Il mio blog con una frequenza di rimbalzo dell'89% ha bisogno del proprio runtime nel browser, perché ho bisogno che le navigazioni successive siano veloci, voglio solo recuperare un... fondamentalmente una differenza di dati." Comunque nessuno sta cliccando sul tuo prossimo articolo, amico, non spingere un runtime giù per il tubo. Quindi devi essere molto consapevole del tuo contesto.

Harry: E so che... se Jeremy Keith sta ascoltando questo, probabilmente mi prenderà in giro, ma direi che c'è una differenza tra un sito Web e un'app Web e la definizione di ciò è molto, molto oscuro. Ma se hai un'applicazione di lettura e scrittura pesante, quindi qualcosa in cui stai inserendo dati, manipolando dati, ecc. Fondamentalmente il mio sito non è un'app web, è un sito web, è di sola lettura, che metterei fermamente nel campo del sito web. Qualcosa come il mio software di contabilità è un'app web, direi che è un'app web e sono pronto a subire un po' di costi di avvio, perché so che sarò lì per 20 minuti, un'ora, qualunque cosa. Quindi hai bisogno di un po' di contesto, e ancora, forse il narcisismo è un po' duro, ma devi avere un vero "Dobbiamo fare di questo giornale un'applicazione lato client?" No, non lo fai. No, non lo fai. La gente ha attivato il blocco degli annunci, alla gente non piacciono comunque i siti di giornali per pendolari. Probabilmente non leggeranno nemmeno l'articolo e ne parleranno su Facebook. Basta non creare qualcosa del genere come applicazione renderizzata dal client, non è adatto.

Harry: Quindi penso che ci sia sicuramente un punto in cui passare di più al cliente aiuterebbe, ed è allora che hai meno sensibilità a cambiare. Quindi qualsiasi tipo di com, ad esempio, sto facendo un audit per un momento per un sito che... penso sia un sito E-Com ma è al 100% sul client. Disabiliti JavaScript e non vedi nulla, solo un div id vuoto = "app". E-Com è... sei molto sensibile a qualsiasi problema. Il tuo flusso di pagamento è anche leggermente sbagliato, sono da qualche altra parte. È troppo lento, vado da qualche altra parte. Non hai il contesto in cui qualcuno è disposto a dormire in quell'app per un po'.

Harry: Photoshop. Apro Photoshop e sono abbastanza felice di sapere che ci vorranno 45 secondi di schermata iniziale perché rimarrò lì per ... praticamente i 45 secondi valgono i 45 minuti. Ed è così difficile da definire, motivo per cui faccio davvero fatica a convincere i clienti "Per favore, non farlo" perché non posso semplicemente dire "Per quanto tempo pensi che il tuo utente sarà lì". E puoi approssimarlo da... se la tua frequenza di rimbalzo è dell'89% non ottimizza per una seconda visualizzazione della pagina. Prima abbassa la frequenza di rimbalzo. Penso che ci sia sicuramente una divisione, ma quello che direi è che la maggior parte delle persone cade dalla parte sbagliata di quella linea. La maggior parte delle persone inserisce nel client cose che non dovrebbero esserci. CNN, ad esempio, non è possibile leggere un singolo titolo sul sito Web della CNN finché non viene avviata completamente un'applicazione JavaScript. L'unica cosa resa dal server è l'intestazione e il piè di pagina, che è l'unica cosa che non interessa alle persone.

Harry: E sento che è solo... non so come arriviamo a quel punto. Non sarà mai l'opzione migliore. Fornisci una pagina che è effettivamente inutile che poi deve dire "Fantastico, vado a prendere quella che sarebbe stata un'app Web ma la eseguiremo nel browser, quindi andrò a chiedere un titolo , allora puoi iniziare a... oh, te ne sei andato. Questo mi infastidisce davvero, davvero.

Harry: E non è colpa di nessuno, penso che sia l'infanzia di questo tipo di ecosistema JavaScript, il clamore che lo circonda, e inoltre, questo suonerà davvero duro ma... È fondamentalmente un sacco di ingenua implementazione. Certo, Facebook ha inventato React e qualsiasi cosa, funziona per loro. Nove volte su 10 non lavori su scala Facebook, 95 volte su 100 probabilmente non sei il più intelligente ingegneri di Facebook, ed è davvero, davvero crudele e suona orribile da dire, ma puoi solo ottenere... queste cose sono veloci per impostazione predefinita. È necessaria un'implementazione molto, molto elegante di queste cose per renderle corrette.

Harry: Stavo discutendo con il mio vecchio... era un ingegnere capo della squadra in cui ero 10 anni fa a Sky. Ne stavo parlando con lui l'altro giorno e ha dovuto lavorare molto duramente per rendere veloce un'app con rendering client, mentre per rendere veloce un'app con rendering server non è necessario fare nulla. Devi solo non farlo rallentare di nuovo. E mi sento come se ci fossero un sacco di occhiali colorati di rosa, ingenuità, marketing... Sembro così cupo, dobbiamo andare avanti prima che inizi davvero a perdere persone qui.

Drew: Pensi che abbiamo la tendenza, come settore, a concentrarci di più sull'esperienza degli sviluppatori che sull'esperienza dell'utente a volte?

Harry: Non nel complesso, ma penso che il problema si presenti in un punto che ti aspetteresti. Se guardi alla disparità... non so se l'hai visto, ma presumo che tu l'abbia fatto, sembri avere il dito sul polso, la disparità tra i dati dell'archivio HTTP su quali framework e Le librerie JavaScript sono utilizzate in natura rispetto allo stato del sondaggio JavaScript, se segui lo stato del sondaggio JavaScript direbbe "Oh sì, il 75% degli sviluppatori utilizza React" mentre meno del 5% dei siti utilizza React. Quindi, mi sento come, in massa, non penso che sia un problema, ma penso che nelle aree che te lo aspetteresti, la forte fedeltà a un framework per esempio, l'esperienza degli sviluppatori è... evangelizzata probabilmente prima dell'utente. Non credo che l'esperienza degli sviluppatori debba essere trascurata, voglio dire, tutto ha un costo di manutenzione. La tua auto. C'è stata una decisione quando è stato progettato che "Beh, se nascondiamo questa chiave, quella funzionalità, da una meccanica, ci vorrà molto più tempo per aggiustarla, quindi non facciamo cose del genere". Quindi ci deve essere un equilibrio tra ergonomia e usabilità, penso che sia importante. Penso che concentrarmi principalmente sull'esperienza degli sviluppatori sia solo sconcertante per me. Non ottimizzare per te, ottimizza per il tuo cliente, il tuo cliente ti paga non è il contrario.

Drew: Quindi la camera dell'eco online non è esattamente rappresentativa della realtà quando vedi tutti dire "Oh, dovresti usare questo, dovresti farlo", quindi in realtà è solo una piccola percentuale di persone.

Harry: Esatto, ed è una buona cosa, è rassicurante. La camera dell'eco... forse non è salutare avere quel tipo di monocultura, se così la si vuole chiamare. Ma anche, mi sento come... e l'ho visto in molto del mio lavoro, in molti sviluppatori... Come consulente, lavoro con molte aziende diverse. Molte persone stanno facendo un lavoro straordinario in WordPress. E WordPress alimenta il 24% del web. E sento che potrebbe essere abbastanza facile per uno sviluppatore del genere che lavora in qualcosa come WordPress o PHP sul backend, codice personalizzato, qualunque esso sia, sentirsi un po' come "Oh, immagino che tutti stiano usando React e noi non lo stiamo facendo ” ma in realtà no. Tutti parlano di React ma tu stai ancora seguendo il flusso, sei ancora con la maggioranza. È abbastanza rassicurante trovare la maggioranza silenziosa.

Drew: La tendenza verso i generatori di siti statici e quindi l'hosting di siti interamente su una CDN, una sorta di approccio JAMstack, immagino che quando parliamo di quei tipi di siti di tipo pubblicazione, piuttosto che di siti di tipo software, immagino che sia una tendenza davvero salutare , penseresti?

Harry: Lo adoro, assolutamente. Ricordi quando chiamavamo SSG "file lembo", giusto?

Drew: Sì.

Harry: Quindi, ho costruito CSS Wizardry su Jekyll quando Jekyll era chiamato un sito Web di file 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: Sì.

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: Incuteva rispetto ma era uno dei ragazzi, ci piaceva davvero molto. Ma era enorme in ogni dimensione. Ben più di un metro e ottanta, ma solo un ragazzone. Grande, grande, grande, grande uomo. E ci ha detto "Se dovessi progettare una porta, la progetteresti per la persona media?" E i cervelli di 15 anni stavano dicendo "Beh sì, se tutti hanno all'incirca 5'9 allora sì" Era tipo "Beh, immediatamente, Harry non può usare quella porta". Non progetti per la persona media, progetti per le estremità perché vuoi che sia utile alla maggior parte delle persone. Se hai progettato una sedia per la persona media, il signor Brocklesby non ci sarebbe andato bene. Quindi mi ha insegnato da un'età davvero, davvero, il design alle tue estremità.

Harry: E il punto in cui diventa davvero interessante in web perf è... Se immagini una scala e prendi la scala dal bot... Ok, ho appena capito che la mia metafora potrebbe... mi atterrò e potrai ridere di io dopo. Immagina una scala e la sollevi dai pioli inferiori. E queste sono le tue peggiori esperienze. Prendi il piolo inferiore della scala per sollevarlo. L'intera scala viene con esso, come una marea che sale fa galleggiare tutte le barche. Il motivo per cui la metafora non funziona è che se prendi una scala dal piolo più alto, anche tutto si solleva, è una scala. E la metafora non funziona nemmeno se la trasformo in una scala di corda, perché una scala di corda poi, sollevi il piolo inferiore e non succede nulla ma... il punto è che se puoi migliorare l'esperienza per il tuo 90° percentile, deve alzalo per il tuo 10° percentile, giusto?

Harry: Ed è per questo che dico ai clienti che mi diranno cose come "Oh beh, la maggior parte dei nostri utenti utilizza il 4G su iPhone", quindi va bene, ok, e iniziamo a testare il 3G su Android, come "No, no, la maggior parte dei nostri utenti sono iPhone” ok... questo significa che il tuo utente medio avrà un'esperienza migliore, ma chiunque non sia già nel 50° percentile viene semplicemente lasciato indietro. Quindi imposta il livello piuttosto alto per te stesso impostando le aspettative piuttosto basse.

Harry: Scusa, ho la pessima abitudine di dare risposte molto lunghe a domande brevi. Ma è stata una domanda fantastica e, per concludere, sono decisamente d'accordo con te al 100% sul fatto che vuoi guardare quella coda lunga, vuoi guardare quella... il tuo 80° percentile perché se prendi tutte le esperienze su il sito e guardi la mediana, e migliori la mediana, ciò significa che l'hai reso ancora migliore per le persone che erano già abbastanza soddisfatte. Il 50% delle persone che viene effettivamente ignorato non è l'approccio giusto. E sì, torna sempre al signor Brocklesby che mi dice "Non progettare per la persona media perché poi Harry non può usare la porta". Oh, per chiunque ascolti, sono alto 193 centimetri, quindi sono piuttosto allampanato, ecco di cosa si tratta.

Drew: E tutte quelle braccia e gambe.

Harry: Sì. Eccone anche un altro buono. La mia ragazza ha recentemente scoperto le impostazioni di accessibilità in iOS... quindi tutti hanno il telefono in modalità silenziosa, giusto? Nessuno in realtà ha un telefono che squilla davvero, tutti ce l'hanno in silenzio. Ha scoperto che "Oh sai, puoi impostarlo in modo che quando ricevi un messaggio, il flash lampeggi. E se tocchi due volte il retro del telefono, verrà eseguito uno screenshot". E queste sono impostazioni di accessibilità, progettate per quel 95° percentile. Eppure lei dice "Oh, questo è davvero utile".

Harry: Lo stesso con OXO Good Grips. OXO Good Grips, gli utensili da cucina. Ne ho un sacco in cucina. Sono stati progettati perché la moglie del fondatore soffriva di artrite e voleva realizzare utensili più comodi. Ha progettato per il 99° percentile, la maggior parte delle persone non ha l'artrite. Ma progettando per il 99° percentile, inavvertitamente, tutti gli altri pensano "Oh mio Dio, perché tutti i pelapatate non possono essere così comodi?" E mi sento come se fosse davvero, davvero... mi piace uno stato di benessere o un aneddoto che mi piace tirare fuori in questo tipo di scenari. Ma sì, se ottimizzi per loro... Beh, una marea in aumento fa galleggiare tutte le barche e questo quindi ottimizza la coda delle persone e catturerai molti clienti ancora più felici.

Drew: Hai la frusta manuale OXO Good Grips?

Harry: Non lo faccio. Io no, va bene?

Drew: Guardaci dentro. È così buono.

Harry: Ho l'affettatrice per mandolino OXO Good Grips che mi ha tolto la punta del dito la scorsa settimana.

Drew: Sì, non mi avvicinerò a uno di quelli.

Harry: Sì, è colpa mia stupida.

Drew: Un altro esempio tratto dalla mia esperienza con il catering per quella coda lunga è che, nel progetto su cui sto lavorando in questo momento, quella coda lunga è proprio alla fine, hai persone con le prestazioni più lente, ma se si scopre chi sono quei clienti, sono i clienti più preziosi per l'azienda-

Harry: Va bene.

Drew: … perché sono le organizzazioni più grandi con la maggior quantità di dati.

Harry: Giusto.

Drew: E quindi stanno colpendo colli di bottiglia perché hanno così tanti dati da visualizzare su una pagina e quelle pagine devono essere rifattorizzate un po' per aiutare quel caso d'uso. Quindi stanno vivendo l'esperienza più lenta e, quando si arriva al punto, stanno pagando di più e facendo molta più differenza di tutte le persone che hanno un'esperienza davvero veloce perché sono utenti gratuiti con un piccola quantità di dati e tutto funziona bene ed è veloce.

Harry: Questa è una dimensione affascinante, vero? In effetti, ho avuto una situazione simile... non avevo neanche lontanamente l'impatto sul business di quello che hai appena descritto, ma ho lavorato con un cliente un paio di anni fa e il loro CEO si è messo in contatto perché il loro sito era lento. Come, lento, lento, lento. Anche un bravo ragazzo, è solo un bravo ragazzo con i piedi per terra, ma ha un mentore, come un vero ricco. E ha l'ultimo iPhone, se lo può permettere. È un multimilionario, trascorre molto del suo tempo volando tra l'Australia, da dove viene, e l'Estonia, dove ora risiede.

Harry: E sta volando in prima classe, ovviamente. Ma significa la maggior parte del suo tempo sul suo bello e brillante iPhone 12 Pro Max, qualunque cosa, qualunque cosa, sia tramite il WiFi dell'aereo, il che è terribile. Ed è stata questa giustapposizione davvero sorprendente in cui è proprietario del sito e lo usa molto, è un sito che usa. E lo stava spingendo... Voglio dire facilmente che il loro cliente più ricco era il loro CEO. Ed è in questa posizione stranamente privilegiata in cui ha una connessione peggiore di Joe Public perché è da qualche parte sopra Singapore su un volo Quantas a farsi versare champagne sul collo e sta lottando. E questa è stata un'intuizione davvero affascinante che... Oh sì, perché hai il tuo 95° percentile può praticamente andare in entrambe le direzioni.

Drew: Sì, è quando inizi a ottimizzare per l'utilizzo di un sito con un bicchiere di champagne in mano che pensi "Forse stiamo iniziando a perdere un po' la strada".

Harry: Sì, esattamente.

Drew: Abbiamo parlato un po' della misurazione delle prestazioni e, secondo la mia esperienza con il lavoro sulle prestazioni, è davvero essenziale misurare tutto. Ad esempio, A in modo da poter identificare dove si trovano i problemi, ma B in modo che quando inizi effettivamente ad affrontare qualcosa puoi dire se stai facendo un diverso e quanta differenza stai facendo. Come dovremmo misurare le prestazioni dei nostri siti? Quali strumenti possiamo utilizzare e da dove iniziare?

Harry: Oh amico, un'altra grande domanda. Quindi c'è una serie di risposte a seconda di quanto tempo, risorse, inclinazione c'è verso la fissazione della velocità del sito. Quindi quello che proverò a fare con il cliente è... Certe metriche standard sono davvero buone. Tempo di caricamento, non importa più. È molto, molto, molto... Voglio dire, è un buon proxy se il tuo tempo di caricamento è di 120 secondi. Immagino che tu non abbia un sito Web molto veloce, ma è troppo oscuro e non è rivolto ai clienti. In realtà penso che i vitals siano davvero un buon passo nella giusta direzione perché misurano l'esperienza dell'utente ma si basano su input tecnici. Il più grande Contentful Paint è una cosa davvero piacevole da visualizzare, ma le cose tecniche che ci sono sbloccano il tuo percorso critico, assicurati che le immagini dell'eroe arrivino rapidamente e assicurati che la tua strategia di font web sia decente. C'è un sottofondo tecnico in queste metriche. Quelli sono davvero buoni fuori dallo scaffale.

Harry: Tuttavia, se i clienti hanno tempo, di solito è il momento, perché vuoi acquisire i dati ma hai bisogno di tempo per acquisire effettivamente i dati. Quindi quello che cerco di fare con i clienti è dire “Guarda, non possiamo lavorare insieme per i prossimi tre mesi perché sono al completo. Quindi, quello che possiamo fare è configurarti rapidamente con una prova gratuita di Speedcurve, impostare alcune metriche personalizzate", quindi ciò significa che per un cliente editore, un giornale, misurerei "Quanto velocemente è stato il titolo del articolo reso? Con quale rapidità è stata renderizzata l'immagine principale per l'articolo?" Per un cliente di e-commerce voglio misurare, perché ovviamente stai misurando cose come avviare il rendering in modo passivo. Non appena inizi a utilizzare qualsiasi software di monitoraggio delle prestazioni, acquisisci gratuitamente le metriche delle prestazioni effettive. Quindi il tuo primo dipinto ricco di contenuti, il più grande contenuto, ecc. Quello che voglio davvero catturare sono le cose che contano per loro come azienda.

Harry: Quindi, lavorando con un client E-Com nel momento in cui siamo in grado di correlare... Più veloce è il tuo inizio di rendering, qual è la probabilità di un'aggiunta al carrello. Se riesci a mostrare loro un prodotto prima, è più probabile che lo acquistino. E questo è un grande sforzo da impostare, questo è un po' l'obiettivo di allungamento per i clienti che sono davvero ambiziosi, ma qualsiasi cosa tu voglia veramente misurare, perché come ho detto, non vuoi davvero misurare ciò che è il tuo più grande Contentful Paint è, vuoi misurare le tue entrate ed è stato influenzato da Large Contentful Paint? Quindi l'obiettivo finale, l'ultima cosa, sarebbe qualsiasi cosa tu vedresti come un KPI per quell'azienda. Potrebbe essere, sui giornali, fino a che punto qualcuno ha fatto scorrere l'articolo? E questo è correlato in qualche modo al primo ritardo di input? Le persone hanno letto più articoli se il CLS era inferiore? Ma prima di iniziare a creare metriche personalizzate, onestamente penso che web vitals sia un ottimo punto di partenza ed è stato anche abbastanza ben normalizzato. Diventa un... non so quale sia la parola. Il minimo comune denominatore immagino, in cui tutti nel settore ora possono discutere delle prestazioni su questa parità di condizioni.

Harry: Un problema che ho, e in realtà ho bisogno di organizzare un incontro con il team di vitals, è anche che penso davvero che Lighthouse sia fantastico, ma CLS è il 33% dei vitali web. Hai LCP, FID, CLS. CLS è il 33% dei tuoi parametri vitali. Vitals è ciò che normalmente va davanti al tuo team di marketing, al tuo dipartimento di analisi, perché compare nella console di ricerca, è menzionato nel contesto delle pagine dei risultati di ricerca, mentre vitals è interessato, hai un peso elevato, 33%, un terzo di vitali è CLS, è solo il 5% del nostro punteggio Lighthouse. Quindi quello che otterrai sono sviluppatori che costruiscono attorno a Lighthouse, perché può essere integrato negli strumenti, è una metrica di laboratorio. Vitals è dati sul campo, è rum.

Harry: Quindi hai questa enorme disconnessione in cui hai il tuo team di marketing che dice "CLS è davvero pessimo" e gli sviluppatori stanno pensando "Beh, è ​​il 5% del punteggio di Lighthouse che DevTools mi sta dando, è il 5% del punteggio che Lighthouse CLI ci fornisce in CircleCI” o qualunque cosa tu stia usando, ma per il team di marketing è il 33% di ciò che gli interessa. Quindi il problema è che c'è un po' di disconnessione perché penso che Lighthouse sia molto prezioso, ma non so come riescano a conciliare quella differenza abbastanza enorme in cui nei parametri vitali, CLS è il 33% del tuo punteggio... beh, non punteggio perché tu in realtà non ne ho uno, e Lighthouse è solo il 5%, e sono cose del genere che devono ancora essere appianate prima di poter rendere questa discussione senza soluzione di continuità.

Harry: Ma, ancora, risposta lunga a una domanda breve. Vitals è davvero buono. LCP è una buona metrica dell'esperienza utente che può essere ridotta a soluzioni tecniche, lo stesso con CLS. Quindi penso che sia davvero un buon punto di partenza. Oltre a ciò, sono metriche personalizzate. Quello a cui cerco di convincere i miei clienti è un punto in cui a loro non importa quanto sia veloce il loro sito, si preoccupano solo di guadagnare di più da ieri, e se è così è perché funzionava velocemente? Se ha fatto meno è perché andava più lentamente? Non voglio che inseguano un mistico LCP di due secondi, voglio che inseguano l'LCP ottimale. E se questo si rivela effettivamente essere più lento di quello che pensi, allora qualunque cosa, va bene.

Drew: Quindi, per lo sviluppatore web che è solo interessato a... non hanno budget da spendere per strumenti come Speedcurve e cose simili, possono ovviamente eseguire strumenti come Lighthouse solo all'interno del proprio browser, per ottenere una buona misurazione... Sono cose come Google Analisi utili per quel livello?

Harry: Lo sono e possono essere resi più utili. Analytics, ormai da molti anni, ha acquisito informazioni rudimentali sulle prestazioni. E questo sarà il tempo DNS, TCP e TLS, il tempo al primo byte, il tempo di download della pagina, che è un proxy... beh, qualunque cosa, solo il tempo di download della pagina e il tempo di caricamento. Quindi metriche abbastanza goffe. Ma è un buon punto di partenza e normalmente ogni progetto che inizio con un cliente, se non ha New Relic o Speedcurve o altro, dirò semplicemente "Bene, fammi dare un'occhiata alle tue analisi" perché posso almeno proxy la situazione da lì. E non sarà mai neanche lontanamente buono come qualcosa come Speedcurve o New Relic o Dynatrace o altro. Puoi inviare metriche personalizzate davvero, davvero, davvero facilmente all'analisi. Se qualcuno che ascolta vuole poter inviare... il mio sito per esempio. Ho metriche come "Quanto velocemente riesci a leggere l'intestazione di uno dei miei articoli? A che punto è stata renderizzata l'immagine della pagina Informazioni? A che punto è arrivata la call to action che ti implora di assumermi? Dopo quanto tempo viene visualizzato sullo schermo?" Davvero banale acquisire questi dati e quasi altrettanto banale inviarli agli analytics. Quindi, se qualcuno vuole visualizzare la fonte sul mio sito, scorrere fino al tag body di chiusura e trovare lo snippet di analisi, vedrai quanto è facile per me acquisire dati personalizzati e inviarli all'analisi. E, nell'interfaccia utente di analisi, non devi fare nulla. Normalmente dovresti impostare rapporti personalizzati ed estrarre i dati e renderli presentabili. Questi sono un cittadino di prima classe in Google Analytics. Quindi, nel momento in cui inizi ad acquisire analisi personalizzate, c'è un'intera sezione della dashboard dedicata ad essa. Non c'è nessuna configurazione, nessun lavoro pesante in GA stesso, quindi è davvero banale e, se i clienti hanno un budget reale o forse voglio mostrare loro il potere del monitoraggio personalizzato, non voglio dire "Oh sì, lo prometto andrà davvero bene, posso avere solo 24.000 dollari per Speedcurve?" Posso iniziare dicendo semplicemente “Guarda, questo è rudimentale. Vediamo le possibilità qui, ora possiamo forse convincerti a passare a qualcosa come Speedcurve.

Drew: Ho spesso scoperto che il mio istinto su quanto dovrebbe essere veloce qualcosa, o quale impatto dovrebbe avere un cambiamento, può essere sbagliato. Farò un cambiamento e penserò di rendere le cose più veloci e poi lo misuro e in realtà ho rallentato le cose. Sono solo io che sono spazzatura a web perf?

Harry: Per niente. Ho un esempio davvero pertinente di questo. Preload... una rapida introduzione per chiunque non abbia sentito parlare di preload, il caricamento di determinate risorse sul Web è intrinsecamente molto lento e i due candidati principali qui sono le immagini di sfondo nei CSS e i caratteri Web, perché prima di poter scaricare un'immagine di sfondo, devi per scaricare l'HTML, che quindi scarica il CSS, e quindi il CSS dice "Oh, questo div sulla home page ha bisogno di questa immagine di sfondo". Quindi è intrinsecamente molto lento perché hai quell'intero pezzo di tempo CSS nel mezzo. Con il precaricamento, puoi inserire una riga in HTML nel tag head che dice "Ehi, non lo sai ancora ma, fidati, avrai bisogno di questa immagine molto, molto, molto presto". Quindi puoi inserire un precaricamento nell'HTML che attiva preventivamente questo download. Quando il CSS ha bisogno dell'immagine di sfondo, è come "Oh fantastico, ce l'abbiamo già, è veloce". E questo è pubblicizzato come questo web perf Messiah ... Ecco la cosa, e te lo prometto, l'ho twittato la scorsa settimana e da allora ho avuto ragione due volte. La gente sente parlare del precaricamento e delle promesse che offre, e inoltre è fortemente spinto da Lighthouse, in teoria rende il tuo sito più veloce. Le persone si sposano così tanto all'idea del precarico che anche quando posso provare che non funziona, non lo rimuoveranno più. Perché "No, ma ha detto Lighthouse". Questa è una di quelle cose in cui la teoria è valida. Se devi aspettare il tuo font web, invece di scaricarlo prima, vedrai le cose più velocemente. Il problema è che, quando pensi a come funziona effettivamente il Web, a qualsiasi pagina che visiti per la prima volta, a qualsiasi dominio nuovo di zecca che raggiungi, hai una quantità limitata di larghezza di banda e il browser spende quella larghezza di banda in modo molto intelligente. Esaminerà il tuo codice HTML molto rapidamente e creerà una lista della spesa. La cosa più importante è CSS, poi è questo jQuery, poi è questo... e poi le prossime cose sono queste, queste e queste meno prioritarie. Non appena inizi a caricare il tuo HTML con i precaricati, dici al browser "No, no, no, questa non è più la tua lista della spesa, amico, questa è la mia. Devi andare a prendere questi”. Quella quantità finita di larghezza di banda è ancora limitata ma non viene spesa per più risorse, quindi tutto diventa leggermente più lento. E ho dovuto fischiare questo due volte nell'ultima settimana, e ancora la gente dice "Sì, ma no, è perché si sta scaricando prima". No, è stato richiesto prima, ma sta rubando larghezza di banda dal tuo CSS. Puoi letteralmente vedere che i tuoi font web stanno rubando larghezza di banda dal tuo CSS. Quindi è una di quelle cose in cui devi, devi, devi seguire i numeri. L'ho fatto prima su un cliente su larga scala. Se stai ascoltando questo, hai sentito parlare di questo client e ho insistito sul fatto che "No, no, i tuoi tag sono nell'ordine sbagliato perché è così che dovrebbe essere e devi averli in questo l'ordine perché teoricamente indichi in quello…” Anche in quello che ero per il cliente sapevo che mi stavo preparando per uno stupido. A causa del modo in cui funzionano i browser, deve essere più veloce. Quindi sto facendo lo stratagemma, questo cambiamento... a molti milioni di persone, ed è diventato più lento. È diventato più lento. E io seduto lì, insistendo con indignazione "No ma, i browser funzionano così" è inutile perché non funziona. E l'abbiamo ripristinato e io ero tipo "Scusa! Ti fatturerò ancora per quello!” Quindi non sei affatto tu.

Drew: Segui questi numeri.

Harry: Sì, esattamente. "In realtà devo farti pagare di più, perché ho passato del tempo a ripristinarlo, mi ci è voluto più tempo." Ma sì, hai assolutamente ragione, non sei tu, è una di quelle cose in cui... l'ho fatto un sacco di volte su scala molto più piccola, dove sarò tipo "Beh, in teoria dovrebbe funzionare" e non 'T. Devi solo seguire cosa succede nel mondo reale. Ecco perché quel monitoraggio è davvero importante.

Drew: Man mano che il panorama cambia e la tecnologia si sviluppa, Google lancia nuove tecnologie che ci aiutano a rendere le cose più veloci, c'è un buon modo per stare al passo con i cambiamenti? Ci sono risorse che dovremmo considerare per mantenere aggiornate le nostre competenze quando si tratta di prestazioni web?

Harry: Per affrontare rapidamente l'intero "creare Google"... so che è un po' ironico, ma mi concentrerò su questo. Immagino che verso l'inizio, scommetto sul browser. Cose come AMP, ad esempio, nella migliore delle ipotesi sono una soluzione a posteriori. Non c'è sostituto per la creazione di un sito veloce e nel momento in cui inizi a utilizzare cose come AMP, devi attenerti a quegli standard non standard, la misericordia del team AMP che cambia idea. Ho avuto un cliente che ha speso una fortuna per la licenza di un font da un provider di font AMP autorizzato, poi a un certo punto, AMP ha deciso "Oh, in realtà no, quel font fornito, ora li elencheremo in blocco" Quindi avevo un cliente che ha investito molto in AMP e in questo fornitore di font e ha dovuto scegliere "Bene, annulliamo tutto il lavoro AMP o sprechiamo questo numero molto grande di un anno sul font web" bla, bla, bla. Quindi sarei molto diffidente nei confronti di chiunque... Sono un esperto di sviluppatori Google ma non conosco nessun ordine di bavaglio... Posso essere critico, e direi... evitare cose che vengono salutate come una taglia unica -soluzione adatta a tutti, cose come AMP.

Harry: E per scaricare su qualcun altro per un secondo, Cloudflare ha una cosa chiamata Rocket Loader, che è in stile AMP nel suo sforzo. È progettato come "Oh, accendi questa cosa sulla tua CDN, renderà il tuo sito più veloce". E in realtà è solo un sostituto per costruire correttamente il tuo sito in primo luogo. Quindi... per affrontare quell'aspetto, cerca di rimanere il più indipendente possibile, conosci come funzionano i browser, il che significa immediatamente che Chrome è monocultura, sei tornato in grembo a Google, ma sai come funzionano i browser, attieniti ad alcune ideologie fondamentali. Quando stai costruendo un sito, guarda la pagina. Che sia in Figma, o in Sketch, o ovunque sia, guarda il design e dì "Beh, questo è ciò che un utente vuole vedere per primo, quindi non metterò nulla in questo modo. Non caricherò pigramente questa immagine principale perché è stupido, perché dovrei farlo?" Quindi pensa solo a "Cosa vorresti che fosse il primo utente?" Su un sito E-Com, sarà quell'immagine del prodotto, probabilmente nav allo stesso tempo, ma le recensioni del prodotto, le domande e le risposte del prodotto, lo caricano pigramente. Mettilo dietro JavaScript.

Harry: Alcuni metodi fondamentali di lavoro che ti saranno utili, indipendentemente dalla tecnologia su cui stai leggendo, ovvero "Dai la priorità a ciò che il tuo cliente dà la priorità". Fare più lavoro su questo sarebbe più veloce, quindi non mettere le cose in mezzo a quello, ma poi cose più tattiche di cui le persone devono essere consapevoli, tenersi al passo... e ancora, tornare direttamente a Google, ma web.dev si sta rivelando una risorsa fenomenale per informazioni indipendenti dal framework e dallo stack... Quindi, se vuoi conoscere i parametri vitali, vuoi conoscere le PWA, quindi web.dev è davvero fantastico.

Harry: In realtà ci sono pochissime pubblicazioni incentrate sulla performance. L'e-mail di Calibre è, penso che la sua e-mail perf quindicinale sia semplicemente fenomenale, è davvero un buon riassunto. Tieni d'occhio la piattaforma web in generale, quindi c'è il Performance Working Group, ha un sacco di cose sulle proposte di GitHub. Ancora una volta, torniamo a Google, ma nessuno conosce questo sito Web e il suo fenomenale: chromestatus.com. Ti dice esattamente su cosa sta lavorando Chrome, quali sono i segnali provenienti da altri browser, quindi se vuoi vedere qual è il lavoro sui suggerimenti prioritari, puoi andare e ottenere collegamenti a tutti i bug tracker pertinenti. Chrome Status ti mostra le pietre miliari per ogni... "Questo è in uscita in MAT8, questo è stato rilasciato nel '67" o qualsiasi altra cosa, questa è davvero una buona cosa per approfondimenti piuttosto tecnici.

Harry: Ma continuo a tornare su questa cosa, e so che probabilmente suono come "Il vecchio grida a Cloud" ma attieniti alle basi, quasi ogni singola sterlina o dollaro, euro, che abbia mai guadagnato, ha insegnato ai clienti che "Sai che il browser lo fa già, giusto" o "Sai che non potrebbe essere più veloce" e questo suona davvero giusto da parte mia... Non ho mai guadagnato un centesimo dalla vendita di tecnologia extra. Ogni soldo che guadagno riguarda la rimozione, la sottrazione. Se ti ritrovi ad aggiungere cose per rendere il tuo sito più veloce, sei nella direzione sbagliata.

Harry: Caso in questione, non nominerò affatto... la grande società pubblicitaria/motore di ricerca/browser, non le nominerò e non nominerò il framework JavaScript, ma attualmente sono in discussioni con un framework JavaScript molto, molto grande e molto popolare sulla rimozione di qualcosa che sta danneggiando attivamente o, facoltativamente, sulla rimozione di qualcosa che danneggerebbe le prestazioni di un numero enorme di siti Web. E loro dicevano "Oh, stiamo andando avanti..." qualcuno di questa grande azienda, perché ha fatto delle ricerche... ed è come "Abbiamo bisogno di un'opzione per rimuovere questa cosa perché puoi vedere qui, e qui, e qui sta rendendo questo sito più lento. E la loro soluzione era aggiungere altro, come "Oh, ma se fai anche questo, puoi evitare quello" ed è come "No, no, aggiungere altro per rendere un sito più veloce deve essere la soluzione sbagliata. Sicuramente puoi vedere che stai andando nella direzione sbagliata se ci vuole più codice per finire con un sito più veloce.

Harry: Perché è stato veloce all'inizio e tutto ciò che aggiungi è ciò che lo rende più lento. E l'idea di aggiungere altro per renderlo più veloce, anche se... potrebbe manifestarsi in un sito Web più veloce, è nel modo sbagliato. È una corsa al ribasso. Scusa, mi sto davvero innervosendo, puoi dire che non ho inveito per un po'. Quindi questa è l'altra cosa, se ti ritrovi ad aggiungere funzionalità per rendere un sito più veloce, probabilmente stai andando nella direzione sbagliata, è molto più efficace renderlo più veloce rimuovendo le cose che aggiungerle.

Drew: Hai messo insieme un video corso intitolato "Tutto ciò che ho fatto per rendere veloce la magia CSS".

Harry: Sì!

Drew: È un po' diverso dai tradizionali corsi di video online, vero?

Harry: Lo è. Sarò onesto, in parte è... non voglio dire pigrizia da parte mia, ma non volevo progettare un curriculum che doveva essere molto rigido e portarti da zero a eroe perché il tempo necessario per farlo è enorme e il tempo non sapevo se l'avrei fatto. Quindi quello che volevo era avere materiale pronto per l'uso, solo proiettarmi sullo schermo mentre lo parlavo in modo che non iniziasse con "Ecco un browser ed ecco come funziona", quindi devi essere almeno consapevole di fondamenti di web perf, ma sono hack e suggerimenti per professionisti ed esempi di vita reale.

Harry: E poiché non avevo bisogno di fare un curriculum completo, sono stato in grado di abbassare il prezzo. Quindi non è un grande corso di 10 ore che ti porterà da zero a eroe, è entrare e uscire come meglio credi. Fondamentalmente è solo guardare il mio sito che è un eccellente terreno di gioco per cose che sono instabili o... è molto basso per me sperimentare lì. Quindi ho appena fatto una serie di video. È stato molto divertente da registrare. Ho solo demolito il mio sito e ho parlato di "Beh, è ​​così che funziona ed ecco come potresti usarlo".

Drew: Penso che sia davvero fantastico il modo in cui è suddiviso per risolvere diversi problemi. Se voglio saperne di più sull'ottimizzazione delle immagini o altro, posso pensare "Bene, cosa ha da dire il mio amico Harry a riguardo?", immergiti nel video sulle immagini e parto. È davvero accessibile in questo modo, non devi passare ore e ore di cose, puoi semplicemente andare al pezzo che vuoi e imparare ciò che devi imparare e poi uscire.

Harry: Penso di aver cercato di mantenerlo di più... Il vantaggio di non fare un curriculum rigido è che non devi prima guardare un certo video, non c'è un'introduzione, è solo "Vai a guardarti intorno e vedi cosa trovi interessante" il che significava che qualcuno che soffre di problemi di LTP è come "Oh beh, devo tuffarmi in questa cartella qui" o se soffre di problemi con CSS possono immergersi in quella cartella. Ovviamente non ho statistiche, ma immagino che ci sia un alto tasso di abbandono sui corsi, semplicemente perché devi arrancare attraverso tre ore di introduzione nel caso ti perdi qualcosa, ed è come "Oh, sai una cosa, non posso continua a farlo ogni giorno” e le persone potrebbero semplicemente abbandonare molti corsi. Quindi il mio pensiero era solo tuffarsi, non è necessario che tu abbia visto le tre ore precedenti, puoi semplicemente andare a trovare quello che vuoi. E il feedback è stato davvero, davvero... In effetti quello che farò è che non esiste ancora, ma lo farò subito dopo la chiamata, chiunque utilizzi il codice sconto SMASHING15, avrà il 15% di sconto di esso.

Drew: Quindi è quasi come se avessi ottimizzato le prestazioni del corso stesso, perché puoi semplicemente andare direttamente al bit che desideri e non devi fare tutte le negoziazioni e-

Harry: Sì, non intenzionale, ma me ne prenderò il merito.

Drew: Allora, ho imparato tutto sulle prestazioni web, cosa hai imparato ultimamente, Harry?

Harry: Roba tecnica... non proprio. Ho molto nella mia lista "da imparare", quindi QUIC, tipo di cose H3 mi piacerebbe avere un po' più di conoscenza pratica di questo, ma ho scritto un e-book durante il primo blocco nel Regno Unito, quindi ho imparato come creare e-book è stato molto divertente perché sono solo HTML e CSS e so come aggirare il problema, quindi è stato molto divertente. Ho imparato l'editing video molto rudimentale per il corso, e quello che mi è piaciuto di questi non è un lavoro concettuale. Ovviamente, imparando un linguaggio di programmazione, devi lottare con i concetti, mentre l'apprendimento di un e-book era solo un flusso di lavoro e... cose su cui non avevo mai armeggiato prima, quindi è stato interessante imparare ma non ha richiesto un cambio di carriera , quindi è stato molto carino.

Harry: E poi, cose non tecniche... guido molte bici, cado da molte bici... e poiché non viaggio affatto dallo scorso marzo, quasi un anno ormai, ho fatto molte di più andare in bicicletta e concentrarsi molto di più su... migliorarlo. Quindi ho fatto un sacco di ricerche sulla potenza in uscita e sulle soglie funzionali, al momento sto facendo un programma di allenamento, gambe così costantemente e costantemente sfinite, ma sto imparando molto sulla fisiologia del ciclismo. Non so perché perché non ho intenzione di farne altro che continuare a guidare. È stato davvero affascinante. Sento di essere stato molto fortunato durante i blocchi, al plurale, ma sono riuscito a rimanere attivo. Molte persone perderanno cose semplici come il tragitto giornaliero in ufficio, una buona occasione per sgranchirsi le gambe. Nel Regno Unito, come saprai, il ciclismo è stato molto difeso, quindi ho armeggiato molto di più per imparare di più sull'andare in bicicletta da un aspetto più fisiologico, il che significa... non so, sono solo un nerd qualcos'altro per cambiare.

Drew: Forse non c'è molta differenza tra l'ottimizzazione delle prestazioni sul Web e l'ottimizzazione delle prestazioni nel ciclismo, sono tutti guadagni marginali, giusto?

Harry: Sì, esattamente. E la quantità di grafici che ho guardato sulla bici... ho i dati di potenza dalla bici, esco a fare un giro e torno come "Oh se avessi altri cinque watt qui ma poi ne risparmierò 10 watt lì, potrei fare questo, questo e questo il più veloce di sempre” e... sono stato un enorme giacca a vento a riguardo. Ma sì, hai ragione. Sai una cosa, penso che tu abbia trovato qualcosa di veramente interessante lì. Penso che questo genere di cose sia un buon sport/passatempo per qualcuno che è un po' ossessivo, a cui piace inseguire i numeri. Ci sono cose su, voglio dire che lo saprai ma, Strava, hai i tuoi KOM. Ne ho insaccati 19 l'anno scorso, il che è, per me, una quantità fenomenale. Ed è quasi tutto dall'ossessione dei dati disponibili e dal guardare "Questo ragazzo che sto cercando di battere, stava facendo 700 watt a questo punto, se potessi arrivare fino a 1000 e poi smetterla" e bla, bla, bla ... è essere ossessivo. nerd. Ma hai ragione, immagino sia un genere di cose simile, vero? 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: Sì. 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.