Eseguire test sintetici delle Web Performance con webpagetest.org
•Download as PPTX, PDF•
0 likes•966 views
Queste slide sono dal talk che ho fatto al Turin Web Performance Group Meetup il 27 settembre 2016, tenutosi presso Login Coworking di Via Pietro Micca 12 a Torino. Prima di spiegare come si usava WebPageTest.org, ci tenevo a parlare un po’ di cultura generale e dei concetti base delle web performance, oltre anche ad alcuni temi fondamentali e le loro differenze. La versione con le note: https://goo.gl/7KlGLR
Recommended
Recommended
More Related Content
Similar to Eseguire test sintetici delle Web Performance con webpagetest.org
Similar to Eseguire test sintetici delle Web Performance con webpagetest.org (20)
Eseguire test sintetici delle Web Performance con webpagetest.org
- 1. @sgelob | www.olegs.be Eseguire test sintetici delle Web Performance con WebPageTest.org Olegs Belousovs | Web Performance & UX Turin Web Performance Group – 27 settembre 2016
- 2. @sgelob | www.olegs.be Come un browser fa il rendering dei contenuti Designing for Performance di Lara Callender Hogan | http://bit.ly/2ddWpx5
- 3. @sgelob | www.olegs.be Come un browser fa il rendering dei contenuti Analisi della performance del percorso di rendering critico | http://bit.ly/1pgxuec
- 4. @sgelob | www.olegs.be Ottimizzazione del percorso di rendering critico Le performance percepite sono la vera velocità e quella che un utente reale percepisce durante la visita di un sito web. Non importa tanto il tempo che ci mettono i vostri siti web a caricarsi in totale, quanto la velocità con la quale i vostri visitatori iniziano a vedere i contenuti sullo schermo e possono cominciare a interagire. Se la prima cosa che un utente vede per i primi secondi è una pagina bianca, l’esperienza utente sarà pessima e alcune persone potrebbero pensare che non sta succedendo nulla o che il sito non funziona e quindi abbandonarlo.
- 5. @sgelob | www.olegs.be Differenza tra Synthetic Testing e RUM Synthetic Testing è un controllo simulato dello stato di salute del vostro sito web. Permette di misurare una serie di metriche come response time, load time, numero di risorse che compongono una pagina e le dimensioni, tutto questo simulando diversi tipi di connessioni (3G, 4G, ADSL, fibra etc…). Potete testare anche un sito web in produzione, una volta che va online. RUM sta per real user measurement ed è la pratica per misurare l’esperienza degli utenti reali, mentre navigano attraverso un sito web. Gli esseri umani hanno molte differenze dalle macchine e queste differenze sono ciò che rende RUM diverso dal testing e monitoraggio sintetico. Con RUM potete monitorare come vanno le performance nel tempo, gli ambienti dei vostri utenti reali, come si comportano gli script di terze parti, etc…
- 6. @sgelob | www.olegs.be Differenza tra PageSpeed Insights e WebPageTest.org PageSpeed Insights di Google vi mostra solo un numero e quindi una metrica vanitosa che non vi dice nulla sull’esperienza dell’utente reale. Spesso leggo online «Come faccio ad avere 100 su 100 su PageSpeed?» o cose simili… Con WebPageTest.org, riusciamo a capire meglio come una persona sente la velocità del nostro sito web in diverse condizioni di connessione e utilizzando vari browser, attraverso gli strumenti come Waterfall, Filmstrip e Video.
- 7. @sgelob | www.olegs.be Cos’è WebPageTest.org Fonte: www.webpagetest.org/about WebPageTest è un progetto open source che è principalmente sviluppato e supportato da Google come parte dei loro sforzi per rendere il web più veloce. WebPageTest è uno strumento che è stato originariamente sviluppato da AOL per uso interno ed era stato open sourced nel 2008 sotto licenza BSD. La piattaforma è in fase di sviluppo attivo su GitHub ed è anche disponibile per il download, se desiderate installare un’istanza privata. La versione online su www.webpagetest.org è gestita per il beneficio della comunità di Web Performance, con diverse aziende e gli individui che forniscono le infrastrutture di test in tutto il mondo.
- 8. @sgelob | www.olegs.be Synthetic Testing con WebPageTest.org Prima dovete misurare le prestazioni attuali del vostro sito, individuare i vari problemi che lo rendono lento e solo dopo pensare alle ottimizzazioni da fare. Essendo ogni sito web diverso da un altro, senza una misurazione accurata non serve buttare sopra tutti i plugin e le tecniche di ottimizzazione di questo mondo, perché si rischia di finire a fare over-optimization. Utilizzate WebPageTest quando volete con una connessione e un browser. Si può condividere un link al test e assicurarsi che sono tutti sulla stessa pagina. 1. Scoprire quanto è veloce una pagina; 2. Trovare il modo di renderla più veloce.
- 12. @sgelob | www.olegs.be da Waterfalls 101 di Web Performance Today http://bit.ly/1nT9yLK
- 13. @sgelob | www.olegs.be da Waterfalls 101 di Web Performance Today http://bit.ly/1nT9yLK
- 17. @sgelob | www.olegs.be Visual Comparison
- 18. @sgelob | www.olegs.be WebPageTest.org Tricks Documentazione (in inglese): http://bit.ly/2d6pAl2 ● Controlla la disponibilità delle risorse http://bit.ly/2cwFlhk ● Generare un Waterfall personalizzato ● Elencare tutte le immagini http://bit.ly/2d2yOBd ● Flow View ● Autenticazione e manipolazione del DOM ● Blocco delle richieste
- 19. @sgelob | www.olegs.be Utilizzi avanzati di WebPageTest.org ● RESTful APIs http://bit.ly/2dyBW6J ● Continuous Integration http://bit.ly/2cHotI2 ● Private Instances http://bit.ly/2dfN6ZY
- 20. @sgelob | www.olegs.be Altri tool per fare test sintetici YSlow Chrome DevTools Pingdom Website Speed Test Yellow Lab Tools sitespeed.io
- 21. @sgelob | www.olegs.be@sgelob | www.olegs.be Le principali cause di pessime Web Perf ● Immagini in formati errati e non ottimizzate ● File testuali (JS e CSS) non compressi con Gzip ● File JavaScript e CSS non minificati ● Utilizzo di troppi font personalizzati ● Molte regole di CSS non utilizzate nel front-end ● Video che si caricano in automatico ● Script di terze parti non raggiungibili (SPOF)
- 22. @sgelob | www.olegs.be@sgelob | www.olegs.be Alcuni metodi per ottimizzare le Web Perf ● Riducete le richieste HTTP al minimo ● Ottimizzate le immagini oltre Photoshop ● Minificate i file CSS, JS e HTML delle pagine ● Comprimete i file CSS, JS e HTML con Gzip ● Utilizzate una Content Delivery Network ● Mettete CSS nel <head> e JS prima di </body> ● Concatenate JS e CSS (non serve con HTTP/2) ● Evitate i redirect inutili…
- 23. @sgelob | www.olegs.be Leggete i libri sulle Web Performance
- 24. @sgelob | www.olegs.be@sgelob | www.olegs.be Time Is Money di Tammy Everts | http://amzn.to/2c0vBBX
- 25. @sgelob | www.olegs.be@sgelob | www.olegs.be Using WebPageTest di Rick Viscomi, A. Davies e M. Duran | http://amzn.to/2cc0GiF
- 26. @sgelob | www.olegs.be@sgelob | www.olegs.be Designing for Performance di Lara Callender Hogan | http://amzn.to/2cmxxTo
- 27. @sgelob | www.olegs.be@sgelob | www.olegs.be Responsible Responsive Design di Scott Jehl | http://amzn.to/2ckcl1B
- 28. @sgelob | www.olegs.be@sgelob | www.olegs.be Iscrivetevi ai blog sulle Web Performance ● Web Performance Today – http://bit.ly/2cvlobR ● O'Reilly Performance – http://oreil.ly/2cc1aWi ● Planet Performance – http://bit.ly/2caZny7 ● Catchpoint’s Blog – http://bit.ly/2cvlq3p ● Steve Souders – http://bit.ly/2cEOXLv ● Ilya Grigorik – http://bit.ly/2cHVhTI ● Tim Kadlec – http://bit.ly/2c0xsXk
- 29. @sgelob | www.olegs.be@sgelob | www.olegs.be Guardate i video corsi sulle Web Performance Gratuiti ● Website Performance Optimization su Udacity bit.ly/1XLxEq4 ● Browser Rendering Optimization su Udacity bit.ly/1GpARFj A pagamento ● High Speed UX con Steve Souders oreil.ly/2dyE52l ● Introduction to WPO con Kent Alstad oreil.ly/2d5UOXN
- 30. @sgelob | www.olegs.be@sgelob | www.olegs.be Partecipate alla comunità delle Web Performance ● Meetup Turin Web Performance Group: bit.ly/29T4pQt ● Gruppo Web Perf su Slack (in inglese): bit.ly/1Q6Z7QT ● Gruppo Web Perf Italia su Facebook: bit.ly/29MRgHA
- 31. @sgelob | www.olegs.be Leggete e studiate i case studies su wpostats.com Case studies ed esperimenti che dimostrando l’impatto delle ottimizzazioni delle web performance (WPO) sulla user experience e metriche di business. «Il 23% delle persone ha maledetto il proprio dispositivo mobile, il 11% ha urlato contro e il 4% lo ha gettato via, dopo aver percepito problemi di performance durante una transazione.» — Ricerca di Harris Interactive per Tealeaf, 2011
- 32. @sgelob | www.olegs.be@sgelob | www.olegs.be@sgelob | www.olegs.be
Editor's Notes
- Ho raccolto davvero tanto materiale e sono sicuro che oggi andrete via pieni di ispirazione e con nuove conoscenze. Prima di spiegare come si usa WebPageTest.org, ci tenevo a parlare un po’ di cultura generale e dei concetti base delle web perf, oltre ad alcuni temi fondamentali e le differenze.
- Latency che è la quantità di tempo necessaria per un pacchetto di dati per arrivare da un punto all'altro. Su mobile c’è la torre cellulare o ripetitore di mezzo… + a volte i proxy server… Bandwidth – esempio di un bus e un taxi che hanno lo stesso tempo di percorrenza su una strada ma con contenuto diverso all’interno. Richieste sono i file che compongono un sito web… CSS, JS, HTML, immagini, font… Connessioni … TCP (fino a 6 connessioni parallele con HTTP/1.1; con una sola trasferisci tutte le richieste con HTTP/2). Guardatevi il video di Simone Bordet del meetup di luglio… TTFB è il primo byte che il browser riceve, quindi è buon indicatore di un back-end veloce
- Il browser costruisce il DOM in modo incrementale e si può usare questo fatto a nostro vantaggio. Cosa succede in questo diagramma: affrontiamo un roundtrip di rete per recuperare il documento HTML. Il markup recuperato ci informa che ci serviranno anche i file CSS e JS: questo significa che il browser deve tornare al server e ottenere il CSS e JS prima che possa eseguire il rendering della pagina sullo schermo. Di conseguenza, il browser affronterà un minimo di 3 round trip prima di poter visualizzare la pagina. I file CSS e JS potrebbero eseguire multipli roundtrip nel caso di peso eccessivo. Per poter eseguire il file JavaScript dovremo anche bloccare e aspettare CSSOM. Le richieste CSS e JavaScript saranno avviate più o meno nello stesso momento. Praticamente il browser ottiene l’HTML, scopre entrambe le risorse e avvia le due richieste. --- Un file CSS esterno blocca il rendering degli elementi del DOM dopo di lui. Un JS esterno blocca il parsing e la costruzione del DOM. --- DOM è lo standard ufficiale del W3C per la rappresentazione di documenti strutturati in maniera da essere neutrali sia per la lingua che per la piattaforma.
- Ottimizzando il percorso di rendering critico, possiamo migliorare in modo significativo il momento in cui eseguiamo il primo rendering delle nostre pagine. Es: Twitter – time to first tweet; Facebook – news stream timeline; Vedremo dopo la funzionalità Filmstrip di WebPageTest che mostra proprio come avviene gradualmente il rendering dei contenuti in un browser. Speed Index – è il tempo medio entro il quale vengono visualizzate le parti visibili della pagina (in millisecondi). Carica critical CSS (inline above-the-fold styles) + JS in modo asincrono. <link href="print.css" rel="stylesheet" media="print"> … Spezzare file CSS e caricarle con media queries: <link href="big-screens.css" rel="stylesheet" media="(min-width: 61.5em)"> Esempio della ricerca: Amazon.com (il più lento a caricarsi ma era percepito come il più veloce) e About.com (sito più veloce a caricarsi ma percepito però come il più lento).
- Synthetic Testing, chiamato anche Synthetic Performance Monitoring e Active Monitoring… – Come siete messi in confronto alla competizione; – Come il design delle vostre pagine influisce sulle performance; – Come la nuova versione del vostro sito si comporta in confronto alla precedente (benchmarking prima/dopo). --- RUM è un monitoring passivo che ascolta tutto il traffico sul vostro sito web. Ci sono diversi tool a pagamento come SOASTA mPulse ma c’è anche in Google Analytics. La parte più importante è che i dati RUM si legano strettamente con User Experience e metriche di business come il bounce rate, page views, tempo di permanenza sul sito e ovviamente il tasso di conversione (nel caso di un sito ecommerce). Non potete usare RUM per fare benchmarking con la competizione e non potete usarlo per testare un sito in staging. --- RAIL (Response – Animation – Idle – Load) è un user-centric performance model promosso da Google.
- In Italia non abbiamo ancora location di testing, se volete contribuire al progetto potete contattare Patrick Meenan e offrire la vostra disponibilità. Dovreste essere coinvolti attivamente nella community altrimenti non penso che la vostra proposta verrà accettata. E «aspettatevi di essere hackerati» :)
- Una volta inserito un indirizzo URL e fatto partire il test si finisce su questa pagina con dei risultati. Vediamo ora parte per parte gli elementi che compongono i risultati di un test. (dopo vedremo anche una demo dal vivo) Vediamo ora i gradi di ottimizzazione: Possono essere da A (90%+) a F (0-59%) vanno a incremento di 10 punti. Sono ottimizzati in ordine di importanza da sinistra a destra. First Byte Time è il tempo che passa fino a quando il browser riceve il primo byte della risposta del server. Keep-alive Enabled misura l'efficienza del riutilizzo della connessione. Controlla le richieste che riaprono una connessione in modo efficiente. (configurazione server side) Compress Transfer controlla se le risorse testuali (JS, CSS, HTML) trasferite sono compresse con GZIP (configurazione server side). Immagini sono risorse binarie e vengono escluse dal calcolo di grado della compressione. Compress Images misura la qualità delle JPEG, ottimizzandole e facendo una comparazione con quelle reali sul sito. Le immagini progressive sono buone per le performance percepite. Cache static content controlla se i contenuti statici hanno impostazioni di durata della cache. Dato che potrebbe arrivare da Cache-Control: max-age oppure Expires header. Effective use of CDN vede se si fa uso di una CDN per ridurre i tempi di round trip caricando le risorse dai punti più vicini fisicamente ai visitatori del sito. Qui non c’è un grado ma dice soltanto se passa o non passa il grado di valutazione.
- La parte che vorrei discutere ora è la tabella con i dati. Sono metriche che indicano la comunicazione tra il browser e il server e la loro misurazione in millisecondi e byte. Load Time è la stessa cosa di Document Complete Time e indica il tempo dalla richiesta iniziale fino a quando il browser genera l’evento onLoad (fino a quando il browser considera la pagina caricata). First Byte è il tempo fino a quando il browser riceve il primo byte della risposta del server. Start Render indica quando il contenuto inizia a visualizzarsi nel browser dell'utente (conosciuto anche come First Paint). Notate che Start Render non indica se il primo contenuto che compare nel browser è utile o importante, o semplicemente sono degli annunci pubblicitari o widget. User Time Il W3C User Timing spec fornisce una API per sviluppatori in modo da aggiungere metriche personalizzate per le loro applicazioni web. Viene fatto attraverso due funzioni principali: performance.mark e performance.measure performance.mark registra il tempo (in millisecondi) dal navigationStart performance.measure registra il delta tra due marchi Nel caso del mio sito ho un marcatore performance.mark('fonts:active'); che dice quindi quando i font custom vengono caricati e applicati. Speed Index è il tempo medio entro il quale vengono mostrate le parti visibili della pagina (espresso in millisecondi e dipende dalle dimensioni del viewport). C’è una formula matematica per il calcolo che ora non vi sto a elencare :) DOM Elements indica il numero di elementi nel documento HTML. Document Complete sono le metriche raccolte fino a quando il browser considera la pagina caricata (evento onLoad). Accade di solito dopo che tutti i contenuti di immagini sono caricate, ma potrebbe non includere il contenuto che viene attivato dall’esecuzione di JavaScript. Time Stessa cosa di Load Time… Requests Il numero di richieste HTTP prima dell’evento onLoad che il browser deve fare per raccogliere le risorse della pagina come immagini, JavaScript, CSS, etc (esclusa la prima richiesta). Bytes In La quantità di dati che il browser dove scaricare per caricare la pagina. (metrica spesso chiamata Page Size) Fully Loaded è il momento quando tutte le risorse di una pagina, tra cui script di terze parti che non sono visibili, sono stati caricati e la pagina è completa. Di solito comprende qualsiasi attività che viene attivata da JavaScript dopo che il principale caricamento della pagina è terminato. Time Tempo dall’inizio della navigazione iniziale fino a quando c’è stata inattività della rete per 2 secondi dopo il Document Complete. Requests Il numero di richieste HTTP totali che il browser deve fare per raccogliere le risorse della pagina come immagini, JavaScript, CSS, etc (esclusa la prima richiesta). Bytes In Numero totale dei byte ricevuti in questo test. Visually complete is the time at which all the content in the viewport has finished rendered and nothing changed in the viewport after that point as the page continued loading. It's a great measure of the user experience as the user show now see a full screen of content and be able to engage with the content of your site.
- Ora vediamo come leggere un Waterfall… ovvero il grafico a cascata.
- Ogni riga del Waterfall corrisponde a una richiesta di una risposta separata. La prima richiesta che fa il browser di solito viene fatta per ritrovare il HTML del sito e include anche il DNS Lookup, che praticamente ritrova dove risiede su Internet il suo contenuto. Le richieste successive ritrovano file CSS, JS, immagini, font e avranno questa struttura: – Tempo di connessione iniziale del browser al server; – Tempo per il browser di ricevere indietro il primo byte dal server; – Tempo per caricare e mostrare il contenuto nel browser. DNS Lookup risolve indirizzo umano a un IP. Come guardare su una rubrica telefonica. Initial Connection è il tempo che il browser ci mette per connettersi al server. Come comporre un numero di telefono e aspettare una risposta. SSL Negotiation Aggiunge tempi di caricamento perché il browser e il server si devono mettere d’accordo su un modo sicuro di comunicare. TTFB Tempo che ci mette il server per prepararsi a rispondere a una richiesta. Server cerca nel DB o si connette a API esterne… Content Download Tempo che ci mette il server a spedire indietro nel browser il contenuto richiesto. Proporzionale direttamente al peso della risorsa e velocità di connessione.
- Start Render indica quando il contenuto inizia a visualizzarsi nel browser dell'utente (conosciuto anche come First Paint). Notate che Start Render non indica se il primo contenuto che compare nel browser è utile o importante, o magari semplicemente sono degli annunci pubblicitari o widget di terze parti. Document Complete sono le metriche raccolte fino a quando il browser considera la pagina caricata (evento onLoad). Accade di solito dopo che tutti i contenuti di immagini sono caricate, ma potrebbe non includere il contenuto che viene attivato dall’esecuzione di JavaScript. Fully Loaded è il momento quando tutte le risorse di una pagina, tra cui script di terze parti che non sono visibili, sono stati caricati e la pagina è completa. Di solito comprende qualsiasi attività che viene attivata da JavaScript dopo che il principale caricamento della pagina è terminato. Rosso Sono errori HTTP 404 risorsa non trovata e capitano anche errori interni del server HTTP 500. Giallo Sono per lo più Redirect 301. Evitateli perché causano un round trip inutile. Capita anche che sono file in cache, soprattutto se si fanno test con repeat view. Vedere: – TTFB lungo = problema di back-end; – Se c’è arancio a inizio ogni barra sono le nuove connessioni aperte. Attivare Keep-Alive sul server. – Guardate se c’è del testo rosso; – Guardate se ci sono barre molto lunghe; – Guardate se ci sono dei gap tra una richiesta e un’altra. (problema di connessione o JS). Buono se: – Meno righe possibili. – Meno barre arancioni possibili. – Barre di colore verde fluo più corte possibili. – Meno blu possibile. – Le linee verticali Start Render e Document Complete dovrebbero avvenire il più presto possibile, e queste linee devono essere il più vicino possibile tra loro. (lo vediamo ora nella prossima schermata) – Waterfall verticale significa buon utilizzo del network
- Connection View La vista Connection View in WebPageTest mostra ogni connessione a un server e le richieste che vengono recuperate. Il numero di richieste che ci vogliono per caricare la pagina è diverso dal numero di connessioni che un browser fa per recuperare i contenuti. Le parti chiare sono TTFB e le scure sono il download della risorsa. Questo è un buon metodo per scoprire gli anti-pattern delle ottimizzazioni delle web perf del percorso di rendering critico. Le connessioni aperte possono essere riutilizzate per trasferire le risorse dallo stesso dominio. Connessioni parallele – Multiplexing in HTTP/2
- Demo Chiedere un sito a caso al pubblico.
- Demo Importante selezionare all’inizio il flag su Capture Video.
- Demo Scegliere un sito della concorrenza, inerente al sito web che il pubblico ha scelto in precedenza.
- – Tool pubblico, quindi capita che ci sono code. Serve per vedere la disponibilità in questo momento di ogni location di testing (demo) – Generare un Waterfall personalizzato (demo) – Elencare tutte le immagini (demo): comodo per vedere tutte le risorse di immagini – Flow View (demo) logData 0 navigate https://olegs.be/blog/ logData 1 navigate https://olegs.be/2016/07/nasce-meetup-turin-web-performance-group/ – Autenticazione e manipolazione del DOM (demo) lodData 0 navigate https://olegs.be/login setValue id=u username setValue id=p password submitForm id=login-form logData 1 navigate https://olegs.be/profile/username – Blocco delle richieste block ads navigate https://olegs.be/
- – Potete inviare test facendo POST o GET verso https://www.webpagetest.org/runtest.php e riceverete una risposta in XML. – Integrazione con un wrapper Node.js, Jenkins, Travis-CI… – WebPageTest è disponibile come pacchetto software per l'installazione e la gestione di istanze private.
- YSlow – analizza le pagine web e perché sono lente, basandosi sulle regole di Web Performance di Yahoo! Sul sito ci sono una lista di 34 regole e Best Practices. Disponibile in diversi modi: come estensione per i browser, come bookmarklet, Command Line (HAR), PhantomJS, Node.js e ovviamente il Source Code. Io uso in Chrome per vedere nel tab Components il peso e il numero totale delle componenti di una pagina web.
- + Latency che è la quantità di tempo necessaria per un pacchetto di dati per arrivare da un punto all'altro. Su mobile c’è la torre cellulare o ripetitore di mezzo… Cose fuori controllo: rete dati che si sta utilizzando, browser in utilizzo, hardware dei dispositivi, location geografica…
- Le immagini che sono l’offensiva maggiore, ma anche la cosa più facile da ottimizzare… I signori di Dexecure hanno analizzato 4.3 milioni di immagini JPEG dai 500,000 siti top in httparchive.org, per un totale di 195GB di dati. Hanno trovato che il 38.9% di quelle immagini aveva dei metadati. In queste immagini, i metadati occupavano nella media il 15.8% del peso totale dell’immagine!
- Prendere copie cartacee e mostrarle una a una, dicendo che dopo durante il apericena possono sfogliarli.
- Tamy Everts Director of Content at SOASTA Libro culturale sull’importanza delle web perf nel mondo ecommerce.
- Libro tecnico su come usare WebPageTest.org che parte semplice e arriva ai capitoli molto complessi.
- Engineering Director at Etsy.com Ottimo libro culturale e per designer e sviluppatori, ma anche per persone che operano nel web in generale.
- Scott Jehl Web Designer e Developer in Filamentgroup Ottimo libro per chi fa front-end e responsive web design.
- – Blog curato da Kent Alstad (Olstad) di Radware; – O'Reilly Media; – Aggregatore di RSS curato dal Stoyan Stefanov. Anche voi potete contribuire alla lista dei siti su GitHub; – Blog della società Catchpoint che offre strumenti di end-user monitoring; – Blog di alcuni dei guru più noti della community delle web perf…
- Venite a trovarci, il meetup è aperto a tutti e il prossimo sarà il 27 settembre alle 19:00 in Via Pietro Micca 12.
- Per convincervi voi che le performance contano e convincere i vostri clienti, capi o membri del team di prenderle in considerazione sul serio e mettere le persone al centro di tutto. Perché altrimenti, se non misurate e non ottimizzate i vostri siti che realizzate, questo è quello che le persone probabilmente faranno mentre visiteranno i vostri siti lenti, soprattutto da mobile…
- Grazie per la vostra attenzione. Se ci sono domande, abbiamo ancora del tempo, altrimenti continueremo da un’altra parte con chi rimane e potete farmele lì. Il 12 ottobre parlerò di cosa sono le Web Performance e perché dovete preoccuparvene al WordPress Meetup Torino da Toolbox.