Gaming Google — Il punteggio perfetto per il faro

Ho sempre esitato a condividere il mio codice. Non è che io creda che sia scadente, né sono afflitto dalla sindrome dell'impostore. È solo che il codice di condivisione offre uno sguardo sulla follia che è la mia mente, e che sembra in qualche modo crudele per tutti gli altri. Permettetemi di guidarvi in un viaggio che mi ha quasi portato sull'orlo della sanità mentale. Tutto è iniziato con l'aggiornamento Lighthouse di Google.

Per chi non lo sapesse, l'aggiornamento Lighthouse di Google ha rappresentato un cambiamento sostanziale nel ranking di ricerca, basato sulle prestazioni di un sito Web e sul rispetto delle migliori pratiche. Se desideri testare il tuo sito Web, è sufficiente aprirlo in Chrome su un desktop, premere F12 per aprire gli strumenti per sviluppatori di Chrome e quindi fare clic sulla scheda «Lighthouse». Scegli Desktop o Mobile e fai clic su «Analizza». Dopo circa un minuto, riceverai cinque punteggi, ciascuno compreso tra 0 e 100, per prestazioni, accessibilità, best practice, SEO e Progressive Web App (PWA).

Prima di approfondire i dettagli tecnici, permettetemi di presentarmi. Mi chiamo Jonathan Grantham e sono l'orgoglioso proprietario di una piccola azienda SaaS B2B, Nexoid, specializzata in software ERP e ITSM. Il sito web di cui parlo in questo articolo è www.nexoid.com. Sentitevi liberi di dare un'occhiata, aprite il codice sorgente. Puoi seguirmi anche su LinkedIn. Il mio profilo è www.linkedin.com/in/jonathongrantham/

Dopo il rilascio dell'aggiornamento Google Chrome Lighthouse, ho fatto quello che avrebbe fatto qualsiasi imprenditore coscienzioso: ho controllato il mio sito web. Con mio grande sgomento, i risultati sono stati tutt'altro che soddisfacenti. Con punteggi di 21/100 per le prestazioni, 30/100 per l'accessibilità, 45/100 per le migliori pratiche, 11/100 per la SEO e un fallimento per la PWA, sono rimasto scioccato. Avevo creato personalmente il sito Web, un'architettura a pagina singola abbastanza standard utilizzando React.js. I punteggi sono stati un duro colpo.

Imperterrito dal contraccolpo iniziale, ho lanciato MS Code e ho iniziato a risolvere i problemi uno per uno, con Performance come primo obiettivo. Le guide fornite nello strumento Lighthouse si sono rivelate molto utili. Ho convertito tutte le immagini da JPEG e PNG a moderni file WebP e mi sono assicurato che ogni tag img fosse dotato di una proprietà di larghezza e lunghezza per evitare cambiamenti di layout. Queste modifiche da sole hanno aumentato il mio punteggio da 21/100 a 60/100. È stato un miglioramento significativo, ma tutt'altro che perfetto. L'unico suggerimento rimasto era quello di «ridurre il codice JavaScript inutilizzato», il che non è stato particolarmente utile. L'unico JavaScript presente era il framework React.js, in quanto tutto il resto era stato eliminato.

Con Nexoid, AM Digital è stata in grado di estendere i vantaggi di una soluzione ITSM unificata anche alle operazioni rivolte ai clienti. Il portale clienti, integrato con Azure, ha offerto un'esperienza più connessa, dinamica e senza interruzioni per i propri clienti, con conseguente aumento della soddisfazione e del coinvolgimento dei clienti. Il portale consentiva la sincronizzazione in tempo reale con i dati dei clienti, garantendo che tutte le informazioni fossero aggiornate e accurate, migliorando così l'erogazione dei servizi e rafforzando il rapporto cliente-azienda.

Nonostante i miei continui sforzi per risolvere il problema, ho incontrato ostacoli costanti. Ho provato a rimuovere parti di React.js, ho esplorato il «caricamento lento» e ho testato vari ottimizzatori e compressioni. Tuttavia, il problema derivava dallo stesso React.js, che aveva una dimensione di circa mezzo megabyte.

Riesco quasi a sentire sviluppatori web esperti gridare: «Non usare React per un sito web! È pensato per creare applicazioni web!» Ora ne sono ben consapevole.

Quello che era iniziato come un compito apparentemente semplice di convertire alcune immagini si è ora trasformato in una revisione completa del sito Web utilizzando un nuovo framework. Frustrato e pronunciando a bassa voce alcune parole scelte, mi misi alla ricerca di un sostituto adatto. Ho considerato prima Vue e poi Angular, probabilmente i maggiori concorrenti di React.js. Tuttavia, entrambi hanno presentato lo stesso problema.

Nel tentativo di semplificare le cose, ho deciso di esaminare le tecnologie più vecchie e ho provato jQuery. Eppure, mi sono imbattuto nello stesso problema. È diventato evidente che non esisteva un framework di Single Page Architecture pronto all'uso in grado di placare le divinità di Google.

Sembrava che la mia unica opzione rimanente fosse ricorrere a JavaScript vanigliato.

La mia serie di esperimenti è iniziata con una pagina HTML di base senza JavaScript. Quindi, ho provato una pagina HTML con un div il cui contenuto poteva essere sostituito. Mi sono subito reso conto che apportare più modifiche simultanee alla pagina tramite JavaScript comportava delle penalità da parte di Lighthouse. La soluzione consisteva nel manipolare il contenuto del tag body come una stringa e poi reintegrarlo, creando così solo una singola modifica DOM visibile.

Ora avevo una pagina HTML minimalista con un tag body vuoto, completata da una piccola funzione di onload nel tag head. Questa funzione ha ispezionato l'URL ed eseguito una richiesta HTML GET per recuperare il file di testo corrispondente contenente il codice HTML del corpo della pagina. Si potrebbe pensare che questa sia una soluzione adeguata. Sfortunatamente, non è riuscito quando ho tentato di caricare dinamicamente la funzionalità JavaScript.

A differenza di altri tag, se aggiungi un tag di script con un semplice avviso («yes this fired») nella stringa del contenuto del corpo, non verrà eseguito. Sebbene non sia ideale, una soluzione alternativa consisteva nell'analizzare la stringa del corpo, identificare tutti i contenuti dei tag dello script e inserirli in una funzione di valutazione JavaScript. L'approccio è stato piuttosto efficace, ma ha avuto problemi quando si trattava di namespace e la console per gli sviluppatori è stata invasa da antiestetici avvertimenti. La soluzione consisteva nell'estrarre i tag dello script dall'HTML e aggiungerli come elemento di script dopo il rendering del DOM. Google non ha penalizzato questa azione per qualche motivo.

Stavano facendo progressi e avevo una soluzione di architettura a pagina singola di base. Ma non così in fretta. Sebbene Google sia efficiente nell'indicizzare le pagine di Single Page Architecture (lo fa aprendole in un browser, consentendo l'esecuzione di tutto il JavaScript e quindi scansionando il DOM), Bing, Yahoo e altri principali motori di ricerca utilizzano un metodo simile e più semplice. Tuttavia, la maggior parte delle altre piattaforme come Facebook, Reddit, LinkedIn e WhatsApp recuperano solo il file HTML, recuperando un piccolo file HTML con un corpo vuoto. La mia soluzione non era praticabile. Ora dovevo replicare questo concetto per ogni pagina del sito Web e includere JavaScript per passare alla modalità Architettura a pagina singola quando un utente faceva clic su un collegamento.

Avevo bisogno di uno strumento in grado di generare HTML per ogni pagina, in base alla mia soluzione. Mi è venuto in mente di avere la risorsa perfetta a mia disposizione: il mio sistema ERP, Nexoid. Ho creato un modello Nexoid che comprende un sito Web e oggetti dati di pagine Web. Il record del sito Web ha facilitato la creazione di una pagina Web modello generico, mentre i record delle pagine Web contenevano il contenuto di ogni singola pagina. L'ultimo pezzo del puzzle era una funzione o uno script del flusso di lavoro in grado di leggere il record del sito Web e tutti i record delle pagine Web correlate per generare i file HTML. Dopo alcuni giorni, era operativo. Avevo creato un Content Management System (CMS) di base. Lo sviluppo di un CMS fino a questo punto non è eccessivamente complesso; la vera sfida sorge quando si integrano altri flussi di lavoro CMS, approvazioni, localizzazioni, anteprime, ecc.

Un requisito fondamentale per il nuovo sito Web era la localizzazione; volevamo lanciarlo in 11 lingue. Essendo un'azienda IT, mi sono naturalmente orientato verso soluzioni tecnologiche. Invece di assumere un traduttore per ogni pagina, ho optato per AWS Translate. Sebbene i traduttori di intelligenza artificiale siano decenti, non sono perfetti e gli errori sono abbastanza evidenti da rivelare un'origine non umana. Un membro dello staff francofono ha valutato la traduzione dell'IA e le ha dato un 6/10, descrivendola come «comprensibile, ma non un francese adeguato».

Tuttavia, ci siamo imbattuti in un trucco prezioso. Abbiamo scoperto che inserendo prima il testo in inglese tramite ChatGPT, chiedendogli di «riordinarlo» e poi incollandolo, il testo viene riformulato in un modo che è ancora inglese ma è molto più compatibile con i modelli linguistici. L'uso dell'inglese riformulato da ChatGPT come base per la traduzione migliora notevolmente la qualità della traduzione, portandola a 9 o addirittura a un perfetto 10 su 10.

Avendo sviluppato una solida base tecnologica per la creazione del sito Web, stavo facendo progressi. Tuttavia, una nuova sfida è emersa quando abbiamo iniziato a creare pagine più complesse. In base alle nuove linee guida di Lighthouse, è diventato necessario consolidare tutti i JavaScript, i CSS e l'HTML in un unico file. Ciò valeva anche per le versioni Single Page Architecture.

Abbiamo fatto ricorso all'inserimento di tutti i file JavaScript e CSS come tag in linea. Una strategia simile era richiesta per la versione Single Page Architecture. Abbiamo creato un file JSON contenente tutti gli script, gli stili e l'HTML.

Lighthouse ha identificato il problema successivo nella dimensione delle risorse; i file di pagina HTML e JSON erano eccessivamente grandi. Ho risolto questo problema utilizzando «minify», una libreria Node.js progettata specificamente per comprimere file HTML, CSS e JavaScript. Questa soluzione ha comportato una riduzione delle dimensioni dei file di testo di oltre il 40%. Inoltre, minify offriva l'ulteriore vantaggio dell'offuscamento, rendendo il codice grezzo più difficile da leggere e migliorando la sicurezza.

Approfondiamo il tema dell'hosting. Tradizionalmente, un Content Management System (CMS) funziona tramite un server di applicazioni che gestisce la richiesta HTML dell'utente. Interpreta la richiesta di pagina dall'URL, individua le risorse corrispondenti in un database, recupera il record del database (possibilmente insieme ad altri), elabora le informazioni per assemblare la pagina e infine la consegna all'utente finale come documento HTML piatto. Questa descrizione riguarda principalmente la richiesta HTML iniziale quando un utente visita un nuovo sito Web, sebbene io conosca AJAX e altre tecnologie simili.

Tuttavia, questo modello convenzionale presenta alcuni inconvenienti nel contesto del nuovo mondo di Lighthouse. In primo luogo, la comunicazione avanti e indietro tra il server delle applicazioni e il server del database, nonché la compilazione delle pagine, introducono ritardi. In secondo luogo, nella sua forma più semplice, un server di applicazioni e un server di database sono fisicamente disponibili solo in un'unica posizione. Questa configurazione è eccellente se ti trovi nello stesso edificio o nella stessa città, ma significativamente meno efficiente se stai tentando di accedere al sito dall'altra parte del mondo. Ad esempio, la latenza media di ping tra Australia e Regno Unito è di circa 250 millisecondi.

La nostra soluzione a queste sfide prevede l'utilizzo di AWS S3 per l'hosting dei file statici generati dallo script di pubblicazione menzionato in precedenza e di AWS CloudFront per la distribuzione globale dei contenuti. Al momento della stesura di questo articolo, AWS CloudFront distribuiva contenuti in oltre 90 città in 47 paesi. Per un utente di Melbourne, in Australia, che accede a un sito Web del Regno Unito, AWS CloudFront ha ridotto la latenza del ping da 250 millisecondi a soli 13 millisecondi (questa è la differenza di fuso orario tra Melbourne e i server edge AWS a Sydney).

Arriviamo ora al componente Progressive Web Application (PWA) del test Lighthouse, che in precedenza non era qualcosa a cui avevo prestato molta attenzione. Per chi non lo conoscesse, una PWA coinvolge un service worker JavaScript che gestisce il sito Web come un'applicazione Web. Se è un po' complesso, consideralo in questo modo: è essenzialmente uno strumento automatico di download e memorizzazione nella cache. Quando un utente visita il tuo sito Web, l'obiettivo è rendere le richieste successive il più rapide e semplici possibile. Il service worker PWA consente di scaricare già le risorse successive sul computer locale dell'utente, eliminando la necessità di un'altra richiesta GET Internet.

Al momento della stesura di questo articolo, il sito web di Nexoid è relativamente piccolo e contiene solo 19 pagine. Tuttavia, quelle 19 pagine sono tradotte in 11 lingue diverse, per un totale di 209 pagine. Inizialmente, ho provato a scaricare ogni risorsa nel service worker, il che ammontava a circa 5 MB. Questa dimensione era troppo grande per un carico iniziale e Lighthouse mi ha penalizzato per questo. Ho deciso di scaricare solo i file JSON della pagina inglese, che includono tutti i CSS, HTML e JavaScript necessari per visualizzare ogni pagina.

La struttura finale è la seguente: un bucket S3 ospita i file HTML compilati, denominati senza l'estensione.html. Ad esempio, www.nexoid.com/en rappresenta l'HTML della homepage inglese, www.nexoid.com/de è per l'HTML della home page tedesca e www.nexoid.com/en/platform si riferisce all'HTML della piattaforma inglese e così via. Inoltre, ci sono file JSON che contengono le parti del corpo e della testa che cambiano durante la navigazione tra le pagine, come https://www.nexoid.com/en.json, https://www.nexoid.com/de.json e https://www.nexoid.com/en/platform.json, tra gli altri.

In conclusione, comprendere Lighthouse ha rappresentato una sfida significativa. Sono scettico sul fatto che i prodotti CMS tradizionali e pronti all'uso possano affrontare efficacemente questo compito. Riflettendo sulla mia esperienza con piattaforme come WordPress e Drupal, trovo difficile credere che possano essere ottimizzate per ottenere un punteggio Lighthouse perfetto. Nel complesso, credo che lo sforzo sia utile e Google è giustificato nel porre maggiore enfasi sulle prestazioni. Tuttavia, questo cambiamento è e continuerà ad essere un notevole punto dolente per i web designer e le agenzie.

Se sei interessato a saperne di più su Lighthouse o se desideri discutere dei prodotti e servizi di Nexoid, non esitare a contattarci. Puoi contattarci tramite LinkedIn o tramite la pagina «Contattaci» sul nostro sito Web.