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.

Warp speedAlla 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. 🙂

Hacking di Google: servizi nascosti, sconosciuti o futuri

Tutto quanto state per leggere è solo un gioco.

Smanettare nel codice di Google è sempre divertente. Osservando il codice HTML oppure certe convenzioni seguite per anni sui nomi di acuni file, emergono abitudini dell’azienda di Mountain View o caratteristiche che possono essere sfruttate per trovare informazioni interessanti.

Tra tutte, probabilmente le informazioni più ghiotte sono quelle relative a servizi non ancora pubblici ma previsti per il futuro.

Nei prossimi paragrafi vi condividerò i risultati di alcune delle ricerche che ho svolto, precisando che quanto ho trovato non corrisponde necessariamente a nuovi servizi o prodotti di Google ma potrebbero essere riferimenti a servizi pubblici che il sottoscritto non conosce o ricorda. 😛

Proprio per la suddetta ragione, vi chiederò di aiutarmi a capire se si tratta di servizi realmente nuovi o meno. 🙂

Logo dei servizi

Gli URL usati per i logo di Google sono sempre stati del tipo:

http://www.google.com/images/logos/nomeservizio_logo.gif

Vengono anche usate leggere variazioni nell’URL, per specificare le versioni di uno stesso logo in lingue diverse dall’inglese; tuttavia l’URL sopra indicato rimane quello principale e “canonico”.

Non si può escludere che prima di annunciare un nuovo prodotto, per esempio un nuovo motore di ricerca verticale oppure un nuovo servizio per le aziende, alcuni dei file necessari ad erogare il servizio vengano predisposti online con un po’ di anticipo.

Chissà che cosa si scoprirebbe se qualcuno provasse a testare l’esistenza di nuovi logo con alcune migliaia di accessi ad URL del tipo:

http://www.google.com/images/logos/ + parola + _logo.gif

Ho voluto approfittare dell’esistenza online di qualche dizionario inglese gratuito. Tra i tanti logo che ho beccato, io non conosco quelli che seguono. Mi dareste una mano a risalire ai servizi che li usano? I commenti del blog sono a vostra disposizione! 🙂

  • http://www.google.com/images/logos/new_logo.gif
  • http://www.google.com/images/logos/press_logo.gif
  • http://www.google.com/images/logos/beat_logo.gif
  • http://www.google.com/images/logos/storage_logo.gif
  • http://www.google.com/images/logos/agency_logo.gif
  • http://www.google.com/images/logos/shallow_directory_logo.gif (trovato in altro modo e sicuramente usato in passato)

New Google Logos

Sono riuscito a trovare qualche piccolo inizio facendo delle ricerche, ma non ho acquisito alcuna certezza sull’uso di quei logo. Ogni vostro contributo è benvenuto.

Identificatori dei motori verticali

Quando effettuate una ricerca su Google Web (vi consiglio di farne una su Google.com e proseguire nella lettura) appare a sinistra dei risultati una colonna con delle icone dedicate ai motori di ricerca verticali.

Cliccando su una qualunque delle icone, per esempio quella del motore delle News, l’URL della pagina visualizzata dal browser cambia e al suo interno il parametro “tbm” contiene una stringa di testo che identifica il motore di ricerca verticale selezionato, “nws” nel caso delle News:

http://www.google.com/search?q=test&hl=en&prmd=ivnsfd&source=lnms&tbm=nws&sa=X&oi=mode_link&ct=mode&cd=4

Se provate a modificare il valore “nws” in un altro identificatore di un motore di ricerca verticale, Google produrrà la pagina relativa. Potete provare cambiando “nws” con “mbl”, che è l’identificatore dei contenuti Realtime:

http://www.google.com/search?q=test&hl=en&prmd=ivnsfd&source=lnms&tbm=mbl&sa=X&oi=mode_link&ct=mode&cd=4

Errore HTTP 400 di GoogleChe succede se al parametro “tbm” viene assegnato un valore che non corrisponde ad un motore di ricerca verticale esistente? Google mostra un errore di tipo 400 (Bad Request) all’utente:

http://www.google.com/search?q=test&hl=en&prmd=ivnsfd&source=lnms&tbm=ciccio&sa=X&oi=mode_link&ct=mode&cd=4

Ravanando nel codice Javascript di Google, ho trovato un array che ospita valori destinati ad essere assegnati al parametro “tbm”, ovvero una lista di identificatori dei motori di ricerca. Sono tutti validi e accettati da Google, nel senso che non producono un errore di classe 400, tuttavia alcuni identificatori sono “inattivi” e i motori di ricerca richiamati non forniscono risultati.

Nella tabella che segue ho riassunto i codici conosciuti, quelli sconosciuti e alcune mie congetture basate su associazioni puramente arbitrarie e personali. Per tutti i codici, ho aggiunto un link all’URL dei risultati.

Codice Motore di ricerca Note
evn Sconosciuto Events?
frm Sconosciuto
ppl Sconosciuto People?
prc Sconosciuto
klg Sconosciuto Knol/Knowledge?
pts Patents
rcp Recipes
shop Shopping
vid Videos
nws News
mbl Realtime
bks Books
plcs Places
isch Images
blg Blogs
dsc Discussions

Voglio indirizzare la vostra attenzione sopratutto sulle congetture “People” (che è diverso da Google Profiles, che possiede un identificatore diverso da “ppl”) e “Knol/Knowledge“, perché un’associazione di questi concetti può essere fatta con quello che mostrerò di seguito.

Grafica delle icone

L’ultima fonte di informazioni riservate potrebbero essere le icone che Google usa per i servizi di ricerca. Fortunatamente, piuttosto che gestirle tutte con file a sé stanti, Google usa la buona tecnica degli Sprite CSS e quindi unisce tutte le icone dei servizi di ricerca in un’unica immagine.

Quella che segue è la versione dell’immagine che è stata usata quando Google ha introdotto per tutti gli utenti la barra laterale per la selezione del tipo di ricerca, nel maggio 2010:

http://www.google.com/images/nav_logo15.png
Icone inutilizzate

Come potete notare, tra le icone appaiono un punto di domanda verde e due omini stilizzati (che ricordano un po’ quelli di Myspace): si tratta dunque di servizi di ricerca già preventivati all’epoca da Google, mantenuti fino alla più recente versione dell’immagine, ma che non vengono mai mostrati agli utenti nella barra verticale.

Volendo concedermi un volo di fantasia e cercando a tutti i costi di associarli agli identificatori dei motori verticali illustrati pocanzi, mi verrebbe da dire che le due icone misteriose potrebbero essere associate rispettivamente a dei concetti quali “Know/Knowledge” e “People”.

Ma queste sono le mie congetture. Vi invito a fare le vostre specie se, a differenza del sottoscritto, avete notato l’uso di queste icone prima d’ora. 🙂

Approfondimenti

Se siete i classici smanettoni che voglio ulteriormente approfondire quanto Google tenta di tenere riservato, vi segnalo una persona che fino a poco tempo fa era considerato il vero esperto in materia: Tony Ruscoe. Il suo blog è ricco di indicazioni su come approcciare la ricerca di servizi non accessibili al pubblico.

Tony ha usato per anni diversi sistemi, differenti da quelli sfruttati da me e spiegati in questo post. Stanchi di ricevere continui dictionary attack, quelli di Google hanno alla fine pensato che sarebbe stata una buona idea accettare la sua candidatura nel Webmaster Team e l’hanno assunto nel 2010. Interrompendo di fatto le sue ricerche.

Branding e traffico posizionandosi in Google Suggest!

Sono convinto che, nella percezione dell’utente, i suggerimenti di ricerca di Google o di altri motori di ricerca provengano semplicemente dal motore stesso. L’utente non sa che i suggerimenti ricevuti sono conseguenza di un calcolo statistico sulle ricerche più popolari o del momento e, per quello che gli riguarda, ricevere un suggerimento da Google implica che il suggerimento sia buono, perché tutto sommato proviene da un brand che negli anni ha investito per ottenere fiducia dalle persone.

L’effetto del suggest durante la digitazione della ricerca ha introdotto per la prima volta nel rapporto utente-motore un profondo cambiamento: in base a quanto il motore suggerisce, l’utente può essere indirizzato verso ricerche che all’inizio della digitazione non pensava di fare. In un certo senso, il suggerimento ha in parte la forza di distogliere l’utente dall’intenzione iniziale per portarlo su strade nuove e, auspicabilmente, verso traguardi per lui più utili o interessanti.

In che modo le aziende si pongono in questo morboso triangolo d’amore e odio utente-motore-azienda?

Le aziende che hanno investito nel proprio brand per diverso tempo, fino a farlo diventare popolare nel proprio settore o popolare in associazione ad un prodotto, possono beneficiare della visibilità aggiuntiva che deriva da Google Suggest.

Il fenomeno è molto evidente in quei contesti in cui le query che iniziano con una categoria di prodotto o servizio vengono “completate” dai suggerimenti del motore con i brand solitamente associati al prodotto. Il primo esempio che mi viene in mente è quello delle assicurazioni online, ma ne esistono diversi altri.

Un brand che appare in un suggerimento di ricerca si è meritato quello spot di visibilità perché ha investito per associare in maniera molto forte il proprio marchio con la tipologia di prodotto. Quello spot è la conseguenza di quanto alcuni utenti cercano, ma il brand viene suggerito anche agli utenti che all’inizio della digitazione non pensavano in maniera specifica a quel brand. E questo fenomeno rappresenta un’opportunità per aumentare il valore di un marchio e per ottenere nuovo traffico qualificato.

L’idea malsana

Da un po’ di tempo mi frulla per la testa l’idea di posizionare una query all’interno di Google Suggest. Solo un’immagine può trasmettere l’effetto che si potrebbe ottenere.

Esempio della visibilità che si potrebbe ottenere posizionandosi su Google Suggest

Clicca per osservare l'effetto finale

Il risultato ottenibile si discosterebbe dal classico posizionamento di un sito web nei risultati di una ricerca, perché presenta caratteristiche che mi affascinano e che, per quello che ne so, non sono state finora esplorate:

  • il suggerimento del brand avverrebbe prima ancora che l’utente effettui la ricerca (modifica del percorso di ricerca)
  • il brand verrebbe chiaramente associato ad una tipologia di prodotto (identità)
  • nella lista di suggerimenti, il brand sarebbe in buona compagnia di altri brand affermati (autorevolezza)
  • qualora l’utente selezioni quella ricerca, l’intera SERP risultante sarebbe incentrata sul brand (presidio della SERP)

Adesso, quelli di voi che mi conoscono penseranno che l’applicazione dell’idea avrebbe come inevitabile sfogo la simulazione di ricerche degli utenti. E mi conoscono bene, perché in effetti è così, tuttavia sarebbe errato pensare che l’obiettivo non possa essere raggiunto attraverso normali attività di marketing.

Per esempio, degli spot radiofonici potrebbero comprendere come messaggio finale una call-to-action in cui si invitano le persone a “cercare su Internet” [sic] “tipoprodotto brand“, al fine da indurre una nascita naturale delle ricerche che associano il tipo di prodotto al marchio da posizionare (per una volta, in tutti i sensi).

Va da sé che l’associazione non avverrebbe solo nella testa delle persone ma anche negli algoritmi di clustering del motore di ricerca.

Infine, se la ricerca consigliata risultasse poco digitata fino all’inizio della campagna radiofonica, un picco di accessi con quella keyphrase potrebbe anche essere considerato uno strumento di monitoraggio del ROI. Figo, no? Insomma, io lo trovo figo.

Di sinergia tra search marketing ed altri canali di visibilità si potrebbe parlare a lungo: ce n’è sempre stata troppo poca e a mio parere tanto si potrebbe fare per ottimizzare gli investimenti e ottenere maggiori benefici senza maggiorazioni di costo significative. Le idee non mancano, da sradicare è la gestione dei canali a compartimenti stagni o privi di una regia comune.

Ma torniamo agli aspetti più beceri: la simulazione di query. Le persone più attente su FaceBook avranno notato un mio strano screenshot che immortala le prime fasi della progettazione di un querybot. La faccenda mostra sfide piuttosto complesse.

Su questo progetto vi aggiornerò, come per tutti gli altri, strada facendo. 🙂

Hacking di Google Hot Trends

Logo di Google Hot TrendsMicro-post per segnalarvi che mi sono preso tutte le estensioni nazionali dei nomi di dominio ed ho controllato se per caso vi fossero feed non documentati ma accessibili di Google Hot Trends.

Gli unici trovati sono stati:

  • USA
  • India
  • Singapore
  • Giappone

Anche giocando di parametri nelle URL di alcuni servizi interni, dei feed atom e dei gadget per iGoogle, speravo in una ricerca più fruttuosa.

Nel processo, almeno, ho dato una bella rispolverata all’elenco dei parametri usati da Google negli URL. Ma non fermatevi ai contenuti del link proposto, un elenco esaustivo non è stato mai compilato/aggiornato.

Lo strumento di monitoraggio SERP che manca

Mooolto tempo fa venne fuori un tool per SEO che comparava la SERP di una query su Google.com con la corrispondente SERP su Yahoo!.

Il tool permetteva di osservare visualmente quali risultati (si legga: siti web) osservati su Google apparivano anche su Yahoo! e viceversa. Pur non essendo di utilità pratica per il lavoro quotidiano dei SEO, era uno strumento simpatico per rendersi conto quanto i risultati dei due motori di ricerca differivano.

Uno degli aspetti interessanti era che era possibile osservare anche in che modo i siti comuni alle due SERP cambiavano posizione nei due motori: allego uno screenshot nel quale le linee tra due specifici punti permettono di rendersi conto quanto interi gruppi di siti su Google avanzavano o arretravano di posizione nella corrispondente SERP di Yahoo!.

Comparazione di una SERP di Yahoo! e la corrispondente di Google

Perché tiro fuori dal cappello questo vecchissimo tool? Perché all’epoca rimasi affascinato dalla modalità di visualizzazione scelta per dare evidenza delle differenze di posizione e perché credo che un approccio molto simile potrebbe essere usato per un tipo di tool di monitoraggio delle SERP che al momento non mi risulti esista e verrebbe estremamente utile ai SEO.

Di che sto cianciando

Tutti i tool di rank checking esistenti si focalizzano sul monitoraggio delle posizioni di uno specifico sito web e al massimo estendono le analisi ad un gruppo di altri siti web (es: competitor), che il SEO deve fornire. L’attenzione è comunque accentrata su un sito web principale.

Tuttavia non esiste un tool per il monitoraggio di una SERP in sé, che valuti come i siti cambiano di posizione nel tempo per una o più query a prescindere da quali siti popolano la SERP stessa.

A che cosa potrebbe servire un tool siffatto? A comprendere, di fronte a repentini cambiamenti di posizione di un sito, se un fenomeno è circoscritto al sito o se è esteso a diversi siti che sono soliti popolare le SERP.

Questo genere di informazione risolverebbe diversi tipici grattacapi dei SEO: di fronte ad un repentino cambiamento nel modo in cui Google o altri motori trattano il nostro sito abbiamo la tendenza a chiederci che cosa abbiamo fatto per scendere o salire di posizione o che cosa non abbiamo fatto e che avremmo dovuto fare.

Sono domande lecite, che però spesso non prendono in considerazione quando altri siti oltre al nostro hanno sperimentato fenomeni simili, potenzialmente indicatori di un tweak dell’algoritmo di ranking.

Chi è pratico di un settore e controlla frequentemente le SERP di riferimento possiede l’occhio abbastanza allenato per cogliere i movimenti dei competitor. In caso di repentini cambi di algoritmo i forum si riempiono inoltre di SEO e webmaster allarmati. Tuttavia non esiste uno strumento o un metodo che fornisca informazioni dettagliate, indici globali di cambiamento delle SERP o comodi sistemi di alert.

Io ritengo che uno strumento simile manchi alla tavolozza del pittore SEO e che grafici simili a quelli del tool che vi segnalavo ad inizio articolo potrebbero risultare davvero molto immediati per aiutarci a comprendere meglio i mutevoli comportamenti dei motori di ricerca…

…specie quando vengono preannunciati ed avremmo la possibilità di monitorare facilmente “il prima e il dopo”.

Qualcuno di voi accetta la sfida e me ne progetta uno? 😛