AMP di Google, Canonical Web e Importance of Web Standards

Hai mai fatto clic su un collegamento dopo aver cercato su Google qualcosa, solo per scoprire che Google non ti ha portato alla pagina Web effettiva ma a una strana versione di Google? Invece che l'indirizzo web sia la fonte dell'articolo, dice ancora "google" nella barra degli indirizzi sul tuo telefono? Questo è ciò che è noto come Google Accelerated Mobile Pages (AMP) e ora Google ha annunciato che AMP si è laureato al programma di incubazione della Fondazione OpenJS . La OpenJS Foundation è uno sforzo congiunto tra i principali progetti nell'ecosistema JavaScript, come NodeJS e jQuery, la cui missione dichiarata è "supportare la crescita sana dell'ecosistema JavaScript e web". Ma invece di uno standard che inizia con la comunità web, una gigantesca azienda sta arrivando alla comunità dopo che hanno già costruito gran parte del web mobile e stanno chiedendo un timbro di gomma. La discussione nella comunità web dovrebbe essere il primo passo per creare standard web e non solo un ostacolo dell'ultimo minuto che Google deve superare .

Cos'è AMP?

Questo framework HTML ridotto e supportato da Google è stato creato con la promessa di creare pagine web più veloci per una migliore esperienza utente. Eliminare contenuti a caricamento più lento, come quelli sviluppati con JavaScript. Ad alto livello, AMP funziona caricando rapidamente versioni ridotte di pagine web complete per la visualizzazione su dispositivi mobili.

Il progetto Google AMP è stato annunciato alla fine del 2015 con la promessa di fornire agli editori un modo più veloce di servire e distribuire i contenuti ai propri utenti. Anche questo è stato commercializzato come un approccio più adattabile rispetto a Apple News e Facebook Instant Articles . Le pagine AMP hanno iniziato a fare la loro comparsa nel 2016. Ma subito, molti hanno notato che AMP ha invaso i principi del web aperto . Il Web è stato costruito su standard aperti, sviluppati attraverso il consenso, che possono utilizzare sia i piccoli che i grandi attori. Il che, in questo caso, implica mantenere in primo piano gli standard web aperti e scoraggiare gli standard chiusi e proprietari.

Invece di utilizzare tag di markup HTML standard, uno sviluppatore utilizzerebbe i tag AMP. Ad esempio, ecco come appare un'immagine incorporata nell'HTML classico, rispetto a come appare usando AMP:

Tag immagine HTML:

<img src=”src.jpg” alt=”src image” />

Tag immagine AMP:

<amp-img src=”src.jpg” width=”900” height=”675” layout=”responsive” />

Dal momento che la velocità della pagina di lancio ha dimostrato di essere più veloce quando si utilizza AMP, le promesse della tecnologia non sono necessariamente cattive solo dal punto di vista della velocità. Naturalmente, ci sono modi per migliorare le prestazioni diversi dall'uso di AMP, come ridurre al minimo i file, creare codice più leggero, CDN (reti di distribuzione dei contenuti) e la memorizzazione nella cache. Esistono anche altri framework supportati da Google come PWA (applicazioni web progressive) e operatori del servizio.

AMP esiste da quattro anni e le critiche continuano ancora oggi con le ultime progressioni di AMP attorno a una parte molto importante del Web, l'URL.

URL canonici e URL AMP

Quando visiti un sito, forse il tuo sito di notizie preferito, normalmente vedresti il ​​dominio originale insieme a un percorso associato alla pagina in cui ti trovi:

https://www.example.com/some-web-page

Questo, insieme al suo certificato SSL , chiarirebbe che stai vedendo il contenuto web servito da questo sito a questo URL con una buona dose di fiducia. Questo è quello che sarebbe considerato un URL canonico.

Un URL AMP, tuttavia, può avere questo aspetto:

https://www.example.com/platform/amp/some-web-page

Utilizzando gli URL canonici, gli utenti possono verificare più facilmente che il sito in cui si trovano è quello che stanno cercando di visitare. Ma gli URL AMP hanno confuso le acque e hanno costretto gli utenti ad adattare nuovi modi per verificare le origini dei contenuti originali.

Di chi è il contenuto?

Un ulteriore passo avanti è la loro struttura per le pagine pre-renderizzate dal contenuto memorizzato nella cache . Questo URL non sarebbe visibile all'utente, ma piuttosto il contenuto (testo, immagini, ecc.) Offerto nella pagina cache proviene dall'URL sottostante.

https://www-example-com.cdn.ampproject.org/c/www.example.com/amp/doc.html

L'URL finale, quello visualizzato o la barra degli URL, di una pagina AMP memorizzata nella cache sarebbe simile a questo:

https://www.google.com/amp/www.example.com/amp.doc.html

Questo modello di cache non segue il concetto di origine web e crea un nuovo framework e una nuova struttura a cui aderire. La promessa è prestazioni ed esperienza migliori per gli utenti. Tuttavia, l'approccio è prima l'implementazione e successivamente gli standard web. Dal momento che Google è diventata una parte così radicata del Web moderno per così tanti, qualsiasi tecnologia implementata avrebbe immediatamente una grande quota di utenti e utenti . Questo è anche associato ad altri argomenti che altri team di prodotto all'interno di Google hanno fatto per rimodellare l'URL come lo conosciamo. Ciò ha radicalmente cambiato il modo in cui il web mobile è servito per molti utenti.

Un altro sviluppo più recente è il supporto per gli scambi HTTP firmati , o "SXG", un sottoinsieme dello standard dei pacchetti Web che consente un ulteriore disaccoppiamento della distribuzione del contenuto web dalle sue origini con scambi HTTP firmati crittograficamente (una pagina web). Questo dovrebbe risolvere il problema, introdotto da AMP, che l'URL che un utente vede non corrisponde alla pagina che sta cercando di visitare. SXG consente la visualizzazione dell'URL canonico (invece dell'URL AMP) nel browser quando si arriva, chiudendo il ciclo all'editore originale. Il lato positivo qui è che è stato utilizzato uno standard web, ma il lato negativo qui è la velocità di adozione senza il consenso generale di altri importanti stakeholder . Attualmente, SXG è supportato solo nei browser basati su Chrome e Chromium .

Spingere l'AMP: come ha preso il sopravvento un nuovo "standard"?

Gli editori di notizie sono stati tra i primi ad adottare AMP. Google ha anche collaborato con un importante CMS (sistema di gestione dei contenuti), WordPress , per promuovere ulteriormente AMP. Gli editori utilizzano i servizi CMS per caricare, modificare e ospitare contenuti e WordPress detiene circa il 60% della quota di mercato come CMS preferito. Gli editori competono anche su altri prodotti Google, come Ricerca Google. Quindi forse alcuni editori hanno adottato AMP perché pensavano che avrebbe migliorato la SEO (ottimizzazione dei motori di ricerca) su uno dei motori di ricerca più utilizzati del web. Tuttavia, questo argomento è stato contestato da Google e sostengono che le prestazioni hanno la priorità indipendentemente da ciò che viene utilizzato per ottenere il risultato di quella pagina a quella misura di prestazione. Poiché l' algoritmo di ricerca di Google è principalmente segreto , possiamo fidarci di queste affermazioni solo sulla loro parola. Tangenzialmente, la funzione "Prima pagina" nella Ricerca sui dispositivi mobili ha recentemente abbandonato AMP come requisito.

Il progetto AMP era più chiuso in termini di controllo all'inizio del suo lancio, nonostante si fosse promosso come un progetto open source. I publisher hanno finito per segnalare velocità più elevate, ma questo è stato lasciato a una serie di metriche "il tempo dirà". In conclusione, l'affermazione "non hai bisogno di AMP per classificarti più in alto" è spesso in competizione con "usa semplicemente AMP e ti posizionerai più in alto". Il che può essere allettante per gli editori che cercano di raggiungere la barra delle prestazioni per dare la priorità ai loro contenuti.

Prima comunità web

Dovremmo concentrarci meno sul fatto che AMP sia o meno un buon strumento per le prestazioni e di più su come questo framework è stato modellato dalla proprietà iniziale di Google. Il livello di cache è di proprietà di Google e, anche se non è richiesto, le implementazioni più comuni utilizzano questa funzione di cache. Le preoccupazioni relative all'analisi sono state affrontate e hanno anche fatto la cortesia di consentire ad altri importanti fornitori di annunci nel modello AMP relativo al contenuto degli annunci. Questa è una semplice concessione, tuttavia, poiché Google Analytics ha una quota di mercato così ampia del Web misurato.

Se Google fosse semplicemente una società di prestazioni web, sarebbe ancora un'eccessiva centralizzazione delle decisioni del web. Ma non sono solo un'azienda con una sola funzione, sono un gigantesco conglomerato che controlla già il più grande sistema operativo mobile, browser web e motore di ricerca del mondo. Gestire il progetto attraverso la OpenJS Foundation è un approccio più gradito. La nuova struttura di governance è composta da gruppi di lavoro, un comitato consultivo e un comitato direttivo tecnico di persone all'interno e all'esterno di Google. Ciò dovrebbe portare più voci al tavolo e strutturare AMP in un processo migliore per le decisioni future. Questa mossa presumibilmente disaccoppiare Google AMP Cache, che ospita le pagine, da AMP runtime, che è la sorgente JavaScript per elaborare i componenti AMP in una pagina.

Tuttavia, tutto ciò va bene dopo che AMP è stato integrato nei principali siti di notizie , e-commerce e persino organizzazioni non profit . Quindi questo nuovo modello non è un approccio democratico e equilibrato. Indipendentemente dalle intenzioni, buone o cattive, coloro che lavorano con entità potenti devono controllare il loro potere alla porta se vogliono una rete più equa e utilizzabile. Non riconoscere il potere che si esercita, rafforza solo un falso senso di democrazia che non esisteva.

Inoltre, lo stesso processo degli standard web è lungi dall'essere perfetto. Le organizzazioni di standardizzazione sono fortemente dominate da membri di società aziendali e le connessioni che si possono avere con loro offrono un immenso capitale sociale. Le persone meno rappresentate non hanno il capitale sociale per aderire o essere membri. È molto lungo fino a quando si verifica un processo più equo per questo tipo di organizzazioni; insieme alla mancanza di diversità che questi tipi di gruppi tendono ad avere , i costi di adesione e gli impegni di tempo. Questi problemi particolari non sono colpa di Google, ma Google ha un'enorme quantità di potere quando si tratta di unirsi a questi gruppi. Quando ti unisci alle organizzazioni standard, non si tratta di guadagnare, ma di decidere se dovrebbero allentare i loro regni.

A questo punto del progetto AMP, Google non può rilasciare retroattivamente il controllo che aveva nell'adozione di AMP. E non possiamo tornare a un Web pre-AMP per ricominciare. Le discussioni sull'opportunità di rimuovere o scoraggiare il progetto AMP per un framework diverso sono passate da tempo . La possibilità o meno da parte degli utenti di rinunciare a AMP è stata decisa in molti angoli del Web. Tutto ciò che possiamo fare ora è imparare dal processo e cercare di assicurarci che AMP sia sviluppato nel migliore interesse degli utenti e degli editori in futuro. Tuttavia, il web aperto non dovrebbe essere alterato da molteplici lezioni apprese sul potere e il controllo da grandi aziende tecnologiche che hanno ottusamente bisogno di riapprendere la responsabilità ad ogni nuova impresa.