Velocizzazione dei siti: creare un fake CDN

Da un po’ di tempo mi è venuta in mente un’idea malsana per velocizzare il caricamento delle pagine web da parte dei browser, in particolare quelle che inducono il browser a scaricare tante risorse, per esempio immagini.

Alla base di tutto c’è la considerazione che i browser decidono di scaricare in parallelo solo un numero limitato di risorse ospitate sullo stesso host.

Per esempio, se una pagina web contiene molte immagini e se tutte sono ospitate sotto l’host www.nomesito.it, allora i browser decideranno di scaricarne in parallelo solo una quantità massima, iniziando a richiedere le immagini successive via via che le immagini del primo “pool” sono state ricevute.

Una tecnica per indurre i browser a mettere in parallelo più richieste, ottimizzando così l’uso della banda, consiste nell’ospitare le immagini/risorse su host diversi.

Quella che segue è la tecnica che vi propongo. Sì, so che è improprio parlare di “CDN”. Un vero CDN è tutt’altra cosa. Non mi è venuto in mente un nome migliore di “Fake CDN”. Rassegnamoci.

Attenzione, pericolo: quanto segue non è un tutorial! Io vi indico il risultato finale che bisogna ottenere, sta a voi capire in che modo ottenerlo sul vostro specifico sito o server! Fate conto che diversi CMS (es: WordPress) o pannelli di controllo (es: Plesk) possono gestire in automatico alcuni file di configurazione dei vostri server e che ciò potrebbe andare in conflitto con eventuali modifiche manuali che voi decideste di fare. Procedete solo se sapete bene dove mettere le mani.

Cosa serve

• Possibilità di gestire i DNS
• Server Apache e possibilità di aggiungere alias ai domini serviti
• Un linguaggio di programmazione lato server (PHP, ASPX, ecc.) che gestisca la produzione del codice HTML delle pagine
• Saper programmare col linguaggio di programmazione

Primo passo

Bisogna modificare il DNS e inserire un host catch-all con un wildcard, per esempio: *.cdn.nomesito.it

Come tipo di record DNS potete usare un CNAME e potete farlo puntare al dominio principale nomesito.it

In questo modo tutti gli host del tipo qualsiasicosa.cdn.nomesito.it verranno risolti, alla fine dei giochi, con l’IP associato al nome di dominio nomesito.it

Secondo passo

Bisogna dire ad Apache che gli host del tipo *.cdn.nomesito.it devono essere gestiti come se fossero alias del dominio principale.

La direttiva da usare per ottenere ciò è ServerAlias, che dovrebbe essere inserita all’interno di una sezione VirtualHost già esistente nel vostro file di configurazione del server.

Alla fine dovreste avere qualcosa di simile:

<VirtualHost *:80>
    DocumentRoot /www/dominio.it
    ServerName www.dominio.it
    ServerAlias *.cdn.dominio.it
    ...
</VirtualHost>

Terzo passo

Il CMS del vostro sito dovrebbe essere istruito per produrre dinamicamente gli URL delle immagini usati negli attributi SRC dei tag IMG nelle pagine HTML.

Per esempio, ogni volta che c’è da produrre l’URL di una delle tante foto/immagini che ingolfano la vostra bellissima home page, il CMS dovrebbe produrre URL di immagine del tipo: http://a.cdn.nomesito.it/img/foto-322.jpg

Il sistema di parallelizzazione si ottiene usando, sulla stessa pagina, URL che fanno riferimento ad host diversi, tipo:

• http://a.cdn.nomesito.it/img/foto-322.jpg
• http://b.cdn.nomesito.it/img/foto-839.jpg
• http://c.cdn.nomesito.it/img/foto-063.jpg
• ecc…

In altre parole, la cartella “img” è sempre la stessa ma grazie ai tre passi indicati i suoi contenuti possono essere raggiunti attraverso host diversi.

Che criterio va usato per produrre la parte di host che deve variare per ogni URL di immagine (“a”, “b”, “c”, ecc.)? E’ categorico che ogni immagine venga mostrata sempre sotto lo stesso host, per evitare problemi di duplicazione di contenuti negli indici dei motori.

Il metodo più semplice per ottenere ciò potrebbe essere quello di calcolare un hash del nome immagine (es: foto-275.jpg), prendere il primo carattere della stringa dell’hash ed usarlo come lettera da anteporre a cdn.nomesito.it

Se come algoritmo di hash decideste di usare un CRC32, che produce un valore in esadecimale, i caratteri pseudo-random prodotti sarebbero le lettere dell’alfabeto da “a” ad “f” e i caratteri numerici da “0” a “9”: 16 diversi caratteri/host da usare per le vostre immagini.

Vi invito tuttavia a ideare sistemi differenti e più elastici per la generazione del carattere da anteporre a “cdn”, in quanto sedici differenti host potrebbero in alcuni casi anche essere eccessivi per i nostri scopi.

Conclusioni

L’esempio presentato si riferisce solo alle immagini, ma ovviamente può essere applicato a qualsiasi tipo di risorsa.

Questo post ha solo lo scopo di illustrare l’idea, sta a voi decidere come implementarla sui vostri sistemi: le modalità possono cambiare tantissimo. Se avete poco chiaro come procedere, è un buon segno per far fare il lavoro a qualcun altro. 😛

Buono smanettamento e, se vi va, fatemi sapere come è migliorata la parallelizzazione delle vostre risorse usando WebPageTest. 🙂

SEO e down Aruba: conseguenze, contromisure e prevenzione

E’ di questa mattina la notizia che mezza Italia è down a causa di un “principio d’incendio” in Aruba.it.

Scrivo questo brevissimo post nel tentativo di riassumere quali sono le conseguenze SEO di un evente simile e che contromisure potrebbero essere prese per evitare danni in futuro.

Va da sé che la quantificazione dei danni subiti dal down di un sito è strettamente correlata alla necessità del sito di rimanere online: siti che vivono di pageview perdono denaro ogni singolo secondo che non sono online. Siti la cui sopravvivenza è meno legata alle pageview e alla presenza online costante, possono subire danni economici minori, anche se mai nulli.

Conseguenze SEO

Quando un sito è down, il motore di ricerca tenta e ritenta di collegarvisi più volte, nel tentativo di comprendere la durata e gravità del fenomeno. Questo è vero sopratutto per i motori che hanno un crawling esteso e attento, come Google.

Nel caso in cui il down di un sito duri poco (fino a qualche ora) le ripercussioni sulla visibilità del sito sono minori: il sito può in teoria scendere di posizione nelle SERP, ma in modo contenuto. A volte la posizione rimane invariata.

Nel caso in cui il down di un sito duri molto di più, da 24 ore in su, le ripercussioni si fanno più serie, non solo perché la discesa nelle SERP è maggiore ma anche perché i tempi di risalita dopo la riattivazione del sito possono essere più lenti.

A prescindere dalla durata del down (poche ore o qualche giorno) in tutti i casi che ho osservato negli anni, i siti web sono sempre ritornati alle posizioni originarie, anche se la velocità di riacquisizione delle posizioni può essere lenta: da qualche ora a qualche giorno.

Contromisure SEO

Nel caso in cui l’intero server sia down ed il web server non è in grado di erogare nemmeno una risposta HTTP del tipo 503 (Service unavailable), allora non c’è modo di informare gli spider dei motori del disservizio temporaneo attraverso quegli stessi server.

Se però i server DNS del sito sono gestiti da una struttura differente da quella che gestisce i server temporaneamente down, è allora possibile modificare i record DNS in modo da farli puntare ad un host diverso. Se sul nuovo host è presente una copia del sito, esso tornerà raggiungibile e gli spider dei motori se ne renderanno conto in tempi solitamente brevi.

Nello specifico caso odierno di Aruba, chi aveva presso di loro sia i server web sia i server DNS, si attacca al tram.

Prevenzione per il futuro

• Usare gestori diversi per server DNS e server web
• Individuare un host che offra un servizio di ridondanza dei dati, su reti e infrastrutture non dipendenti da un unico fornitore
• Qualcuno di voi saprebbe segnalarne altre nei commenti al post?