Tutto ciò che devi sapere sulle pagine mobili accelerate di Google

Nel maggio del 2015, Facebook ha presentato la sua nuova piattaforma di pubblicazione in-app, Instant Articles. Un mese dopo, Apple ha dichiarato che la vecchia esperienza di Edicola (essenzialmente una cartella stravagante piena di app di notizie) sarebbe stata sostituita in iOS 9 con una nuovissima piattaforma di aggregazione e scoperta di notizie chiamata Apple News.

Ulteriori letture su Smashing:

• Prestazioni percepite
• Precarico: a cosa serve?
• Prepararsi per HTTP/2
• Miglioramento progressivo
• Web AMP progressivi

Quattro mesi dopo, è stato il turno di Google di annunciare il proprio piano, un po' tardivo ma non meno ambizioso, per rivoluzionare il consumo di notizie mobili con una soluzione basata sul Web open source chiamata Accelerated Mobile Pages o AMP. In pochi mesi, abbiamo visto la relativa tranquillità dell'editoria digitale mobile sfociare in un'altra guerra di piattaforme su vasta scala mentre Facebook, Apple e ora Google competono sia per la fedeltà degli editori che per l'attenzione dei lettori.

Mentre Facebook e Apple hanno un vantaggio significativo su Google, ci sono tutte le ragioni per credere che AMP raggiungerà rapidamente (e potrebbe persino superare uno o entrambi i suoi concorrenti). Se sei uno sviluppatore o un editore che ha bisogno di aggiornarsi sul perché, cosa e come delle pagine mobili accelerate di Google nel modo più rapido ed efficiente possibile, sei nel posto giusto.

Ma qual è il problema?

Prima di discutere le soluzioni, vale la pena dedicare un momento all'esplorazione del problema. Se leggi molto su dispositivi mobili, è probabile che tu sia già fin troppo consapevole del fatto che l'interazione con i contenuti basati sul Web su un telefono o tablet varia da appena accettabile a orrenda. Le pagine spesso si caricano lentamente, vengono visualizzate in modo irregolare e si comportano in modo imprevedibile per due motivi principali:

• interferenza di terzi . Gli annunci e le relative tecniche di tracciamento non solo aggiungono richieste di massa e aggiuntive a un dispositivo già limitato dalla larghezza di banda e dalla CPU, ma le pagine spesso si comportano come se fossero possedute mentre si contorcono attorno a più chiamate document.write() . Il New York Times ha recentemente condotto un test che ha mostrato riduzioni significative delle dimensioni delle pagine e un aumento della durata della batteria dopo l'installazione di un blocco dei contenuti iOS.
• danni collaterali da design reattivo . Sebbene la maggior parte dei siti Web progettati in modo reattivo stiano bene su schermi di tutte le dimensioni, spesso contengono molto del bagaglio dei siti Web desktop se visualizzati su dispositivi mobili. Quando Paul Irish ha eseguito un controllo delle prestazioni di Reddit, ha scoperto che gran parte del sovraccarico poteva essere ricondotto a una risorsa chiamata SnooIcon, la mascotte di Reddit renderizzata in SVG in modo che potesse essere animata (da una libreria di terze parti, il che significa più sovraccarico) al passaggio del mouse, non una situazione in cui le risorse si trovano spesso su dispositivi mobili.

Inserisci gli articoli istantanei di Facebook, le notizie di Apple e le pagine mobili accelerate: i nostri salvatori da un mondo in cui, secondo Facebook (PDF, 3,4 MB), il tempo medio di caricamento di un articolo sui dispositivi mobili è di 8 secondi. Anche se chiamare 8 secondi un'eternità è ovviamente un'iperbole, dato che potresti essere nel tuo secondo video di Vine in quel lasso di tempo, è probabilmente giusto dire che, per gli standard odierni, è almeno un eone.

Una breve demo di Facebook Instant Articles, Apple News e Accelerated Mobile Pages. Tieni presente che gli articoli istantanei di Facebook e le notizie di Apple sono esperienze in-app, mentre AMP è interamente basato su browser.

In che modo AMP è diverso?

Un po' di contesto su come AMP è diverso da Facebook Instant Articles e Apple News renderà più chiare alcune delle decisioni prese da Google per la sua nuova iniziativa di pubblicazione digitale.

Gli articoli istantanei di Facebook e le notizie di Apple hanno diverse caratteristiche in comune:

• esperienze in-app . I lettori accedono agli articoli istantanei di Facebook tramite Facebook sui dispositivi mobili e Apple News è un'app standalone fornita con iOS 9. Nessuna delle due piattaforme attualmente consente agli utenti di visualizzare gli articoli nei loro formati specifici al di fuori della rispettiva app. Considera entrambi come un aggiornamento di RSS specifico per l'applicazione.
• guidato dalla sindacazione . Sebbene gli articoli istantanei di Facebook e le notizie di Apple utilizzino formati di diffusione molto diversi (il formato di notizie di Apple è basato su JSON e il markup degli articoli istantanei è più o meno racchiuso in HTML in un feed RSS), si basano su principi simili: convincere il tuo CMS a generare il formati di syndication necessari e Facebook o Apple News lo inghiottiranno, lo analizzeranno e lo renderanno bello e veloce attraverso renderer personalizzati e ottimizzati.
• orientato all'esperienza . Sebbene gli articoli istantanei di Facebook e le notizie di Apple siano entrambi incentrati sulle prestazioni, sono ugualmente interessati a rendere gli articoli dall'aspetto moderno. Entrambe le piattaforme hanno componenti che consentono interazioni fluide e fluide che tipicamente associamo a esperienze di lettura personalizzate e costruite a mano.

Al contrario, le pagine mobili accelerate hanno un focus distinto:

• esperienza basata sul web . I documenti AMP sono progettati per essere visualizzati nel browser o in WebView.
• documenti atomici . Sebbene i documenti AMP siano convalidati, analizzati e parzialmente visualizzati dal runtime AMP (molto altro su quello di seguito), sono documenti completi e indipendenti che risiedono sul tuo server web (e, facoltativamente, in una cache CDN), piuttosto che raccolte di metadati che a un certo punto verranno trasformati in articoli e resi in app.
• orientato alle prestazioni . AMP si preoccupa molto di più delle prestazioni dei documenti AMP che dell'estetica o dei modelli di interazione. Questo non vuol dire che i documenti AMP siano intrinsecamente semplici (possono essere attraenti come gli articoli istantanei di Facebook o gli articoli di Apple News con lo stile giusto), ma il runtime è molto più interessato a rendere un articolo rapidamente visualizzato che a fornire effetti visivi fantasiosi come piccole cose pazze e tremolanti.

Che cos'è esattamente AMP?

Basta con il filosofare e lo sventolare ad alto livello. Entriamo nello specifico. Mentre girare la testa su Facebook Instant Articles e Apple News è abbastanza facile (sono essenzialmente aggregatori di notizie fantasiosi con renderer personalizzati basati su formati di syndication proprietari), AMP è il valore anomalo. È un po' più difficile da capire, per due motivi:

• Non esiste un modello semplice con cui confrontarlo. Quando l'RSS era nuovo, ci meravigliavamo tutti del suo potere, scrivevamo innumerevoli articoli e post sul blog sul suo potenziale dirompente, dichiaravamo la home page morta (ancora una volta) e poi continuavamo a dimenticarlo. Gli articoli istantanei di Facebook e le notizie di Apple sono essenzialmente un riavvio RSS, tranne per il fatto che eliminano tutti gli inconvenienti degli standard e ognuno funziona in una sola applicazione.
• AMP non è un cliente. . Mentre Facebook Instant Articles, Apple News e AMP hanno diversi elementi in comune, come formati di syndication proprietari e renderer personalizzati, AMP è l'unico senza un client dedicato (diverso dal browser). Più dei suoi fratelli, AMP è un insieme di specifiche, convenzioni e tecnologie che possono essere combinate in una soluzione, piuttosto che essere una soluzione end-to-end (da editore a lettore) in sé e per sé.

Ora che sappiamo pensare a AMP come a una raccolta di ingredienti, piuttosto che a una torta completamente cotta, diamo un'occhiata a quali sono questi singoli componenti:

• HTML AMP,
• il runtime AMP,
• la cache AMP.

HTML AMP

I documenti AMP sono scritti in HTML, ma non solo in HTML. Alcuni tag vengono bannati, mentre vengono introdotti alcuni nuovi tag (in parte per sostituire quelli bannati e in parte per incapsulare funzionalità interattive). Puoi pensare all'HTML AMP come sarebbe l'HTML se fosse stato progettato pensando solo alle prestazioni mobili (invece di essere introdotto ben 14 anni prima dell'introduzione dell'iPhone).

Poiché AMP HTML è progettato per prestazioni ottimali, per comprenderne e apprezzarne il valore, dobbiamo comprendere i problemi che risolve. Ecco le tre cose principali che compromettono il caricamento e il rendering delle pagine Web sui dispositivi mobili:

• dimensione del carico utile . Il responsive web design ci è servito bene perché ci consente di creare un unico sito Web per ogni dispositivo e schermo disponibile. Ma questo a volte significa anche fornire payload di dimensioni desktop (HTML, JavaScript, CSS e risorse) a dispositivi mobili con limiti di larghezza di banda e CPU estremamente limitati. (Coloro che pensano ai loro telefoni come a dei piccoli computer desktop danno troppo credito all'hardware mobile. Il tuo iPhone 6s ha 2 GB di RAM, mentre il tuo laptop probabilmente ne ha 8 o 16.)
• caricamento delle risorse . Le risorse non vengono sempre caricate nell'ordine ottimale, il che significa che larghezza di banda, CPU e RAM sono spesso dedicate a risorse che gli utenti potrebbero non vedere mai. Inoltre, le risorse spesso non dichiarano le loro larghezze e altezze (specialmente se servite tramite reti pubblicitarie o iniettate tramite chiamate document.write() ), il che non solo fa sì che la pagina si ridimensioni automaticamente poiché le dimensioni delle risorse sono determinate pigramente, ma attiva anche operazioni non necessarie e costosi ricalcoli del layout. Questo è ciò che fa sì che le pagine web saltino in giro come gattini che inseguono il laser mentre si manifestano sempre così lentamente.
• Esecuzione JavaScript . Non ho intenzione di affrontare l'argomento delle prestazioni di JavaScript qui, ma i siti Web moderni spesso lo accumulano per megabyte e, sebbene possa essere eseguito senza alcuna latenza distinguibile sui computer desktop, i dispositivi mobili sono ancora un ambiente molto diverso, dove, penso siamo tutti d'accordo, JavaScript è meglio ridurre al minimo.

Dati questi tre ostacoli alle esperienze Web fluide sui dispositivi mobili, l'HTML AMP esiste principalmente per tre scopi:

• incoraggiare la brevità . I documenti AMP non sono versioni reattive di siti Web desktop. Sebbene i documenti AMP possano essere (e di solito lo sono) reattivi, sono reattivi in ​​un contesto mobile. In altre parole, piuttosto che una pagina che funziona assolutamente ovunque (desktop e mobile), i documenti AMP sono progettati specificamente per funzionare bene su tutti i dispositivi mobili.
• controllare il caricamento di risorse esterne . Il runtime AMP controlla il caricamento delle risorse esterne per garantire che il processo sia altamente efficiente, con il risultato che i contenuti vengono visualizzati sugli schermi degli utenti nel modo più rapido e intelligente possibile.
• incapsulare la funzionalità interattiva . Sebbene i documenti AMP tendano a dedicarsi direttamente al compito di presentare ai lettori esperienze di lettura semplici, ciò non significa che non possano essere moderni e interattivi. Il runtime AMP fornisce funzionalità incapsulate tramite JavaScript altamente ottimizzato, in modo che gli sviluppatori non rischino di ostacolare le prestazioni scrivendone di proprie.

Tag HTML AMP

Di seguito è riportato un elenco di tag che sono stati completamente banditi in AMP HTML:

• script Questo è ovviamente un grande. Fornirò maggiori dettagli sulla posizione di AMP su JavaScript di seguito; per ora, supponi che gli unici tag di script che avrai nei tuoi documenti AMP siano quelli che caricano il runtime AMP e, facoltativamente, un tag per i dati collegati basati su JSON.
• base Il tag di base sembra essere proibito per molta cautela e potrebbe finire nella whitelist se la comunità si lamenta. (La mia ipotesi è che a nessuno importi davvero in un modo o nell'altro.)
• frame e set di frameset Non esattamente un buon uso degli immobili mobili comunque, quindi buona liberazione.
• object , param , applet ed embed Purtroppo, i tuoi documenti AMP non conterranno alcuna applet Flash o Java. (Quello era sarcasmo, nel caso non fosse del tutto ovvio.)
• form e elementi di input (con l'eccezione del tag del button ) È probabile che il supporto per i moduli venga eventualmente implementato come componenti incapsulati perché sono di uso limitato senza script.

Ora, ecco un elenco di tag che sostituiscono le loro controparti HTML al fine di ottimizzare il caricamento delle risorse e applicare le migliori pratiche di sicurezza:

• [amp-img](https://www.ampproject.org/docs/reference/amp-img.html) Sostituisce il tag img e ottimizza il caricamento delle risorse tenendo conto di fattori come la posizione del viewport, le risorse di sistema e la connettività.
• [amp-video](https://www.ampproject.org/docs/reference/amp-video.html) Sostituisce il tag video HTML5, in modo che i contenuti video possano essere caricati pigramente (tenendo in considerazione il viewport).
• [amp-audio](https://www.ampproject.org/docs/reference/extended/amp-audio.html) Sostituisce il tag audio HTML5 in modo che il contenuto audio possa essere caricato pigramente (tenendo in considerazione il viewport).
• [amp-iframe](https://www.ampproject.org/docs/reference/extended/amp-iframe.html) Il tag amp-iframe applica le migliori pratiche di sicurezza facendo cose come il sandboxing di contenuti per impostazione predefinita e ponendo restrizioni su dove gli iframe possono apparire per garantire che non dominino un documento AMP.

Infine, ecco tutti i tag che AMP HTML introduce per aggiungere funzionalità o interattività ai tuoi documenti, senza che tu debba scrivere JavaScript:

• [amp-ad](https://www.ampproject.org/docs/reference/amp-ad.html) Il tag amp-ad consente al runtime AMP di gestire il caricamento degli annunci proprio come tutte le altre risorse caricate esternamente (attualmente , gli annunci vengono caricati per ultimi) e garantisce che JavaScript dalle reti pubblicitarie non possa essere eseguito all'interno del documento AMP principale o attivare calcoli di layout non necessari. (Addio, document.write() !)
• [amp-analytics](https://www.ampproject.org/docs/reference/extended/amp-analytics.html) Questo framework in miniatura racchiude i dati analitici e li invia a fornitori di terze parti. Ad oggi, il supporto AMP proviene da Adobe Analytics, Chartbeat, ClickTale, comScore, Google Analytics, Nielsen e Parse.ly.
• [amp-pixel](https://www.ampproject.org/docs/reference/amp-pixel.html) Viene utilizzato per incorporare web beacon e supporta token per inviare diverse variabili client al server.
• [amp-carousel](https://www.ampproject.org/docs/reference/extended/amp-carousel.html) Questo componente ottimizzato visualizza le immagini figlio con un orientamento orizzontale interattivo.
• [amp-lightbox](https://www.ampproject.org/docs/reference/extended/amp-lightbox.html) Ciò consente ai lettori di aprire le immagini in una vista "lightbox" a schermo intero. Supporta la specifica sia delle miniature che delle immagini a grandezza naturale.
• [amp-anim](https://www.ampproject.org/docs/reference/extended/amp-anim.html) Questo carica GIF animate e fornisce funzionalità segnaposto tanto necessarie.
• [amp-font](https://www.ampproject.org/docs/reference/extended/amp-font.html) Imposta un timeout di caricamento sui caratteri personalizzati e specifica i caratteri di riserva se i caratteri personalizzati non vengono caricati entro il tempo assegnato .
• [amp-fit-text](https://www.ampproject.org/docs/reference/extended/amp-fit-text.html) testo all'interno di un tag amp-fit-text verrà automaticamente assegnata una dimensione del carattere ottimizzata per lo spazio disponibile. Pensala come una piccola reattività preconfezionata.
• [amp-list](https://www.ampproject.org/docs/reference/extended/amp-list.html) Con il tag amp-list , puoi caricare dati JSON dinamici e ripetuti e quindi renderli utilizzando un HTML modello. (Vedi il tag amp-mustache di seguito.)
• [amp-mustache](https://www.ampproject.org/docs/reference/extended/amp-mustache.html) Supporta il rendering dei modelli HTML di Mustache.
• [amp-install-serviceworker](https://www.ampproject.org/docs/reference/extended/amp-install-serviceworker.html) Se scegli di non utilizzare una cache AMP (molto più informazioni sulla memorizzazione nella cache di seguito), il Il tag amp-install-serviceworker carica e installa un service worker per la pagina corrente. I lavoratori dei servizi sono abili, ma secondo me è un po' troppo presto per fare affidamento su di loro.
• [amp-youtube](https://www.ampproject.org/docs/reference/extended/amp-youtube.html) Com'era prevedibile, questo incorpora il video di YouTube con l'ID video specificato.
• [amp-twitter](https://www.ampproject.org/docs/reference/extended/amp-twitter.html) Incorpora i tweet (schede Twitter opzionali).
• [amp-instagram](https://www.ampproject.org/docs/reference/extended/amp-instagram.html) Incorpora immagini di Instagram.
• [amp-brightcove](https://www.ampproject.org/docs/reference/extended/amp-brightcove.html) Questo componente carica e visualizza i video (e un lettore video) da Brightcove.
• [amp-pinterest](https://www.ampproject.org/docs/reference/extended/amp-pinterest.html) Incorpora un widget Pinterest, o il pulsante "Pin It", nel documento AMP.
• [amp-vine](https://www.ampproject.org/docs/reference/extended/amp-vine.html) Incorpora il video Vine specificato nel documento AMP.

Nota che, sebbene i tag con prefisso amp- non siano esattamente HTML standard, non sono nemmeno proprietari. Piuttosto, sono elementi personalizzati legittimi con implementazioni JavaScript che fanno cose come applicare le migliori pratiche di sicurezza e dare priorità al caricamento di risorse remote (ulteriori informazioni nella sezione "AMP Runtime" di seguito). In altre parole, mentre l'HTML AMP potrebbe sembrare sospettosamente simile alla strategia di abbracciare, estendere ed estinguere, in realtà è solo un'applicazione intelligente degli standard web e non molto diversa dagli attributi dei data- personalizzati.

Stile HTML AMP

Lo stile dei documenti AMP viene eseguito con CSS standard e non è molto diverso da come stili già i contenuti. Tuttavia, tieni a mente diverse cose:

• Tutto lo stile deve essere eseguito con un foglio di stile in linea: nessun foglio di stile collegato esternamente e nessuno stile in linea a livello di elemento. (Un foglio di stile collegato esternamente richiederebbe il download di un documento aggiuntivo prima di poter calcolare il layout e gli stili a livello di elemento in linea potrebbero gonfiare il documento.)
• Gli stili sono limitati a 50 KB. La filosofia di Google è che 50 KB sono sufficienti per un bel documento o articolo, ma non per un bel sito web.
• Il tuo foglio di stile inline deve avere l'attributo amp-custom (cioè <style amp-custom> ).
• Le regole @ — @font-face (ulteriori informazioni sui caratteri di seguito), @keyframes e @media — sono consentite.
• Alcuni selettori hanno limitazioni note per mettere alla prova le prestazioni, come il selettore universale ( * ) e il selettore :not() .
• Il qualificatore !important è bandito per garantire che il runtime AMP abbia l'ultima parola sul dimensionamento degli elementi.
• Lo stile dei componenti AMP personalizzati come amp-carousel viene eseguito sovrascrivendo le classi predefinite, come .amp-carousel-button-prev , o utilizzando un insieme predefinito di proprietà personalizzate CSS, come --arrow-color .
• Tutte le risorse caricate esternamente devono avere proprietà di larghezza, altezza e layout specificate (ulteriori informazioni sul layout di seguito) per ridurre al minimo i costosi ricalcoli del layout DOM.
• Sono consentite transizioni e animazioni che possono essere accelerate dalla GPU (e che non attivano ricalcoli). Attualmente, opacity e la transform sono nella whitelist.

Per ulteriori dettagli sullo stile dei documenti, consulta la specifica HTML AMP.

Caratteri

AMP supporta felicemente i caratteri personalizzati, con alcune qualifiche:

• I caratteri devono essere caricati con un tag di collegamento o una regola CSS @font-face . In altre parole, non puoi caricare i caratteri usando JavaScript.
• Tutti i caratteri devono essere serviti su HTTPS.
• I fornitori di font devono essere inseriti nella whitelist. Attualmente, gli unici provider autorizzati sono fonts.googleapis.com e fast.fonts.net . Ma, vista la rapidità con cui editori, inserzionisti e fornitori di analisi stanno aggiungendo il supporto per AMP, sospetto che presto ne seguiranno altri.

Disposizione

L'approccio di AMP al layout è stato concepito attorno a due obiettivi principali:

• Il runtime deve essere in grado di dedurre la dimensione di tutte le risorse caricate esternamente prima che vengano effettivamente caricate, in modo che un layout finale possa essere calcolato il più rapidamente possibile. Una volta calcolato il layout, l'articolo può essere renderizzato e i lettori possono iniziare a interagire con esso, anche se gli annunci, le immagini, l'audio e il video non hanno ancora completato il caricamento. (E, man mano che queste risorse si caricano, il rendering verrà eseguito senza interruzioni, senza interrompere l'esperienza di lettura aggiornando il layout del documento.)
• Gli articoli AMP dovrebbero essere reattivi. Come suggerisce il nome "Pagine mobili accelerate", i documenti AMP sono specificamente destinati ai dispositivi mobili; quindi, in questo contesto, "reattivo" non include le risoluzioni desktop. Piuttosto, i documenti AMP dovrebbero avere un bell'aspetto su tutti i dispositivi mobili, da quelle minuscole vecchie reliquie di iPhone 4 che le persone stanno ancora utilizzando fino ai relativamente giganteschi iPad Pro.

Il primo obiettivo viene raggiunto principalmente dal requisito che tutte le risorse caricate esternamente abbiano attributi di width e height (ed è ulteriormente rafforzato dalla limitazione degli script, che garantisce che le nuove risorse non possano essere inserite). Quest'ultimo si ottiene tramite media query standard, l'attributo media , l'attributo sizes e l'attributo layout specifico AMP.

Di seguito è riportata una panoramica dei layout attualmente supportati da AMP:

• nodisplay L'elemento non viene visualizzato inizialmente, ma la visualizzazione può essere attivata da un'azione dell'utente. (Questo è usato insieme a componenti come amp-lightbox .)
• fixed L'elemento ha una larghezza e un'altezza fisse, il che significa che il runtime non può applicare alcun comportamento reattivo.
• responsive Secondo me, questa è la più utile e magica delle opzioni di layout di AMP. L'elemento utilizza tutto lo spazio assegnato pur mantenendo le sue proporzioni. (Fondamentalmente, "Fai in modo che questa cosa abbia un bell'aspetto a qualsiasi risoluzione, per favore e grazie.")
• fixed-height L'elemento utilizza lo spazio assegnato ma mantiene un'altezza fissa (scalando orizzontalmente).
• fill L'elemento riempie il contenitore in cui si trova indipendentemente dalle proporzioni. (Pensa alla width: 100% e height: 100% .)
• container L'elemento è un contenitore e, quindi, lascia che i suoi figli (al contrario del suo genitore) ne definiscano le dimensioni, esattamente come un elemento div standard.

Ottenere un layout del documento funzionale e diretto utilizzando il sistema di layout di AMP è relativamente facile, ma se si considera tutto ciò che supporta e come i valori si applicano ai diversi tipi di elementi, c'è una discreta quantità di sfumature. Per una ripartizione molto più dettagliata, vedere le specifiche del layout AMP.

Che dire di SVG?

Supportato! Basic SVG gode di un supporto completo su browser desktop e mobili e la grafica non diventa molto più reattiva dei vettori, quindi AMP e SVG costituiscono un'ottima squadra. La limitazione più grande è che, a causa delle restrizioni di scripting, non sarai in grado di animare i tuoi vettori con JavaScript, cosa che, se siamo onesti, probabilmente non dovresti comunque farlo su dispositivi mobili. Tuttavia, se devi davvero dare un po' di vita al tuo SVG, puoi comunque farlo usando le animazioni CSS, secondo gli stessi vincoli delineati nella sezione di stile sopra. Ricorda che SVG fa parte del DOM, quindi può essere disegnato e animato con la stessa facilità di qualsiasi altro elemento.

La filosofia di AMP su JavaScript

Buone e cattive notizie qui. La cattiva notizia è che presto non scriverai JavaScript per i tuoi documenti AMP. Ma in un certo senso, questa è anche la buona notizia. Tieni presente che AMP non è un framework per applicazioni mobili. Piuttosto, è un framework di articoli per dispositivi mobili e, poiché gli articoli dovrebbero essere ottimizzati per esperienze di lettura fluide e fluide, non ci sono davvero molti casi d'uso validi per scripting lato client pesanti.

Detto questo, vietare per sempre tutto JavaScript è irrealistico e un po' draconiano. La realtà è che il Web si affida da tempo a JavaScript, anche nel contesto di esperienze di lettura semplici e relativamente blande, per cose come pubblicità, analisi e funzionalità interattive. Inoltre, una delle cose migliori del Web è la sua apertura e la sua capacità apparentemente infinita di sperimentazione, espressività e creatività, gran parte delle quali è alimentata da JavaScript.

Riconoscendo sia l'onere che JavaScript arbitrario scritto dall'utente pone sulle garanzie di prestazioni, sia l'ubiquità e l'inevitabilità di JavaScript in un ambiente Web moderno, il team AMP ha elaborato i seguenti principi di scripting:

• Nessun JavaScript scritto dall'utente è supportato o consentito in questo momento. Puoi avere solo due tipi di tag script nei tuoi documenti AMP: tag di dati collegati (il cui tipo è application/ld+json ) e tag per includere sia il runtime AMP che i componenti AMP estesi.
• Gli autori del progetto AMP hanno anticipato la maggior parte delle esigenze di JavaScript nel contesto del consumo di articoli mobili, quindi AMP supporta alternative ( amp-pixel , inclusi caratteri personalizzati con tag di collegamento o regole @font-face , ecc.) oppure fornisce implementazioni compatibili con il runtime AMP e che, quindi, garantiscono sicurezza e prestazioni ( amp-ad , amp-analytics , amp-carousel , ecc.).
• Se devi davvero utilizzare JavaScript per qualcosa come una funzionalità interattiva, puoi creare la funzionalità in modo indipendente e quindi includerla con un [amp-iframe](https://www.ampproject.org/docs/reference/extended/amp-iframe.html) . Al contenuto incluso in un amp-iframe è consentita anche una comunicazione limitata con il documento principale per cose come il ridimensionamento delle richieste.
• I componenti AMP sono open source (Apache 2) e aperti ai contributi, quindi nel tempo appariranno nuovi componenti (in effetti, nel corso della scrittura e della modifica di questo articolo sono comparsi diversi nuovi componenti, quindi ho già aggiornato alcune volte). Mentre il team AMP darà la priorità ai componenti generalizzati rispetto alle funzionalità specifiche del servizio (un widget specifico per la tua startup social, ad esempio), si impegna anche a fornire una diversità sufficiente per ospitare la più ampia gamma di contenuti possibile.
• Infine, tutte queste politiche sono soggette a modifiche. Man mano che le funzionalità del browser come i web worker, gli elementi personalizzati e il DOM ombra diventano più ampiamente supportati, le opzioni per supportare JavaScript scritto dagli utenti e componenti personalizzati, pur garantendo sicurezza e prestazioni, si espanderanno notevolmente.

Per ulteriori informazioni sul futuro dei componenti AMP, consulta la sezione "Componenti estesi" della specifica "Componenti HTML AMP".

Anatomia di un documento AMP

Ora che hai una conoscenza abbastanza solida dell'HTML AMP, analizziamo un campione.

Ovviamente, inizierai i tuoi documenti AMP con una dichiarazione doctype :

 <!doctype html>

Successivamente, designa il tuo documento HTML come AMP HTML, cosa che, che tu ci creda o no, utilizzi l'emoji ad alta tensione come attributo nel tag html :

 <html >

Oppure, se sei un burbero vecchio stile e setola all'idea di adornare il tuo codice con adorabili emoji, puoi invece utilizzare l'attributo amp molto più conservativo:

 <html amp> <!-- A good sign that you're boring! -->

Nel tag head , non dimenticare le istruzioni per la codifica dei caratteri utf-8 :

 <meta charset="utf-8">

E collega alla versione non AMP del tuo documento (contrassegnata come canonical , in modo che non appaia come contenuto duplicato):

 <link rel="canonical" href="my-non-amp-index.html">

Al contrario, la tua versione non AMP dovrebbe contenere un riferimento al documento AMPlificato:

 <link rel="amphtml" href="my-amp-index.html">

Poiché le pagine AMP sono destinate ai dispositivi mobili (e desideri anche la rasterizzazione della GPU), assicurati di includere un tag meta viewport :

 <meta name="viewport" content="width=device-width,minimum-scale=1,initial-scale=1">

La prossima riga di codice sembrerà un po' strana, e questo perché lo è. Sai come a volte vedrai una pagina Web visualizzare brevemente il testo prima che i caratteri siano stati caricati e applicati, quindi sfarfallare e renderizzare di nuovo come previsto dal designer? Il tag sottostante mantiene l'opacità della pagina a 0 (invisibile) finché non è stato applicato uno stile appropriato.

 <style> body { opacity: 0 } </style> <noscript> <style> body { opacity: 1 } </style> </noscript>

Il problema con questo approccio è che, se il runtime AMP non riesce a caricare, è tecnicamente possibile che l'opacità della pagina non vada mai da 0 a 1 . Per compensare tali contingenze, il codice sopra sarà probabilmente modificato in qualcosa di più vicino a questo:

 <style> body { animation: amp-timeout 0x 5s 1 normal forwards; } @keyframes amp-timeout { 0% {opacity: 0;} 100% {opacity: 1;} } </style>

La prossima cosa da fare è includere il runtime AMP JavaScript:

 <script async src="https://cdn.ampproject.org/v0.js"></script>

E includi le implementazioni JavaScript per tutti i componenti estesi di cui hai bisogno:

 <script async custom-element="amp-youtube" src="https://cdn.ampproject.org/v0/amp-youtube-0.1.js"></script> <script async custom-element="amp-audio" src="https://cdn.ampproject.org/v0/amp-audio-0.1.js"></script> <script async custom-element="amp-carousel" src="https://cdn.ampproject.org/v0/amp-carousel-0.1.js"></script> <script async custom-element="amp-lightbox" src="https://cdn.ampproject.org/v0/amp-lightbox-0.1.js"></script> <script async custom-element="amp-anim" src="https://cdn.ampproject.org/v0/amp-anim-0.1.js"></script> <script async custom-element="amp-twitter" src="https://cdn.ampproject.org/v0/amp-twitter-0.1.js"></script> <!-- etc. -->

(Nota l'uso dell'attributo async . Non è facoltativo: meno blocchi, meglio è.)

Facoltativamente, puoi aggiungere un po' di dati collegati, come questo:

 <script type="application/ld+json"> { "@context": "https://schema.org", "@type": "NewsArticle", "headline": "Turn Your AMP up to 11!", "image": [ "img/cover-opt.jpg" ], "datePublished": "2015-01-11T08:00:00+08:00" } </script>

Ora aggiungiamo alcuni font, utilizzando i tag link o le regole @font-face nel tuo CSS:

 <link href='https://fonts.googleapis.com/css?family=Roboto+Condensed:300,700' rel='stylesheet' type='text/css'> <link href='https://fonts.googleapis.com/css?family=Lora:400,700,400italic,700italic' rel='stylesheet' type='text/css'>

E poi faremo alcuni stili (non più di 50 KB), con l'attributo amp-custom richiesto:

 <style amp-custom>

Ora sei pronto per creare un documento HTML più o meno standard utilizzando tutto ciò che hai appena appreso sull'HTML AMP.

Il tempo di esecuzione dell'AMP

Non dedicherò molto tempo al runtime AMP perché, come tutti i runtime, è un po' una scatola nera. Questo non vuol dire che il runtime AMP sia inaccessibile (è open source, come il resto del progetto). Piuttosto, come tutti i buoni runtime, gli sviluppatori non hanno bisogno di sapere esattamente come funziona per trarne vantaggio, purché generalmente capiscano cosa fa.

Il runtime AMP è implementato interamente in JavaScript e viene avviato includendolo nel documento AMP, come faresti con qualsiasi file JavaScript esterno:

 <script async src="https://cdn.ampproject.org/v0.js"></script>

Da lì, il runtime AMP fa principalmente tre cose:

• gestisce il caricamento delle risorse e la definizione delle priorità,
• implementa componenti AMP,
• facoltativamente, include un validatore di runtime per AMP HTML.

Il validatore è fondamentale per la creazione di documenti compatibili con AMP. Può essere attivato semplicemente aggiungendo #development=1 all'URL del documento. Quindi, tutto ciò che devi fare è aprire la tua console per vedere la tua pagella.

Gli errori si presentano così:

Un documento AMP bello, pulito e conforme è simile al seguente:

La cache AMP (opzionale).

I documenti AMP possono essere serviti da un server web come qualsiasi altro documento HTML, ma possono anche essere serviti da una speciale cache AMP. La cache opzionale utilizza diverse tecniche per ottimizzare ulteriormente un documento AMP:

• I riferimenti alle immagini possono essere sostituiti con immagini dimensionate in modo specifico per il viewport dello spettatore.
• Le immagini above the fold possono essere integrate per salvare richieste HTTP aggiuntive.
• Le variabili CSS possono essere integrate per ridurre l'overhead lato client.
• È possibile precaricare implementazioni di componenti AMP estese.
• HTML e CSS possono essere minimizzati per ridurre il numero di byte inviati via cavo (o, in questo caso, le onde radio).

Chiunque può eseguire la propria cache AMP sulla propria CDN oppure gli editori possono utilizzare Google gratuitamente. Dato che Google sembra sapere una o due cose sulla scalabilità, suppongo che la maggior parte degli utenti di AMP sarà felice di accettare quell'offerta. (Documentation on how to opt in to Google's cache is forthcoming, but given that Google already indexes and caches the Internet, it's a safe bet that it will revolve around your link tags and perhaps an additional meta tag.)

How Do Readers Find AMP Content?

The fact that AMP document are more or less standard HTML that will render in any modern browser is, in my opinion, a huge advantage (AMP is far more open and inclusive than Facebook Instant Articles or Apple News). But from a practical perspective, it also raises the question of how audiences will find AMP content.

If readers use Google to search from a mobile device, Google can link directly to AMP versions of articles (Google has not said that it will prioritize AMP documents over non-AMP documents, but it has said that it will use “mobile friendliness” as a mobile search signal, so you do the math). In fact, Google has indicated that it will begin sending traffic to AMP pages from Google Search on mobile as early as late February 2016. Discovery and curation engines such as Pinterest may also choose to start directing mobile traffic to AMP pages (with a few infrastructure changes). Finally, websites can redirect their own mobile traffic from responsive versions of articles to their AMP counterparts. But from my perspective, a few pieces of the puzzle are still missing.

Will other search engines direct mobile traffic to AMP articles? (Perhaps not search engines that want to do business with Apple.) Will social networking apps preload AMP documents when users post links to articles, in order to make rendering nearly instantaneous? (Probably not Facebook.) Will mobile browsers start looking for link tags with amphtml relationships? (Chrome, maybe, but probably not mobile Safari.) And will aggregators and news readers out there build specifically for lightning-fast AMP content? (Time to resurrect Google Reader!)

At this point, the answers to most of these questions are the same: to be determined.

See AMP In Action

The easiest way to see AMP in action is to check out Google's search demo. If you're the trusting type, you can watch the video and just assume it all works as well as it's depicted. If you're more the trust-but-verify type, you can go to g.co/ampdemo on your mobile device and try out some AMP pages for yourself (QR code below).

You can also check out the AMP experience through desktop Chrome using Chrome's Developer Tools. All you have to do is this:

1. Go to g.co/ampdemo in Chrome.
2. Open the Developer Tools by going to “View” → “Developer” → “Developer Tools.”
3. Go into device mode by clicking on the little phone icon in the top-left corner.
4. Pick your favorite device to emulate. (For best results, reload the page in the emulator.)

Who's Adopting AMP?

It's still relatively early days for AMP, so it's hard to tell exactly who is adopting the new format in earnest, and to what extent. That being said, I've already seen several implementations out there in the wild, and according to the AMP FAQ and AMP blog, it's being taken seriously by many major publishers (metered content and subscription access is currently under review), CMS developers, advertisers, and analytics providers. I won't list them all here because I'm sure the landscape will change almost daily, but you can keep an eye on the AMP project's home page and/or the AMP blog for news.

What Do I Think?

I'm glad you asked. My guess is that just about all publishers will eventually adopt it. If companies like BuzzFeed have taught the industry anything, it's the importance of being in as many places as possible, and that digital publishing should be a technology platform capable of getting content in front of readers wherever they are, as opposed to being a singular destination waiting for readers to come to it.

The investment required to support AMP is also relatively minimal. If a publisher already supports — or plans to support — Facebook Instant Articles and Apple News, then they might as well implement support for AMP as well. While CMS strategies vary widely across the publishing industry, most CMS' have a concept of templates and/or plugins that, once implemented, would do most of the work of converting articles into AMP HTML. (WordPress, the closest thing we have to an industry leader, already has a plugin and plans on supporting AMP for all publishers in January 2016.) And because AMP is far less proprietary than its competition (meaning that it is open source, open to contributions, based on web technologies and client-agnostic), I would expect publishers to feel more comfortable distributing their content in a format that they feel they will have more control over long-term.

The reality is that publishers will back whatever syndication formats and partners will help get their content in front of the maximum number of readers with the least amount of overhead and investment. Right now, we are in the very early stages of a new type of war that is part platform, part format and in which each party will leverage its unique strengths to maneuver itself into the best possible position. At this point, it's far too early to say which will endure and which will become the RSS of tomorrow.

Risorse addizionali

• “Introducing the Accelerated Mobile Pages Project, for a Faster, Open Mobile Web” Google Official Blog
• Accelerated Mobile Pages Project, official website
• Accelerated Mobile Pages, blog
• AMP HTML, GitHub
• Docs, Accelerated Mobile Pages Project
• Nigel Tufnel explaining why his amp goes to 11