Bene e benvenuti su Gitbar, 45 gradi all'ombra eppure noi siamo ancora qua a registrare con più forza di prima, in realtà se sentite dei rumori molesti è il mio setup in viaggio che è orrido a dir poco e il condizionatore a palla, ma questi non sono i discorsi che oggi ci interessano, oggi andiamo a parlare di un argomento che solliticherà la curiosità ma prima di parlarne intanto devo dare il benvenuto a Leo che è il padrino dell'ospite di oggi ciao Leo come stai? Ciao ciao tutto tutto bene tutto bene sì siamo tornati a portare gli amici su github come è stato per un periodo quindi basta persone che non conosco portiamo gli amici e facciamoli conoscere.Fa molto italiano questo libro.che poi l'hai visto è mio cugino, no è bravo è bravo.In questo caso però l'ospite di oggi è veramente veramente bravo.Allora prima di fartelo presentare come mio solito devo ricordare rapidamente i contatti info@gitbar via email o @brainrepo su twitter ma soprattutto anche se ma soprattutto non si dice, il gruppo Telegram @Gitbar dal vostro client Telegram preferito mi raccomando se non l'avete ancora fatto iscrivetevi.Detto questo Leo io direi che possiamo iniziare quindi lascio a te il timone e guidaci nella presentazione dell'ospite di oggi.Benvenuti su Gitbar, il podcast dedicato al mondo dei full stack developer, i mezzo artigiani, i mezzo artisti che ogni giorno infilano le mani nel fango per creare nel modo più efficiente possibile quei prodotti digitali che quotidianamente usiamo.Sì, allora l'ospite di oggi, io l'ho conosciuto perché siamo stati entrambi speaker al Web Marketing Festival a Rimini, non ci conoscevamo prima, però abbiamo passato due o tre serate insieme perché dopo la conferenza, dopo i talk, poi c'è sempre la parte di networking, abbiamo fatto nel twerking e lui è un suo amico ed è stato interessantissimo perché non abbiamo mai parlato di codice tant'è che l'ultima sera ho detto ma comunque non si è parlato di codice ma perché parliamo di su guitar recuperiamo il tempo quindi il questa persona è matteo lullo che è un front-end developer vi dico il nome ve lo lascio per anzi lascio che si presenti da solo chi sei matteo ciao ciao ciao allora come dicevi tu sono uno sviluppatore front-end principalmente mi occupo di sviluppo front-end, diciamo che negli anni mi sono appassionato a un argomento che oggi magari sgredoleremo un po', tireremo fuori qualche carta dal mazzo che sono le performance, quindi sono appassionato di performance, in realtà di guerre stellari, ma so che Leo non fa niente impazzire, quindi diciamo di performance anche e niente, sviluppo da un po' e mi piace cercare di far andare i siti il più velocemente possibile.Tema caldissimo, al di là della situazione climatica se ascoltate la puntata nel momento in cui viene registrata però performance sono una parte molto importante e impattante nello sviluppo dei siti o delle applicazioni web.Sì esatto adesso è diventato ancora più hot perché ovviamente google ha tirato fuori le vitals che sono dei kpi poi magari ne faremo una chiacchiera e diciamo che già prima erano abbastanza core le performance per banalmente il posizionamento dei modelli di ricerca adesso sono diventati ancora più importanti.Se prima era una cosa che era solo da sviluppatore, adesso è entrato anche a piedi uniti nell'ambito di marketing SEO, quindi tutti quanti corrono al riparo.Il mio sito è lento e vogliono farlo andare forte.Come da tradizione io di queste cose non so nulla, infatti io vengo qua per imparare, per cui mi fa molto piacere che possiamo affrontare questo argomento.Fighissimo, bene, ottimo.La prima domanda che faccio è una domanda per capire con chi stiamo chiacchierando oggi, in fondo siamo davanti a una birra, per cui mi piacerebbe sapere da te come è iniziato tutto, la genesi.Come mi sono appassionato alle performance tu dici proprio in generale o proprio...Entrambi, entrambi, come è iniziata la tua carriera e cos'è che ti ha spinto ad approfondire questo questo argomento.Allora io la mia carriera ha ha iniziato in maniera un po' strana perché io ho fatto una marea di lavori prima di iniziare a fare seriamente in maniera continuativa lo sviluppatore, nel senso che io sono stato un light designer, mi piaceva, facevo il tecnico luci, ho lavorato in discoteca, ho fatto il Rudy, andavo a scaricare i camion con dentro gli amplificatori, queste cose così, ho fatto il giardiniero, ho fatto il back office, ho fatto una marea di robe, però ho studiato informatica, sono diplomato un periodo informatico e diciamo che mi è sempre rimasta in questo periodo della mia vita in cui ancora non ero uno sviluppatore al 100%, il pallino, la passione, seguivo sempre dei blog, leggevo, scrivevo, facevo qualcosa per i fatti miei.Poi la vita mi ha portato a tornare a fare lo sviluppatore e diciamo la passione grossa sulle performance e la fortuna che ho avuto è che ho avuto la possibilità di lavorare sempre su prodotti principalmente editoriali, quindi lavoravo su siti di news e questa casa qua mi ha fatto appassionare a due argomenti grossi che sono UX e UI e le performance, perché comunque sono due cose che vanno abbastanza a braccetto e la passione che ho io nel navigare il web, nel senso che è proprio un posto che a me piace da impazzire, mi ha fatto appassionare alle performance web perché quando io sono uno di quegli utenti che è proprio super, diciamo un po' pigro, nel senso che quando vedo che un sito ci mette davvero tanto io cambio, quindi navigo cambio molto in fretta.Conoscendo me stesso ho detto come faccio a fare una persona come me riesca a rimanere sul mio sito e quindi mi sono un po' informato, ho avuto la fortuna di lavorare con persone che ne sapevano, di vedere cose e di capire cose e allora piano piano mi sono appassionato sempre di più, tant'è che ho detto che questo un argomento che è molto bello, ma le persone ne parlano sempre come se fosse un side project, non come se fosse un qualcosa di principale, perché si parla sempre della tecnologia, del framework javascript, della nuova versione di PHP, lo dico apposta perché c'è Leo, si parla sempre molto di quello e magari di altre cose che sono "accessorie", come potrebbero essere le performance, però magari sono un mix di varie cose, se ne parla un pochino Adesso vedo che per fortuna è iniziato a essere un argomento che è sulla bocca di tutti, quindi sono molto contento di riuscire a portarlo anche un pochino in giro.Per me è una quest, quindi per me è abbastanza divertente.Quindi è bello vedere che le persone si appassionano cercando di passargli quello che io ho imparato, quello che è appassionato a me, cerco di darlo agli altri e trasmetterglielo su questi argomenti.Quando dici che sono accessorie dipende, perché poi quando vedi che c'è una correlazione tra quanto ci metti a caricare nella tua pagina e quante conversioni hai, quindi ci metti più a caricare la pagina e fai meno vendite, allora dici aspetta ma non è solamente un vezzo, forse questo è anche qualcosa che fa parte del core business dell'azienda.Certo certo certo, diciamo che magari fino a ieri, sono abbastanza sicuro di dirti di affermare questa cosa qua, fino a ieri era più importante il colore o l'immagine che avevi di background no? Perché magari anche proprio il prodotto si baciava su alcune cose, cioè secondo me non per essere cattivo ma ancora si pensava a fare facciamo il sito desktop fighissimo e il mobile cioè lo adattiamo utilizziamo bootstrap no? La solita parola dada che adesso adesso il brivido sembra che bootstrap sia la morte.Utilizziamo bootstrap così tanto si adatta e facciamo un bel sito con una bella immagine di background enorme super figa bellissimo perché graficamente è una roba da paura, le performance zero, cioè nel senso privi light house e dice via e quindi invece adesso come hai detto tu c'è la conversione porta vendite magari banalmente porta visualizzazioni porta click e quindi vogliono tutti quanti il sito performante sì assolutamente assolutamente.Mi chiedeva appunto se quando dici vogliono il sito performante è una cosa che arriva dal business, nel senso te lavori in una grande azienda e sei te magari l'esperto di web performance.È il business che ti chiede "guarda come si fa, lo vogliamo più veloce perché sappiamo questo?" oppure sei te che gli dici "guardate, io mi occupo di performance, se miglioriamo la velocità più gente viene convertita".Qual è stata la tua esperienza? Allora la mia esperienza diretta è stata che un pezzettino sono stato sicuramente io a istruire il business, ok? Perché comunque ho più sensibilità sull'argomento, no? Dall'altro lato ho visto che poi piano piano ho iniziato a farmi più richieste, nel senso che poi ovviamente chi si occupa di SEO già all'epoca magari strizzava un po' gli occhi, l'occhiolino alle performance, adesso ovviamente ancora di più.Quindi diciamo che è esperienza che consiglio che do io spassionato a tutti sviluppatori che magari ascolteranno Gitbar e quindi inizieranno a pensare alle performance è se voi avete la sensibilità cercate di proporla all'azienda o al prodotto per cui lavorate perché comunque così facendo instarate un rapporto che sicuramente è vantaggioso perché poi arriverà il momento in cui queste cose ve le chiederanno quindi altra cosa che io subito consiglio è quando si parte con un progetto e si deve pensare anche alle performance è meglio pensarle subito che pensarle quando si è finito perché poi dopo ci si arriva come tutte le cose, o il testing, per dire, anche col testing bisogna magari pensarci subito perché poi arriva la fine che ti trovi davanti un muro e scavalcarlo diventa più complesso che invece costruirlo piano piano.Le performance è la stessa identica cosa.Quindi secondo consiglio, primo consiglio è magari proponetevi, secondo consiglio è pensateci subito.Poi sicuramente adesso vedo che anche tanto il business UX si sta interessando molto, come dicevo prima Seo, quindi magari vedo su altri progetti dove magari non seguo direttamente io, che ci sono persone che magari hanno visto anche il lavoro che ho fatto io, iniziano a far delle domande, quindi iniziano a chiederlo un pochino prima.Però è una cosa che bisogna portare sicuramente sul proprio posto di lavoro.Per risponderti.Faccio una domanda giusta per chiarire ancora meglio l'argomento.Noi oggi abbiamo iniziato a di performance, no? Ma quando si parla di performance, di cosa si parla? Quali sono i KPI, le KPI che vogliamo monitorare e soprattutto che cos'è lo studio della performance del web? Allora, questa è una bellissima domanda perché racchiudo un po' tutto e davvero si apre una porta su un mondo che è davvero molto grande.Le performance intese come proprio web performance, quindi le performance web, sono tendenzialmente, uno pensa subito alla velocità di caricamento della pagina.Quindi l'utente, quanto tempo ci mette a scaricare sul proprio client, tramite il browser, l'HTML, le risorse, e avere un'interazione sulla pagina.In realtà non è solo questo, perché negli anni, diciamo, si è evoluto questo, tutto questo filone di conoscenze si è evoluto e quindi si studia anche altre cose, come per dire la reattività, la velocità di alcuni elementi in pagina di caricarsi, la composizione di come è composta la pagina, come vengono caricate le risorse.Quindi diciamo inizialmente che per semplificare è la velocità effettiva del caricamento della pagina, però è tante altre cose.I KPI principali sono tre adesso, che sono i Core Web Vitals, che sono il CLS, il Feed e il, scusatemi, è il Comulative Layout Shift, se riesco a dirle giusti, First Input Delay e non me lo ricordo più il testo, bellissimo.Tanto noi non conosciamo nemmeno gli altri quindi abbiamo tempo per… comunque stanno a rappresentare dei fattori principali, ok? che sono tre dogmi, possiamo definirli così, utilizzando questo parolone che rappresentano tutta l'esperienza utente e alcune parti tecniche per esempio il feed, first input delay, rappresenta la reattività di quello di cui noi abbiamo in mano sul nostro smartphone.Io adesso faccio una piccola assunzione.Quando parlerò di performance e parlerò magari di viewport, di questo e di quest'altro, io, come esempio, ho sempre il mio smartphone, perché ad oggi, nel 2021, pensare di parlare di desktop è un po' indietro.quindi teniamo il mobile come nostro standard e come nostro riferimento.Quindi il feed, come dicevo, è first input delay, quindi la velocità, la reattività che ha la pagina di risponderti.Banalmente l'apertura di un menu, il caricamento di un video, quando scrolli se ci sono delle animazioni.Colmolo T-playout shift è un KPI importantissimo, ok? che è il KPI che rappresenta il movimento che ha la pagina una volta caricata.Quindi per Google questa cosa ha rivoluzionato un po' l'ambito delle performance perché Google ha iniziato a far pesare quello che l'utente provava.Quindi questo KPI rappresenta pieno quello che l'utente prova perché quando tu navighi la pagina, magari c'è un banner che può essere una D, magari può essere un pop-up che si apre, l'utente prova tutti questi stati inaspettati del caricamento, quindi la pagina trasla, sale e scende.Questa cosa qui per Google è molto negativa, perché magari mentre uno sta per cliccare "compra ora", "acquista ora" oppure sta per cliccare "vedi altro", la pagina appare un pop-up, con "acquista ora" lui premia e è acquistato qualcosa.Oppure, per esempio, quando si appare un banner e si sposta da sotto...E tu clicchi, apri il banner e non ce la fai.cose qua google le odia quindi è iniziale.- Questa è la shift che dico, dovrebbe essere già lo spazio definito nella pagina.- Sì certo certo, poi va beh le ottimizzazioni poi magari ve le racconto anche qualcosina.Diciamo che questo qua calcola tutti questi spostamenti inaspettati.L'altro KPI che mi sono ricordato, ho fatto un po' l'emozione ragazzi, voi siete abbastanza importanti, dai ve la faccio tirare un po'.Sono emozionato di essere qui, veramente euforico come diceva qualcuno, è l'LCP che vuol dire Largest Countable Paint.che cos'è? Il render dell'elemento più ciccione che c'è in pagina.Nel senso, parlo di "abodefold", immaginatevi di avere di fronte a voi il vostro smartphone, l'abodefold è tutto quello che appare sullo schermo, quando voi navigate sul browser, ok? L'LCP calcola quanto questo pezzo di HTML, di CSS, di quello che avete in view, viene caricato.Quindi non tutta la pagina, ma solo quel pezzo lì.Quindi per Google è importante che inizialmente quel pezzo di pagina sia ottimizzato e caricato velocemente.Questi tre KPI, che sono, li ripeto perché adesso li so tutti tre, SCP, Cumulatively Out Shift e Feed, First Input Delay, sono i Core Web Vitals e sono i KPI che ad oggi sono quelli più importanti.Ce ne sono altri mille, che ne so, il Backend Time, quindi il tempo che il backend risponde alla pagina, all'altro server, JS long track, cioè il tempo di quanto il JS viene inizializzato e runnato.Ce ne sono davvero tantissimi, davvero davvero davvero tantissimi.Diciamo che Google...Chi definisce questi KPI? Cioè è Google che li definisce quindi seguiamo Google perché fa da padrone nel momento in cui te appari in SERP o una cosa che viene dal bus, dalla community? Allora, tutte e due, nel senso che sicuramente i Core Web Vitals che sono arrivati adesso li ha definiti Google, ok? Invece tanti altri KPI erano KPI che sono KPI magari anche più tecnici, ok? Come Backend Time, che vengono definiti un po' dalla community, un po' da quei personaggi illustri che hanno creato anche un po' il web, no? Ci sono comunque tante cose carine se si cerca su sull'internet.Ci sono degli strumenti, dei tool free, uno in primis che è WebPagetest, che è uno strumento super completo dove all'interno trovi tutti questi KPI, le vitals con ovviamente un valore maggiore e poi tutto il resto che ti permette di capire davvero quanto effettivamente è complesso anche soltanto capire muoversi tra questi KPI.Infatti io sono molto contento perché oggi vedo che anche tanti qua si iniziano a interessare a far dei test, a capire le performance, però effettivamente quando poi inizia a sfogliare i KPI, inizia a guardare sono cose da sviluppatore, nel senso che ti devi andare a guardare, devi capire i rapporti, hanno tanti significati.Per dire, ieri uno dei KPI più importanti era lo speed index.Lo speed index era non una sommatoria, ma calcolava, se tu guardavi era un grafico, e calcolavo uno spazio bianco, minore era questo spazio bianco, quindi questo valore scendeva tra due punti e maggiore era la performance che aveva in pagina.Però ovviamente io penso che magari domani ci sarà un altro, perché magari alcuni TPI verranno semplificati, le vitals hanno già fatto una semplificazione e hanno introdotto l'esperienza utente, quindi magari un giorno ne arriveranno ancora altri.Diciamo che Google, essendo Google, essendo un gigante, come se stessimo parlando di Zeus dell'Olympus, un po' nel mondo, ha deciso un po' il chiaro e il cattivo tempo, tanto che questi valori adesso fanno indicizzazione, nel senso, in base a come vai, vieni più o meno posizionato in un motore di ricerca, che questa cosa è una discriminante molto grossa.Prima il crawler di Google vedeva come eri performante in base a quello che capiva se era una pagina navigabile o meno.Cioè, dava importanza, perché dava importanza perché diceva "questo è un sito veloce, è più facile, quindi posso navigare più pagine".Quindi dava importanza, ma era non importantissimo come oggi, perché oggi se questo QPI va male, sono divisi tutti e tre in tre fasce, che sono "bene, possiamo migliorare" e "siamo messi male", in base a questa fascia qua, tu ti posizioni, quindi da quello non scappi.diciamo che è proprio un accessorio al SEO.Però non pensi che collegare ciò che riguarda performance, e nel calderone ci metto anche la questione dell'accessibilità, ma vabbè teniamola da parte.No no va benissimo anche quello è un mondo enorme, però collegare il concetto di performance al concetto di ottimizzazione e di SEO, non pensi sia una forzatura, nel senso che non necessariamente un sito che ha del buon contenuto deve essere per forza performante.Non vedi questo come una forzatura.Allora io ti risponderò per me no, nel senso che un'altra di quelle cose che mi ha fatto appassionato tanto le performance è stata questa storia e quindi questo per far capire quanto le performance secondo me devono essere importanti al netto del contenuto, perché comunque un sito con un buon contenuto deve, cioè per me deve essere anche performante perché comunque deve arrivare all'utente.Diciamo che la discriminante è l'utente nel senso che come dicevo prima l'utente può essere pigro quindi tu puoi avere anche il contenuto più bello ma se il tuo sito non si carica e quindi l'utente vede una pagina bianca il contenuto anche se qualcuno diceva content is king no? secondo me ciao io penso che dopo cinque secondi che è già un'esagerazione di tempo l'utente vada via quindi statisticamente parlando anche se è un buon contenuto il non è performante rischi che ti perdi comunque visualizzazioni perché gli utenti sono diventati molto caprari, diciamo gli diamo dei pecoroni faccio anche io un po' il provocatore, è gente un po' insensibile quindi scrolla e basta e cerca le foto dei gattini o le wags quindi va veloce, tappa e va via.Infatti se pensiamo adesso il social che va più forte è TikTok dove sono video di a massimo 30 secondi e vai, l'unica cosa che puoi fare è tappare, mettere un cuore o un commento.Quindi secondo me no, però ritornando al discorso che ho iniziato a dire, un'altra cosa che mi ha fatto appassionare molto è la storia di questa ragazza che, non questa ragazza in generale, una persona, un esempio, che io ho detto cacchio, però per me è importante, una persona che è dall'altra parte del mondo, magari in un posto in cui poco il telefono o c'è una connessione che non è veloce, perché noi in Italia siamo abituati bene, perché comunque abbiamo il 4G, il 5G, il 3G, sì e no, però navighiamo.Magari siamo, che ne so, nel deserto dei Gobi.Io sono un ragazzo che è di Genova e durante la tragedia del Ponte Morandi non so se i miei parenti stanno bene.Magari nel deserto dei Gobi vado su Lanza, vado su SkyTg24, vado sul Corriere, vado su Repubblica e dove mi trovo in quel momento la connessione va a 320k al secondo e prima di capire la lista dei feriti o capire che cosa è successo passa tanto tempo perché il sito magari non è ottimizzato per rispondere prima a quello perché magari in Italia siamo abituati che il profitto è un po' posizionato prima e io non ce l'ho contro la DV perché so che l'adv mi paga lo stipendio però magari per scaricare un adv per scaricare un tracento per fare un'operazione di analytics io la pagina non la vedo vedo solo il titolo magari e magari ho anche un titolo che mi mette ancora più paura e non riesco ad aprire l'articolo perché mi va in timeout perché la connessione al server è lunghissima perché perché non è stato ottimizzato perché magari non c'è un ttl su una risorsa non ho niente in cache quindi sono lì e sono in sbattimento per me sta casa qua Ritornando un po' anche al discorso dell'accessibilità, per me questo è accessibilità.Cioè un sito, l'accessibilità fa parte, le performance, fantastico ragazzi, fantastico, guardatemi, le performance fanno parte dell'accessibilità perché appunto una roba del genere deve essere accessibile.Allora, io volevo farti una domanda che è quali sono gli strumenti che devono essere utilizzati, cioè che te utilizzi per valutare, nel senso, hai parlato di qualche strumento di Google, o di Lighthouse, non so se è di Google, ma l'ho sentito un po' parlare.Volevo sapere che, in questa immagino facciano un controllo su loro, sulla tua pagina e ti danno il risultato.Volevo sapere che strumenti ci sono qui e cosa analizzano e che altri strumenti utilizzi.Immagino i Chrome Developer Tools siano sempre aperti nel tuo browser.Volevo sapere quali parti di questi tool utilizzi di più e in che modo, come approcci l'ottimizzazione.Allora, io consiglio sempre dei tool sia free, cioè nel senso consiglio tre tool che sono più o meno free, e un tool che invece è premium.Allora, Lighthouse, come dicevi, è uno strumento, diciamo, di Google stesso, e quindi all'interno, direttamente, quando apri la console, ci giochi vicino e c'è tutta la parte di Odis delle performance.quindi tu lo lanci direttamente dalla tua pagina web.L'unica cosa che ha un grosso pro che appunto tutti quanti lo possono utilizzare e un grosso contro che tutti quanti lo possono utilizzare nel senso che oltre a far tu il test lo può fare il tuo business analyst, il tuo PM, il tuo capo su premio e quindi ti fa un test e ti dice "ah, ho Google che segna 19" In realtà è un tool molto figo perché ti consiglia tantissime ottimizzazioni, però fa una prova a caldo.La prova a caldo vuol dire che magari simula una rete, magari simula un device, magari non tiene in conto di x cose che tu hai all'interno del tuo sito.Adesso li hanno introdotti anche loro, perché Google ovviamente fa una cosa, la utilizza, allora dice aggiungiamola perché poi la gente la usa.Banalmente i service worker, hanno introdotto anche i service worker quando si fanno dei test di performance.Il service worker è un po' una caching che abbiamo all'autobrowser, cioè è un JS, sono i web worker, quindi sono dei JS che non lavorano sul main thread e fanno da filtro, nel senso beccano le chiamate che tu gli dici "cacheami queste risorse" e te le tengono sul browser.Adesso Lighthouse tiene conto anche di queste cose, però è comunque un test a caldo.come dicevo prima, un altro strumento molto figo è WebPagetest bello perché c'è dentro tanto, puoi simulare anche lì alcune cose ci puoi mettere dentro degli script che ti permettono di navigare la pagina come se avessi la CMP attiva o non la CMP attiva parlo, scusatemi, del GDPR, quindi tutta la parte dei cookie ed è bellissimo perché è fatto molto dalla community, quindi c'è una marea di documentazione, c'è un sacco di cose, un sacco di forum tecnici dove trovi tantissima gente che è super in gambe e ti dà una mano e il tool è molto bello e molto completo.Ovviamente essendo un tool free, magari quando ti metti a fare un test rimani in coda, nel senso che magari c'è già qualcun altro che lo sta utilizzando in quel momento e quindi il tuo test rimane un attimo in coda e quindi prima di essere runnato, magari ci sono 17 test prima di te.però è molto molto molto bello, molto completo ed è il primo e il più storico ancora prima di Lighthouse esisteva già quel tool poi c'è Sitespeed.io che è un altro tool molto carino ed è secondo me un tool super da developer nel senso che è molto figo perché si può integrare con le pipeline banalmente con Jenkins quindi ogni volta che fai un rilascio puoi fare dei test di performance se sei uno che ne sa un pochino di Node può scrivere tante cose banalmente io mi sono fatto con Sidespeed IO il mio progettino in locale e riesco a testare le performance anche di collaudo e di sviluppo, non solo di produzione.Ok, Lighthouse Google lo fai sia su produzione collaudo, perché comunque ovviamente lo fa sul browser in quel momento, ma come dicevo è un test caldo, quindi ha questo diciamo contro.Sidespeed IO ha questo pro che invece proprio tu gli puoi passare tutte le CDN, gli puoi passare dove dove si trova in quel momento il tuo collaudo il tuo sviluppo e lui ti fa questi test utilizza comunque ti puoi definire la rete, gli puoi definire la velocità della rete, gli puoi definire il device quindi è molto molto bello e poi può essere integrato alle pipeline, noi lo utilizziamo su Jenkins quindi su quello io mi sto trovando discretamente bene l'unica cosa che...Scusa Matteo, Lighthouse però può essere integrato...Sì, anche Lighthouse può essere integrato su Pipeline, praticamente fa la stessa cosa che ti fa sul browser, ti tira fuori i dati, e tu tramite un API poi lo richiami.Cioè diciamo che su questa cosa si assomigliano molto 6speed.io e Lighthouse, soltanto che 6speed.io ti permette di arrivare, secondo me, un pochino più preciso sulla parte di collaudo.Secondo me è un pelo più preciso di Lighthouse, che comunque fa anche lui da testa caldo, ma sono strutturati decisamente meglio.perlomeno la mia esperienza mi sono trovato meglio, ho provato le API di tutte e due e mi sono trovato un pochino meglio mi sembra più specifico, per uno sviluppatore, per uno sviluppatore poi c'è l'ultimo tool che è molto figo, essendo un tool premium ovviamente lo si paga, è Speedcure Speedcure è molto molto molto bello, perché è un tool che ti permette di fare una cosa molto figa che è il real user monitoring tramite un cookie che si chiama Lux che tu installi sul tuo sito e poi vai a misurare le performance dei device dei tuoi utenti quindi diciamo che i tuoi utenti fanno da test ok quindi tu hai effettivamente vedi veramente che cosa stanno facendo quindi non tanto con cosa stanno facendo ma come vanno le tue performance perché ovviamente gdpr compliant e tutto.Ecco la mia domanda era subito.E' molto molto molto figo e poi ha una parte di dashboard che è bellissima perché è proprio business addicted nel senso che piace tanto al business, ha un sacco di graficoni, un sacco di torte, tutte robe colorate sai quindi quelli dell'universo."Ah ma io questo ci capisco è un grafico a torta" invece gli altri tool hanno tanti KPI, hanno queste super mega immagini waterfall con un sacco di cose scritte che scendono e quindi devi essere uno sviluppatore e capire un po' di quello che stai guardando.Invece SpeedCurve è bello perché te lo confezione e anche una persona che non è prettamente un dev guardandolo riesce a capire.Quindi è molto bello, ti permette di comparare test, ti permette di far tante tante tante cose.Infatti io principalmente preferisco questi tool che ho detto, quindi Lighthouse, SpeedCurve, WebPageTest e Sitespeed.io.Ci sono anche altri.Scusami, questi che hai nominato, danno dei risultati coerenti? Cioè se migliori su uno, migliori anche sull'altro? Sì sì sì.Allora diciamo che magari su alcune cose i KPI vengono calcolati leggermente diversi o magari hanno dei KPI a confronto che sono sulla carta uguali ma poi hai risultati diversi per dire Lighthouse ha il performance score che è quello generale e invece 6PDAIO ha il coach score che è quello generale e ti sembrano diversi ma perché magari uno un KPI lo calcola in un determinato momento e un altro lo calcola in un altro diciamo che non esiste ancora ad oggi un ente ufficiale come potrebbe essere quello per il GDPR dei cookie che ha descritto in perfilo e per segno il KPI, quando va preso, in che momento va preso.Infatti ogni tanto ti vedi che magari all'improvviso vedi che le performance sono scese, ma perché magari hanno iniziato a prendere un KPI da un determinato punto che invece prima lo calcolavano prima.Quindi hai un peggioramento, in realtà non è che la tua applicazione non è cambiata.Però più o meno se diciamo sono in linea tra di loro, cioè alcuni KPI come le vitals, sia su speedcube sia dove si sono uguali.Come dicevo prima Lighthouse fa un test a caldo quindi in realtà lui non sta tenendo conto di tante cose quindi essendo un test sul browser in quel momento è il tool che secondo me è utile per trovare le ottimizzazioni e fare le prove al volo ma non ti dà effettivamente la visione.Diciamo che è molto simpatico è molto carino ma è solo il primo passo non so come dire, cioè nel senso è quella cosa da cui ci passi e poi dici ok adesso ho capito come funziona magari provo con qualcosa di un pochino più serio, tipo la prima bicicletta che ti compri prima di comprarti una bici un po' più figa però non la fai a tanti chilometri.Tipo il php? Non so, non so, funziona così col php? Io ce lavoro, però fa sempre bene nominarlo, la cosa in cui uno inizia e poi fa qualcosa di serio.Vabbè sì certo come dicono tutti, Wordpress, iniziamo con Wordpress e poi dopo facciamo un sito più serio.Esattamente.La mia domanda è un po' strana, però viene da un'esperienza che sto facendo proprio questi giorni qua.Io sto lavorando in e-commerce e capita che la parte editoriale pubblichi dei contenuti che in qualche modo inficciano sulle performance del sito.Adesso estremizza la GIF animata da 20 mega ok ci sono sì delle pipeline di ottimizzazione all'upload del file però può essere quello può essere gli other tag messi in modalità cinofallica come direbbe qualcuno.Ti è mai capitato e lo dico perché ci sto lavorando proprio questi giorni di schedulare queste verifiche nel tempo al di là proprio del concetto di continuous integration e di rilascio perché di solito si fa di schedulare temporizzando appunto queste verifiche con degli alert di questo tipo e se sì esistono dei tool open source che possiamo utilizzare mettere nel nostro processo di monitoring che ci permettono di verificare questi parametri? Allora sicuramente nel senso che al net di Continuous Integration io i tool che vi dicevo prima più o meno ce li ho aperti sempre cioè nel senso un giro me lo faccio ogni giorno perché sembra una cagata ma basta davvero poco perché le performance cadono giù banalmente appunto una D che arriva che magari all'interno si porta altra roba, l'editore che carica un'immagine che davvero anche se è stata ottimizzata, delle immagini ottimizzate, non si sa come ha fatto, ha caricato comunque una JPEG da un PNG da 8000 MB e tu dici "come cavolo è?" oppure persona non sensibile, nuova feature, "ah, mettiamo uno slider con dentro un carosello di video in top alla pagina, in above the fold, quindi nella parte alta" e quindi io questi tool che dicevo prima ce li ho sempre accesi.SpeedCure come tool premium te lo fa, nel senso che tu imposti dei performance budget e lui ti manda dell'email quando tu questi performance budget li superi.Non so se è speed IO o no, neanche web page test, perché sono i test che tu runni.Cioè tu runni e poi ti guardi il test, ok? Quando lo fai, lo fai con la pipeline, come dicevamo prima, uno magari va a fare un rilascio e quindi se lo va a guardare, no? Non so se ci sono altri...Io so che c'è questo strumento che io però non ho mai usato, che è Pingdom, non so se questo ti crea degli alert che te li manda.questo io non sono ancora preparatissimo, però sto iniziando a studiarmelo perché ho visto che la gente me lo chiede.Quindi come mi chiede le ottimizzazioni WordPress e quindi mi sto studiando come ottimizzare le performance di WordPress, mi sto guardando anche un pochino Pingdom, ancora non so se si fa una cosa del genere, spero di sì perché sarebbe comodo avere un tool free che ti permette di fare magari una configurazione locale, magari con una Docker Image o qualcosa che ti permette di fare questa cosa qua.Se no, sta a te, nel senso io ho questa sensibilità conosco appunto il prodotto, so che potrebbe succedere quindi preventivamente vado a guardare.Poi alcune cose la GIF da 20 mega sinceramente no, cioè nel senso quello che bisogna fare anche da sviluppatori è cercare di picchiare le mani e dire no non si fa perché se no se non si abituano se non si abituano gli editori se non ci dice guarda che sta cosa sbagliata probabilmente loro non cambieranno mai perché la gif del gattino che ride per loro è sempre bella.La mettiamo ma magari non la mettiamo sopra, magari la carichiamo in l'esilode, magari la mettiamo proprio per ultimo, magari non la mettiamo proprio.Però bisogna un pochino istruirli perché se no è un po' il discorso...è come dire che una persona da sola che non è sa un tubo si mette a posto i tubi di casa e ovviamente fa un danno al rivale idraulico e gli dice "guarda magari questo tubo qua...meglio di no" magari metti questo, cioè mi chiami, faccio questo lavoro, quindi magari evitiamo un po' di farci pagare come sempre fossimo delle scimmiette, quindi bisogna un pochino istruirli.Io questa roba qua per me è proprio una crociata, proprio aperta, cioè io ho sempre dato in testa al business e forse anche un po' per questo, come dicevo prima, ottenendo poi risultati, poi vengono a chiederti, a farti le domande.Dicono "oh ma abbiamo questa idea fighissima, mettiamo due banner della pubblicità, uno sotto l'altro, subito, appena apri mentre scrolli e tu dici no magari no dai facciamo, cerchiamo di fargli lo stesso però magari non così dai.No in realtà questa è perché la soluzione che ho trovato almeno temporaneamente è quella appunto di far girare un headless lighthouse triggerato da una cron, dall'airflow della situazione quindi che lo attiva periodicamente e che si va a vedere appunto a monitorare le performance è da una parte a mandare un bel messaggino su slack al team editoriale o che sta succedendo bellissimo dall'altra salvare le performance su data storage per poter fare dei grafici avere dei grafici di variazione a seconda delle pubblicazioni nel contenuto che può essere il content della situazione no? Quindi cambia qualcosa a livello di contenuto, si fa vedere il cambio di performance, magari anche triggerato dal salvataggio sul CMS e a quel punto viene notificato il tutto.In questo modo si ha, diciamo, non voglio chiamarlo blame verso la parte editoriale, una sensibilizzazione verso la parte editoriale che esula dalla figura dello sviluppatore o dell'esperto di performance.Questa roba si è automatizzata, il cazzotto sulla nuca arriva subito.Ah no certo assolutamente, assolutamente.No no ma infatti è fighissimo, fai benissimo.Cioè nel senso io non sono così smanettone come te perché magari non ho voglia, lo ammetto proprio brutalmente, e magari perché io ci passo più del tempo o magari non ho alcune competenze e quindi me lo faccio diciamo a manella e il cazzotto però mi piace darlo.Però devo essere una cosa, io quello che cerco sempre di dire no, perché comunque voi dite "tu sei l'esperto delle performance" però secondo me deve diventare una roba che deve essere come una best practice, quando scrivi una row function, non lo so, qualcosa che si scrive bene in php, che prima magari non si usava adesso si usa sempre, come l'inter secondo me dovrebbe essere le performance, quindi qualsiasi sviluppatore ci si mette dietro deve iniziare a ragionare anche mettendo le performance visto che abbiamo l'inter che ci dice così, abbiamo questo abbiamo quest'altro pensiamo anche a questa cosa qua, poi è una roba che va portata anche su altri tavoli, secondo posto dopo lo sviluppatore chi deve pensare a questa cosa qua che solitamente è quello con cui cozi di più è ioX, loro fanno dei disegni bellissimi, guarda ho pensato di fare questo parallax mentre carichiamo il video perché l'effetto che dai all'utente è quella sensazione di brezza marina.Fighissimo, va bene, ma noi stiamo parlando di un utente che magari deve comprare una cosa e magari fa un acquisto svoiatissimo, veloce, soltanto perché vede il prezzo, clicca e va e tu per caricarmi la borsa ci metti 20 secondi perché vuoi fargli fare l'effetto parallax, lo zoom più bello degli zoom perché se muovo il device si sposta dall'immagine? No, nel senso capiamo, pensiamo alle performance visto che abbiamo capito che adesso più il sito è performante magari più chiudiamo vendite.Quindi il secondo tavolo poi sicuramente è quello di UX e UI che devono iniziare a digerire questo argomento, visto che comunque loro si fanno avanti essendo le persone più creative del mondo è giusto anche che questa creatività venga messa a servizio anche della persona.Il prodotto deve essere bello, io non dico che deve essere brutto, infatti il problema del web anche oggi è che si è molto standardizzato con l'avvenuta di cose come Bootstrap, anche se io non ho niente contro Bootstrap, si è molto standardizzato, abbiamo questi design che sono tutti fluidi, quindi allargo e chiudo, allargo e chiudo, gli m-site non esistono più che poi non è vero, perché ci sono ancora molti che fanno questi ragionamenti, anche fighi, nel senso che non è che dici brutto, ma belli.Però sia un po' standardizzato.Noi guardiamo la carta stampata e invece è ancora un altro mondo, fighissimo, pieno di design, super bello.Però ovviamente la carta stampata è un prodotto, il web è un altro.Quindi bisogna cercare di unire le due cose e trovare ovviamente la pietra filosofale, perché comunque è un po' trovare l'America, riuscire a fare queste due cose.E qua arriva la mia domanda/provocazione.Siccome con Leo abbiamo fatto un altro episodio, la mia domanda è, Web Performance è WebGL e quindi tutto ciò che riguarda il 3D nel web.Questo è un tasto colente, giusto? Però allo stesso tempo è tutto un altro mondo che si sta sviluppando.Quindi secondo te cosa si dovrà fare per far incontrare questi due poli che oggi sono agli antipoli? Allora la mia risposta a questa domanda è un metodo che io utilizzo quando mi applico alla scrittura del javascript e quando penso alle performance applicate al javascript perché secondo me è l'unica soluzione.Secondo me si riduce tutto un po' pensando alla coda in cassa quando vai a pagare nel senso che bisogna trovare la quadra in tutto e soprattutto anche in queste due cose quindi render 3d fighissimo nel caricamento quindi cercare di dare all'utente dividere le funzionalità il più possibile per dare all'utente sempre qualcosa quindi magari se abbiamo una roba fighissima un giochino qualche cosa dei canvas delle robe super belle magari non darle tutte in blocco iniziare a darle in maniera graduale perché così l'utente inizia a far qualcosa come diciamo prima no l'LCP quindi vedo la bot default vedo qualcosa sullo schermo inizio a far qualcosa e il resto si carica utilizzando un metodo che potrebbe essere cioè non un metodo lazy loading ma l'idea di lazy loading no di caricare in maniera lazy quando mi serve secondo me questo potrebbe essere la chiave di volta per riuscire a fare due cose così diverse tra loro che in realtà poi tanto non lo sono, perché comunque non è che stiamo dicendo che un sito non può pesare 20 mega, può pesare 20 mega, come dicevo prima, non è che dico che io la dv non le voglio caricare, perché magari la dv si porta dietro anche jquiri, questa parolone orribile, "oh jquiri", però magari le carico io.E io aggiungerei per riconoscenza.Esatto, le aggiungerei in un secondo momento, quindi magari prima carico qualcosa che per me è più importante, che essere banalmente la dv ok e poi carico qualcos'altro io penso youtube no youtube ti permette di far vedere dei video in 4k e quando ti carica il player o tutti quanti dicono il player di youtube o il player di netflix pam è partito ma se voi guardate la pagina youtube solitamente cos'è che carica il video e poi inizia a montare tutto il resto quindi per me questa roba qua c'è nel senso va applicata anche un po alle proprie properties voglio caricare che per me la cosa più importante in quel momento il video, carico prima il video e poi inizio a caricare le altre risorse.Per me è più importante che venga renderizzato tutto l'html, allora metterò tutti i miei JS in defer, caricherò il mio CSS in maniera sincrona, troverò un modo di qualche trick per poterlo caricare prima o caricare prima i font perché così almeno non ho sfarfallino in pagina e poi piano piano il resto arriverà da sé.Cosa fighissima che secondo me si può fare, cioè utilizzando una syncing port con webpack, utilizzando la Singapore in maniera ancora più aggressiva utilizzando gli observer, quindi caricando quel chunk di JS che descrive quella funzionalità solo se è presente in pagina quando sta per arrivare in view.Quindi sono tutte robe che sono un po' estremizzate perché ovviamente parlando di kanbans, parlando di cose un pochino più massicce, quindi giochi che possono girare sul browser web, però sono cose che secondo me piano piano ci si può arrivare, quando si parla anche sempre delle performance delle spa, a Angular React, uno dice Shadow DOM, adesso si iniziano a parlare anche di questi concetti, il DOM virtuale, questo Shadow DOM che comunque è presente in pagina e va bene anche a Google, secondo me piano piano ci stiamo avvicinando a questa realtà e sarebbe fighissimo secondo me portarla sempre più avanti.Quindi la mia risposta a questa provocazione, che è bellissima, è proprio questa, cioè capire l'importanza di quello che vuoi caricare e caricarlo passo passo, perché ovviamente tutto subito non si può fare, perché se tutto è importante niente è importante.Quindi dividiamo le cose e come quando mettiamo sul carrello della spesa, io sono una di quelle persone che gli piace fare i sacchetti fatti bene, quando carico le robe sul carrello, sul nastro che poi andrò a pagare, cerco di metterle una alla volta, non li appoggio tutte una sopra l'altra, perché poi quando mi trovo a imbustare la commessa lancia fortissimo, quindi mi troverò a imbustare in maniera molto veloce magari lo faccio male invece se le sistemo tutte bene poi la mia bustola carico come se fosse un Tetris.Allora non sono solo, quindi anche tutte le cose da mettere in freezer insieme.Organizzazione, bisogna prendere spunto anche da queste realtà per portarle sul nostro lavoro visto che noi parliamo sempre di qualcosa di intangibile secondo me è la maniera migliore per applicarla.Prendo un attimo un momento per ringraziare chi in questo momento ci sta offrendo da bere sono le persone che hanno donato una birra a Gitbar e che fanno sì che questo episodio possa essere registrato anche se oggi con mezzi di fortuna dal mio lato.E devo ringraziare Andre Ortu, Leo Properzi che ci hanno invitato una birra e anche Dev Schusd Francesco che oltre ad averci invitato una birra ci ha anche scritto un messaggio Donatori non ce ne sono, saltiamo la parte.Citazione.In realtà grazie a tutte e tre perché hanno reso le nostre uvvole un po' più idratate in questo episodio quindi alziamo i calici al cielo e brindiamo alla loro salute.Grazie di nuovo.ritorniamo a noi Matteo io ho un'altra domanda da qualche anno a questa parte sono esplosi, è esplosa la moda del, anzi è riesplosa la moda del server side rendering e dello static site generation quindi parlo dei grandi nextjs mio grande amato e Gatsby mio amante.Questi è improprio chiamarle così però io me ne sbatto e le faccio la stessa.Questi framework stanno democratizzando l'approccio alle performance da altro punto di vista, prendendo comunque delle decisioni abbastanza opinionate in fase di installazione, guarda per esempio alcuni tool che sono out of the box su Gatsby e su Next, come l'utilizzazione delle immagini per esempio, no? Anzi, forse su Gatsby è un plugin da installare, ma non lo installano tutti di default alla prima installazione.Quindi mi chiedo quanto questi tool stiano aiutando nella sensibilizzazione verso il mondo del performance? Allora io ti dirò che inizialmente, perlomeno con l'esperienza che ho avuto io, sembrava il contrario.Cioè non tanto perché sembrava un casino fare l'ottimizzazione di performance con loro.Perché "ah no, next.js mi restituisce la pagina che è un HTML super compresso, non riesco a mettere il critical CSS, non riesco a fare i pre-connect".Quindi inizialmente sembrava che fosse proprio il contrario.Quello che magari riuscivo a fare con qualcosa di un pochino più old style, old school, con questi framework, utilizzando la sua stessa parola, sembrava che non ci riuscissi a fare una roba del genere.Quindi ho detto "Caspita, ma com'è? È incredibile, questa roba è assurda.Tecnologie moderne così fighe non possono fare questo".In realtà non è vero, nel senso che ovviamente bisogna prendere alcune scelte, alcune decisioni, magari rinunciare a qualcosina e sicuramente anche quello adesso va un pochino per la maggiore e sta diventando un pochino più forte sicuramente magari con nuove versioni o upgrade di alcuni prodotti poi ci porteremo dietro anche qualcosina in più.Per dire io le ottimizzazioni basiche consiglio sempre a tutti quando mi chiedono "ah ma io voglio partire domani che cosa posso far subito?" le consiglio anche da applicare a Next o Gaps, quindi non le vedo come una cosa vincolante né positivamente né negativamente.Secondo me dipende sempre dal prodotto che hai come ci vuoi lavorare su.Non so se ti ho risposto.A questo punto ti devo girare la domanda che ti sei fatto da solo e quindi ti devo chiedere Quali sono le prime cose da fare quando abbiamo un sito e vogliamo migliorare in termini di performance? Allora, per partire domani con ottimizzazioni, prima di tutto bisogna farsi un esame di coscienza e capire che cosa abbiamo fatto oggi.Nel senso che se il mio sito non è per niente performante, ma magari lavorarci e metterci mano vicino vuol dire sacrificio enorme magari iniziamo a pensare di far qualcos'altro non nel senso di lasciar stare il proprio sito ma magari di farlo evolvere in qualcos'altro e pensando con le performance subito dall'inizio come dicevo prima cioè arrivarci troppo dopo rischi che poi c'è un muro invalicabile però ci sono cosine che una persona può iniziare a fare che possono aiutare io consiglio subito di fare i pre connect sulle risorse in head se noi abbiamo dei domini che sono al di fuori della nostra pagina dove noi andiamo a richiedere delle risorse come potrebbero essere delle adb, dei tracciamenti, delle cdn a risorse statiche, utilizzare il pre-connect subito in head, subito proprio dopo la dichiarazione di html che è un tag, un pre-connect con il source al dominio perché così facendo noi indichiamo al browser che dobbiamo stabilire una connessione a questi X domini.Una volta che noi abbiamo fatto questa cosa, ogni volta che il browser troverà una risorsa con quel dominio avrà già la connessione aperta.Ok? Si tratta di 0,00003 millisecondi perché per fare una connessione ci vuole presso che nulla, però sommate su una pagina fanno, fa comunque differenza.Quindi Preconnect è una cosa che che consiglio sempre.La sync o il defer del JS, perché vedo che c'è sempre tanta confusione sull'utilizzo di async e dell'utilizzo di defer, non di defer, lì dipende molto da che cosa dobbiamo fare in che momento, come dicevo prima, un po' lo stack, però io sinceramente consiglio di caricare tutto il JS sempre in defer, perché così almeno il defer lui cosa fa? Mentre interpreta il browser, interpreta tutta la pagina HTML, quindi inizia a disegnare la pagina, quando arriva un JS, se è in defer, lui va avanti a disegnare, intanto lo scarica.Una volta che l'HTML è finito, lo runna.Quindi io consiglio sempre di fare questa cosa qua perché perlomeno anche lì il JS magari si attiva su pezzi di HTML che magari ancora non sono arrivati, se noi non utilizziamo il defer.Quindi consiglio sempre di utilizzare il defer e in alcuni casi la sync.Altra cosa molto interessante, che sempre mi fanno mille domande che non si capisce cosa sia e come si fa, è il Critical CSS, che si applica a una metodologia che è il Critical Path, che si può applicare a 1200 cose, che applicata nell'ambito delle performance rappresenta un insieme di regole, quindi questo CSS rappresenta un insieme di regole che disegnano l'abodefault, quindi quello che noi vediamo subito sul nostro smartphone.queste regole qua vengono scritte direttamente in pagina, ok? all'interno di un tag style, ok? quindi il browser quando inizierà a disegnare la pagina avrà già le regole che gli servono almeno per disegnare la parte iniziale questa cosa qua che può essere più o meno banale dà un boost alle performance, soprattutto su alcuni KPI come sono l'LCP, quello che dicevo prima perché comunque noi abbiamo tutto il set di regole per disegnare quello che vediamo e l'utente ha già qualcosa di finito, quindi si può aprire il menu, si può tappare la prima card, il primo elemento e così via quindi questi qua sono tre, poi consiglio anche il "Lazy load" nativo, quindi l'utilizzo dell'attributo "loading=lazy" che adesso è supportato sia da Firefox che da Chrome, si spera che Safari si apri a un utilizzo speriamo che non diventi il nuovo Internet Explorer Io lo auguro! (risate) Io lo auguro ma...Trattiamo malissimo PHP quando poi potremmo prendercelo con Safari e mettere tutto in un lavoro.Esatto! Parliamo mai di Safari? Safari 14, grazie! Una cosa sul Critical Path, quello aiuta anche nel momento in cui, perché ci sono molte pagine che magari caricano i contenuti successivamente, però disegnano dei placeholder, tipo delle immagini grecine in caricamento, per far capire "ok, ti ho caricato questo, quindi Google è contento" Sì, sì, allora, quello che mi dicevi tu fa parte delle ottimizzazioni sul CLS e praticamente, facciamo piccola digressione, quello che dicevamo, no? Il fatto che la pagina trasli per combattere questa cosa qua bisogna cercare di dare degli ingombri a tutto infatti Google consiglia di cercare di utilizzare delle altezze minime o delle altezze ben definite, ok? Perché se noi abbiamo dei box con...adesso si vedono tanti, eh? magari con scritto ad grigino con scritto ad sappiamo che un box della dv e poi magari la dv arriverà un secondo momento o abbiamo dei form o degli i-frame ok i frame magari vengono utilizzati a un sito che deve metterci dentro i dati che arrivano dal querinale non so un esempio che ci abbiamo gli i-frame con tutti quei dati magari ci mette un attimo a rispondere e noi lasciamo un bel box colorato così google capisce che c'è un ingombro ma l'utente capisce che c'è un ingombro perché poi google sta cercando di emulare quello che fa l'utente e quindi è un'ottimizzazione e quindi per lui va bene come va bene per una persona.Ha capito che lì c'è qualcosa, no? Perché comunque i nostri udenti non è che sono degli ebidi, è che sono delle scimmiette che scrollano e basta.Sì e no.Ehm...Anche questa è una provocazione.Mi sto facendo un sacco di terrabucciate attorno e mi sto divertendo tantissimo.Ehm...Ehm...Comunque, come dicevo, no? Facciamo queste ottimizzazioni.Per quello che dicevi tu, col critical, in realtà noi stiamo dichiarando quello che è sopra.queste cose qua possono essere all'interno anche del CSS.Quindi il critical ci disegniamo la parte subito.Altra cosa che si può fare insieme al critical è la dichiarazione dei font.Tenere la dichiarazione dei font visto che i font sono altre di quelle cose pesanti perché magari voglio il gothic graziato bellissimo sul mio sito che non ne capisco il perché però voglio il comics sun più simpatico ancora però magari è un font che pesa 500k o magari pesa un mega e che vuol dire tre secondi ragazzi quando si scarica un mega di se abbiamo una connessione che non è velocissima 3 secondi sono tanti eeehm caricando i font così, mettendoli all'interno di un tag style come per il critical css e avendoli abbastanza in alto, quindi all'interno del led cercandoli di tenere abbastanza in alto li abbiamo subito quindi il browser magari mentre sta disegnando sta iniziando a disegnare la pagina, li ha già scaricati quindi noi evitiamo che poi la pagina venga utilizzata un font di sistema che poi in realtà è abbastanza impossibile, quindi avremo sempre un font di sistema.Infatti quello che consiglio io è cercate di avere sui siti dei font che si avvicinano sempre di più ai font di sistema perché così almeno quando avremo questo cambiamento di stato del font il movimento della pagina sarà minore, ok? Quindi li carichiamo così in un tag style in modo che insieme al critical riusciamo a dare all'utente subito qualcosa che è diciamo il 98% completo, poi il resto della pagina arriverà il quinto secondo.il quinto secondo avremo sicuramente già il CSS, magari avremo anche il JS, quindi avremo tutte le nostre cose e l'utente non si sarà neanche accorto del cambiamento di stato.Quindi è il trick, per questo dicevo che il critical probabilmente di queste operazioni è quello che più ti dà il boost.Poi il lazy loading nativo, molto molto comodo anche se si parlava male di Safari, perché comunque ha impatto zero sullo sviluppo perché devi aggiungere un tag, lo si può usare sulle immagini, lo si può usare sui iframe, è comodo.Poi se non hai la possibilità, perché il tuo sito viene utilizzato solo da utenti che usano Safari, magari come l'esilord utilizziamo una libreria javascript che potrebbe essere YAL, che ti va a cambiare o banalmente, tu ti scrivi un JS che ti va a prendere la tua IMG, gli metti un data source set, quindi data-src, utilizzi i data attribute e quando entri in view gli vai a cambiare il data source set alla source, cioè prendi il data source e te lo metti a posto della è una cosa che si può fare.Altre ottimizzazioni così, un'altra che mi vien da dire che secondo me nel 2021 non può mancare è quello che dicevo prima, il service worker.Adesso io utilizzo sempre questo motto che a mia volta ho ascoltato in un talk, che è "Stipka trovo"."Stipka trovo" vuol dire "conserva quello che trovi".Il service worker, cioè per esprimere il concetto di service worker non c'è un detto migliore di quello.Quindi come avevo spiegato prima è una cache lato client ed è comodissimo perché appunto ti permette di avere X funzionalità banalmente la navigazione offline, ti permette di installare la progressive web app che sembrava che fosse il futuro poi c'è stato un po' una frenata non si capisce se sarà figo o non sarà figo però comunque è comodo perché comunque è una scorciatoia sulla tua home che ti porta al sito più performante.A livello di performance vai in a bomba perché comunque le risorse vengono cached all'interno del tuo browser e ci sono varie metodi un po' come il TTL quindi puoi dire la risorsa me la tieni controlla che sia presente sul server nuova me la riscarichi oppure ti tieni prima questa e poi fai il controllo e poi la cambi oppure tienila per x giorni.Io uno che utilizzo è sempre quello di Google è Workbox, che consiglio, che secondo me è carino.Famosissimo.Famosissimo Workbox, esatto.Ed è, secondo me, una cosa abbastanza carina.Cioè, dare la possibilità all'utente anche di avere una navigazione offline, secondo me è una cosa che mi ha sempre stimolato.Quindi, è bellino quando trovi un sito che magari c'è quell'articolo che non riesci mai a leggere.Magari ti rientri lì e quando sei sull'aereo che devi essere offline, magari l'articolo ce la fai a leggerlo, no? Quindi, quello secondo me è una cosa molto carina.Per partire, facendo un po' un sunto di queste ottimizzazioni, i Preconnect, il Critical CSS, l'easy loading nativo e se hai la possibilità che magari ci metti un pochino più di mani ci butti dentro anche i service worker o magari iniziare ad approcciarsi, un approccio a l'easy load ma su tutto, nel senso caricare le cose solo quanto servono.Banalmente è una synch import di Webpack, io sto parlando di frontend, quindi parlo principalmente di frontend, una single port di webpack potrebbe essere una cosa molto simpatica quindi se hai un hook in pagina che quell'elemento è effettivamente in pagina, ti raggiungi il JS che serve per gestirlo, se no va avanti.Che ci permette di avere un bundle sizing, quindi il JS che in quel momento è presente in pagina è minore con fronto a avere sempre tutto, perché magari poi è una cosa che non usi e quindi è inutile portartela dietro.Questa cosa qua, come dicevo prima, per me è davvero il core e quindi io spero un giorno di vedere delle robe fighissime fatte in questo modo anche con la domanda che mi hai fatto prima, quel seme della discordia, performance, webGL, così distanti tra loro.Io spero che un argomento fatto in questo modo possa essere poi il futuro, sarebbe molto figo vederlo fatto in questo modo.Ho visto che stiamo andando abbastanza lì, quindi chiedo a Leo se ha qualche domanda.Ho una domanda un po' diciamo filosofica perché sono impressionato da la quantità di informazioni che sono state dette ora e mi fa pensare ma non è che tra un po' un futuro magari più vicino di quello che pensiamo chi si occupa di performance, cioè sarà un lavoro come dire c'è il back-end developer, il front-end developer e l'esperto di performance che governa i front-end dicendo magari te l'hai nominato prima forse i QA o dei QA specializzati nelle performance che mi sembra che ci sia talmente tanta roba che ormai non si può nemmeno più dire che un frontender si deve occupare anche di quello perché deve occuparsi anche di come si sviluppano i frontender non so come la vedi te? Guarda, per me che adesso mi occupo di performance sarebbe una figata perché far questo sarebbe dovvero il sogno di una vita cioè nel senso occuparmi solo di questo sarebbe molto divertente.Ovviamente io non penso, nel senso che, come dicevo prima, sarebbe bello che a tendere le performance diventassero anche delle best, cioè proprio che siano delle best practice, quindi che tutti quanti, anche il back-end, anche il qua capisse più o meno, avesse sensibilità su cosa fare, quando farlo e come farlo.so che sono una marea di informazioni, però non è che ci servono tutte per forza, nel senso che una volta che noi abbiamo impostato il nostro progetto sappiamo che il critical è fatto in questo modo, i pre-connect servono in questo e quando scrivo il JS magari lo faccio in maniera sincrona e poi è una cosa che ti viene naturale, è un po' come iniziare ad andare in bicicletta, poi piano piano immagini sempre più chilometri, quindi secondo me sarebbe molto figo se ci fosse una figura del genere, magari accumunabile a diverse tipologie di figure, magari un frontend che è diventato un po' più manageriale, quindi magari fa un po' più il QA, magari sono diverse figure che si fondono insieme, ma a tendere per me dovrebbe essere qualcosa che abbraccia tutti e quindi è come se parlassimo di testing, come dicevo prima, il paragone col testing, quindi si pensa al test, quando si pensa al test ok che tu dici è sviluppo, quindi io ho delle competenze di sviluppo, le applico anche al test, ma secondo me anche le performance possono diventare così.Tra l'altro in un'ottica di team cross funzionali questa roba ce l'avevamo.Io ho una domanda invece che riguarda il learning path.Quali sono gli elementi e soprattutto le fonti da dove attingere per la costruzione di un learning path verso la direzione dell'apprendere questo mondo e dell'entrare in questo mondo.Allora, Adios Mani è un supervate quindi andatevelo a cercare su Twitter e tutte le cose che ha fatto lui sono fighissime quindi per me è sempre stato un...Lo conosco pure io, pur essendo ignorante l'ho sentito dire pure io quindi è proprio grosso.è grosso, è uno di Big G quindi nel senso è davvero davvero davvero davvero un grande.Tra l'altro si è inventato un brand legato alle performance con delle magliette fighissime che prima o poi devo comprare soltanto che essendo sempre io da solo non riesco mai ad acquistare dall'America perché poi è un casino quindi se c'è qualcuno che ascolta e vuole fare i contatti che così compriamo maglie fighissime.Comunque allora in Italia adesso stiamo iniziando a parlarle io ho sempre seguito i ragazzi di un'azienda che si chiama MODO che loro sono molto bravi, Matteo Fogli è sempre stato una persona abbastanza luminare in Italia sulle performance, quindi io consiglierei di andarvelo a cercare, di ascoltare quello che dice e partecipare alle conferenze, perché adesso piano piano parleremo sempre di più di questo argomento, ed essere curiosi, perché secondo me non c'è ancora una base enorme che ti dice "ok, questo è il libro delle performance, tieni e studiatelo", come potrebbe essere magari per la fortuna di lei un PHP che comunque dice ok c'è un grande scritto un manuale super super figo, ti prendo per il culo perché è divertente, che dice cos'è che era PHP 7 che era quello morto o il 6 non mi ricordo.Il PHP è morto tu.Il 6 non è neanche nato.E quello lì magari c'è il manuale di PHP 6.Il manuale mai venduto di php6.No, no, c'è il manuale di php6, manca il php6 ma c'è il manuale di php6, io l'ho acquistato.Speravano che uscisse e sarei primi, a volte il time to market non funziona.E poi vabbè, comunque sul web c'è davvero tanto, se si scrive web vital su google si trovano tante tante cose.Il css day, salutiamo, saluto il Graspo, ne approfitto per fare un pochino di pubblicità, loro parlano sempre di questa cosa qua.Peraltro siamo anche parte.grande patatoni e quindi sì di essere un pochino curiosi di cercare un po' sul web poi magari mi cercate su link di Matteo Lullo o su instagram twitter o twitch reddoig magari ci facciamo un'altra chiacchierata per sempre un po' parlare di queste cose e poi magari vi passo un po' di robe di robine interessanti vi lascio magari qualche link qualche cosa va bene Ottimo, naturalmente come nostra tradizione è arrivato il momento del Paese dei Balocchi E con tu come il Paese dei Balocchi? Ah il Paese dei Balocchi! Eh non lo so, cioè nel senso risponderei con un po' con avere la curiosità cioè nel senso il consiglio che vi do io è farvi la domanda nel senso per chiedersi, cioè per appassionarsi delle performance bisogna un po' capirle quindi bisogna chiedersi ma che cosa sono le performance, cioè cosa ne so io di performance, quindi avere quella voglia di andare a scavare un po' e a capire che cosa c'è dietro, perché essere risultivo a dirvi "ah no, leggetevi questo libro, andate a leggervi questo articolo su Medium" o X secondo me sarebbe tra virgolette anche un po' banale, perché poi quando vediamo un po' anche quello che racconto io è la visione di un singolo, quindi per me invece è molto di più, molto di più, infatti mi piace molto andare alle conferenze perché poi dopo ho la possibilità di vedere anche quello che pensano gli altri quindi essere un pochino curiosi è la mia risposta a quello che vi consiglio su questo argomento quindi siate curiosi.Oltre ai tool che ci hai elencato durante la core che voglio dire sono...Si certo certo ma quello è partire tecnico invece qua mi sembrava più un po' tipo Paese dei Balocchi inteso come più emotional se posso dirlo invece technical sì Lighthouse, WebPagetest, Sidespeed.io, Speedcurve, Pingdom, ce ne sono tanti poi si trova quello che capisce un po' meglio, io consiglio i primi quattro che ho detto e per me sono abbastanza funzionale quindi su quelli mi trovo molto bene e altra cosa che secondo me è fondamentale che dovrebbe essere un po' un motto di quelli che fanno performance è "se posso farlo con il css meglio quindi tutte quelle animazioni che poi ci ritroviamo sempre a scrivere con una marea di javascript se le facciamo col css potrebbe essere un pochino meglio quindi questo vuol dire anche quando approccio un problema cerchiamo di semplificarlo no voglio un super translate che quando apro il pop up faccia il giro sì va bene cerchiamo di farlo col css quindi magari mettiamo meno animazione però comunque più funzionale e quindi anche il lato performante ha più impatto e poi basta con i flotti, utilizziamo il flex e le grid, basta con i flotti che sono pesanti per il browser.Io sono molto terra a terra e anche abbastanza problematico e vi consiglio invece un articolo.Vi consiglio questo articolo perché in realtà proprio in questo momento del percorso professionale sto lavorando affinché il business abbia la sensibilità in termini di performance e di accessibilità e soprattutto l'impatto che hanno questi due elementi verso il business.faccio un esempio molto semplice proprio oggi discutevo con un collega la rimozione di un hero video dall'home page ha portato un +X di conversione e l'abbiamo visto in modo molto chiaro dai chart di amplitude quindi è stato chiarissimo con un A/B test abbiamo abbiamo visto l'effetto e proprio in In funzione di questo voglio suggerirvi questo piccolissimo articolo che si intitola "How Wallman correlates web performance to business performance" e cosa aggiunge? Nulla.Buttateci un occhio perché in realtà andare a vedere questa correlazione può essere veramente interessante.Leo tu hai qualcosa? Io ho una cosa che non si occupa di performance, non migliorerà la vostra esperienza lavorativa, anzi, peggiorerà le performance, però sono rimasto colpito oggi da questo gioco su browser che è super addictive, è difficilissimo, e si chiama DDD, dot dot dot, non so nemmeno quanto è vecchio se è una cosa di ora.In pratica casca una pallina, che è un diciamo un div fatto circolare, e la dobbiamo portare verso un altro div che sta in un posto random del viewport, utilizzando dei blocchi che mettiamo col mouse.Quindi la palla ha una gravità, mettiamo questi blocchi dove la palla rimbalza e rimbalzando dobbiamo portarla, se la facciamo rimbalzare troppo, tornare indietro a passare sopra questo buco e si va a livello successivo.Il problema è che i blocchi che mettiamo sono circolari quindi non rimbalza dritta quindi è molto difficile vi farà perdere un po di tempo però siamo anche in estate alla fine dobbiamo alleggerirci un po e quindi io vi porto questo questo piccolo passatempo che comunque è correllato con le performance perché è una di quelle cose che ammazza, è velocissimo a caricare, ma è anche una di quelle cose che ammazza le performance lavorative, e poi possono essere migliorate successivamente come aumentare il prezzo e poi fare gli scopi.Ma no, è quello un po' un po' metti la cera togli la cera quindi uno poi diventa più reattivo perché sa come mettere i cerchi bene e anche quando poi scrive è più veloce.Esatto, poi i giochi piacciono a tutti.E' bello.Fantastico, però mi dispiace sarei rimasto un altro paio di ore ma sta giornata lavorativa bisogna pur iniziarla quindi...Anche se stiamo registrando fuori dall'orario di lavoro.Si, si, si.e beh ragazzi allora ne approfitto io per ringraziarvi perché comunque è stato molto divertente la prima mia esperienza podcast quindi super figo super super super figo tra l'altro c'è sempre un podcaster nato e utilizzo e ma te l'ho detto è fare il master di Dungeons & Dragons ti insegna a utilizzare la voce vero vero ma anche i tempi perfetto è arrivato però il momento dei saluti quindi intanto ringrazio Matteo e ringraziamo Matteo per essere venuto a trovarci come il nostro solito sappi che Gitbar da oggi è diventato anche un po' casa tua quindi quando è qualcosa di interessante da raccontarci vieni pure a trovarci una birra fresca c'è sempre.Ringrazio anche Leo che...Che le birre fresche con Matteo se ne è prese tante quindi ho anticipato i tempi è stato molto piacevole.E soprattutto mi ha aiutato in questo episodio anzi ha governato questi episodi dove le mie performance in termini di singolo sono veramente basse.Prima però di salutarvi e di ringraziarti di ricordarti i contatti ci tengo a salutare una persona, prima di farvi un po' di casino perché devo trovare il messaggio che questa persona ci ha scritto si tratta di Smilzao che qualche giorno fa ci ha messo una recensione su Apple Podcast scrivendo scoperto da poco e per caso mi tiene compagnia sul treno, mi antreva da lavoro e mi aiuta a comprendere meglio il vasto e spontanato mondo dei developer e anche a sentirmi meno solo nelle pericolose giornalie del mondo non sei da solo amico ti capiamo perché siamo tutti sulla stessa marca detto questo io ringrazio lo stesso gruppo telegram perché smilzao è anche un utente del gruppo telegram così tanto stiamo per dare i contatti giusto giusto e allora leo a te l'onore Allora vediamo se ricordo bene se siete dei boomer email info@brainrepo.it o gitbar.it @brainrepo su twitter se siete un pochino più in là però se avete bisogno del contatto molto più più stretto con noi con la community venite sul gruppo telegram che trovate scrivendo gitbar se poi vi fa piacere fate come smilzao e lasciateci una recensione su apple podcast Dovete sapere, grazie a queste recensioni, noi riusciamo ad arrivare nella testa dei podcast suggeriti.Questo potrà sembrare una richiesta in termini di orgoglio, vogliamo essere figli, vogliamo essere i primi, non è così, ma grazie appunto a trovarsi in quella posizione ci permette di raggiungere dei nuovi ascoltatori e quindi fare entrare nuove persone nella nostra allegra affanetta per cui se vi fa piacere spellinateci e scrivete anche i due dita se non vi fa piacere fate lo stesso esatto non costa nulla grazie comunque per essere averci seguito fino a quest'ora con questo io credo da devo dirlo una Tunisi durante un colpo di stato io vi saluto io vi saluto da una Firenze che sembra Tunisi senza il colpo di stato per via del tempo e io dalla provincia di Milano, è un caldo incredibile però va bene.Grazie Matteo grazie a voi ragazzi, saluto vero bello.Alla prossima, ciao! GIT BAR il circolo dei fullstack developer una volta a settimana ci troviamo davanti a due birre e con Brain Repo parliamo di linguaggi e tecniche di sviluppo web, di metodologie e di strumenti immancabili nella la cassetta degli attrezzi dei Full Stack Dead.
