Mercoledì 9 novembre 2016
Le app web progressive (PWA), una delle idee innovative più emozionanti sul web, sfruttano le nuove tecnologie per offrire agli utenti il meglio dei siti mobile e delle applicazioni native. Tuttavia, per essere davvero efficaci è importante che siano indicizzabili e collegabili. Ogni suggerimento presentato in questo articolo è una best practice esistente per l'indicizzabilità, indipendentemente dal fatto che stiate creando un'app web progressiva o un semplice sito web statico. Tuttavia, abbiamo raccolto queste best practice per offrirvi un elenco di controllo come guida:
Realizzate contenuti che possano essere sottoposti a scansione
Perché? Tradizionalmente i siti web generano o eseguono il rendering del proprio codice HTML sul server: questo è il modo più semplice per garantire che i contenuti siano direttamente collegabili. Con le applicazioni web si è diffuso il concetto di rendering lato client, tramite cui i contenuti vengono aggiornati dinamicamente nella pagina, senza che questa debba essere ricaricata, durante la navigazione degli utenti.
L'approccio moderno è un rendering ibrido, in cui il rendering lato server viene utilizzato quando un utente apre direttamente un URL e il rendering lato client viene utilizzato dopo il caricamento iniziale della pagina per la successiva navigazione e le richieste asincrone.
L'esempio di applicazione PWA lato server mostra il tipo di rendering unicamente lato server, mentre l'esempio di applicazione PWA ibrida mostra l'approccio combinato.
Se non conoscete la terminologia relativa al rendering lato server e lato client, date un'occhiata a questi articoli sul web sul rendering lato client e server e sul rendering lato server in react and node.js.
Best practice:
Utilizzate il rendering lato server o ibrido, in modo che gli utenti ricevano i contenuti durante il payload iniziale della richiesta web.
Assicuratevi sempre che gli URL siano accessibili in modo indipendente:
https://www.example.com/product/25/
Il link riportato sopra dovrebbe rimandare direttamente alla risorsa specifica.
Se non riuscite a supportare il rendering lato server o ibrido per la vostra app web progressiva e decidete di utilizzare il rendering lato client, vi consigliamo di usare lo strumento "Visualizza come Google" di Google Search Console per verificare se i contenuti vengono visualizzati correttamente per il nostro crawler della Ricerca.
Non reindirizzate gli utenti a link diretti che rimandano alla home page della vostra applicazione web.
Evitate anche di mostrare agli utenti una pagina di errore invece del link diretto.
Fornite URL puliti
Perché? Gli identificatori di frammento (#user/24601/ o #!user/24601/) sono stati
una soluzione alternativa efficace per consentire ai browser di mostrare, tramite il metodo AJAX, nuovi contenuti da un server senza ricaricare la pagina.
Questo metodo è noto come rendering lato client.
Tuttavia, la sintassi degli identificatori di frammento non è compatibile con alcuni strumenti web, framework e protocolli, ad esempio il protocollo Open Graph di Facebook.
L'API History ci consente di aggiornare l'URL senza identificatori di frammento, mantenendo il recupero asincrono delle risorse ed evitando pertanto il ricaricamento della pagina; in questo modo vengono sfruttati gli elementi migliori di entrambi i metodi. Lo schema di scansione del metodo AJAX (e i relativi URL con frammenti con i caratteri di escape #!/) era valido in passato, tuttavia oggi non è più consigliato.
Gli esempi di applicazione PWA ibrida e lato client mostrano l'API History.
Best practice:
Fornite URL puliti senza identificatori di frammento (# o #!), come l'esempio riportato sotto:
https://www.example.com/product/25/
Se utilizzate il rendering ibrido o lato client, assicuratevi di supportare la navigazione del browser con l'API History.
Pratiche non consigliate:
L'utilizzo della struttura "#! URL" per guidare gli URL unici non è consigliato:
https://www.example.com/#!product/25/
Questa struttura è stata introdotta come soluzione alternativa prima dell'introduzione dell'API History. È considerata una sequenza distinta dalla struttura "# URL".
L'utilizzo della struttura "# URL" senza il simbolo ! non è supportato:
https://www.example.com/#product/25/
Questa struttura di URL è già tema di discussione sul web e riguarda la creazione di link diretti all'interno dei contenuti di una pagina specifica.
Specificate URL canonici
Perché? Il miglior modo per evitare un'indicizzazione confusa quando gli stessi contenuti sono disponibili in più URL (nello stesso dominio o in domini diversi) è contrassegnare una pagina come canonica e duplicare il contenuto in tutte le altre pagine.
Best practice:
Includete il seguente tag in tutte le pagine in cui un particolare contenuto viene duplicato:
<link rel="canonical" href="https://www.example.com/your-url/" />
Se supportate pagine AMP, assicuratevi di utilizzare correttamente anche l'istruzione equivalente rel="amphtml".
Pratiche non consigliate:
Evitate di duplicare di proposito i contenuti su più URL senza utilizzare l'elemento link rel="canonical".
Ad esempio, l'elemento link rel="canonical" può ridurre l'ambiguità nel caso di URL con parametri di monitoraggio.
Non create riferimenti canonici in conflitto tra le pagine.
Realizzate contenuti adatti a più dispositivi
Perché? È importante che tutti gli utenti usufruiscano della migliore esperienza possibile quando visualizzano la vostra pagina web, indipendentemente dal dispositivo utilizzato.
Rendete reattivo lo stile del vostro sito; i caratteri, i margini, la spaziatura interna, i pulsanti e lo stile generale del sito dovrebbero ridimensionarsi in modo dinamico in base alla risoluzione dello schermo e all'area visibile del dispositivo.
Immagini di piccole dimensioni ingrandite per dispositivi desktop o tablet offrono un'esperienza negativa. Al contrario, immagini con risoluzioni estremamente elevate richiedono molto tempo per essere scaricate su cellulari e potrebbero influire negativamente sulle prestazioni dello scorrimento su mobile.
Scoprite di più sull'esperienza utente per le applicazioni PWA.
Best practice:
Utilizzate l'attributo srcset per recuperare immagini con risoluzioni diverse per dispositivi distinti ed evitare di scaricare immagini più grandi di quelle che lo schermo del dispositivo è in grado di mostrare.
Ridimensionate le dimensioni del carattere e l'altezza della riga per assicurarvi che il testo sia leggibile, indipendentemente dalle dimensioni del dispositivo. Analogamente, anche la spaziatura interna e i margini degli elementi vengono ridimensionati in modo ragionevole.
Provate diverse risoluzioni dello schermo tramite la funzionalità Modalità dispositivo degli Strumenti per sviluppatori di Chrome e lo strumento Test di ottimizzazione mobile.
Non mostrate agli utenti contenuti diversi da quelli che mostrate a Google. Se utilizzate i reindirizzamenti o il rilevamento degli user agent (noto anche come browser sniffing oppure la pubblicazione dinamica) per alterare il design del sito per diversi dispositivi, è importante che i contenuti rimangano gli stessi.
Utilizzate lo strumento "Visualizza come Google" di Search Console per verificare che i contenuti recuperati da Google corrispondano a quelli visualizzati da un utente.
Per motivi di usabilità, evitate di utilizzare caratteri di dimensioni fisse.
Sviluppate in modo graduale
Perché? Uno dei metodi più sicuri da adottare per aggiungere funzionalità a un'applicazione web è apportare modifiche in modo graduale. Se aggiungete una funzionalità alla volta, potete osservare l'impatto di ogni singola modifica.
In alternativa, molti sviluppatori preferiscono considerare le applicazioni web progressive come un'opportunità per rinnovare il proprio sito mobile con un'operazione unica; la nuova applicazione web viene sviluppata in un ambiente isolato e, una volta pronta, viene sostituita al sito mobile esistente.
Quando sviluppate funzionalità in modo graduale, cercate di dividere le modifiche in diversi passaggi. Ad esempio, se intendete sostituire il rendering lato server con il rendering ibrido, affrontate questa modifica singolarmente e non in combinazione con altre funzionalità.
Entrambi gli approcci presentano pro e contro; lavorare gradualmente semplifica le operazioni relative all'indicizzazione nella ricerca, poiché la transizione è continua. Tuttavia, questo approccio potrebbe comportare un processo di sviluppo più lento e, se lo sviluppo non parte da zero, una ristrutturazione del sito potenzialmente meno innovativa.
In entrambi i casi, le aree più sensibili a cui prestare attenzione sono gli URL canonici e la configurazione di robots.txt nel sito.
Best practice:
Lavorate gradualmente sul sito web aggiungendo una funzionalità alla volta.
Ad esempio, se il protocollo HTTPS non è ancora supportato, eseguite innanzitutto la migrazione a un sito sicuro.
Pratiche non consigliate:
Se avete sviluppato l'app web progressiva in un ambiente isolato, evitate di lanciarla senza controllare che i link rel-canonical e il file robots.txt siano configurati correttamente.
Assicuratevi che i link rel-canonical rimandino al sito reale e che la configurazione di robots.txt consenta al crawler di eseguire la scansione del nuovo sito.
È sensato impedire ai crawler di indicizzare il sito in fase di sviluppo prima del lancio, ma in seguito non dimenticate di consentire nuovamente ai crawler di accedere al nuovo sito.
Utilizzate il metodo di potenziamento progressivo
Perché? Se possibile, è importante individuare le funzionalità del browser prima di utilizzarle. Il rilevamento delle funzionalità è preferibile anche rispetto ai test dei browser che ritenete supportino una determinata funzione.
Una prassi scorretta comune nel passato consiste nell'attivare o disattivare funzionalità eseguendo test per rilevare il browser utilizzato dall'utente. Tuttavia, poiché i browser si evolvono di continuo con nuove funzionalità, questa tecnica è fortemente sconsigliata.
Service Worker è una tecnologia relativamente nuova ed è importante non perseguire il progresso a scapito della compatibilità: è un esempio perfetto di quando utilizzare il potenziamento progressivo.
Best practice:
Prima di registrare un service worker, controllate la disponibilità della relativa API:
if ('serviceWorker' in navigator) {
...
Utilizzate il metodo di rilevamento basato su API per tutte le funzionalità del vostro sito web.
Non utilizzate mai lo user agent del browser per attivare o disattivare funzionalità nell'app web. Controllate sempre se l'API della funzionalità è disponibile e, in caso contrario, utilizzate una versione meno innovativa ma piacevole.
Evitate di aggiornare o lanciare il sito senza eseguire test su più browser. Controllate l'analisi del sito per scoprire quali browser sono più diffusi nella vostra base di utenti.
Eseguite test con Search Console
Perché? È importante comprendere in che modo la Ricerca Google visualizza i contenuti del vostro sito. Potete utilizzare Search Console per recuperare singoli URL dal vostro sito e verificare in che modo vengono visualizzati dalla Ricerca Google tramite la funzionalità "Scansione > Visualizza come Google". Se la relativa opzione viene selezionata, Search Console elabora il vostro codice JavaScript e visualizza la pagina; in caso contrario viene mostrata solo la risposta con il codice HTML non elaborato.
Google Search Console inoltre analizza i contenuti della pagina in vari modi, tra cui il rilevamento della presenza di dati strutturati, schede informative, sitelink e Accelerated Mobile Pages.
Best practice:
Monitorate il vostro sito tramite Search Console e scoprite le sue funzionalità, tra cui "Visualizza come Google".
Fornite una Sitemap tramite Search Console Scansione > Sitemap. Può essere un modo efficace per assicurarvi che la Ricerca Google tenga conto di tutte le pagine del sito.
Annotate con i dati strutturati di Schema.org
Perché? I dati strutturati di Schema.org rappresentano un vocabolario flessibile per riassumere le parti più importanti della pagina in forma di dati elaborabili da un computer. Questi dati possono essere generici e indicare semplicemente che la pagina è di tipo "NewsArticle" oppure possono essere specifici e indicare la posizione, la sede, il nome del gruppo e il rivenditore di biglietti per un gruppo musicale in tour o gli ingredienti e i passaggi di una ricetta.
L'utilizzo dei metadati potrebbe non essere necessario per ogni pagina dell'applicazione web, ma è consigliato se pertinente. Google li estrae dopo il rendering della pagina.
Esistono diversi tipi di dati, tra cui NewsArticle, Recipe e Product, per citarne alcuni. Potete anche esplorare tutti i tipi di dati supportati qui.
Best practice:
Verificate che i metadati di Schema.org utilizzati siano corretti tramite lo Strumento di test per i dati strutturati di Google.
Controllate che i dati forniti siano visibili e che non siano presenti errori.
Non utilizzate un tipo di dati che non corrisponde ai contenuti effettivi della pagina. Ad esempio, non utilizzate
Recipe per una maglietta in vendita. Utilizza invece Product.
Annotate con Open Graph e le Twitter card
Perché? Oltre ai metadati di Schema.org, può essere utile aggiungere il supporto anche per il protocollo Open Graph di Facebook e per le schede informative di Twitter.
Questi formati di metadati migliorano l'esperienza utente quando i contenuti vengono condivisi nei rispettivi social network.
Se il vostro sito o la vostra applicazione web utilizza questi formati, è importante assicurarsi che siano inclusi anche nell'applicazione PWA per garantire una viralità ottimale.
Best practice:
Testate il markup di Open Graph con lo strumento Facebook Object Debugger Tool.
Scoprite il formato di metadati di Twitter.
Non dimenticate di includere questi formati se sono supportati dal vostro sito esistente.
Eseguite test su più browser
Perché? Dal punto di vista degli utenti è senza dubbio importante che il comportamento di un sito web sia lo stesso su tutti i browser. Anche se l'esperienza potrebbe adattarsi a dimensioni diverse dello schermo, tutti ci aspettiamo che un sito mobile funzioni allo stesso modo su dispositivi di dimensioni simili, a prescindere dal fatto che si tratti di un telefono iPhone o Android.
Anche se il web potrebbe essere percepito come frammentato a causa del numero di browser utilizzati in tutto il mondo, la varietà e la concorrenza rientrano tra i fattori che lo rendono una piattaforma così innovativa. Per fortuna gli standard web non sono mai stati così evoluti come in questo momento e i moderni strumenti consentono agli sviluppatori di realizzare con disinvoltura siti web completi e compatibili con più browser.
Best practice:
Utilizzate strumenti di test per più browser, ad esempio BrowserStack.com, Browserling.com o BrowserShots.org, per assicurarvi che la vostra applicazione PWA sia compatibile con più browser.
Misurate le prestazioni di caricamento pagina
Perché? La velocità di caricamento di un sito web è direttamente proporzionale alla qualità dell'esperienza utente. L'ottimizzazione della velocità di una pagina è già un argomento ben conosciuto nell'ambito dello sviluppo web. Tuttavia, a volte, durante lo sviluppo di una nuova versione di un sito, le ottimizzazioni necessarie non sono considerate una priorità elevata.
Durante lo sviluppo di un'applicazione PWA consigliamo di misurare le prestazioni della velocità di caricamento pagina e di ottimizzarla prima del lancio del sito per ottenere risultati ottimali.
Best practice:
Utilizzate strumenti come PageSpeed Insights e Web Page Test per misurare le prestazioni di caricamento pagina del vostro sito. Mentre Googlebot è un po' più paziente per quanto riguarda il rendering, le ricerche hanno messo in evidenza che il 40% dei consumatori abbandona una pagina che impiega più di 3 secondi per caricarsi.
Leggete ulteriori informazioni sui nostri consigli relativi alle prestazioni delle pagine web e sul percorso di rendering critico.
Non relegate l'ottimizzazione tra le operazioni da svolgere dopo il lancio del sito. Se prima di eseguire la migrazione a una nuova applicazione PWA il caricamento dei contenuti del sito web era veloce, è importante che il livello di ottimizzazione non si abbassi.
Ci auguriamo che l'elenco di controllo riportato sopra sia utile e rappresenti una guida adeguata per sviluppare applicazioni PWA tenendo in considerazione l'indicizzabilità.
Quando iniziate, ricordatevi di consultare gli esempi di indicizzabilità delle applicazioni PWA che mostrano il rendering ibrido, lato server e lato client. Come sempre, se avete domande rivolgetevi ai forum per i webmaster.