AngularJS (e affini) / SEO: un incontro “ravvicinato”

AngularJS non è nulla di nuovo, ma rimane ancora un “prodotto fico”. Progettato da Google nel 2009, Angular è un framework JavaScript MVC che porta tutte le funzionalità di una applicazione web fruibile in una singola pagina (Single Page Applications – SPAs) in un framework facile da usare.

Il pacchetto contiene tutto il necessario per creare SPAs: routing, data-binding, procedure per lo unit testing, il rendering HTML, gestione degli eventi ecc.

Anche se non si sta creando una SPA, noto che sempre più spesso gli sviluppatori utilizzano AngularJS per siti dove vi è necessità di manipolare il DOM e rispondere a degli eventi lato utente, cosa che prima si faceva quasi esclsivamente tramite jQuery o “framework” costruiti in casa.

Il perchè di questa transizione verso AngularJS è forse da ricercare nella flessibilità del pacchetto. Per utilizzare Angular non c’è bisogno di utilizzare tutto il pacchetto, ma si possono referenziare solo i moduli di cui si ha bisogno nell’immediato. Viene da se, che invece di usare con una libreria come jQuery che (tanto di cappello e merito per aver risolto mille altri problemi, ma) porterebbe comunque al classico “spaghetti code”, si può a quel punto utilizzare un ambiente più strutturato pur rimanendo negli ambiti della flessibilità oggi richiesta dalle applicazioni web.

Molto spesso mi è stato chiesto se è conveniente utilizzare AngularJS, e a domanda rispondo: dipende molto da quello che avete in mente di costruire.

Se stai pensando di costruire una SPA a tutti gli effetti, Angular potrebbe essere la scelta giusta, anche se altre opzioni come Ember, Meteor o Aurelia possono rappresentare una valida alternativa, soprattutto considerando che alcuni di questi framework hanno guadagnato (e stanno guadagnando) una discreata popolarità.
Al contrario, se stai pensando ad una applicazione più “semplice”, con un minimo di persistenza dei dati JavaScript con persistenza o pagine statiche con una certa interattività, allora forse Knockout può essere la scelta migliore vista la sua curva di apprendimento molto bassa.

AngularJS o jQuery: quale devo usare?

Apprezzo molto che ho appena menzionato altri quattro framework nelle ultime due righe, ma vorrei cercare di limitare l’attenzione su due “pacchetti” che nel bene o nel male tutti conoscono.

Sebbene tanto AngilarJS che jQuery sono tecnologie web, questi sono nati in due periodi storici diversi e per risolvere problemi di natura differente. Infatti l’obiettivo primario di jQuery era di manipolare il DOM (Document Object Model), permettendo di “modificare” l’aspetto di un sito web durante la fase di rendering.

Con il passare del tempo, sempre più persone hanno deciso di adottare jQuery per creare siti web attraenti e performanti, e una nuova necessità si è venuta a manifestare: il mantenimento del codice (che – sono sicuro – in molti siti è scritto in maniera del tutto inconsistente, dando origine al così detto effetto “spaghetti code”).
Angular ha affrontato questo problema introducendo nel mondo web il concetto di una programmazione orientata a moduli (framework). Anche se Angular viene “commercializzato” come soluzione per la realizzazione di applicazioni a “pagina singola”, il valore reale nell’utilizzo di un framework è la separazione dallo strato di front-end, dalla logica, dal controller, creando così un codice che è molto più gestibile e scalabile.

Utilizzando un framework si ha la possibilità di scrivere codice in puro JavaScript, o referenziare una libreria esistente di funzioni comuni volte a ridurre drasticamente il codice necessario per realizzare la maggior parte delle cose in modo più veloce.
Inutile ribadire i vantaggi più immediati, quali un codice più robusto quindi riutilizzabile, leggibile, performante e sicuro. In poche parole, l’uso di un framework come Angular è in grado di offrire:
– Templating
– Data-binding
– Routing (single page app)
– Architettura pulita, modulare e riusabile
– Sicurezza

Nel fare SEO è sicuro utilizzare Angular, jQuery o JavaScript?

Nel 1998 quando venne realizzato Google, tanto JavaScript che CSS erano due cose di cui a malapena si iniziava a parlare. Molto è cambiato da allora, e oggi il web è pieno di siti web ricchi e che fanno pesante uso di JavaScript.
A causa di questo, i motori di ricerca hanno dovuto raffinare i loro algoritmi di interpretazione al fine di comprendere meglio i contenuti che vengono proposti tramite questi meccanismi.

Un comportamento questo che vale prevalentemente su Google, anche se Bing – a discapito di tante altre implementazioni – sembra progredire in maniera molto simile. Purtroppo, questo non è il caso per altri motori di ricerca “locali” come Yandex e Baidu, che hanno difficoltà ad interpretare il linguaggio Javascript in generale, così come jQuery, e di conseguenza a posizionare correttamente siti web realizzati con tali tecnologie.

Pertanto, credo che il modo migliore è quello di valutare la vostra situazione e capire quale è il vostro mercato di che tipo di mercato di riferimento e decidere di conseguenza.

Quali sono le sfide SEO nell’usare un framework come AngularJS?

Costruire un sito web con Angular richiede pochi accorgimenti aggiuntivi rispetto ad un sito costruito con altre tecnologie. Di contro, la sfida più “complessa” viene sotto il profilo tecnico. Infatti non esiste – ancora – una tecnologia standard a disposizione per eseguire la scansione tali siti.
A tale riguardo, a seconda di come il sito è costruito, può essere difficile valutare i vari aspetti on-page (es. profondità dei collegamenti, canonical tag, ottimizzazione dei titoli ecc), così come risulta più complicato misurare altri fattori tecnici come il caricamento della pagina.

Dal punto di vista off-site, su due piedi la prima cosa a cui mi viene da pensare è la struttura URL, che in futuro potrebbe generare problemi durante le fasi di promozione.

Nonostante questo, non posso ignorare i vantaggi nel costuire una SPA. Con il giusto supporto, questi siti possono diventare fantastici vettori per distribure contenuto in grado di rafforzare le relazioni con gli utenti, anche se ben pochi percepiranno i vantaggi fino in fondo.

Un’applicazione a pagina singola può essere anche modellata su di un CMS esistente, questo non significa che la scrittura del codice richieda minor tempo. Un sito dinamico, con contenuto renderizzato come una pagina statica lato server può raggiungere gli stessi risultati di una SPA (e magari farvi risparmiare qualche euro).

Per questo motivo, durante la fase di individuazione e valutazione dei rischi del progetto consiglio di utilizzare delle precauzioni tecniche, adottando delle misure di salvaguardia per ridurre al minimo i rischi di utilizzare delle tecnologie giusto per il gusto di farlo (quando in realtà) non ve ne è un gran bisogno.

The following two tabs change content below.

Andrea Moro

Lascia un commento