Anche se le cache AMP presentano degli svantaggi, operano a favore dell'utente garantendogli un'esperienza costantemente veloce e di facile utilizzo. Le cache sono ideate per:
- Assicurare che tutte le pagine AMP siano realmente AMP valide.
- Consentire che le pagine AMP siano precaricate in modo efficiente e sicuro.
- Effettuare una miriade di ulteriori ottimizzazioni delle prestazioni dei contenuti vantaggiose per l'utente.
Ma prima...
I concetti base: attribuzione di analisi dati e condivisione dei link
Anche se il modello cache AMP non segue il modello di origine (servire la tua pagina dal tuo dominio), attribuiamo comunque tutto il traffico a te, il publisher. Tramite il tag <amp-analytics>, AMP supporta un numero sempre crescente di provider di analisi dati (26 fino a ora e in aumento
!), perché il tuo successo sia misurato e il traffico venga attribuito correttamente.
Quando chiedo a utenti e sviluppatori perché vogliono il "click-through" alla pagina canonica da un risultato AMP memorizzato nella cache, la risposta spesso è: la condivisione dei link. Ammetto che è fastidioso copiare un URL google.com invece dell'URL canonico. Tuttavia il problema non è così grande come immagini: Google modifica i risultati di ricerca AMP memorizzati nella cache con i metadati di Schema.org e OpenGraph, così la pubblicazione del link su qualsiasi piattaforma che li utilizza dovrebbe portare alla condivisione dell'URL canonico. Detto questo, ci sono anche altri modi per migliorare il flusso di condivisione. Nelle visualizzazioni web native, si può condividere l'URL canonico direttamente se l'applicazione lo supporta e, in seguito al feedback degli utenti, il team di Google si sta impegnando per consentire un facile accesso all'URL canonico su tutte le sue superfici.
Dopo questa delucidazione, cerchiamo di approfondire l'argomento.
Quando l'etichetta dice AMP, davvero vuol dire AMP
Il progetto AMP è costituito da un ecosistema basato su un processo di convalida rigoroso per assicurare che i massimi livelli di prestazioni e qualità siano raggiunti. Durante lo sviluppo può essere usata una versione di un validatore, ma la cache AMP assicura la validità all'ultimo stadio, ossia al momento di presentare il contenuto all'utente.
Quando una pagina AMP viene richiesta per la prima volta da una cache AMP, questa cache convaliderà il documento e non lo offrirà all'utente se rileva dei problemi. Le piattaforme che si integrano con AMP (ad esempio Bing, Pinterest, Google) possono scegliere di inviare il traffico direttamente alla pagina AMP all'origine oppure a una cache AMP, ma la validità può essere garantita solo quando questo viene fornito dalla cache. Assicura che quando gli utenti vedono l'etichetta AMP, sanno di avere quasi sempre un'esperienza veloce e di facile utilizzo (a meno che non trovi il modo di creare una pagina AMP lenta ma valida, che è difficile ma non impossibile... mi riferisco a voi, caratteri grandi del web).
Il prerendering è più importante di quello che pensi
Se devi ricordare una sola cosa detta in questo post è che il prerendering, in particolare la variante in AMP, supera notevolmente qualsiasi guadagno di velocità teoricamente ottenuto ospitando direttamente da un server di origine. Anche se il server di origine è più vicino agli utenti, che ti risparmierebbe pochi millisecondi (cosa rara ma possibile), sarà quasi certamente il prerendering a creare il maggiore impatto.
Percepito come molto più veloce
In realtà spesso il prerendering può farti risparmiare secondi, non millisecondi. L'impatto del prerendering, in contrasto con le altre varie ottimizzazioni delle prestazioni nella libreria AMP JS, può essere piuttosto forte e contribuisce sostanzialmente all'esperienza di istantaneità.
Molto efficiente rispetto al prerendering completo
Se fosse tutto qui, potremmo eseguire il prerendering delle pagine AMP altrettanto facilmente dai loro server di origine. Se l'avessimo fatto, non potremmo garantire che quella sia una pagina AMP valida all'origine e ciò è di fondamentale importanza per il prerendering personalizzato fornito dalla libreria AMP JS: il prerendering in AMP, in contrapposizione al semplice prerendering di una pagina intera tramite un qualcosa simile al prefetching di link, limita anche l'uso della larghezza di banda, della CPU e della batteria degli utenti!
I documenti AMP validi "cooperano" durante la fase di prerendering: sono precaricate solo le risorse nel primo viewport e non viene seguito alcuno script di terze parti. Ciò si traduce in un utilizzo inferiore e più economico della larghezza di banda e del precarico ad alta intensità della CPU, consentendo alle piattaforme di eseguire il prerendering non solo della prima, ma di alcune delle pagine AMP su cui probabilmente farà clic l'utente.
Incorporamento sicuro
Dato che le cache AMP non possono contare sul prerendering del browser (consulta la sezione precedente), la normale navigazione da una pagina all'altra non funziona. Quindi nel modello di caching AMP una pagina deve essere aperta inline in una pagina della piattaforma. Le cache AMP assicurano che la pagina AMP richiesta possa farlo in modo sicuro:
- Il validatore assicura che non si verifichi Cross-Site Scripting (XSS) nel documento principale.
- E oltre a questo, la cache AMP analizza e poi riserializza il documento in maniera inequivocabile (ciò significa che non si basa sulla correzione degli errori di HTML5). Ciò garantisce che i bug e le differenze di analisi del browser non possano portare a XSS.
- La cache applica i Criteri di protezione dei contenuti (Content Security Policy, CSP) che offrono un'ulteriore difesa forte contro gli attacchi XSS.
Ulteriore privacy
Le cache AMP eliminano anche un problema potenziale importante di privacy dal prerendering: quando esegui una ricerca su una piattaforma di contenuti che precarica le pagine AMP sulla pagina dei risultati, nessuna di queste pagine saprà mai di essere stata precaricata.
Vedila così: se cerco "breakfast burrito" e mi conosci bene, sai che ovviamente sto cercando la canzone di Parry Gripp con questo nome. Ma la pagina dei risultati di ricerca mi mostra anche un paio di risultati AMP di catene di fast food che vendono veri e propri burrito. Per il mese successivo non desidero vedere burrito ovunque, anche se non ho fatto clic su questi link (mah forse a pensarci meglio dovrei...), e un inserzionista non vuole sprecare fondi in inutili annunci di remarketing sui burrito. Poiché AMP nasconde il precarico dal publisher della pagina AMP e dalle rispettive terze parti, è uno scenario vantaggioso per tutti, utenti e inserzionisti.
Auto-ottimizzazioni che spesso si traducono in un drastico aumento della velocità
La cache AMP è partita con tutto ciò che abbiamo appena descritto ma ora presenta una serie di trasformazioni trasformative per la sua caratteristica roster, tra cui:
- Una Rete per la consegna di contenuti (CDN) coerente, veloce e gratuita per tutti i contenuti (non solo per i grandi publisher).
- Ottimizzazioni di HTML, ad esempio: mettere gli script nell'ordine ideale, rimuovere i tag di script duplicati, le virgolette e gli spazi vuoti inutili.
- Riscrittura di URL JavaScript per avere tempi lunghi di cache.
- Ottimizzazione delle immagini (un miglioramento medio di larghezza di banda del 40%!).
Anche solo per quanto riguarda la compressione delle immagini, grazie alla sua cache, Google offre compressioni senza perdite di dati (senza nessun cambiamento visibile, ad es. rimuove i dati EXIF) e non è dissipativo (senza cambiamenti visibili all'occhio). Converte anche le immagini a WebP per i browser che lo supportano e genera automaticamente gli attributi srcset (le cosiddette immagini reattive) se non sono già disponibili, generando e mostrando immagini ridimensionate correttamente su ogni dispositivo.
C'è un modo migliore di fare questo?
So cosa intendi. Il fornitore di una cache AMP esegue il mirroring dei tuoi contenuti. Si tratta di un ruolo importante e ha una grande responsabilità. Se il provider della cache dovesse fare qualcosa di veramente stupido, come inserire annunci fastidiosi in ogni pagina AMP, AMP smetterebbe di essere una soluzione valida per i publisher e sparirebbe.
Non dimenticare che il progetto AMP è stato creato insieme ai publisher come strumento per rendere il web mobile migliore per i publisher, gli utenti e le piattaforme. Ecco perché il team di AMP ha stabilito delle linee guida rigorose per le cache AMP. Per citartene due estratti interessanti, le linee guida affermano che il contenuto deve fornire "una fedele riproduzione visiva e UX del documento di origine" e i provider di cache devono impegnarsi a mantenere operativi gli URL a tempo indeterminato, anche dopo che la cache stessa è stata rimossa. Queste, e molte altre regole, assicurano che una cache non alteri i tuoi contenuti.
Ma soprattutto c'è spazio per più di una cache AMP, infatti Cloudflare ha appena annunciato la propria! Con le linee guida della cache AMP appena rilasciate, altre società di infrastrutture sono invitate a creare nuove cache AMP, a patto che seguano le regole stabilite. Il resto dipenderà dalla piattaforma che si integra con AMP per scegliere la cache preferita.
Dalla cache agli standard web?
Hai appena letto i vantaggi e gli svantaggi offerti dalle cache AMP nel fornire un'esperienza web mobile facile da usare e all'insegna dell'istantaneità. Che cosa succederebbe se potessimo ottenere molte di queste fantastiche ottimizzazioni senza gli svantaggi e senza dover usare una cache?
Personalmente sogno futuri standard web ancora da inventare che ci permetteranno di fare proprio questo, ossia andare oltre i modelli di cache (ad esempio un sistema di layout statico per sapere che aspetto avrà una pagina prima di caricare le risorse).
Nel 2016 abbiamo fatto i nostri primi passi nell'ambito del CPP che poi è diventato la Feature Policy: un modo per dire cose come "Non consento di avere document.write sul mio sito né eventuali terze parti in qualsiasi iframe che viene caricato". Concetti più avanzati come l'impostazione del layout statico e il prerendering sicuro richiedono cambiamenti un po' audaci per la piattaforma web, ma ehi, proprio come un viaggio nel futuro, non è impossibile, solo molto, molto improbabile.
Per aiutarmi a scoprire l'arcano, contattami su Twitter o Slack. Sono sempre a tua disposizione per dubbi, idee e domande. Avanti!
Pubblicato da Paul Bakaus, AMP Developer Advocate, Google
