In questo articolo ci dedichiamo all’importanza dell’ottimizzazione delle performance in ottica SEO e UX. Quando si tratta di analizzare e migliorare le performance dei siti è bene essere aggiornati sulle novità e sui temi caldi in ambito di prestazioni. Questo articolo serve, infatti, principalmente perché a marzo viene introdotta una nuova metrica dei Core Web Vitals, ovvero l’INP, e andrà a sostituire il Feed.
Vediamo brevemente gli argomenti che andremo a trattare oggi. Oltre a fornire qualche dato per capire l’importanza delle prestazioni per il business online, faremo una panoramica dei Core Web Vitals cercando di limitare i tecnicismi. Non sarà così semplice, ma cercheremo di farvi capire un po’ di più di questi parametri strategici. Vi daremo poi delle indicazioni su chi sono le figure coinvolte nel processo di ottimizzazione, giusto per capire che non è un’attività solo di pertinenza. E questo magari può essere utile per chi deve coordinare questo tipo di attività, capire meglio queste dinamiche. Vedremo poi alcuni strumenti concreti che si usano nell’attività e cercheremo insomma di rendere la cosa ancora più pratica con dei casi concreti.
L’importanza delle prestazioni
Diciamo che è già da qualche anno che le prestazioni dei Core Web Vitals in particolare sono molto importanti. Per determinare l’esperienza positiva dell’utente e anche in ottica SEO, abbiamo voluto condividere con voi alcuni casi di studio. Già nel 2021 Swap, che è un e-commerce di iPhone ricondizionati, si è concentrata sul miglioramento dei Core Web Vitals e le sue revenue mobile sono cresciute del 42%. Dal 2023 Redbus (è un servizio di prenotazione di biglietti online) in maniera anticipata ha lavorato sugli INP perché è già dall’anno scorso Google ha cominciato a dare delle indicazioni; questo ha avuto un incremento diretto delle vendite grazie a questo tipo di miglioramento.
Un altro caso di studio è quello dell’eCommerce di cosmetici Carpe che ha ottimizzato Shopify. Quindi anche Shopify è una piattaforma che necessita di ottimizzazione perché si basa su dei temi e comunque tutto ha tutta una serie di dinamiche che coinvolgono i Core Web Vitals e il conversion rate è aumentato del 5%. In ogni caso sono molte le aziende che hanno tratto dei benefici notevoli, concentrandosi a migliorare i Core Web Vitals e le prestazioni in generale. Adesso cerchiamo di capire un po’ di più cosa si nasconde dietro queste sigle: LCP, INP e CLS e svelarci alcuni segreti in merito.
Sono sigle che effettivamente al primo impatto confondono. Quindi andremo a vedere principalmente cosa sono i Core Web Vitals; sono metriche indicatori dati da Google che sono legati a velocità, tempo di risposta e stabilità del layout in un sito web e riflettono l’esperienza utente-centrica applicata a dati reali. Tre sono i parametri principali, che sono l’LCP, il CLS. INP che è quello che andrà a sostituire, come dicevamo prima, il feed. L’INP riguarda più che altro le performance di caricamento, il CLS definisce la stabilità visiva e l’INP prende in considerazione invece l’interattività della pagina, che sono fondamentalmente le tre macroaree che permettono a un sito di essere ottimizzato.
Prima di proseguire, guardando i tre parametri nel dettaglio, è bene ricordarsi di fare comunque attenzione ai valori che vediamo e che vedremo. Sono dei numeri, che se non sono contestualizzati al dominio del sito che andiamo a prendere in considerazione e che andiamo ad analizzare.
Quindi il primo aspetto da considerare è quello di fare attenzione quando arrivano report automatici, da agenzie o direttamente da Google perché possono creare scompiglio. Ma non è detto che i dati dei Core Web Vitals che visualizzate, pur non essendo magari verdi, debbano per forza diventarlo o comunque ci sia la possibilità di farli diventare verdi a tutti i costi, perché dipende poi dal business, dal dominio e dall’interazione, dalle modifiche. L’LCP si misura in secondi e misura le performance di caricamento e il tempo di rendering dell’elemento visibile più largo del viewport immagine o testo relativo a quando la pagina viene caricata la prima volta; è buono sotto i due secondi e mezzo, ovviamente più aumenta il valore e più diventa povera l’esperienza.
Parliamo di immagine o testo riferendoci al fatto che all’interno di un sito potremmo avere un’immagine principale che è larga quanto il viewport o anche su un dispositivo mobile. E non è soltanto il tempo di rendering di quell’elemento, ma il tempo di rendering di quell’elemento, sommato a tutti gli elementi che arrivano prima di esso. Questo andiamo poi a vederlo nei casi pratici.
Il CLS è la stabilità visiva e tiene conto di tutti gli spostamenti di layout imprevisti che accadono durante il caricamento di tutta la pagina. L’esempio che faccio sempre è la pagina che si sta caricando e a un certo punto si carica un font che sposta leggermente l’H1 oppure arriva il banner di cookiebot che che modifica il layout. In questo caso l’unità di misura si chiama punteggio di variazione del layout e non vi annoio dicendovi come si calcola, che è una cosa abbastanza tecnica. Però fino a 0,1 è un punteggio buono.
L’INP, il nuovo arrivato. L’interaction to next paint e la latenza nell’interazione.
Se il feed misurava la prima interazione dell’utente, l’INP misura invece l’interazione più lunga osservata valutando la latenza di tutte le interazioni degli utenti, quindi considerando il click il tocco e quello che viene fatto a tastiera che si verificano durante la durata della visita. E qui a millisecondi ci troviamo un buon valore sotto i 200 millisecondi.
Ci sono anche altri parametri web vitals che influenzano i core e il primo che possiamo citare è il TBT che il total blocking time che è la somma del tempo in eccesso di tutte quelle attività che vengono caricate con valore superiore ai 50 mllisecondi. Immaginatevi che per fare un’interazione ci vuole uno script o può servire del CSS. Di conseguenza il caricamento di queste risorse se è superiore ai 50 mse va a creare un ritardo, che poi va a influenzare anche l’INP.
Parlando invece di server e di connessioni il time to First Byte come c’è scritto, è il tempo che intercorre dal momento in cui il client invia la richiesta Http o https a quando riceve il primo byte di dati in risposta dal server web. E questo è uno di quei parametri che sconfina dall’ambito SEO e mi dà modo di parlare delle diverse configurazioni che sono coinvolte nel processo di ottimizzazione delle performance.
Diciamo che è un lavoro di squadra e di fatto il SEO Specialist analizza e coordina un team che idealmente è composto dal sistemista che affronta la parte di server, configurazione, ottimizzazione, cache in DNS. Il backend developer che ottimizza il codice si occupa delle chiamate del database e in de generale dell’ottimizzazione delle query del database. Poi il frontend developer o designer che invece è più focalizzato sulla parte di interazione.
Ma vediamo meglio come ottimizzare il time to First Byte e quali sono le cose che lo influenzano. Innanzitutto le caratteristiche del server, della connessione e anche più, precisamente della versione per esempio di HTTP che utilizza il server. Anche il DNS è coinvolto nel time to First Byte.
Scegliere un DNS performante è altrettanto importante come l’uso corretto dei redirect. Spesso col tempo, quello che succede è che vengono mantenuti redirect molto vecchi e addirittura si crea una catena di redirect. È ovvio che una catena di redirect implica del lavoro a livello sia di DNS che in generale a livello server, e questo aumenta il time to first byte; è una buona norma una volta ogni sei mesi o una volta all’anno, fare un check, verificare e fare un po’ di pulizia sui redirect inutili. Oltretutto, spesso e volentieri l’elenco di redirect va ad aumentare la dimensione dell’htaccess o del file dell’url writing in is e in generale comunque il file .htaccess va mantenuto il più snello possibile.
Come dicevo prima anche le query del database possono influenzare negativamente il time to First Byte. Quindi c’è da fare un po’ un query profiler e cercare di capire quali sono le prime e più importanti, quelli che vengono eseguite e capire se si può fare del caching o delle ottimizzazioni avanzate che mediamente è quasi sempre possibile fare perché si tende ad andare online di fretta con una versione del sito che non è ottimizzata e dopo a lasciare in una seconda passata questo tipo di ottimizzazione che però fa molto spesso la differenza. La scelta del CMS è fondamentale, così come capire le differenze fra headless e non headless e capiremo quali possono essere i forti vantaggi di una scelta headless. Sempre in tema CMS, per citare un esempio, WordPress.
Sia i temi che i plugin hanno una influenza sul time to First Byte. Spesso e volentieri è meglio come dire sviluppare temi ad hoc e non prendere dei temi già fatti perché i temi già fatti contengono una quantità di codice notevole, ridondante o comunque inutile. E questo ovviamente causa ritardi e spesso e volentieri si installano plugin per fare delle cose che invece si possono fare a livello codice in maniera molto più, semplice. Quindi anche qui fare un check dei plugin è molto importante e può portare delle ottimizzazioni veloci.
L’adozione di una cdn che magari consente di fare caching di pagine dinamiche offre molti vantaggi; può essere utilizzata anche per protezione firewall e via dicendo e quindi è fortemente consigliata. Cloudflare è un esempio di Cdn che, anche con una cifra piuttosto accessibile, si può attivare in maniera semplice e mano mano che si prende confidenza consente di fare delle ottimizzazioni molto fini e dei lavori anche molto interessanti. Per cercare di ottenere dei risultati molto interessanti.
Welcome INP: nuovo parametro, nuove sfide.
Abbiamo già detto che questo parametro entra in scena il 12 di marzo. Abbiamo già detto che la differenza sostanziale tra il feed dell’INP è la somma di tutte le interazioni rispetto alla prima interazione. E a questo punto per andare un po’ più, veloci, per arrivare poi ai casi di studio, cerchiamo di capire di cosa si tratta.
Il fattore principale dell’interattività è spesso javascript, anche se i browser forniscono interattività anche tramite controlli che possono essere casella di controllo, pulsanti di opzione e controlli con tecnologia CSS. Per quanto riguarda gli INP, vengono osservati solo i seguenti tipi di interazione: abbiamo il clic con mouse, il tocco, toccare un dispositivo con un touch screen se è consenziente ovviamente e premere un tasto su una tastiera fisica o sullo schermo. Andiamo un attimo nel dettaglio di quali possono essere le cause che vanno a far peggiorare l’INP. Possono essere il ritardo di input, il tempo di elaborazione, il ritardo di presentazione. Per l’utente questa cosa è unica nel senso semplicemente clicco in un punto non succede immediatamente quello che dovrebbe accadere e tutto questo succede in queste tre macro sezioni.
Parlavamo prima del total blocking time e delle task bloccanti. Ecco, nel momento in cui faccio un’interazione quindi ho un input ricevuto il task bloccante deve finire di fare la sua attività. A quel punto parte la parte di processo dove abbiamo il click. Mouse up e pointerup non vengono calcolati ma ci sono, e abbiamo poi render paint. Questa è un’interazione. Andava benissimo per il FID, era la prima che l’utente avrebbe fatto. Moltiplichiamola per tutte le interazioni possibili che abbiamo sulla pagina e prendiamo quella più lenta. Quindi immaginate di vedere più interazioni, più task bloccanti. E a quel punto il tempo ovviamente aumenta e l’INP può peggiorare.
Come le risolviamo queste cose? E qua metto un bel DEV Alert più che altro perché diventa un po’ più complesso rispetto a quello che poi andremo a vedere per alcuni casi in cui è un po’ più visivo. In questo caso bisognerebbe velocizzare le chiamate degli eventi, ottimizzare il rendering e ridurre al minimo le dimensioni del Dom. Come detto precedente, valutiamo anche il total blocking time per ottimizzare l’INP all’interno della presentazione, dato che l’ottimizzazione dell’INP è comunque, come tutte le ottimizzazioni, un processo iterativo.
Come comunicare ai reparti competenti quali sono le attività da svolgere? Su quali pagine o template del sito è necessario operare? Come comunicare, cioè concretamente con i vari attori in gioco? La prima cosa che possiamo considerare è sempre pensando ai report automatici. Bisogna prima capire quali pagine vogliamo misurare; è bene partire sicuramente con analytics per cercare di capire quali sono le pagine più visitate, da quali Paesi arrivano i visitatori, quali sono i dispositivi, quali sono le interazioni con le pagine, ma soprattutto la struttura del nostro sito. Parlavamo prima di wordpress, ad esempio di CMS e mi posso aspettare che venga utilizzato WordPress per più tipologie di siti. Quindi se penso a un e-commerce, a un blog o un sito vetrina, per quanto il CMS possa essere lo stesso, io mi aspetto dei template differenti per obiettivi di business differenti. Di conseguenza, se stiamo parlando di un e-commerce, a me verrebbe da pensare che vorrei ottimizzare le categorie. Vorrei ottimizzare la scheda prodotto. Vorrei ottimizzare il carrello; e l’home page la tengo comunque in considerazione.
Ma se parliamo ad esempio di un blog, io mi aspetto che la pagina dell’articolo singolo sia super ottimizzata per dare maggior valore a livello di esperienza sia per l’utente che per il ranking. Se stiamo parlando di un sito vetrina, allora tengo buona l’home page.
Ovviamente tutto può essere monitorato ma trattandosi sempre di processi iterativi, io continuerò a ripeterlo per tutta la vita. È bene scegliere con cura le pagine con le quali iniziare; è bene anche tenere uno storico di tutti questi dati e nel flusso del lavoro con i colleghi Frontend e DEV, cioè sostanzialmente prima che loro introducano delle modifiche, fare sempre la fotografia prima e dopo e avere questo tipo di approccio, provare sempre le cose dal punto di vista delle prestazioni proprio per avere sempre uno storico di quello che è stato fatto e capire se le modifiche introdotte hanno apportato delle migliorie oppure oppure se c’è qualcosa da rivedere.
Altro tool che andiamo a prendere in considerazione non può che essere Page Speed Insight che è un tool che ci offre Google e ci permette di fare l’analisi di una pagina e vedere effettivamente il report della valutazione dei Core Web Vitals. Questo tool è importante per due motivi, a sinistra ci dà i dati aggregati del Chromex Report che sono dati reali storici del sito e la prova sul campo della pagina interessata. Quello a destra invece utilizza una limitazione di rete e un solo dispositivo, quindi anche qui il report automatico potrebbe darvi un 43% di prestazioni, ma in verità i vostri Core Web Vitals sono superati. L’altro tool che è interessante utilizzare è Webpage Test, che di solito utilizziamo per fare analisi un po’ più approfondite e per validare le ipotesi fatte con Page Speed Insight e andare a verificare come i due tool possono essere utilizzati simultaneamente
Tra l’altro Web test consente anche di bloccare le risorse una per una delle configurazioni avanzate molto sofisticate che consentono di fare un vero e proprio debug delle prestazioni in maniera veramente sottile e interessante.
Oltre alla possibilità di scegliere tra Side Performance, abbiamo anche delle configurazioni avanzate che ci permettono di impostare, sulla base dell’analisi che abbiamo fatto precedentemente sia a livello di Analytics, sia il punto di partenza del nostro sito. Quindi vogliamo avere una connessione a Milano, vogliamo avere una connessione a Londra, negli Stati Uniti o vogliamo anche avere un tipo di connessione che è 4G, DSL, cablata?
Caso pratico: analizziamo il sito di Evoluzione
Partiamo con il caso pratico, dobbiamo ovviamente leggere i dati, quindi partiamo dal sito di Evoluzione. Facciamo prima di tutto un’analisi e guardiamo i dati da Analytics; vediamo che la pagina più visitata in 12 mesi è l’homepage, al secondo posto abbiamo la Mobile, ha una distanza siderale, però possiamo anche vedere che la permanenza media sulla pagina desktop è di 1 minuto e 22 secondi e per quella su mobile invece abbiamo 9 secondi. Quindi questo potrebbe essere già un piccolo campanello d’allarme. Cerchiamo di analizzare come mai da desktop gli utenti restano di più e da Mobile di meno. Potrebbe essere una questione di UX. Potrebbe essere una questione di performance.
Mi butto su Page Speed Insight e verifico che su mobile abbiamo una valutazione non superata e abbiamo un LCP di 5,2 secondi e ovviamente con dati del Chrome Ux Report. In questo caso, a differenza della schermata precedente di Amazon, nella parte sotto il bottone analizza, dove abbiamo questo URL e origine. Prima avevamo questo URL visibile, in questo caso non è cliccabile perché significa che il Chrome Ux Report non ha abbastanza dati aggregati per la singola pagina e quindi somma tutto il dominio.
Di conseguenza è un’analisi, una valutazione Core Web Vitals non superata ma non su evoluzione agency su tutto quello che c’è sotto e nel test reale vediamo che l’ LCP al posto che essere 5,2 è 14,6135.
Passiamo a Webpage Test, giusto per darvi un’idea. Se facciamo una connessione cablata contro un ADSL ci troviamo dei valori ancora diversi a livello di LCP. Ovviamente andiamo a prendere quella più, lenta. In questo caso c’è sempre una discrepanza tra Webpage Test e Page Speed insight. Per quanto riguarda i valori suggerimento nel momento in cui facciamo delle modifiche cerchiamo di poi di fare un’analisi su uno stesso tool, quindi non misuriamo una cosa su Webpage Test e poi guardiamola su Page di Inside, continuiamo ad analizzarla sullo stesso tool. A questo punto, dopo aver messo in analisi l’home page, Webpage test ci offre una risorsa a cascata con un grafico che ci offre molti spunti. Vediamo delle risorse bloccanti che sono quelle con la X a fianco. Possiamo vedere tutto sulla destra, una riga tratteggiata verde che rappresenta la fine dell’LCP.
Tornando su Page Speed Insight ci offre di filtrare per metrica, quindi filtrato per l’elemento LCP e ci mostra che l’lcp da mobile è data dal testo del banner di Cookie Bot; di conseguenza torniamo su Webpage Test e andiamo a vedere effettivamente dove viene caricata la risorsa di Cookiebot e scopriamo che viene caricata al sotto il video.
Di conseguenza vediamo che è effettivamente al filo con la riga tratteggiata in verde dell’ LCP. Quindi a questo punto, quello che dicevamo all’inizio che l’ LCP è dato dal caricamento dell’elemento più, largo, più, tutte le precedenti, ci può aiutare a capire che forse in questo caso potremmo decidere di caricare Cookiebot a livello di JS precedentemente al caricamento del video. Oppure potremmo togliere Cookiebot in barba alla privacy.
Rispetto a un e-commerce, con un sito istituzionale abbiamo delle necessità diverse e di conseguenza anche qui passiamo ad Analytics e vediamo come l’homepage mobile abbia il doppio delle visualizzazioni rispetto a quelle desktop, che comunque è terzo a livello di visualizzazioni. E poi, come dicevamo, entrano in gioco le categorie, le sottocategorie e il blog.
Dopo aver visto la mole del traffico. A questo punto anche qui un rapido check su Page Speed Insight, cominciando dalla home page su computer. La valutazione risulta superata anche su Mobile, anche se ha un INP migliorabile. Cosa potremmo fare qui se restiamo su Page Speed Insight?
Possiamo ridurre l’impatto del codice di terze parti che sicuramente andrebbe a migliorare l’interazione dell’utente. Abbiamo del codice di terze parti che blocca il thread principale per molto 970 millisecondi. Si tratta nelle prime posizioni di Cookiebot ovviamente. Quindi qua mi verrebbe da dire, andiamo poi nel dettaglio per verificare quanto questo codice di terze parti vada a influenzare poi l’INP. Quindi in questo caso, per quanto riguarda Tag manager è coinvolto per forza il team di Analytics che deve validare questa cosa.
Tutte le figure vengono prese in carico nel senso sia il front developer che lo sviluppatore nel caso in cui ci fossero altri codici di terze parti iniettati che qua non vediamo. Anche perché Tag Manager è importante che venga caricato il prima possibile, ma ovviamente se è necessario mantenerlo.
Nelle prime posizioni quel blocco noi lo manterremo, non possiamo farci molto. Potrebbe essere iniettato magari non tramite un plug-in all’interno di WordPress o all’interno di un CMS. Potrebbe essere messo direttamente nella pagina, ma anche qua è un trade-off tra quello che ci serve e quello che possiamo fare sia a livello di tempo che a livello di costi
Passiamo ora ad un altro aspetto visibile da Webpage Test che ci dà uno spunto sul quale lavorare sempre per un eCommerce LCP alto su connessioni DSL. Ricordiamoci che il valore dell’Lcp qui rispetto a Page Speed Insight è comunque un po’ più alto. Cerchiamo di vedere velocemente: abbiamo un LCP alto e sappiamo grazie a Wepage Test qual è l’elemento che porta effettivamente questo valore? È un’immagine che è in home page. E andiamo a vedere effettivamente come mai è così in basso nella cascata di caricamento, se è una risorsa che dovrebbe essere caricata prima ed è una risorsa che l’utente vede immediatamente. A quel punto noi sappiamo che per ottimizzare questo valore ci basterebbe, lato codice, chiedere agli sviluppatori front-end di fare delle modifiche per migliorare l’lcp.
Ci accorgiamo che la risorsa viene caricata dal browser quando meglio crede e a quel punto, dato che si tratta di un’immagine principale, dovrebbe essere una risorsa caricata il prima possibile. Quindi possiamo dire al browser di cercare di caricarla prima. A quel punto si sposterebbe prima all’interno di questa cascata e l’ LCP potrebbe effettivamente migliorare. Quindi è proprio una modifica molto veloce e sostanzialmente si tratta di togliere il lazy loading. A che cosa? In questo caso si fa una richiesta dell’immagine? Ci sono vari modi. Si può addirittura chiedere al Server di servire il prima possibile quell’immagine. Rispetto che fare un altro tipo di caricamento, il lazy loading alla fine è comunque un suggerimento, nel senso che se noi abbiamo più immagini in lazy loading l browser potrebbe anche averne necessità anticipatamente e quindi servirla prima.
Quindi, dopo aver fatto delle modifiche, com’è che misuriamo l’impatto? Il suggerimento è quello di fare a/b testing, quindi una prova con due pagine diverse, nel senso che, soprattutto nel caso di landing page o di pagine di atterraggio per campagne l’ideale è provare a fare due test in cui una pagina è ottimizzata e l’altra no. E a quel punto possiamo dare delle metriche su qual è il click totale. Quali sono le lead che vengono generate rispetto alla pagina meno ottimizzata? Vodafone sul sito web.dev ci offre, grazie a questo schema, il fatto che ha avuto un miglioramento notevole delle performance a livello di click, migliorando una landing page rispetto all’altra. A livello grafico erano identiche, quindi è solo una questione di caricamento.
Tips e Best Practice per migliorare le prestazioni di un sito
A questo punto chiudiamo con dei tips evergreen e che per quanto sia ottimo fare sempre ab test, ci sono delle best practice da seguire costantemente. Questo perché in alcuni casi il sito è già ottimizzato e bisogna fare delle piccole modifiche un po’ alla volta.
Se invece non ci sono queste, sarebbe ottimo cominciare con questo elenco:
- Prima delle immagini principali visibili in una schermata, che dovrebbero essere servite prima delle altre e ottimizzate in dimensioni e peso perché potrebbero concorrere all’LCP, abbiamo i font e i css che andrebbero serviti prima perché potrebbero concorrere al CLS, quindi allo spostamento del layout script CSS che intervengono nelle interazioni. Andrebbero ovviamente ottimizzati e serviti prima di altri perché potrebbero concorrere all’inp lato server.
- Occhio al TTFB perché potreste avere anche un sito perfetto che però non si accende. Potete anche pensare di correre, ma tanto tendenzialmente andare troppo a risparmio sugli hosting e sui server ha sempre delle controindicazioni. Magari si ha la velocità nell’ottanta per dei casi. Però quando non siamo davanti al sito e ci sono dei momenti di alto traffico, le performance degradano e noi non ce ne accorgiamo. Conseguentemente il consiglio principale è di scegliere comunque un hosting adeguato a quelli che sono i nostri obiettivi prima di fare cashing e cose più, sofisticate, partire da quella base. Dopo, piano piano, si fanno tutte le ottimizzazioni. Ma già un hosting poco performante ti preclude la strada.
- Come ultima cosa, quando effettuiamo delle verifiche, è bene farlo su più tool ma poi è fondamentale confrontare le modifiche tra test con lo stesso tool.
In verità page speed insight non possiamo non metterlo, ma Web Page Test lo utilizzeremmo comunque se uno avesse solo una possibilità; a quel punto l’ideale è stare su Page speed insight perché mi conferma il superamento della verifica dei Core Web Vitals e comunque può dare dei dettagli iniziali abbastanza importanti che sommato ad Analytics, ci può effettivamente aiutare già a fare delle modifiche. Oggi stanno nascendo tanti tool nuovi, soprattutto tantissimi real user monitoring, anche molto sofisticati, dedicati proprio alla parte di performance e con un monitoraggio costante che quindi creano uno storico.
Consigliamo di attivare questo tipo di monitoraggio perché anticipa i problemi o perlomeno in tempo reale ti segnala un problema di cui magari ti accorgeresti dopo del tempo. Anche The Bug Bear effettivamente è un bel tool, che fa monitoraggio continuativo sulle pagine. Anche se forse non è il più adatto alle medie imprese.
Resta quindi un’ultima domanda. Se bisogna ottimizzare le immagini, ottimizzare i font, bisogna utilizzare gli script. Bisogna ottimizzare tutto e quindi tutto è prioritario? Ovviamente no, perché non è solo una questione di pagine da ottimizzare, ma è in relazione al traffico, all’utilizzo.
Le performance si uniscono al miglioramento della SEO ma non sono l’unico fattore di ranking. Quindi arriva il report automatico e facciamo degli interventi possibili che fanno parte però di uno schema più, ampio e variegato di attività e di conseguenza.
Bellissimo avere tutti i tre parametri verdi, ma in relazione al proprio business, alle proprie esigenze. Se vogliamo un video in home page e l’LCP non è verde, a quel punto va bene comunque, perché quello che vogliamo dare noi al nostro utente è comunque un certo tipo di immagine.
Siamo praticamente giunti alla conclusione di questo articolo. Nonostante i problemi del nostro sito (utilizzato per il caso pratico) che però è in via di rifacimento, in Evoluzione siamo molto attenti e sensibili alle problematiche delle performance. Soprattutto sappiamo dove guardare e sappiamo se si può intervenire oppure se abbiamo le mani legate.
Se vuoi approfondire la questione, o se hai bisogno del nostro supporto o di una nostra consulenza, non esitare a contattarci!