 Iniziamo con l'intervento di Igor Deli che è un giovannissimo esperto in sviluppo web per un'agenzia milanese, è giusto? E oggi ci parla di un argomento molto importante di cui tutti dovremmo, quando gestiamo un sito web dovremmo avere qualche base perlomeno ovvero i trucchi per rendere veloce il nostro sito web. Quindi lascia la parola a Igor e poi domande dopo preparatevele se ne avete. Grazie. Grazie a tutti, buongiorno. Io sono Igor, mi occupo dello sviluppo di siti web. In questo talk oggi vedremo otto trucchi, ovvero otto step per velocizzare un sito web. Una presentazione brevissima su di me. Lavoro come consumente digitale, ottimizzo i siti web con l'obiettivo di fornire delle soluzioni veloci e che quindi possano incrementare le vendite di un'azienda o di un professionista. Ma partiamo subito. L'importanza di un sito web veloce, oggi si parla sempre più spesso di siti web con WordPress sia la possibilità di realizzare siti in maniera semplice alla portata di tutti. Con questo si aggiungono plugin, temi multi purpose e così via. Abbiamo dei siti sì che sono belli però sono lenti da caricare. Per quanto riguarda quindi l'importanza di un sito web veloce entra in gioco l'asseo. Come sempre di più Google tiene conto la velocità del nostro sito web come fattore di ranking. Google non solo vede il tempo di caricamento della nostra pagina ma vede anche tutti quei dettagli che influiscono sul caricamento. Quindi sia il page load time, il peso della pagina, il time to first byte per quanto riguarda l'hosting ed altri dettagli. Quindi è importante ottimizzare il sito sia per ottenere un buon posizionamento su Google che per ottenere anche dei risultati per quanto riguarda la user experience. È provato ormai che utenti tendono ad abbandonare un sito web che impiega oltre tre secondi a caricare. Quindi un sito web veloce si converte in un sito web che funziona per Google quindi potrà essere posizionato sicuramente in maniera migliore. E sia per gli utenti che tendono sempre a volere una risposta immediata e quindi vogliono il sito web veloce per avere subito la risposta. Un sito web lento che impiega più di tre secondi a caricare circa il 40% degli utenti abbandona il sito immediatamente e di questo l'80% non ci torna più sul sito. Questi sono dati presi da internet da blog comunque autorevoli. Allora partiamo subito con il primo punto di questo talk. Il primo punto parlere a di performance test ovvero tutti quegli strumenti che ci permettono di analizzare le performance della nostra pagina. Avere questi strumenti è importante. Tuttavia non bisogna focalizzarsi semplicemente ad ottenere un punteggio 100 su un tool piuttosto che l'altro. Ma bisogna andare ad analizzare questi dati e trarne degli spunti per andare a sistemare eventuali problemi che rallentano la velocità della nostra pagina web. Prima di tutto come si può pensare Google si può pensare che utilizzi page speed insights per analizzare le nostre pagine invece non è così. Google non utilizza page speed insights non utilizza la funzione performance di analytics ma utilizza un altro strumento che fa il crowdsourcing da dati di utenti reali. Quindi è necessario ottimizzare il proprio sito non tanto basandosi semplicemente su questi strumenti ma andando ad analizzare bene tutti i dati per capire qual è il tempo totale di caricamento di una pagina. Quindi Google analizza i siti web grazie a questa estensione di Chrome che installiamo direttamente l'utente e stalla e prende i dati per capire se il sito va veloce. Raggiungere punteggio 100 su page speed non deve essere l'obiettivo finale. Può esserci un sito che si ha un 100 su page speed piuttosto che una su gt matrix che però non è effettivamente veloce perché perché il test non è stato effettuato in maniera corretta piuttosto che è stato utilizzato una posizione del test troppo lontana rispetto al target di riferimento del nostro sito. Quindi potremmo riscontrare dei valori che non sono poi così attendibili. L'analisi del sito si deve basare sia su una parte back end che su una parte front end bisogna lavorare si sulla parte front end quindi solo ottimizzazione delle risorse javascript css immagini e così via. Ma bisogna lavorare anche sul back end perché è questo che influisce un 20 per cento del restante 80 delle performance di una pagina web. Il secondo no sempre il primo quali sono i valori da tenere in considerazione quindi per analizzare una pagina web. Il primo punto è il total page sites ovvero il peso totale che una pagina può essere l'on page o qualunque altra pagina. Il peso totale è determinato da tutte le risorse che la compongono quindi dalle immagini dal dal javascript al css solitamente il peso ideale di una pagina web può essere tra un megabyte un megabyte e mezzo. Poi ci sono pagine che per necessità esigenze differenti possono pesare anche di più e lì allora si va a lavorare su altre tipologie di ottimizzazione. Il secondo punto è il first paint ovvero il tempo necessario per vedere il primo contenuto visibile nella pagina in questo caso si parla di velocità percepita quindi il sito carica sin 4 5 secondi ma l'utente comincia a vedere il primo contenuto già dopo il primo secondo secondo. Per utilizzare il first paint si può utilizzare la tecnica della bovdefold quindi che elimina tutto il css che va a bloccare il rendering della pagina in questo modo rendiamo subito visibile l'utente il testo piuttosto che il titolo di un articolo se parliamo di un blog e rendiamo disponibile in un secondo momento. Il footer leader il menu e tutte le seconde parti che compongono una pagina web. Il terzo valore da tenere in considerazione è il page load time ovvero il tempo di caricamento che impiega una pagina web a caricare è importante basarsi sul sul valore in secondi del caricamento della pagina web. Bisogna valutare la posizione da cui si effetto al test ed altri dettagli che entrano in gioco su sull'analisi di una pagina. Il quarto punto è il time to forced bite ovvero il tempo che impiega il browser dell'utente a raggiungere il server ogni file javascript ogni file css ogni immagine effetto una richiesta http al server. Quando quindi il numero di richiesta http anche è notevole il tempo per effettuare in ogni una conta possiamo quindi si avere un sito che impiega tre secondi a caricare ma poi ha un time to forced bite dovuto a problemi sull'hosting che ne aggiunge un altro in più piuttosto che si parla di mili secondi solitamente. Il quinto punto sono le richieste ovvero quante richiesta http fa una pagina web quante richieste fa per il css per il javascript e per le immagini poi bisogna tenere conto le richieste interne e richieste esterne le richieste interne ovviamente sono più rapide essendo nella rete locale del nostro hosting mentre le richieste esterne impiegaranno più tempo a raggiungere la destinazione. Il sesto punto da tenere in considerazione il paese di origine del test tutti gli strumenti che ci sono per analizzare le performance di una pagina fanno scegliere la località del test questo influenza molto il risultato che si ottiene quindi è necessario scegliere una locazione del test in base al target di riferimento del nostro sito. Se poi si parla di siti fruibili a livello internazionale possiamo utilizzare il test su più paesi anche per verificare l'efficacia della nostra cdn piuttosto che del DNS. Il secondo step è proprio il server DNS che spesso è un un fattore che non viene preso in considerazione fin da subito quando si fa la scelta del hosting provider. L'hosting si sa che è uno dei fattori fondamentali per la velocità del sito web per il successo del sito web ma è importante anche sapere che è necessario una velocità del server DNS e risolvere un nome di dominio in dritzo P in tempi rapidi. La posizione del datacentere quindi sia un fattore fondamentale per il sito web e anche il server DNS che deve essere posizionato in più punti qualora il sito fosse fruibile in più paesi. Ci sono casi in cui il sito può essere disponibile su un server dedicato, su una macchina in cloud o comunque un hosting performante. Ma il dominio si trova su un hosting su un register scarso diciamo dove il DNS non riesce a risolvere le richieste in tempi accettabili e quindi potrebbe anche sovraccaricarsi o essere addirittura saturo e non riuscire ad inoltrare il traffico alla nostra macchina di hosting. Come funziona la risoluzione del DNS? La risoluzione del DNS consiste semplicemente nella traduzione del nome di dominio quindi www.ilnostrosito.it in un indirizzo P. Questo compito lo fa il domain name system che deve risolvere nel minor tempo possibile la richiesta del nostro utente. Se il nostro DNS server è in Italia e ci visita un utente dagli Stati Uniti ovviamente il tempo per risolvere questa richiesta sarà maggiore, più l'utente lontano sarà maggiore. Per ovviare a questo problema si può utilizzare qualsiasi servizio come cloud flare ad esempio che metta a disposizione dei name server in base alla location dell'utente che ci visita che si auto populano con i nostri record. Quindi l'utente otterrà una risposta immediatamente dal nostro DNS più vicino e di conseguenza da un eventuale cdn per rendere fluibili contenuti con le immagini e le risorse statiche. Il terzo punto è la cache client side quindi quell'area del computer, del dispositivo dell'utente che ci visita che ha il compito di memorizzare tutti i contenuti statici del nostro sito. Quando un sito web quindi viene memorizzato nella cache dell'utente si intende che sono stati archiviati nella sua memoria fissa del computer o del cellulare in modo che la seconda volta che verrà a visitare il sito riuscirà ad accedere più velocemente e grazie a questo storage a livello locale. Ogni volta che l'utente effettuarà una richiesta al sito non dovrà effettuare una query, effettuare una chiamata al server HTTP, al server DNS per risolvere tutte le query del database ma avrà semplicemente una risposta di un contenuto statico. D'altra parte abbiamo la cache server side che ha lo stesso concetto della cache dell'utente non avvene fatta lato server, senza la cache server side l'utente che vi sta al sito avrà come risultato una risposta di una pagina HTML che viene generata dinamicamente richiamando degli script PHP che ne richiamano altri che di conseguenza richiamano delle query al database fanno. Mentre con la cache server side il sistema di caching fornisce all'utente una pagina statica in HTML che è già stata generata una prima volta alla modifica della pagina o alla prima vista dell'utente senza dover richiamare tutte le volte script PHP e query al database. Il quarto punto che può incitare molto sulla velocità del sito web soprattutto quando ci sono tante immagini e tante richieste HTTP quindi è il lazy loading. Il lazy loading è una tecnica di ottimizzazione del sito web che consiste nel caricare una risorsa solo quando è necessaria da parte degli utenti. Perché devo caricare tutto quello che c'è below the fold quindi che non è nel viewport dell'utente quando posso caricarlo semplicemente al momento della necessità. Il lazy loading effetta quindi il caricamento di una risorsa in modalità on demand come dicevamo l'utilizzo della tecnica lazy loading consente di risparmiare tempo di caricamento quando le immagini piuttosto che qualsiasi alta risorsa ha un numero abbastanza notevole. Il quinto punto sono le immagini svg. Le immagini svg sono delle immagini scalabili che ormai sempre di più si cominciano ad utilizzare sul web e consentono di mettere a disposizione un'immagine scalabile e vettoriale. Da oltre 15 anni il formato svg è una standard del v3c il world web wide consortium ma soltanto ultimamente negli ultimi anni è stato cominciato ad utilizzare effettivamente su tutte le pagine web. Perché questo perché il nostro internet explore anche non ha mai fornito il supporto completo svg quindi aveva una limitazione per gli utenti che visitavano il sito da questo browser. Tuttavia negli ultimi anni sono stati implementati e reso e reso standard per tutti i browser. Quindi un'immagine vettoriale a differenza di un'immagine a pixel quindi un'immagine bitmap è possibile ridimensionarla senza perderne la qualità e è possibile renderla disponibile per tutti i dispositivi in maniera scalabile. Un buon modo di cominciare con l'svg sono sicuramente le icone creare risparmiale spazio sull'icone può influire anche questo sulla velocità del sito web. In questa slide vediamo la differenza del peso tra un'immagine png e un svg di un icona di un sito. Ha preso questa icona che ho inserito ultimamente in un sito in png pesa a 215 kilobytes mentre in svg ne pesa a 13 questo è un banalissimo esempio della differenza di peso. Stiamo parlando di dimensioni molto basse però su delle immagini magari di una certa dimensione è possibile risparmiare diversi kilobytes. Il sesto punto sono le richieste che fa il browser quindi il nostro utente al nostro server. Una pagina web composta da risorse JavaScript, da risorse CSS, da immagini e da molte altre risorse. Ognuna di queste è una richiesta al nostro server. Qual è il numero ideale di richieste HTTP che deve fare un browser al nostro server? Non c'è un numero ideale. La prima ipotesi che tutti possono pensare, minifico tutto e vado a concatenare tutte le risorse JavaScript e tutte le risorse CSS in un unico file. In questo modo sì abbiamo creato una sola chiamata HTTP per il CSS ed una sola per il JavaScript ma stiamo fornendo un file che è pesantissimo. Quell JavaScript e quel CSS non sarà necessario su tutte le pagine quindi è necessario anche fare un'analisi dettagliata di quali risorse servono su quali pagine e di conseguenza poi andare a concatenare tutte le risorse in una, due o tre richieste per il JavaScript e altre per il CSS. Per diminuire le chiamate HTTP ho portato questo caso che mi è capitato su un sito ma capita spesso. Parlo del plugin WPML. Questo plugin solitamente il language switcher mette tutte le bandiere delle traduzioni del nostro sito. Ognuna di queste effettuano la chiamata HTTP. Mi sono trovato su un sito che era tradotto in oltre 30 lingue con 30 chiamate HTTP a delle immagini che si avevano dei pesi risori dal punto di vista del peso ma erano comunque delle chiamate HTTP che avevano un time to first bite e quindi rallentamento per il sito. Utilizzando la tecnica del CSS e mailspride è possibile creare un'unica immagine che le racchiude tutte. Solitamente si utilizza molto sulle icone o su tutti quegli elementi grafici che compongono una pagina. Così da fare una sola chiamata HTTP dal nostro CSS e rendere visibile solamente la parte che ci interessa. Qua vediamo l'esempio che dicevo di WPML che richiama un file PNG quindi una richiesta HTTP per ogni bandiera del selettore della lingua. Utilizzando il CSS e mailspride è possibile unire tutte le immagini in un'unica immagine principale richiamata una sola volta. E tramite il CSS definiamo la regola che va a richiamare quella parte dell'immagine che contiene la bandiera italiana. Quindi dell'HTML richiameremo semplicemente la regola CSS. Questo può essere un buon modo per andare ad ottimizzare alcuni aspetti che rallentano il sito effettuando più richieste HTTP. Il settimo step sono il DQ&Q che si tratta semplicemente del richiamare o non richiamare delle risorse nella nostra pagina web. In informatica il DQ&Q ha un significato leggermente diverso mentre quando si parla di work questo si parla richiamare o non richiamare delle risorse CSS o delle risorse JavaScript. Come dicevamo prima tutti pensano di riuscire di poter richiamare un unico file JavaScript o un unico file CSS unificando tutto. Tutto il JavaScript e tutto il CSS ma non sempre così appunto perché se no troviamo delle risorse che sono pesantissime. Quindi è necessario fare un'analisi di cosa serve e su quale pagina serve al fine di avere il file più leggero per ogni pagina ad hoc studiato per quella. Un esempio è contact form 7 quanti utilizzano contact form 7. Più o meno tutti penso un 80% utilizzerà questo plugin per i formi di contatto nel 90% dei casi contact form 7 è richiamato solo nella pagina contatti. Però il plugin di contact form 7 richiama il suo CSS che define lo stile del form e richiama il suo JavaScript che serve per fare l'autolavalidazione dei campi. Inseriti dall'utente lo richiamo su tutte le pagine. Questo non è necessario quindi tramite il the queue and queue riusciamo a inserire questa semplice regola nel nostro functions punto PHP del tema per andare ad eliminare. Ad esempio in questo caso il CSS di contact form 7 mandrebbe fatto anche col JavaScript andare a eliminarlo da tutte le pagine. E richiamarlo semplicemente con un if solamente sulla pagina che ha come ID quella della pagina contact. Un altro esempio potrebbe essere revolution slider che si trova quasi sempre nei tutti i siti con temi multipurpose richiama le sue risorse. Spesso anche molto pesanti su tutte le pagine quando la un page quella che lo utilizza principalmente. L'ottavo punto è il protocollo qui il protocollo qui è un nuovo protocollo introdotto da Google ufficialmente nel 2017. Che consente di anche qui dire ottenere delle prestazioni maggiori in alcuni casi sulle nostre pagine web. Non è ancora integrato ufficialmente ufficialmente non è ancora integrato principalmente in tutti i browser ma Google su su Chrome. Ha già cominciato a farne utilizzo qui che sta per qui UDP internet connection. E da l'obiettivo di prendere tutto ciò che ha di buono il protocollo TCP attualmente utilizzato ed integrarlo con UDP. UDP è un protocollo basato su su l'internet protocoll che è da sempre preferito per le sue basse latenze. Nell'ambito del gaming è molto utilizzato appunto perché non c'è bisogno di una risposta dal server di destinazione come fatti cp. È possibile risparmiare tempo sulla sulla latenza di connessione con il nostro server. Google sostiene che qui riesca a velocizzare le loro pagine sul motore di ricerca di un circa un 3% che visto così può sembrare poco ma è sempre uno step per arrivare ad ottimizzare il nostro sito. Su siti web con maggiori risorse siti web più pesanti e meno ottimizzati piuttosto che su conutenti che hanno delle connessioni molto lente con delle latenze alte. Quick può far notare delle delle prestazioni più notevoli. I utilizzatori di Chrome hanno già cominciato ad utilizzarlo non ne facciamo caso ma probabilmente sui siti che lo supportano già stiamo navigando con il protocollo quick che è introdotto in Chrome. Leggevo proprio in questi giorni come su YouTube addirittura c'è integrando in il protocollo quick la funzionalità del congestion control e del loss recover UDP come sono riusciti a diminuire il rebuffer dei video su YouTube di un 30% in meno per chi va su una pagina web. Quindi può essere un protocollo molto interessante anche che diversi hosting provider hanno cominciato ad integrare nel loro infrastrutture. Ricapitolando world speed auto step per velocizzare il sito. Abbiamo visto performance test quindi strumenti per l'analisi delle performance delle nostre pagine come non bisogna focalizzarsi semplicemente su ottenere un accento su gt matrix piuttosto che su page spin in strikes ma è necessario analizzare questi dati e trarre uno spunto per risolvere i problemi che vediamo sulle nostre pagine. In secondo punto il server DNS l'importanza del server DNS assieme alla scelta dell'hosting provider quindi i tempi di risposta del DNS se si parla di siti a livello internazionale la posizione del DNS in più punti e di name server distribuiti su diversi punti. Il terzo punto caching system tutto quello che consiste nel memorizzare nel server nel dispositivo dell'utente tutte le risorse statiche del nostro sito in modo da non richiamarle tutte le volte dal nostro server e non generare le quaria del database tutte le volte che inutente visita. Il quarto punto lesi loading che già può effettuare anche questo delle delle notevoli migliori al sito o vero caricare i contenuti solo quando effettivamente sono necessari all'utente. Il quinto step il formato svg come può farci risparmiare di spazio per per dimensioni delle immagini sul web e un formato scalabile completamente su qualsiasi dispositivo. Il sesto step le richieste HTTP quindi come andare a diminuirle concatenando tutto in un unico risorse ma stand attenti a non concatenare tutte le risorse che non sono necessari su quelle pagine web dove non vengono utilizzati plug in o altre funzionalità che vengono richiamate su tutte le pagine di default. Il settimo punto il de queue in queue ovvero richiamare o rimuovere le risorse javascript css dalle pagine dove non sono necessarie quindi contact form seven per fare ancora un esempio o revolution slider. L'ottavo punto il protocollo quick quindi il nuovo protocollo introdotto da google che metti insieme udp etcp per trarne un miglior protocollo. Per me è tutto vi ringrazio e lascio spazio le domande. Grazie Igor e abbiamo delle domande. Grazie ciao. Una domanda per il primo punto non hai nominato audits con uno strumento di chrome ok no temevo ci fosse un motivo ma si dice così. E poi non è un'altra. Quando è nominato la bovde fold quindi il discorso di caricare alcune risorse prima o dopo dare la priorità dei contenuti all'utente. A me è un dubbio cioè vorrei approfondire questa cosa. Se l'utente va su una pagina inizia a vedere il contenuto della pagina ma non vede il menu non vede un'animazione non vede il future. Il future essendo in fondo magari a meno problemi non può essere un problema a livello di usabilità per l'utente cioè vero che carica prima la pagina vero che dice però. Bisogna analizzare quali contenuti fornire prima l'utente quali dopo solitamente quasi parla di velocità percepita dall'utente quindi fornirgli subito una risposta alla sua richiesta. Solitamente si manda in priorità il contenuto della pagina ovviamente non può mancare leder perché se l'utente si trova spiazzato non sa dove andare a muoversi all'interno del nostro sito. Comunque il future potrebbe essere un elemento caricabile in una seconda fase. Sì il tempo in cui l'utente può cominciare ad interagire con il nostro sito. Una volta mi capitano situazioni in cui l'utente si carica legge già il contenuto però metti mi un un loader all'inizio perché non voglio vedere l'animazione dopo banalmente. Ok. Può essere problematico. Può essere anche questa una soluzione per cominciare a dare un primo caricamento della pagina web o un preloader delle pagine. Grazie. Ciao e ho una domanda. Ho una domanda su. Sì parlavi di css sprite. Sì. E quel sito lì era su http 2 o http e basta con http s. Era su http 2 ma giustamente non vengono vengono unificate tutte le richieste effettuate dalle richieste tt quindi sono una sola. Però nel caso spero non ci siano siti semplicemente con il protocollo http ancora sarebbe usata delle richieste singole quindi un time to frostbite per ogni richiesta. Css sprite su http 2. Css sprite su http 2. Sì. Ok. Grazie. Domanda stupida ma non so la risposta. Allora Google analizzi siti e da questo dipende da una valutazione da questa valutazione dipende il posizionamento. Sì. Questa valutazione è data sull'intero sito o su ogni singola pagina. Google come dicevo all'inizio non utilizza gli strumenti che mette sia a disposizione a noi utenti ma utilizza questa estensione di Chrome che gli strumenti degli sviluppatori di Chrome. Grazie a quella riesce ad ottenere il tempo di caricamento di ogni pagina del sito che vis da l'utente quindi alle dati provenienti da utenti reali. Quindi su ogni pagina. Può influire anche questo su non c'è una linea guida ufficiale su questo ma potrebbe influire su ogni pagina potrebbe avere un suo posizionamento in base alla sua velocità. Grazie ciao. Non hai parlato di delle cdn per un motivo particolare perché non sono. Nelle o negli otto punti principali. Sì non ho integrato la cdn perché solitamente si fa un'analisi più particolare quando si comincia a utilizzare una cdn. Non sempre può trarne vantaggio e non sempre è utile utilizzarla ovviamente su siti a livello internazionale. Rendere i contenuti in più punti disponibili e quindi al vicinare gli utenti può può aiutare il caricamento del anzi aiuta sicuramente il caricamento del nostro sito. È uno step sicuramente necessario quando si parla di siti internazionali posso fare. Sì hai parlato delle immagini svg ma non di web p. Sì web p non l'ho escluso non l'ho mai utilizzato particolarmente sulle pagine web. Perché ho avuto anche dei problemi a livello di integrazione in realtà comunque anche quello un formato di immagine alternativo all svg che viene più utilizzato per le icone per tutti gli elementi grafici. Web p consente anche di ottimizzare in maniera notevole delle immagini jpeg o png comunque immagini fotografie. Grazie a te io avevo una domanda o una domanda più che una cosa un po' parella cioè nonostante si punti sempre di più sulla velocità del sito lo trend dello sviluppo è quello sempre di fare più siti singol page rispetto a siti con possiedate pagine che vai controtendenza sarebbe molto meglio fare un sito con tante piccole pagine che quindi caricano dolcemente invece di fare singol page invece si va verso il singol page masochismo. Sì i trend sono sempre quelle di creare pagine siti one page quindi tutto in un'unica pagina e lì diventa più difficile ottimizzarlo perché hai una quantità maggiore di immagini di risorse di animazioni e quant'altro. Il lesi loading potrebbe aiutare in questo caso carichiamo il contenuto solo quando effettivamente è necessario all'utente. Ciao allora tendenzialmente penso che il 99,9% dei siti abbiano su analytics facebook e tag manager e vi è discorrendo. Uno fa un test su page speed su gt matrix e guarda caso tutti i problemi derivano da analytics da facebook eccetera. Andando a falsificare ad esempio bloccando il caricamento di questi pixel di questi script esterni che non dipendono dal proprio sviluppo può essere un aiuto diciamo all'ottimizzazione. Cioè ad esempio sui miei siti per falsificare i dati diciamo all'utente gli faccio vedere che il sito in realtà il 99% perché non faccio caricare l'analytics questo mi aiuto ovviamente a vendere un sito. Ma in generale c'è un modo per ottimizzare questo tipo di problema o? Solitamente lo script il pixel di facebook piuttosto che google analytics si integra sempre nel leader della pagina in modo da ottenere subito il page views su analytics. Una soluzione potrebbe essere quello di spostarlo nel footer per caricarlo in un secondo momento comunque richiede anche quello delle risorse durante il caricamento. E però ad esempio se non sbaglio quello di analytics non è cashabile dal browser dell'utente perché giustamente in continuo aggiornamento vi discorrendo. Quindi se anche lo mettessi nel footer della pagina proprio come ultima risorsa caricata un page speed mi dice guarda che questa risorsa non è cashabile dall'utente quindi ottimizza questa risorsa. Di conseguenza io però non posso farci nulla perché ovviamente risiede sul server di google e di conseguenza io non ho accesso questa roba qua. Quindi diciamo lo fuscamento di questi script può essere un aiuto diciamo in generale anche i termini di google che mi dice guarda questo qua. C'ha delle ottimizzazioni abbastanza abbastanza buone perché non carica determinati script anche se in realtà poi l'utente alla fine di carica perché l'analytics mi serve. No perché google appunto utilizza i dati presi d'autenti reali quindi non utilizza page speed o audit per capire la velocità della nostra pagina web. Quindi sarebbe comunque la velocità effettiva che un utente ha percepito caricando il nostro sito web grazie a te. Ciao di nuovo una domanda un po' più pratica purtroppo spesso per questioni vuoi commerciali vuoi quello che si lavora con temi primi già fatti già impacchettati con una quantità di risorse che imbarazzante inutile via discorrendo. Se si fa un tema custom il problema non si pone se si utilizza un tema del genere sì perché vengono caricate robe allucinanti tu prima ha parlato del dei qui non so mai come si pronuncia dei quei. E si può influire può aiutare quello nel momento in cui si utilizza un tema premium sì nel momento che si utilizza un tema premium che carica magari 10 risorse javascript relative a 10 librerie diverse per qualsiasi animazione particolare mai utilizzata è possibile andare a rimuoverlo a toglierlo dalle pagine dove non è necessario da tutte le pagine se non lo utilizziamo. Sì è possibile fare un'ottimizzazione su temi premium anche se ovviamente poi mi consiglio quello di basarsi su delle strutture custom in base alle esigenze poi ci sono casi e casi in cui ci troviamo a dover modificare un sito che è già stato realizzato con un tema premium. Quello c'è il problema poi è sempre lì. Esatto è lì allora andiamo a eliminare le risorse non necessarie o anche gli elementi del visual composer se c'è che non sono necessari che comunque vengono caricati sia nel beccante che anche nel front end li eliminiamo. Basta visual composer nella vita. Basta questo è lo slogan. Grazie a te. Io volevo solo fare una una punta alla domanda che hai fatto tu. Perché ci sono anche comunque degli strumenti terzi dei plugin che ti aiutano ad applicare delle regole di ottimizzazione a livello di browser caching per le richieste da terzi. Però una punta di quello che stavi dicendo tu devi vendere il sito al 99 per cento 100 per cento. A me piaceva perché anche io lavorò nell'ambito della web performance che un po' cambiassimo il chip da quel punto di vista. Cioè se tu vendi qualcosa con l'idea che dietro c'è un falsare dei dati perché il cliente così lo apprezza meglio potresti tornare indietro ed educare il cliente e spiegarli che cosa c'è. Dietro page speed dietro queste come stava dicendo Igor il 100 per cento è un fittizio e una vanity metri che praticamente qualcosa che ci aiuta a essere contenti del lavoro che stiamo facendo. Sì ancora meglio ancora me. Esatto è questo. Sì. Esatto e tu al tuo capo gli dici capo abbiamo la possibilità di entrare nei server di Google e metterci le mani e cambiare qualcosa a noi no. Facebook quello che abbiamo la possibilità di manipolare manualmente questa cosa no non dipende da noi il nostro sito però è veloce te lo dimostro con GTI metrix. Hai altri strumenti per. Lo so. Sì sì sì no è difficile c'è una campagna proprio però che dobbiamo prenderci a cuore secondo me perché è l'unica strada in cui possiamo valorizzare veramente i nostri sforzi di performance. Non so dicendo te però di come ha fatto ricordare tante conversazioni passate e attuali. Ci sono abbiamo un minuto per una domanda la sopra. Premesso che sono perfettamente d'accordo su questa tua ultima considerazione però mi chiedo a questo punto come ti poni nei confronti del prossimo badge della vergogna che Google ha intenzione di dispingere su tutti i risultati. Ripeto premesso che sono d'accordo sull'educazione purtroppo però appunto sta diventando sempre una cosa conosciuta. Quindi il cliente ti chiede page speed voglio avere il valore adesso Google viene ulteriormente a gambatesa con questo bel volevo una considerazione generale grazie. Sì da qualche giorno gira questa news di Google che introdurà questo badge su sui siti web che sono lenti e su quelli veloci ovviamente li premierà. Li bisognerà lavorare su tanti altri aspetti che cerchino di portare sito ad avere le migliori performance e da avere quindi un badge che sia in linea con Google senza mostrare il badge della vergogna aiutenti. Solo su Chrome apparirà sì ma pensi che utilizzerà i stessi parametri di page speed oppure i parametri reali che utilizza per l'indicizzazione. Su questo non mi sono informato ma penso utilizzi i dati di page speed insides. Benissimo. Si basa sempre sul Chrome user e report che è quel campione di dati esatto quell'estensione di lighthouse tutti i dati che stanno dietro il lighthouse e il tool di Chrome e quindi da lì sempre prende questi badge sia di page speed che il nuovo. Beggio di lente il velocità su Chrome che è da quello che ho letto verrà fuori da lo stesso database quindi il discorso è sempre quello stiamo facendo delle valutazioni su un report molto piccolo dei utenti reali però molto piccolo rispetto agli utilizzatori web.