#BlackLivesMatter
AMP

Come funziona AMP

La combinazione delle seguenti ottimizzazioni permette alle pagine AMP di essere così veloci da garantire il caricamento istantaneo. Si tratta di 7 motivi, ma se per te è troppo lungo da leggere, puoi guardare semplicemente il video esplicativo:

Esecuzione asincrona di tutti i codici JavaScript AMP

JavaScript è potente, può modificare praticamente ogni aspetto della pagina, ma può anche bloccare la costruzione del DOM e ritardare il rendering della pagina (consultare anche Aggiunta di interattività con JavaScript). Per impedire a JavaScript di ritardare il rendering della pagina, AMP consente solo l'esecuzione di JavaScript asincrono.

I componenti AMP possono contenere codici JavaScript nascosti, ma sono accuratamente progettati per evitare peggioramenti delle performance.

Sebbene il codice JS personalizzato sia consentito in componenti amp-script, e il codice JS di terze parti sia consentito in iframe, questi non bloccheranno mai il rendering. Ad esempio, se un codice JS di terze parti utilizza un API che ha un impatto notevole sulle prestazioni: document.write, questa non blocca il rendering della pagina principale.

Dimensione statica di tutte le risorse

Le risorse esterne, come immagini, annunci o iframe, devono dichiarare le loro dimensioni in HTML in modo che AMP possa determinare le dimensioni e la posizione di ciascun elemento prima che le risorse vengano scaricate. AMP carica il layout della pagina senza attendere il download di alcuna risorsa.

AMP separa il layout del documento dal layout delle risorse. È necessaria una sola richiesta HTTP per realizzare il layout dell'intero documento (+ caratteri). Poiché AMP è ottimizzato per evitare costosi ricalcoli e layout di stile nel browser, non ci saranno nuove ristrutturazioni del layout quando le risorse saranno caricate.

I meccanismi di estensione non bloccano il rendering

AMP non consente ai meccanismi di estensione di bloccare il rendering della pagina. AMP supporta estensioni per elementi quali lightbox, instagram embedding, tweet, ecc. Sebbene tali elementi necessitino di richieste HTTP aggiuntive, esse non bloccano il layout e il rendering della pagina.

Qualsiasi pagina che utilizza uno script personalizzato deve dichiarare al sistema AMP che presenta un tag personalizzato. Ad esempio, lo script amp-iframe indica al sistema che ci sarà un tag amp-iframe. AMP crea la casella iframe prima ancora di sapere cosa includerà:

<script async custom-element="amp-iframe" src="https://cdn.ampproject.org/v0/amp-iframe-0.1.js"></script>

Mantieni tutti i codici JavaScript di terze parti fuori dal percorso critico

Gli elementi JS di terze parti di solito utilizzano il caricamento JS sincrono. Inoltre adottano anche la sincronizzazione di più script con document.write. Ad esempio, se hai cinque annunci sulla tua pagina e ognuno di essi provoca tre caricamenti sincroni, ciascuno con un ritardo di connessione di 1 secondo, avrai un tempo di caricamento di 15 secondi solo per i codici JS.

Le pagine AMP consentono i codici JavaScript di terze parti ma solo negli iframe in modalità sandbox. Limitandoli agli iframe, essi non possono bloccare l'esecuzione della pagina principale. Anche se attivano ricalcoli multipli di stile, i loro piccoli iframe hanno DOM davvero limitati.

Il tempo necessario per eseguire i ricalcoli di stile e layout è limitato dalle dimensioni del DOM, quindi i ricalcoli iframe sono molto rapidi rispetto al ricalcolo di stili e layout per la pagina.

Tutti gli elementi CSS devono essere inline e dalle dimensioni limitate

Gli elementi CSS bloccano tutto il rendering, il caricamento della pagina e tendono a dilatarsi. Nelle pagine AMP HTML sono consentiti solo stili inline. In questo modo si escludono una o più richieste HTTP dal percorso di rendering critico rispetto alla maggior parte delle pagine web.

Inoltre il foglio di stile inline ha una dimensione massima di 50 kilobyte. Anche se questa dimensione è sufficiente per pagine molto sofisticate, richiede tuttavia che l'autore della pagina faccia buona pulizia degli elementi CSS.

L'attivazione dei caratteri deve essere efficiente

I caratteri web sono molto grandi, per cui l'ottimizzazione dei caratteri web è fondamentale per le performance. In una pagina tipica con alcuni script di sincronizzazione e alcuni fogli di stile esterni, il browser attende a scaricare questi caratteri enormi fino a quando tutto ciò non si verifica.

Il sistema AMP dichiara zero richieste HTTP fino all'avvio del download dei caratteri. Questo è possibile solo perché tutti i codici JS in AMP hanno l'attributo async e sono consentiti solo i fogli di stile inline; non ci sono richieste HTTP che impediscono al browser di scaricare i caratteri.

Ridurre al minimo i ricalcoli di stile

Ogni volta che si misura qualcosa, si attivano ricalcoli di stile che sono onerosi perché il browser deve costruire il layout dell'intera pagina. Nelle pagine AMP, tutte le letture DOM avvengono prima di tutte le scritture. Questo assicura che ci sia al massimo un ricalcolo di stili per frame.

Ulteriori informazioni sull'impatto dei ricalcoli di stile e layout sulle performance di rendering.

Esecuzione delle sole animazioni con accelerazione GPU

L'unico modo per avere ottimizzazioni veloci è eseguirle sulla GPU. La GPU conosce i livelli, sa come eseguire alcune operazioni su questi livelli, può spostarli, rimuoverli, ma non può aggiornare il layout della pagina; lascerà tale compito al browser e questo non va bene.

Le regole per gli elementi CSS relativi alle animazioni assicurano che le animazioni possano essere accelerate dalla GPU. In particolare, AMP consente solo l'animazione e la transizione su trasformazioni e opacità, che non richiedono il layout di pagina. Ulteriori informazioni sull'utilizzo di trasformazioni e opacità per i cambiamenti di animazione.

Priorità per il caricamento di risorse

AMP controlla tutti i download di risorse: gestisce la priorità del caricamento di risorse, caricando solo ciò che è necessario e recuperando in anticipo le risorse caricate in modalità lazy.

Durante il download delle risorse, AMP ottimizza le operazioni in modo che le risorse più importanti vengano scaricate per prime. Le immagini e gli annunci vengono scaricati solo se è probabile che siano visualizzati dall'utente, in primo piano, o se è probabile che l'utente scorra rapidamente verso di essi.

AMP recupera in anticipo anche le risorse caricate in modalità lazy. Le risorse vengono caricate il più tardi possibile, ma vengono recuperate il più presto possibile. In questo modo gli oggetti si caricano molto velocemente ma la CPU viene utilizzata solo quando le risorse vengono effettivamente mostrate agli utenti.

Caricamento istantaneo delle pagine

La nuova API preconnect viene sfruttata per garantire che le richieste HTTP vengano gestite il più veloce possibile. In questo modo, è possibile eseguire il rendering di una pagina prima che l'utente dichiari esplicitamente che desidera accedervi; la pagina potrebbe essere già disponibile al momento in cui l'utente la seleziona effettivamente, con conseguente caricamento istantaneo.

Se il pre-rendering può essere applicato a tutti i contenuti web, esso può anche determinare un notevole impiego di banda e CPU. AMP è ottimizzato per ridurre entrambi questi fattori. Il pre-rendering scarica solo le risorse in primo piano e il pre-rendering non gestisce gli oggetti che potrebbero essere onerosi in termini di CPU.

Durante il pre-rendering di documenti AMP per il caricamento istantaneo, vengono effettivamente scaricate solo le risorse in primo piano. Durante il pre-rendering di documenti AMP per il caricamento istantaneo, le risorse che potrebbero utilizzare molta CPU (come iframe di terze parti) non vengono scaricate.

Maggior informazioni su Perchè AMP HTML non sfrutta appieno il pre-caricamento.