I miglioramenti delle performance sugli utenti reali nel 2025

I clienti e gli utenti finali chiedono un'interattività immediata ora più che mai. Le performance rimangono la chiave del vostro successo, con aziende come Google che inseriscono le performance ai primi posti nei risultati delle ricerche. Akamai ha investito notevolmente nelle performance dei siti. Grazie ai nostri miglioramenti e alle nuove funzioni, potete ottimizzare le performance delle app per i clienti reali.

In questo blog, vi mostreremo come i nostri miglioramenti hanno influito positivamente sulle metriche CWV (Core Web Vitals) dei nostri clienti. Come segnale di posizionamento nei SEO, specialmente nel 2025, le metriche CWV sono, di fatto, lo standard per le performance reali. Utilizziamo le metriche CWV perché si focalizzano sugli utenti reali delle applicazioni moderne, indipendentemente dalla connessione, dalla posizione, dal browser o dal dispositivo in uso.

In seguito, vi mostreremo come sia possibile usare queste ottimizzazioni per migliorare le performance delle applicazioni, inclusi i miglioramenti introdotti, nonché le funzioni e i controlli che ora potete aggiungere alla configurazione delle vostre soluzioni Akamai per accelerare la velocità di siti e app.

Andiamo ad iniziare.

I miglioramenti delle performance che abbiamo introdotto l'anno scorso possono avere un impatto tangibile sugli utenti reali. Google ha confermato questa affermazione tramite il rapporto CrUX (Chrome User Experience), che è un database fornito da Google e disponibile pubblicamente con informazioni sulle reali user experience dei siti web in termini di performance e tempi di caricamento.

Grazie ai dati raccolti dagli utenti reali che hanno fornito il loro consenso, Google può monitorare e aggregare le metriche che riflettono le fondamentali interazioni degli utenti anziché test simulati o eseguiti in laboratorio.

Con le nuove funzioni di Akamai, abbiamo registrato migliori risultati negli indicatori KPI (Key Performance Indicator) incentrati sugli utenti, nonché nei valori LCP (Largest Contentful Paint) e INP (Interaction to Next Paint), oltre ai tempi per il primo byte che, anche se più tecnici, rimangono ancora popolari. Esaminiamo ora alcuni esempi di siti web che hanno registrato un'evoluzione positiva delle metriche CWV (Core Web Vitals).

NOTA: i valori illustrati di seguito sono stati ricavati da alcune schermate visualizzate nell'eccellente strumento treo.sh, che consente di visualizzare i dati CrUX cronologici per tutti i siti web presenti nel dataset.

La sezione illustrata in verde nella parte superiore del grafico mostra la percentuale di richieste per cui il valore LCP è risultato inferiore a 2,5 secondi; inoltre, mostra che il 20% di utenti in più ha registrato "buone" user experience (in verde) (il valore LCP è risultato inferiore a 2,5 secondi) a partire da febbraio rispetto ai tre mesi precedenti.

Il sito si è, spesso attestato nella sezione illustrata in arancione a indicare che era necessario apportare dei miglioramenti ed è stato, potenzialmente penalizzato dai risultati delle ricerche di Google, anche se ora appare decisamente nella sezione illustrata in verde che indica in modo chiaro una migliore soddisfazione degli utenti.

Una banca incentrata sulla sicurezza ha registrato straordinari miglioramenti del valore INP (Interaction to Next Paint) (Figura 2), non solo migliorando le sue operazioni di implementazione, ma anche ottimizzando le varie versioni di JavaScript in Akamai Bot Manager che sono state pubblicate nei mesi scorsi. La banca ha registrato un continuo miglioramento del suo valore INP, passando dal 55% a più dell'87% di utenti soddisfatti (INP < 200 millisecondi).

Anche se non è di per sé una metrica CWV, il tempo per il primo byte (TTFB) è comunque un valore importante da monitorare perché, spesso, procede di pari passo con l'LCP.

Un sito di e-commerce già ad alta velocità è diventato ancora più rapido nel corso degli ultimi otto mesi da quando la piattaforma è stata migliorata (per ulteriori informazioni, consultate la sezione "Che cosa abbiamo migliorato?"). Nella Figura 3, viene illustrato un continuo incremento, in linea con i miglioramenti della piattaforma di Akamai, nella percentuale di utenti che si sono dichiarati soddisfatti dei valori TTFB riscontrati sul sito.

Un altro cliente, che opera sempre nel settore alberghiero, tradizionalmente ha registrato valori TTFB sotto la media e non ha utilizzato i sistemi di ottimizzazione delle performance messi a disposizione da Akamai. Dopo aver implementato alcune best practice consigliate dal team addetto alla performance di Akamai, il cliente ha visto migliorare il valore TTFB del proprio sito web, che è passato da 3 secondi a soli 0,6 secondi in poco più di un mese (Figura 4).

Con Akamai, non sono solo i siti più lenti ad acquisire maggiore velocità, ma anche i siti già veloci. Il sito di e-commerce illustrato nella Figura 5, che registra milioni di visitatori al mese, ha recentemente raggiunto uno straordinario valore LCP, pari a 500 millisecondi LCP al P75, un eccellente INP di 50 millisecondi e un punteggio CLS (Cumulative Layout Shift) pari a zero.

Utilizzando la piattaforma di Akamai, potrete creare siti innovativi e altamente scalabili con migliori tempi di attività e i massimi livelli di performance del settore senza compromessi: solo il meglio.

A questo punto del post, potreste aspettarvi un confronto tra le nostre performance e quelle di altre reti per la distribuzione dei contenuti (CDN). Tuttavia, specialmente nel 2025, riteniamo che, in coscienza, sia difficile effettuare un confronto di questo tipo.

Un motivo principale consiste nel fatto che le metriche CWV dipendono non solo dalla velocità della CDN, ma anche dalla programmazione del front-end e del back-end di un sito, nonché dalle sue specifiche configurazioni della CDN, tutti valori che possono essere completamente diversi da un sito all'altro. Ovviamente, potete creare siti sia veloci che lenti su qualsiasi piattaforma. 

L'alternativa è utilizzare metriche di livello inferiore, come un basso valore TTFB, che, all'apparenza, è una metrica facilmente confrontabile tra le varie CDN: basta scaricare qualcosa da una CDN,  misurare la velocità della connessione e i tempi della richiesta... et voilà!

Tuttavia, anche se è certamente facile raccogliere questi risultati, tali valori hanno sempre meno senso nell'odierno mondo dei protocolli HTTP/3 (e HTTP/2) e delle loro connessioni multioggetto. L'efficiente (ri)utilizzo di queste connessioni tramite avanzate funzioni (come la prioritizzazione dei flussi e la condivisione della larghezza di banda) ha molta più importanza per le experience degli utenti finali (e per le metriche, come l'LCP) rispetto alla configurazione iniziale di tali connessioni.

Inoltre, molte altre tecniche cambiano il modo con cui il valore TTFB viene misurato in pratica, inclusi il codice 103 Early Hints, l'intestazione Early-Data (0-RTT), i record DNS HTTPS, l'API delle regole di speculazione, ecc. (come verrà descritto nella sezione "Che cosa abbiamo migliorato?").

Di conseguenza, la misurazione del valore TTFB per due oggetti presenti su due CDN (uno con e uno senza una di queste funzioni attivate) può condurre già a risultati radicalmente diversi che non dicono nulla su ciò che la CDN è effettivamente in grado di fare (come illustrato nelle Figure 1-5).

Per dimostrare la nostra teoria, ecco l'esempio di un cliente che si è affidato eccessivamente ad una previsione secondo cui avrebbe registrato una drastica riduzione del valore TTFB del proprio sito in seguito all'abbandono della soluzione di Akamai (Figura 6). Il cliente era passato ad un'altra soluzione agli inizi di agosto 2024 e, sfortunatamente, i suoi dati CrUX pubblici erano peggiorati all'istante.

Ci siamo focalizzati sui dati CWV relativi ai clienti di Akamai per mostrare come abbiamo influito sugli utenti reali anziché affidarci alle tradizionali tecniche di confronto degli standard di riferimento. L'importante è non farsi abbagliare da grandi promesse, ma, invece, controllare le metriche CWV di alcuni dei siti più importanti al mondo: molto probabilmente, si sono affidati ad Akamai e le loro performance sono assolutamente straordinarie.

Ora che avete constatato quali straordinari risultati potete aspettarvi dai miglioramenti che abbiamo apportato negli ultimi 12 mesi, è giunto il momento di descrivere in maggior dettaglio di cosa si tratta. Abbiamo apportato miglioramenti nelle seguenti aree:

• Piattaforma
• Akamai Image & Video Manager
• Soluzioni per la sicurezza
• Analisi e monitoraggio degli utenti reali

Il fulcro di Akamai è rappresentato dalla sua piattaforma altamente distribuita che continua ad avvicinare sempre più i carichi di lavoro agli utenti finali. Questa piattaforma ampiamente diffusa ci consente di implementare i nostri miglioramenti con una portata senza precedenti.

Tra gli ultimi miglioramenti concepiti nell'intento di distribuire i vostri contenuti il più rapidamente possibile (agli utenti reali), figurano i seguenti

• Codice 103 Early Hints
• Intestazione Early-Data (0-RTT)
• TLS 1.3 all'origine
• API delle regole di speculazione
• Ottimizzazioni del DNS
• Limite anti-amplificazione

Per le risorse non memorizzabili nella cache e i mancati riscontri nella cache, ​gli edge server di Akamai​ devono contattare il server di origine. In tal modo, viene lasciata inattiva la connessione tra il browser del cliente e i nostri edge server finché non arriva la risposta.

Con il codice Early Hints, i browser possono usare questo tempo di attesa per precaricare le risorse specificate, come i principali fogli di stile CSS (Cascading Style Sheets), i caratteri web o i codici JavaScript critici, nonché preconnettersi a domini o sottodomini di terze parti. Akamai vi offre il pieno controllo sul codice Early Hints per aiutarvi ad accelerare in modo significativo le vostre experience di rendering (LCP).

L'intestazione Early Data è una nuova funzione potente sia per l'HTTP/2 tramite TCP (Transmission Control Protocol) che per l'HTTP/3 tramite QUIC, che consente ai browser di risparmiare un valore RTT (Round-Trip Time) completo sulla maggior parte delle connessione all'edge di Akamai.

Inoltre, è perfettamente compatibile con altre opzioni, come il codice Early Hints, per trasmettere i dati ai browser degli utenti il più presto possibile. Akamai consente di configurare questa potente funzione per garantire i migliori livelli di sicurezza e performance.

Anche se utilizziamo connessioni persistenti al loro massimo potenziale, a volte Akamai deve stabilire una nuova connessione TCP dal proprio edge alla vostra origine. Abbiamo aggiunto il supporto della versione TLS 1.3, evitando così l'ulteriore RTT che era necessario con la versione TLS 1.2. Per trarre vantaggio da questi miglioramenti nella latenza, assicuratevi di configurare correttamente le vostre origini.

Potete utilizzare la nuova API delle regole di speculazione per velocizzare le applicazioni multipagina eseguendo il prefetching o il prerendering delle future navigazioni. Questa API è in grado di effettuare i caricamenti quasi immediatamente durante il prerendering delle pagine a cui i vostri utenti potrebbero accedere successivamente.

Akamai offre varie opzioni per la distribuzione delle regole di speculazione ai vostri utenti finali, quindi potete influire notevolmente su KPI importanti, come i valori LCP e CLS.

Il nostro team addetto al DNS ha iniziato ad implementare la nostra architettura DNS anycast di nuova generazione. Questo programma, denominato Megacloud, è stato avviato su 8 dei nostri 22 cluster indipendenti che sono stati già convertiti

e annuncerà ognuna delle nostre reti anycast da più sedi. La transizione è complessa e progettata in modo da garantire che non vi saranno compromessi nella resilienza agli attacchi. Ne risulteranno ricerche del DNS anycast più veloci in tutti i percentili e le aree geografiche.

Di solito, l'handshake delle connessioni QUIC richiede 1 solo RTT sulla rete per il completamento. Tuttavia, poiché Akamai è rigorosamente conforme ad alcune requisiti di sicurezza del settore (sulla scia delle raccomandazioni dell' RFC 9000), molte connessioni QUIC (e, quindi, HTTP/3) in pratica richiedono, invece, due RTT.

Per risolvere questo problema, abbiamo incrementato il limite anti-amplificazione delle connessioni QUIC da tre (in base all'RFC) a sette, quindi ora potete trarre pieno vantaggio dalle performance dell'HTTP/3 con un solo RTT per stabilire la connessione.

La nitidezza delle immagini è una parte essenziale della rete moderna. Se il valore LCP è adeguato, le immagini si caricano rapidamente e la soluzione Image & Video Manager è stata concepita per raggiungere questo obiettivo.

• Sottocampionamento della crominanza SharpYUV: AVIF e HEIF sono due moderni formati delle immagini che siamo in grado di fornire e che ora usano la versione SharpYUV del sottocampionamento della crominanza per offrire una migliore rappresentazione dei colori e una maggiore efficienza della compressione.

• Cache+: questo nuovo componente aggiuntivo vi consente di utilizzare Akamai Cloud Wrapper per memorizzare nella cache i prodotti derivati di Image & Video Manager. Inoltre, fornisce uno spazio dedicato nella cache all'interno di Cloud Wrapper per offrirvi un maggior controllo sulle policy di gestione e mantenimento della cache. Ciò influisce notevolmente sulle performance perché riduce la rielaborazione non necessaria e garantisce alle immagini di rimanere nella cache più a lungo, diminuendo le perdite di cache long-tail.

La maggior parte dei nostri clienti non vuole scendere a compromessi con la sicurezza. Tuttavia, ciò non significa che non danno alcuna importanza alle performance.

Nel corso degli ultimi 12 mesi, abbiamo ottimizzato sia la logica sull'edge che la logica lato client delle nostre soluzioni per la sicurezza (come Akamai Bot Manager e Akamai Content Protector). Per le librerie lato client, sono state apportate le seguenti tipiche ottimizzazioni JavaScript:

• Suddivisione delle attività più lunghe in segmenti più brevi
• Rimozione del codice non utilizzato
• Passaggio alle librerie più veloci
• Sostituzione del vecchio codice con controparti più veloci

Queste ottimizzazioni hanno determinato una riduzione dell'invio di byte in rete, diminuendo la congestione dei percorsi di importanza critica e abbassando i tempi necessari per l'analisi e la compilazione del codice JavaScript. Inoltre, l'impatto esercitato dalle nostre soluzioni per la sicurezza sulle metriche TBT (Total Blocking Time) e INP (Interaction to Next Paint) è risultato notevolmente ridotto (ad esempio, vedere la Figura 2).

Una volta comprese le metriche relative alle performance e il modo con cui vengono influenzate dalle varie ottimizzazioni, la domanda successiva che possiamo chiederci è: "Come le misuriamo?". Raggiungere una visibilità end-to-end può risultare complicato, specialmente se si utilizzano più provider di servizi cloud, diversi servizi e una sola CDN.

Fortunatamente, sono disponibili alcune soluzioni per risolvere questi specifici problemi operativi, inclusi quelli riscontrati all'interno della soluzione Akamai mPulse per il monitoraggio degli utenti reali (RUM) e l'osservabilità della CDN.

• Dashboard di attribuzione delle CWV: sapere che il proprio sito è lento è una cosa, scoprire perché è lento è molto più complesso. Alcuni nuovi widget mPulse sono stati resi disponibili per risolvere questo problema perché aiutano ad attribuire i problemi del CLS, ad identificare le cause INP peggiori e più frequenti e a classificare gli elementi del valore LCP.

• Nuovi timer e metriche: tanti interessanti timer e nuove dimensioni sono stati aggiunti alla soluzione mPulse allo scopo di rimuovere le tipiche falle nella visibilità, ridurre il disturbo del RUM e semplificare l'analisi dei dati più rilevanti, tra cui il valore Frustrationindex, lo stato della cache della CDN sulla pagina, quattro nuovi timer del front-end e le informazioni BFCache.

• UNO (Unattributed Navigation Overhead): questo nuovo timer accumula tutti gli intervalli di tempo "sconosciuti" e "aggiuntivi" di una navigazione che non vengono calcolati negli altri timer, tra cui ritardi del browser, i tempi necessari per accedere al disco, i tempi nascosti dalle restrizioni cross-origin, ecc. Questa metrica aiuta a colmare le lacune esistenti e ad individuare i problemi che potrebbero essere rimasti nascosti.

• La soluzione Akamai DataStream 2 è stata modificata e ora include altri dati rilevanti per le performance:

  • Supporto delle intestazioni Early Data TLS e del campo 103 Early Hints
  • Supporto di Akamai EdgeWorkers
  • Supporto della destinazione di TrafficPeak

• Breadcrumbs: la nuova funzione Breadcrumbs vi offre una visibilità in tempo reale sulle condizioni degli errori e sugli aspetti che influiscono sulle performance per la delivery dei contenuti.

• CMCD (Common Media Client Data): raccogliere i dati sulle performance e le metriche sull'utilizzo dei dati dai dispositivi che distribuiscono contenuti come video, brani musicali o giochi è fondamentale per misurare le performance dello streaming. Potete identificare e mitigare:

  • Eventi di buffering
  • Ritardi all'avvio
  • Problemi relativi alla qualità della riproduzione
  • Percentuali di errore
  • Throughput

Negli ultimi 12 mesi, abbiamo introdotto vari miglioramenti che hanno reso più veloci le moderne applicazioni, non solo sulla carta, ma anche per gli utenti reali. L'impatto di questi cambiamenti è mostrato in modo chiaro nei dati CrUX ripetutamente e conduce a risultati CWV notevolmente ottimizzati, migliorando le experience degli utenti finali e il posizionamento nel motore di ricerca di Google.

Anche se siamo soddisfatti dei molti miglioramenti apportati, i nostri team hanno sempre l'opportunità di risparmiare altri millisecondi, sempre tenendo conto dei fattori di sicurezza, scalabilità e disponibilità.

Altre ottimizzazioni sono pianificate per le settimane, i mesi e gli anni a venire. Tenetevi aggiornati: aspettiamo con impazienza un futuro ancora più veloce.