AMP di Google, il Web canonico e l’importanza degli standard Web

Hai mai cliccato su un link dopo aver cercato su Google qualcosa, solo per scoprire che Google non ti ha portato alla pagina web reale ma a qualche 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 è diplomato al Programma di incubazione della OpenJS Foundation . La OpenJS Foundation è uno sforzo congiunto tra i principali progetti dell'ecosistema JavaScript, come NodeJS e jQuery, la cui missione dichiarata è "supportare la crescita sana dell'ecosistema Web e JavaScript". Ma invece di uno standard che inizia con la comunità Web, una gigantesca azienda sta arrivando nella comunità dopo aver già costruito gran parte del Web mobile e chiedendo un timbro di gomma. La discussione della comunità Web dovrebbe essere il primo passo per definire gli standard Web e non solo un ostacolo dell'ultimo minuto che Google deve eliminare.

Che cos'è l'AMP?

Questo framework HTML ridotto a Google è stato creato con le promesse di creare pagine Web più veloci per una migliore esperienza utente. Ridurre il caricamento più lento dei contenuti, come quelli sviluppati con JavaScript. A un livello elevato, AMP funziona caricando rapidamente le versioni ridotte di pagine Web complete per la visualizzazione mobile.

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 contenuti ai propri utenti. Anche questo è stato commercializzato come un approccio più adattabile rispetto agli articoli istantanei di Apple News e Facebook . Le pagine AMP hanno iniziato a comparire entro il 2016. Ma subito, molti hanno osservato che AMP ha invaso i principi del web aperto . Il web è stato costruito su standard aperti, sviluppati per consenso, che possono essere usati sia da attori piccoli che grandi. Il che, in questo caso, implica mantenere in primo piano gli standard web aperti e scoraggiare gli standard proprietari chiusi.

Invece di utilizzare tag di markup HTML standard, uno sviluppatore userebbe 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” />

Poiché la velocità della pagina di lancio si è dimostrata più veloce quando si utilizza AMP, le promesse della tecnologia non sono necessariamente cattive dal punto di vista della velocità. Naturalmente, ci sono modi per migliorare le prestazioni oltre all'utilizzo di AMP, come la riduzione al minimo dei file, la creazione di codice più leggero, CDN (reti di distribuzione del contenuto) e memorizzazione nella cache. Esistono anche altri framework supportati da Google come PWA (applicazioni Web progressive) e operatori del servizio.

AMP è in circolazione ormai da quattro anni e le critiche continuano ancora oggi con le ultime progressioni di AMP intorno 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 contenuti web offerti da questo sito a questo URL con una buona dose di fiducia. Questo è quello che verrebbe considerato un URL canonico.

Un URL AMP, tuttavia, può assomigliare a questo:

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 l'origine del contenuto originale.

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.) Pubblicato nella pagina cache verrebbe dall'URL seguente.

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

L'URL finale, quello visualizzato o la barra dell'URL, di una pagina AMP memorizzata nella cache sarebbe simile al seguente:

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 struttura a cui aderire. La promessa è prestazioni ed esperienza migliori per gli utenti. Tuttavia, l'approccio è prima l'implementazione e gli standard web in seguito. Da quando Google è diventata una parte così radicata della rete moderna per così tanti, qualsiasi tecnologia che implementano avrebbe immediatamente una grande percentuale di utenti e utenti . Questo è anche associato ad altri argomenti che altri team di prodotti all'interno di Google hanno avanzato per rimodellare l'URL così 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 Signed HTTP Exchanges , o "SXG", un sottoinsieme dello standard Web Packages che consente un ulteriore disaccoppiamento della distribuzione del contenuto Web dalle origini con scambi HTTP crittografati (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 all'URL canonico (anziché all'URL AMP) di essere mostrato nel browser quando arrivi, chiudendo il loop indietro al publisher originale. Il positivo qui è che è stato utilizzato uno standard web, ma il negativo qui è la velocità di adozione senza consenso generale da parte di altre principali parti interessate . Attualmente, SXG è supportato solo nei browser basati su Chrome e Chromium .

Spingendo AMP: come è subentrato un nuovo "standard"?

Gli editori di notizie sono stati tra i primi ad adottare AMP. Google ha persino 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 sul web. Tuttavia, questo argomento è stato contestato da Google e sostengono che le priorità sono assegnate alle prestazioni, indipendentemente da ciò che viene utilizzato per ottenere il risultato di tale pagina a tale misura delle prestazioni. Poiché l' algoritmo di ricerca di Google è principalmente in segreto , possiamo solo fidarci di queste affermazioni alla loro parola. Tangenzialmente, la funzione "Top Stories" in Ricerca sui dispositivi mobili ha recentemente eliminato AMP come requisito.

Il progetto AMP è stato più chiuso in termini di controllo all'inizio del suo lancio, nonostante si sia promosso come progetto open source. Gli editori hanno finito per riportare velocità più elevate, ma questo è stato lasciato ad un set di metriche "time will tell". In conclusione, l'affermazione "non è necessario AMP per classificare più in alto" è spesso in competizione con "basta usare AMP e si classificherà più in alto". Il che può essere allettante per gli editori che cercano di raggiungere la barra delle prestazioni per dare priorità ai loro contenuti.

Prima la community Web

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

Se Google fosse semplicemente una società di performance web sarebbe ancora troppo centralizzazione delle decisioni del web. Ma non sono solo una società 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 è costituita 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 decisioni future. Questa mossa presumibilmente abbinerà Google AMP Cache, che ospita le pagine, dal runtime di AMP, che è la fonte JavaScript per elaborare i componenti AMP su una pagina.

Tuttavia, questo è tutto positivo dopo che AMP è stato integrato nei principali siti di notizie , e-commerce e persino senza fini di lucro . Quindi questo nuovo modello non è un approccio democratico e fondato. 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, impone solo un falso senso di democrazia che non esisteva.

Inoltre, lo stesso processo di standard web è tutt'altro che perfetto. Le organizzazioni di standardizzazione sono fortemente dominate da membri di società 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; accoppiato con la 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 si uniscono alle organizzazioni standard, non si tratta di guadagnare, ma di decidere se dovrebbero allentare i loro regni.

A questo punto con il 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 il progetto AMP o di scoraggiarlo in un contesto diverso sono ormai trascorse . Se gli utenti possono o meno rinunciare a AMP è stato deciso 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 superato da molteplici lezioni apprese sul potere e sul controllo da grandi aziende tecnologiche che devono ottilmente imparare di nuovo la responsabilità con ogni nuovo sforzo.