Screaming Frog vs Visual SEO, intervista a Federico Sasso

Screaming Frog è sempre stato il mio tool preferito per eseguire SEO audit e per avere una rapida overview di un sito web (ho scritto anche una guida in italiano). Questo strumento SEO però non è perfetto, ha infatti diversi limiti dipendenti dalla macchina su cui gira, per fortuna non è l’unica alternativa come web crawler SEO lato client, uno dei rivali più noti e che apprezzo ogni giorno di più si chiama Visual SEO Studio sviluppato da Federico Sasso.

Per certi aspetti Visual SEO (sebbene ancora in versione beta alla data in cui scrivo) risulta più efficiente di Screaming Frog. In questo articolo trovi l’intervista completa con questo bravo developer Italiano dove abbiamo analizzato pregi e difetti di entrambi gli strumenti e le sostanziali differenze di progettazione. Alla fine dell’intervista c’è un box di approfondimento scritto direttamente da Federico che chiarisce ulteriormente alcuni aspetti e differenze.

G: Oggi volevo fare alcune domande a Federico Sasso lo sviluppatore di Visual SEO per capire le principali differenze che ci sono tra i due web crawler client più diffusi sul mercato, ovvero Visual SEO e Screaming Frog. Prima di tutto ciao Federico grazie della tua disponibilità, vuoi presentarti?

F: Ciao Giovanni grazie a te per l’invito molto gradito. Io sono uno sviluppatore, nasco come sviluppatore. Mi sono approcciato alla SEO dapprima rivestendo il ruolo anche in-house presso l’azienda per cui lavoravo, poi mi sono appassionato e principalmente sono noto per aver sviluppato questo crawler, uno spider SEO che lavora su desktop e da poco sono anche imprenditore, ho messo su un’azienda.

G: perfetto e noi italiani siamo molto fieri di te per aver distribuito, per ora gratuitamente, questo strumento che molti di noi utilizzano. Quando hai iniziato a sviluppare Visual SEO? Da quanti anni è attivo questo software?

F: per me da troppi, nel senso, le prime righe di codice penso di averle scritte nel 2010, però a dirla tutta non era come il prodotto attuale, era più un’idea di un crawler per un motore di ricerca, poi piano piano ho capito che la cosa che avrei potuto fare per dare un prodotto utilizzabile da tante persone era un crawler desktop quindi ha preso un po’ forma dopo. Tra l’altro non è che dal 2010 ci ho lavorato ininterrottamente, no anzi tutt’altro, diciamo che dal 2011 ci ho lavorato sodo. Sicuramente dal 2010 (NdR: intendeva dire 2012) quasi tutti i giorni, tutte le ore libere, i weekend e le vacanze.

G: ci sta dietro tanto lavoro! Questa intervista si basa sul fatto di voler capire le principali e sostanziali differenze tra il crawler che possiamo definire il più famoso al momento utilizzato che è Screaming Frog e il tuo che speriamo riesca a rubargli una buona fetta di mercato. Io non sono uno sviluppatore quindi è probabile che dica qualche fesseria ma, da quello che so Screaming Frog è sviluppato con Java, mentre Visual SEO come è sviluppato, con che software, con che linguaggio?

F: Screaming Frog è realizzato in Java e Java è un linguaggio creato da Sun Microsystems che è un linguaggio moderno di alto livello che gira non direttamente usando le istruzioni del processore della macchina che lo ospita ma usando quella che viene chiamata una macchina virtuale una virtual machine Java. Questo ha portato notevoli vantaggi nelle architetture moderne. Visual SEO è sviluppato invece in .NET C# che è un ambiente molto simile a Java, chiaramente ispirato da java, quindi c’è anche il runtime che è chiamato .NET che è una virtual machine, come se fossero processori virtuali. I linguaggi Java e C# sono estremamente simili non a caso perché Microsoft inizialmente aveva una versione propria di Java poi c’è stata una querelle legale per cui non poteva vendere come Java un linguaggio su cui faceva troppe trasformazioni, troppe alterazioni rispetto all’originale per cui Microsoft ha detto “bene mi faccio uno completamente mio” e fece un ottimo lavoro in realtà, per quanto ci siano detrattori di Microsoft che hanno molto spesso ragione, in questo caso fece un ottimo lavoro. Fu facile per Microsoft creare un prodotto migliore perché avevano già l’esperienza di java.

G: io utilizzo molto sia il tuo che Screaming Frog e, come chi ci ascolterà potrà ben sapere, essendo dei software lato client la potenzialità, quindi la capacità di scansionare il maggior numero di URL dipende principalmente, anzi totalmente dalla RAM installata sui PC di chi fa girare questo software. Quindi ti chiedo la differenza tra i due linguaggi, ci sono caratteristiche che permettono ad un linguaggio piuttosto che ad un altro di sfruttare meglio la memoria RAM e i processori delle macchine o si equivalgono come prestazioni?

F: a livello di piattaforma e di linguaggio non ci sono significative differenze. Quello che cambia nel consumo di memoria più che altro è l’architettura. Uno è l’architettura della macchina su cui è installata, intendo se sia a 32 o 64 bit perché se noi abbiamo una macchina, parlo per Windows ma credo che per Mac sia uguale, a 32 bit, Windows non può allocare al processo su cui gira il programma più di 2 gigabyte di RAM. Non importa, ne posso avere 20, 24, 48 giga installati ma se sono a 32 bit Windows mi darà soltanto 2 giga. Se poi questi 2 giga sono la memoria totale e ci girano anche altri programmi che sono in concorrenza fra loro per queste risorse di RAM è chiaro che potrò crawlare molto meno perché mano a mano che faccio una crawlata una esplorazione di un sito andrà ad occupare sempre più memoria al prodotto.

G: certo infatti io mi sono fatto un server apposta con Windows 10 64 bit e 32 giga di RAM proprio per far girare questo tipo di crawler.

F: in realtà la differenza non era soltanto quella di essere a 32 o 64 bit, dipende molto anche dall’architettura interna del prodotto. Io non so nulla di come sia fatto internamente Screaming Frog, non lo posso vedere, so che ad esempio Screaming Frog mi sembra che tenga in memoria a crawl time anche il grafo di tutti i link interni. Questo per loro è un costo in termini di memoria, che è incrementale non è lineare, aumenta esponenzialmente all’aumentare della crawlata, dipende da come è fatto il sito e da come è fatto il grafo dei link interni. Visual SEO ad esempio ha un andamento lineare ad oggi, però sono altre scelte architetturali. Ad esempio fino a 7, 8 mesi fa Visual SEO aveva un consumo di memoria esagerato perché teneva, mano a mano che crawlava, teneva in memoria RAM tutto l’HTML delle pagine completo, non solo i metadati. Li teneva in memoria compressa eccetera c’erano mille accorgimenti, però avevamo un sacco di utenti che ogni tanto crashavano perché esaurivano la memoria. Noi abbiamo un crash server, ci arriva un dettaglio, noi non sappiamo nulla dei nostri utenti in realtà, è un codice identificativo e basta, il dettaglio ci dice che questo utente ha avuto questo crash per esaurimento memoria. Se mi mandava una email a cui rispondere ero fortunato di dirgli “guarda è successo questo…”, se no non sapevo farci nulla. Poi abbiamo rifatto completamente l’architettura e dato che Visual SEO Studio ha la caratteristica di salvare continuamente su disco fisso i risultati della crawlata non avevamo la necessità veramente di tenere tutto in memoria, lo facevamo per essere più veloci nella reportistica, poi ce la siamo un po’ studiata e abbiamo trovato un modo furbo per non essere penalizzati nelle prestazioni e non abbiamo più avuto crash assolutamente per 8 mesi tranne giusto un paio di settimane fa un utente turco che poi lo ho contattato, avevo la mail, e mi ha detto che aveva la macchina a 32 bit, aveva 2 giga di RAM totali, aveva 10 software che giravano contemporaneamente, tutto aperto… e aveva comunque esplorato una cosa come 145.000 URL.

G: che non sono pochi!

F: tieni conto che adesso, io so di gente con Screaming Frog ha crawlato più di un milione di URL usando delle macchine virtuali in cloud. Ora da quando abbiamo la nuova architettura noi abbiamo fatto subito degli esperimenti in cloud e al primo tentativo abbiamo crawlato 400.000 URL e poi abbiamo esplorato tutto un sito e non ne abbiamo trovati più grandi, non ci sono stati problemi. Però abbiamo avuto altri colli di bottiglia perché a quel punto rappresentare nell’interfaccia utente 10.000 o 100.000 URL è una cosa, 400.000 è un’altra. C’erano alcune parti, alcune viste del nostro prodotto che erano più deboli, ad esempio non so se conosci la vista ad indice, la vista a directory, alcuni siti hanno delle directory molto nestate, molto nidificate per cui venivano centinaia e centinaia di migliaia di nodi in alcuni casi. Caricare una vista del genere ci metteva 30, 40 secondi e abbiamo detto “mettiamoci un tappo al momento”. Ora forzatamente e artificialmente blocchiamo a 150.000 URL ma in realtà il motore potrebbe fare molto di più se non ci fosse l’interfaccia. Lo sbloccheremo nei prossimi mesi.

G: con quanta RAM raggiungi quel numero?

F: 150.000? ma anche con 2 giga in realtà, poco.

G: allora è molto efficiente perché con Screaming Frog se non hai almeno 16 giga è dura arrivare a 100.000 URL, è molto dura.

F: ti ricordo che il turco ne ha fatti 145.000 con 2 giga totali, quindi…

G: quindi a livello di memoria sembra essere molto più efficiente Visual SEO rispetto a Screaming Frog, anche perché se ho capito quello che dici Screaming Frog durante la scansione tiene tutto in RAM mentre il tuo scrive in contemporanea sul database quindi può scaricare la RAM e alleggerire il carico e quindi andare avanti a lavorare.

F: si perché Screaming Frog ti permette di salvare il lavoro a fine crawlata mi sembra. Io non sono un utente non ho la versione a pagamento di Screaming Frog, non l’ho neanche più installato probabilmente.

G: quello l’ho chiesto io a Screaming Frog quindi so che fino a che non salvi non utilizza nessun database quindi non è che in tempo reale butta i dati nel database quindi nella RAM c’è un in e un out in contemporanea, quindi la memoria è come un vaso che si riempie sempre più d’acqua poi devi salvare. L’unica soluzione spesso per Screaming Frog è o scansionare grossi siti in sezioni, salvi la prima sezione poi scansioni la seconda e vai avanti cosi, mentre col tuo sembra essere molto più efficiente. Magari lo lancio su booking.com e vedo cosa riesce a combinare!

F: fammi sapere! In realtà non so perché Screaming Frog occupi così tanta memoria perché non mi sembra che si tengano tutto l’HTML, mi sembra solo i meta dati, solo l’H1 al massimo, poca roba, non ho idea.

G: farò un test e ti farò sapere! A livello invece di funzionalità pratiche, quali sono le funzioni che secondo te rendono Visual SEO, diverso, nuovo, migliore oppure le caratteristiche peculiari che ti piacciono di più?

F: non parlerò male di Screaming Frog perché è un ottimo prodotto. Non mi piaceva fino ad un anno fa, poi dalla versione 4 hanno fatto anche delle ottime cose devo dire, cose che avevamo iniziato anche noi ma non abbiamo mai rilasciato e sono congelate in rami di sviluppo per mancanza di tempo. Ad esempio loro hanno l’integrazione con Analytics, hanno l’integrazione con i dati di search console, hanno la “custom extraction” che a noi l’hanno chiesta da due anni e mezzo e ancora non l’abbiamo fatta perché abbiamo risorse limitate. Noi siamo due persone, io full time e un altro collaboratore, per cui non è facile fare tutto ma ci stiamo organizzando. Ho sempre cercato di differenziare il più possibile da Screaming Frog, intanto siamo già nati diversi perché comunque abbiamo iniziato entrambi a lavorare ad un prodotto quando l’altro non esisteva pubblicamente quindi ci sono due visioni completamente diverse. Screaming Frog si è sempre proposto come il coltellino svizzero, grande vista tabellare, esporto i dati in Excel, li importo e faccio elaborazioni successive anche se un po’ stanno cambiando, ho l’impressione, l’approccio dell’esportare tanto su Excel e cercano di tenere anche loro più sul prodotto. Visual SEO ha sempre cercato di tenere, di dare risposte subito, dare dati e viste, evitare il più possibile di esportare su un altro software Excel, non credo che tutti ce l’abbiano, che abbiano una licenza, va be ci sono le alternative gratuite per carità. Poi io ho un modo di pensare più visuale quindi ho sempre dato priorità alle viste ad albero. Un punto di forza è la vista “crawl” come noi la chiamiamo, in italiano la chiamo la vista “esplorazione”, ti fa vedere chiaramente subito la struttura di link e il “crawl path” ottenuto. Molti miei utenti apprezzano questa capacità di vedere subito a colpo d’occhio.

G: dici le varie sezioni del sito, quindi folder, la grandezza delle varie sezioni e delle cartelle che comprendono le pagine?

F: si quella è la vista ad indice, ma poi anche la vista ad esplorazione, il “crawl path” proprio, la vista che si vede anche durante il crawling è molto apprezzata. Poi a mio avviso Visual SEO è più avanzato come funzioni di query del dato. Una grossa differenza, una scelta di campo che è stata fatta di Visual SEO diversa da quella di Screaming Frog è che Screaming Frog ha deciso di fare tutto a “crawl time”, cosa vuol dire, se noi andiamo ad impostare dei filtri lo possiamo fare a priori, giusto? Tu sei un utente avanzato di Screaming Frog.

G: Si, prima si impostano i filtri e le regole poi lanci la scansione.

F: Se poi ti rendi conto di aver dimenticato qualcosa, ti rendi conto di aver sbagliato, mannaggia cosa fai?

G: Rifai tutto da capo!

F: Sui siti piccoli va be è abbastanza efficiente quindi lo fai e lo rifai, su siti grossi insomma, dopo tre giorni di crawlata potrebbe essere un problema grave. Abbiamo fatto la scelta opposta, tiriamo giù tutto l’HTML delle pagine, ce l’abbiamo sempre salvato nel database locale e poi lo possiamo interrogare come vogliamo. Quindi non ti costringiamo a fare crawlate di nuovo ripetute per vedere le stesse cose. Però il vantaggio di Screaming Frog che molti apprezzano è la possibilità di vedere subito qualche cosa già durante l’esplorazione, noi facciamo vedere alcune cose tipo, i titoli, la descrizione, qualche cosa lo puoi vedere già subito ma non puoi vedere la ripartizione percentuale, la profondità dei link, quelle tabelle che Screaming Frog ha sulla destra, quelle non te le facciamo vedere subito, te le facciamo vedere dopo. Questa è la differenza tangibile e ci sono PRO e CONTRO.

G: probabilmente Screaming Frog utilizza questo metodo perché appunto si basa tanto sulla memoria mentre il tuo essendo più efficiente lato memoria può permettersi di scaricare tutto. Impostando i filtri su Screaming Frog si riduce un sacco il lavoro, si riduce molto il numero di pagine che scansiona, poi ovviamente dipende dal tipo di filtro ma in genere il filtro va a limitare il lavoro e quindi riesci a sfruttare meglio la memoria. Il tuo non avendo questo tipo di problema lavora in modo differente e può essere anche più efficace.

F: Ho il sospetto che per loro sia stata anche una scelta obbligata perché la loro versione gratuita non permette di salvare quindi se avessero fatto il salvataggio in tempo reale avrebbero perso il tappo per la versione gratuita, sospetto.

G: e questa osservazione mi porta all’ultima domanda. Il tuo tool è stato gratuito fino ad oggi, quindi ce lo regali con molta generosità. Da quando hai intenzione di pubblicare la versione premium ed eventualmente con che modalità, con che tipologia di abbonamento e magari anche il prezzo.

F: il prezzo preferisco non esplicitarlo perché non è scolpito nella pietra, però sarà paragonabile ai concorrenti, questo posso dirlo. Non posso fare un prezzo completamente diverso.

G: per quando hai intenzione di pubblicare la versione definitiva?

F: allora ti dirò subito la tabella di marcia. A fine Gennaio dovremmo pubblicare la versione 1.0, e la versione 1.0 sarà una doppia edizione, ci sarà la versione free che chiameremo “Community” probabilmente che sarà gratuita completamente e avrà dei tappi, delle limitazioni. La versione non tappata, si chiamerà pro-beta e sarà gratuita per un po’, per fortuna. Chiederà soltanto una registrazione ma sarà l’equivalente della versione attuale un po’ migliorata con qualcosina in più probabilmente e sarà gratuita ancora per qualche mese. La versione a pagamento sarà prevista per fine Marzo.

G: benissimo quindi il 2016 vedrà la nascita del prodotto commerciale Visual SEO ed era anche ora perché te lo meriti con tutto il lavoro che gli hai dedicato!

F: penso sia un record di lunghezza della beta, 3 anni di beta.

G: se sei da solo è già tantissimo quello che hai fatto, complimenti!

F: non dormivo più, ho dovuto licenziarmi e mettere un’azienda mia per lavorare su questo, se no non riuscivo più a vivere!

G: grazie mille Federico io ho esaurito le mie domande, hai esposto molto bene tutti quelli che sono i concetti del tuo tool e ti auguro il meglio per il lancio di questo prodotto. Io sicuramente lo acquisterò!

F: grazie!

G: grazie mille Federico a presto e buon lavoro!

F: ciao grazie!

Scarica Visual SEO Studio

Considerazioni EXTRA by Federico Sasso

Sempre sul controllo e consumo di memoria

In Screaming Frog devi impostare tu il limite, e sperare di azzeccarlo (credo che tu possa anche impostare un limite superiore alla tua RAM reale); Screaming Frog se non erro se si accorge se stai per esaurire la quota impostata, interrompe la crawlata e ti permette di salvarla. Poi sei costretto a trovare un file di configurazione, modificarlo a mano, e puoi ricaricare (penso, è quanto capisco dalla loro guida online, l’esperto di Screaming Frog sei tu), rilanciare il software, ricaricare la crawlate e riprenderla (qui di positivo è che ti permettono, a quanto capisco, di riprendere la crawlata tra un lancio e l’altro, noi al momento non lo permettiamo perché non salviamo la coda di URL non esplorati).

In Visual SEO Studio per l’utente è tutto più semplice: il software non pone limiti d’uso RAM a priori, durante l’esplorazione di un sito ha dei “memory checkpoint” che monitorano continuamente e stimano il consumo di RAM, e se la RAM sta per terminare il software si interrompe da solo salvando. Non ha senso continuare, la memoria consumata era tutta quella messa a disposizione dal sistema operativo, l’utente difficilmente potrebbe dover interrompere, aprire il PC e aggiungere RAM fisica!

Casi come quello del Turco che ha avuto un crash per memoria esaurita sono difficilissimi: i memory check point funzionano, a quell’utente è capitato il crash solo perché altri software bevevano dallo stesso secchio senza che Visual SEO Studio potesse saperlo.
La soluzione di Visual SEO Studio permetterà di essere anche usata senza modifiche anche quando avremo una schedulazione delle crawlate: non c’è rischio che all’utente sia mostrata una finestra di dialogo nel cuore della crawlata notturna che chiede di aumentare la RAM.

Gli utenti Screaming Frog hanno anche il problema di installare la versione giusta (32 o 64 bit) del Java runtime. Per i programmi in .net il problema non sussiste perché il runtime .net giusto è già installato con il sistema operativo, al massimo devi averne la release giusta. La release giusta per Visual SEO Studio non è un gran problema da parecchio: chiede .net 4.x che ormai è il minimo installato da macchine anche datate (e può essere installato anche su Windows XP SP3); se il runtime è più recente, Visual SEO userà il runtime più recente.

Sulla necessità di crawlare tanti URL

Come detto intendiamo allentare il limite dei 150K URL nel prossimo futuro. E’ un problema interessante sotto molti aspetti: tecnici e commerciali.

Il limite attuale c’è solo perché se lo sbloccassimo, alcuni utenti crawlerebbero magari mezzo milione di URL, e poi si lamenterebbero se il software è lentissimo a fare alcune elaborazioni (alcuni filtri personalizzati, o le imminenti “performance suggestions” fanno ispezione molto intensiva e su siti grossi ci si mette un bel po’ a farli girare). Per cui oggi preferiamo essere percepiti come “meno URL” ma utilizzabili (non che 150K siano pochi, anzi).

L’utente non percepisce molto la differenza tra grandi numeri. Per il nostro cervello la differenza tra 10.000 e 15.000 è la stessa che c’è tra 1ML e 1.5ML, ma le prestazioni della macchina nel primo caso sono quasi indistinguibili, nel secondo potrebbero essere drammaticamente diverse.

Per sbloccare il limite senza perdere reputazione dovremmo rifare alcuni componenti dell’interfaccia: le viste ad albero in primis, ma ogni componente dopo un po’ mostra dei limiti, anche la vista tabellare se le carichi 1ML di URL diventa lenta. A tutto c’è una soluzione, ma bisogna rifare parti che oggi funzionano bene con un rispettabile 150K, e cambiarle costa tempo di sviluppo per noi oggi molto scarso (la deadline della PRO paid a fine marzo/inizio aprile è molto stretta, dobbiamo anche mettere tutto il sistema di pagamento e fatturazione in piedi, tutta roba prioritaria per la nostra sopravvivenza economica).

Ci sono altri aspetti interessanti, come ti dicevo

150K URL non è poco, quanti sono in percentuale i siti con più URL?

In realtà la risposta non la so – magari la sapessi – ma 150K URL sono già abbondantemente un limite più che adatto per la maggior parte degli utenti anche PRO (e anche in Visual SEO Studio si può segmentare restringendo a una o più cartella l’esplorazione, anche se nel farlo vi è il rischio teorico – come in Screaming Frog – di perdersi qualche URL a secondo di come sono distribuiti i link interni).

Vero, gli eCommerce facilmente superano abbondantemente tali limiti, e tanti degli utenti di Visual SEO sono gestori di siti e-commerce, anche se di solito piccoli eCommerce (non so nulla degli utenti fino a che questi non mi contattano, ma ogni tanto qualcuno lo fa). Però il 90+% delle issue on site di solito sono nel layout, le fixi lì, le fixi ovunque. E per trovare i problemi nel layout non serve crawlare milioni di URL.

Spesso i SEO vogliono la crawlata completa per fare il preventivo; i gestori di eCommerce vogliono la crawlata completa perché non hanno grandi competenze, hanno tanta duplicazione per problemi di canonicalizzazione, problemi di crawl budget, in genere causata da “faceted navigation”, ma anche lì basta poco per fare diventare il numero di URL totali un ordine di grandezza inferiore.

Serve commercialmente/strategicamente permettere di crawlare molto di più? Una volta pensavo di sì, ma già oggi sospetto di coprire gran parte degli utenti potenziali. Potremmo farlo, ma sono 80legs e Deepcrawl quelli percepiti come adatti a grosse crawlate, rischieremmo di seguire una priorità sbagliata nei tempi sbagliati. Probabilmente da un punto di vista di business avrebbe più senso fare un server web based concorrente a quei servizi, e farsi pagare 10 volte il costo di una licenza di software desktop.

Detto questo, certo che per il futuro vogliamo allentare il limite di 150K; magari non così tanto, ma 500K/1ML penso siano ottenibili (e 500K sono più facili).

Sulla velocità di crawl

Ancora su differenze tra Screaming Frog e Visual SEO Studio.

Per Screaming Frog la velocità di crawl è prioritaria, chissenefrega del resto. Certo, non è efficiente come il vecchio Xenu, ma l’architettura del programma è multi-threaded, vuole dire è in grado di effettuare più chiamate HTTP concomitanti. E’ possibile fare un attacco DOS con software come Screaming Frog (anche se non è il più adatto).

Visual SEO Studio fa la scelta opposta: lo spider è adattivo, non forza mai il throughput del web server oltre quelli che ritiene siano i suoi limiti. Lo fa con una coda mono-thread, fa una sola chiamata alla volta, e non fa la successiva fino a che la precedente non è terminata. Lo fa anche per garantire l’ordine di esplorazione e ricostruire i crawl path secondo un algoritmo “breath first” che approssimi in modo ripetibile il comportamento di un search bot (anche se è un’approssimazione: l’esplorazione di Googlebot si approssima a un breath first in assenza di segnali esterni, poi la priorità è pesata dal PageRank, e l’ordine non è esatto perché la pipeline è asincrona). Screaming Frog non prova a emulare un motore di ricerca, l’ordine di esplorazione e i crawl path non gli interessano più di tanto e ne approfitta a piene mani. Visual SEO Studio lo fa invece per scelta progettuale: ricostruzione ripetibile dei crawl path e adattività alla capacità del server.

In realtà Visual SEO Studio potrebbe osare un po’ di più, perché i web server sono fatti per gestire chiamate concorrenti; in particolare se il crawler fosse l’unico utente il web server non patirebbe se Visual SEO Studio forzasse un po’ di più la mano. Sarebbe possibile per noi parallelizzare alcune richieste (a gruppi particolari) senza alterare l’ordine di esplorazione e riuscendo a ricostruire il crawl path, a costo di una complessità leggermente maggiore e un leggero incremento in velocità (non so stimare quanto). Sarebbe sempre più lento in media, ma non di molto. In futuro lo faremo, oggi però gli utenti non se ne lamentano (una volta sì, ma dopo un po’ di ristrutturazioni aumentammo di brutto l’efficienza di crawl).

Anche qui, sono scelte di campo diverse:

• per Screaming Frog prioritario è crawlare veloce, chissene frega del web server.
• per Visual SEO Studio prioritario è non alterare l’efficienza del web server.

(NdR: in realtà Screaming Frog permette di impostare la velocità di scansione: di base il software esegue 5 chiamate in contemporanea ma il limite può essere aumentato o diminuto tramite l’opzione “speed” nel menu di configurazione dello spider.)

Un aneddoto: una volta mi contatta un utente, e mi scrive: “guarda, con Screaming Frog crawlo questo sito a tot URL al secondo, però dopo tot il server di solito va in crash e devo riavviarlo. Con il tuo crawler non si crasha, però ci mette di più, come posso accelerarlo?”
Ovvio che gli rispondo: “non si crasha perché non cerca di andare più di quanto il web server riesce a sostenere!”. Mica che le chiamate HTTP colpiscono più o meno forte, solo più o meno frequente!

Pensiamo a un eCommerce online di un cliente, anche se non glielo crasho, con un crawler che gira per due giorni rallenta tutto, il tasso di conversione si abbassa e sono i bipedi a pagare le transazioni, mica il bot.

Purtroppo per me, questa caratteristica di Visual SEO – adattarsi al ritmo del server senza forzare oltre – fa sì che sia vista dai potenziali clienti SEO come un punto di debolezza. Vero, è più lento in media, ma non così tanto. Su un sito di prova locale ho una volta superato le 200 pagine al secondo! OK, sito piccolo, locale, e molto leggero, ma se il web server risponde, il crawler ha buone prestazioni. Il caso peggiore per Visual SEO Studio è quando una singola pagina va in time-out, e la velocità media si abbatte; una leggera parallelizzazione lo eviterebbe. Lo faremo prima o poi.

Il carico eccessivo sul server non è dato solo dall’eccessiva frequenza di crawl in sé, perché i web server sono fatti bene e scalano, ma dall’eccessiva allocazione di memoria che questa alloca. Il problema è che di solito i bot non accettano cookie di sessione, e ogni loro richiesta implica la creazione di una nuova sessione lato server.

Una volta un sistemista Unix mi disse che ogni sessione su Apache costa in media 7MB; poniamo sia vero (è un dato un po’ contestato): pensa a uno Screaming Frog che per ogni chiamata HTTP causa una nuova sessione, anche fossero solo 5 chiamate al secondo, calcolando come tempo di time-out di 20’=1200″ di una sessione server, vorrebbe dire che dopo 20′ di crawlata ogni istante ci sarebbero allocati 1200x5x7MB = 41 GB. Sarebbero più di 40 GB di RAM allocata sul web server perché un crawler sta spulciando il tuo sito, e magari neanche l’hai autorizzato a farlo.

Nota: per questo motivo il crawler di Visual SEO Studio di default accetta i cookie di sessione, anche se permette di disabilitarli perché in alcuni casi i server si comporterebbero diversamente.

I 7 MB sono il minimo usato da Apache (Nginxcredo sia molto più efficiente), ma se poi chi ha fatto il programma lato server (il CMS, web app, store, quel che è) ha avuto la bella idea di allocare di più a ogni nuova sessione (giuro l’ho visto fare), il problema aumenta ancora di più!

Altre differenze: spoofing e REP

Altra caratteristica di Visual SEO Studio è il più stringente rispetto del Robots Exclusion protocol. Visual SEO Studio per esempio rispetta il crawl-delay fino a un max di 2s; certo, permette di ignorarlo, ma solo per siti per cui l’utente dimostra di avere permesso di amministrazione (elenco “Siti Amministrati”). Visual SEO Studio permette si di cambiare lo user-agent, ma anche qui solo per i siti amministrati. Idem nel permettere di ignorare il Robots.txt, solo per siti amministrati.

Alla base della scelta sono diversi fattori:

Etici: stiamo consumando risorse non nostre senza dare nulla in cambio (nel caso di crawl di sito concorrente o di potenziale cliente).
Screaming Frog non si fa problemi, dice “responsabilità vostra” per qualsiasi cosa. Per noi l’etica conta, e poi se qualcuno si indispettisce e manda avvocato, vaglielo a spiegare a un giudice; vogliamo anche tutelarci con problemi legali… Vedi punto successivo.

Legali: in giro per il mondo vi sono già sentenze, sebbene pochissime, legate al mondo dei crawler. Mia previsione è che diverranno più frequenti. Non possiamo rischiare di affossarci in battaglie legali con costi e tempi assurdi. La possibilità di permettere tutto a chi dimostra di amministrare il web server è la soluzione più sicura, purtroppo molti utenti non hanno chiaro il vantaggio di censire i siti tra i siti amministrati, e se malauguratamente hanno un crawl-delay, ci percepiscono come strumento molto lento anche se potrebbero andare più veloce.

Business: avendo scelto di non permettere spoofing di user-agent (NdR: cambiare user-agent) per siti non nostri, qualunque altro sgarro al REP (es: se permettessimo di bypassare il robots.txt per siti non amministrati), oltre a rendere inutile le nostre scelte, dopo un po’ ci creerebbero una brutta reputazione tra i sistemisti che cercherebbero di bloccare “Pigafetta” (così si chiama l’User Agent di Visual SEO Studio), con danno per le nostre future vendite.

Servizi come Majestic, aHref, etc.. rispettano il REP (Moz invece per parecchio fece il furbetto i primi tempi quando era SEOMoz), se non lo facessero sarebbero molto più bloccati (Majestic ha crawler distribuiti, non da un intervallo fisso di IP, eppure sono i più rigorosi). Screaming Frog non ha questo problema perché i propri utenti possono sempre fare spoofing e chissenefrega. Sono scelte (vedi punti precedenti).

Altro aneddoto: oggi il crawl-delay di siti non amministrati è rispettato fino a un massimo di 2sec, ma una volta era 10″ il limite, e c’era pure un baco per cui in alcuni casi il limite massimo non era applicato. Una volta ricevo un messaggio da un utente, spedito tramite il software (menu help, invia messaggio all’autore); in quei casi mi arriva una mail, e se l’utente specifica un indirizzo e-mail posso capire chi è e rispondergli. L’utente era un SEO d’oltreoceano piuttosto noto; avevamo già avuto cortesi scambi e-mail in privato per altri motivi, ma non sapeva ci fossi io dietro Visual SEO. In questo frangente invece mi riempì di insulti perché il crawler era troppo lento. Non mi rispose mai alla mia richiesta di chiarimento, non so se fosse incappato nel bug o si fosse comunque preso un crawl-delay di 10″, l’unica cosa che scoprii è che nella realtà è uno str..o. Anche fosse stato il software peggiore del mondo, non l’aveva mica pagato, e mai mi rispose.

Sulle versioni per altri sistemi operativi

Come ben sai, Visual SEO oggi è solo per Windows, mentre Screaming Frog ha versioni per Windows, Mac e Unix. Vorrei avere un euro per ogni volta m’hanno chiesto se c’è la versione per Mac. Non è solo un problema di una minore fetta di utenti raggiungibili, per esempio A.S. (NdR: nota SEO internazionale) quando l’ho conosciuta m’avrebbe visionato il prodotto volentieri, però lei è solo utente Mac! Una grande opportunità mancata!

I programmi realizzati in Java sono molto più portabili: i runtime Java da anni sono distribuiti per tutte le piattaforme. Magari il look’n’feel è orrido, ma fare il porting è molto più agevole, ha costi di sviluppo molto inferiori.

.net è nato copiando il più possibile Java, ed è fatto su un runtime – un processore virtuale – proprio come Java, però Microsoft per anni non ha mai investito per portarlo su altre architetture. Alcuni ci hanno provato, e il tentativo che ha avuto più successo si chiama Mono, una versione di .net che gira su Linux e Mac. Da meno di un anno poi Microsoft stessa sta investendo per portare la piattaforma anche su altre architetture (in parte in partnership proprio con Mono).

Questo per dire che il porting su Mac di Visual SEO è possibile, con qualche sacrificio. Abbiamo sempre scelto di usare componenti che ostacolassero il meno possibile il porting (con eccezione per la parte di screenshot, che usa una versione incapsulata di IE, che comunque vogliamo cambiare). Il porting su Mono è ancora embrionale, abbiamo provato timidamente alcune parti, poi abbiamo sospeso per seguire altre priorità. Nei prossimi mesi ci riproveremo, facendoci aiutare da una risorsa esterna.

Non ho idea di quanto una versione Mac ci espanderà nel reach di potenziali clienti. C’è chi insiste a dire che nel mondo SEO / Web Marketing, il Mac copre più del 50% di share. Non ho mai trovato una statistica credibile per nicchia. Se devo dare retta a questo dato (e sembra attendibile), nel mondo desktop (non limitato alla nicchia SEO/WM) Windows ha ancora il dominio assoluto e Mac meno del 10%. Sapere la percentuale per nicchia mi aiuterebbe a stimare meglio quanto budget allocare per il porting (magari chiederò ad Andrea Pernici se mi guarda in Analytics del Forum GT). Un porting su Mono permetterebbe di avere una versione Mac e una Linux; sinceramente al momento mi interessa più la versione Mac, la Linux sarebbe almeno all’inizio un onere di manutenzione a fronte di pochi utenti in più.