AMP
IT
English Deutsch Français العربية Español Indonesia 日本語 한국어 Português Русский Türkçe 中文 Polski Tiếng việt

Ottimizzazione delle pagine AMP ospitate

Important: this documentation is not applicable to your currently selected format email!

Questa guida fornisce suggerimenti e indicazioni per i webmaster che intendono ottimizzare i loro siti web AMP ospitati.

L'AMP è davvero così veloce per definizione?

Il sistema di runtime AMP è in grado di ottimizzare la velocità delle pagine e se le pagine AMP sono fornite da una cache AMP, esse sono completamente ottimizzate per offrire le massime prestazioni di caricamento. Ad esempio, se gli utenti accedono alle tue pagine AMP da Google Search su dispositivi mobili, per impostazione predefinita le pagine saranno fornite da una cache AMP.

Tuttavia, le pagine AMP non vengono sempre fornite da una cache AMP. Un sito web può decidere di mostrare pagine AMP dai propri server per altre sorgenti di traffico. Il caso più frequente è quello di siti realizzati completamente in AMP, come tasty.co, in cui gli utenti hanno la possibilità di accedere direttamente al sito. Un'altra fonte di traffico è Twitter, che ha iniziato a fornire collegamenti alle versioni AMP delle pagine invece di quelle mobili standard. Se un utente clicca su un collegamento in una delle app mobili di Twitter, il collegamento porta alla versione AMP della pagina in questione direttamente sulla sua origine (se disponibile).

Di conseguenza, non sempre le tue pagine AMP saranno fornite solo da cache AMP. Nei casi in cui le pagine AMP sono fornite dai loro server di origine, è importante assicurarsi che esse offrano ugualmente prestazioni di caricamento ottimali.

Le pagine AMP si caricano velocemente per impostazione predefinita, ma ci sono alcune ottimizzazioni aggiuntive delle prestazioni implementabili per permettere ai browser di caricare le pagine ancora più velocemente. Questa guida descrive alcune ottimizzazioni da considerare per la pubblicazione di pagine AMP. Tuttavia, prima di iniziare a leggere, occorre aver studiato tutte le procedure consigliate per ottimizzare le prestazioni web fondamentali. In particolare, l'ottimizzazione delle immagini ha un grande impatto sulla velocità di caricamento delle pagine.

Ad esempio, si possono applicare le seguenti tecniche di ottimizzazione:

il caricamento del modello "The Scenic" è più veloce di due secondi sulle connessioni 3G.

Se vuoi saltare i dettagli dell'implementazione, puoi usare il generatore Boilerplate AMP per generare direttamente pagine AMP ottimizzate personalizzate.

Ottimizzazione del caricamento del sistema runtime AMP

Anche se la specifica AMP è già abbastanza restrittiva sui markup consentiti nella sezione <head>, c'è ancora spazio per ottimizzazioni. Il segreto è strutturare la sezione <head> in modo che tutti gli script che bloccano il rendering e i caratteri personalizzati vengano caricati il più velocemente possibile.

Di seguito è riportato l'ordine consigliato per gli elementi della sezione <head> in una pagina AMP:

<!doctype html>

        <meta charset="utf-8">     <meta name="viewport" content="width=device-width">     <meta name="description" content="This is the AMP Boilerplate.">     <link rel="preload" as="script" href="https://cdn.ampproject.org/v0.js">     <link rel="preload" as="script" href="https://cdn.ampproject.org/v0/amp-experiment-0.1.js">     <link rel="preconnect dns-prefetch" href="https://fonts.gstatic.com/" crossorigin="">     <script async="" src="https://cdn.ampproject.org/v0.js"></script>     <script async="" custom-element="amp-experiment" src="https://cdn.ampproject.org/v0/amp-experiment-0.1.js"></script>     <comment></comment>     <style amp-custom=""><br>      /* Add your styles here */<br>    </style>     <link href="https://fonts.googleapis.com/css?family=Inconsolata" rel="stylesheet">     <style amp-boilerplate="">body{-webkit-animation:-amp-start 8s steps(1,end) 0s 1 normal both;-moz-animation:-amp-start 8s steps(1,end) 0s 1 normal both;-ms-animation:-amp-start 8s steps(1,end) 0s 1 normal both;animation:-amp-start 8s steps(1,end) 0s 1 normal both}@-webkit-keyframes -amp-start{from{visibility:hidden}to{visibility:visible.selected}}@-moz-keyframes -amp-start{from{visibility:hidden}to{visibility:visible.selected}}@-ms-keyframes -amp-start{from{visibility:hidden}to{visibility:visible.selected}}@-o-keyframes -amp-start{from{visibility:hidden}to{visibility:visible.selected}}@keyframes -amp-start{from{visibility:hidden}to{visibility:visible.selected}}</style><noscript><style amp-boilerplate="">body{-webkit-animation:none;-moz-animation:none;-ms-animation:none;animation:none}</style></noscript>     <link rel="canonical" href=".">     <title>My AMP Page</title>           <h>Hello World</h>

Esaminiamo tale ordine un elemento alla volta:

  1. Il primo tag deve essere il tag meta charset, seguito da eventuali tag meta rimanenti.

  2. Quindi occorre precaricare il tag v0.js <script> del runtime AMP con <link as=script href=https://cdn.ampproject.org/v0.js rel=preload>. Il download del sistema di runtime AMP deve iniziare appena possibile, poiché il componente AMP boilerplate nasconde il documento tramite l'attributo body { visibility:hidden } fino al termine di tale caricamento. Il precaricamento del sistema di runtime AMP dice al browser di caricare con la massima priorità lo script. Puoi dare un'occhiata alla sezione rendering lato server per imparare ad evitare questa situazione. {amp-img6} {/amp-img6}

  3. Se la pagina include estensioni che ritardano il rendering (ad es. Amp-experiment, amp-dynamic-css-classes, amp-story), occorre precaricare tali estensioni in base a come sono richieste dal runtime AMP per il rendering della pagina. [sourcecode: html]

[/sourcecode] 1. Usare preconnect per velocizzare la connessione all'altra risorsa che non conosce in anticipo l'URL completo della risorsa, ad esempio Google Fonts: 

&amp;amp;lt;link rel="preconnect dns-prefetch" href="https://fonts.gstatic.com/" crossorigin&amp;amp;gt;
  1. Caricare il runtime AMP: 
&amp;amp;lt;script async src="https://cdn.ampproject.org/v0.js"&amp;amp;gt;&amp;amp;lt;/script&amp;amp;gt;
  1. Indicare i tag <script> per render-delaying extensions (ad es., amp-experiment amp-dynamic-css-classes and amp-story<br>1. Indicare i tag&amp;lt;script&amp;gt; per le estensioni rimanenti (ad es., amp-bind ...). Tali estensioni non ritardano il rendering per cui non devono essere precaricate, poiché potrebbero consumare preziose risorse di rete al rendering iniziale.<br>1. Indicare eventuali stili personalizzati tramite tag &lt;style amp-custom&gt;.&lt;br&gt;1. Aggiungere gli altri tag consentiti nella sezione&lt;head&gt;`. In particolare, i font esterni vanno alla fine perché bloccano il rendering. 1. Infine indicare AMP boilerplate code. Inserendo il codice boilerplate alla fine, si evita che gli stili personalizzati possano sovrascrivere inavvertitamente le regole css boilerplate.<br>

La cache AMP esegue automaticamente tutte queste ottimizzazioni (e alcune altre). Puoi utilizzare lo strumento AMP Optimizer per eseguire automaticamente queste ottimizzazioni sulle pagine della tua origine.

Precaricamento delle immagini hero

AMP HTML utilizza un proprio elemento per le immagini: amp-img. Sebbene amp-img abbia molti vantaggi rispetto al tradizionale tag HTML img, uno svantaggio è che il sistema di runtime AMP deve essere caricato prima che il download dell'immagine possa iniziare. Per alcune immagini, come le immagini hero per una pagina di prodotto, è fondamentale che esse siano caricate il più rapidamente possibile. In questi casi, è meglio pre-caricare l'immagine per assicurarsi che il browser inizi a scaricare l'immagine il prima possibile e non sia necessario attendere il caricamento del runtime AMP.

   <link rel="preload" href="/images/elephants.png" as="image">     ...   {amp-img1}   {/amp-img1}

Ma cosa succede se il layout reattivo richiede immagini hero diverse a seconda della larghezza dello schermo? Ad esempio, un'immagine ampia per desktop e un'immagine più stretta per dispositivi mobili come in questo caso:

 {amp-img0} {/amp-img0} {amp-img1} {/amp-img1}

La cosa buona è che link rel=preload supporta anche le media query. Quindi possiamo usare le stesse media query nelle nostre istruzioni di precaricamento, in questo modo:

<link rel="preload" as="image" href="/images/elephants_narrow.png" media="(max-width: 415px)"> <link rel="preload" as="image" href="/images/elephants_wide.jpg" media="(min-width: 416px)">

Lo stesso approccio funziona anche per le immagini dei poster in amp-video:

<link rel="preload" href="/images/poster.jpg" as="image"> ...  {amp-video1}      ... {/amp-video1}

Occorre essere sicuri di inserire le istruzioni di precaricamento dopo la dichiarazione della finestra di visualizzazione perché il browser necessita delle dimensioni della finestra per determinare la larghezza dello schermo:

<meta name="viewport" content="width=device-width">(max-width: 415px)" ...="">

Precaricare solo le immagini critiche, altrimenti il download dell'immagine potrebbe occupare risorse di rete richieste per il download di altri elementi critici.

Considerare l'idea di utilizzare un processo di lavoro dei servizi

Ora che tutti i principali browser supportano i processi di lavoro dei servizi, è una buona idea valutare l'opportunità di aggiungerne uno al proprio sito.

Esistono due diverse architetture di rete che funzioneranno per navigazioni rapide e affidabili:

  • Per applicazioni a pagina singola: il modello App Shell (che nel contesto AMP è detto AMP-in-PWA). Questo modello richiede che un processo di lavoro dei servizi trasformi un documento AMP in una PWA basata su app shell.
  • Per applicazioni multi-pagina: streaming di risorse composte. Un processo di lavoro dei servizi memorizza nella cache l'intestazione e il piè di pagina statici e utilizza lo streaming per restituire immediatamente una risposta parziale memorizzata nella cache durante il caricamento del contenuto.

Se nessuno di questi modelli viene utilizzato e non è possibile memorizzare nella cache l'intero sito (il che può avvenire solo per siti molto piccoli), il processo di lavoro dei servizi potrebbe avere un impatto negativo sulle prestazioni. La cosa migliore in questo caso è non utilizzarne.

Tuttavia, se occorre che il sito web sia installabile dalla schermata iniziale o per offrire un'esperienza offline, l'uso di un processo di lavoro dei servizi sarà necessario. In questo caso, è importante utilizzare il precaricamento di navigazione per ridurre il potenziale rallentamento (Nota: attualmente, il precaricamento di navigazione è supportato solo in Chrome).

Ecco alcune procedure consigliate, se un sito web AMP utilizza un processo di lavoro dei servizi:

Se stai pensando di inserire un processo di lavoro dei servizi nel tuo sito AMP, dai un'occhiata a questo esempio che ne fornisce uno che implementa tutte le procedure consigliate.

Il sistema di runtime AMP viene pubblicato al massimo 50 minuti dopo ogni aggiornamento per garantire che le modifiche siano sempre disponibili rapidamente. Per evitare probabili mancanze nella cache del browser, è una buona idea fornire il sistema di runtime AMP in uso da un processo di lavoro.

La pre-memorizzazione in cache è importante per una rapida transizione dalle pagine AMP nella cache a pagine sulla loro origine, con o senza contenuti AMP. Il motivo è che la cache AMP riscrive gli URL del sistema di runtime AMP, modificando l'URL sempre valido in quello dell'ultima versione rilasciata, ad esempio:

https://cdn.ampproject.org/v0.js -> https://cdn.ampproject.org/rtv/001515617716922/v0.js.

La conseguenza è che una pagina AMP fornita dalla propria origine non beneficia del caching del browser e in questo caso deve scaricare nuovamente il runtime AMP (senza versione). Un processo di lavoro permette di pre-memorizzare nella cache il runtime AMP senza versione e accelerare la transizione. Per ulteriori informazioni sul motivo per cui la cache AMP applica le versioni agli URL di runtime AMP, consultare questo documento.

In Safari, c'è una differenza fondamentale nel modo in cui vengono implementati i processi di lavoro dei servizi: non è possibile in Safari installare un processo di lavoro per la propria origine, se la pagina è fornita da una cache AMP.

Ottimizzazione dei caratteri personalizzati

In AMP ci sono alcuni modi per ottimizzare il caricamento dei caratteri (la maggior parte di essi non sono in realtà specifici di AMP):

  • Se possibile, utilizzare la direttiva }font-display: optional: essa userà i caratteri solo se sono già nella cache e tornerà ai caratteri di sistema se quelli personalizzati non sono stati ancora caricati.
  • Ottimizzare i caratteri web (ad esempio, fornire caratteri personalizzati usando WOFF2).
  • Pre-caricare i caratteri personalizzati: 
<link rel="preload" as="font" href="/bundles/app/fonts/helveticaneue-roman-webfont.woff2">

-Se si usano caratteri Google o di qualsiasi altro fornitore con URL di caratteri sconosciuto, occorre precollegare il rispettivo server: 

  <link rel="preconnect dns-prefetch" href="https://fonts.gstatic.com/" crossorigin>

Altra cosa importante, prova a ridurre al minimo il numero di caratteri personalizzati che utilizzi sulla tua pagina. Se puoi, usa i caratteri di sistema invece dei caratteri personalizzati perché i caratteri di sistema fanno corrispondere il tuo sito web al sistema operativo dell'utente ed evitano di caricare altre risorse.

Layout AMP per il rendering lato server

Il layout AMP con rendering lato server è una tecnica utilizzata dalle cache AMP per accelerare ulteriormente i tempi di caricamento. Con il rendering lato server è possibile rimuovere il boilerplate AMP in modo che il documento AMP possa essere tracciato senza eseguire JavaScript di runtime AMP. Ad esempio, la versione con rendering lato server di AMP Boilerplate Generator è due volte più veloce della normale versione AMP!

Se stai pubblicando una pagina AMP, dovresti assolutamente considerare l'utilizzo di AMP Optimizer. Gli ottimizzatori AMP consentono di pubblicare pagine AMP ottimizzate dal tuo backend che includono layout AMP con rendering lato server. L'ottimizzatore AMP esegue automaticamente anche molti altri miglioramenti descritti in questo documento.

Ottimizzazioni di base

Ovviamente, tutte le ottimizzazioni di base delle prestazioni web si applicano anche alle pagine AMP: