Siti grandi

Il formato NDJSON, il diario di ripresa, le modalità elenco e sitemap, il benchmark a 200 000 pagine e le protezioni del crawl aggiunte dalla 3.16 alla 3.21.

Cosa è stato misurato

Le versioni dalla 3.16 alla 3.21 hanno formato un programma di scalabilità in sei passi, ognuno misurato su un sito sintetico generato localmente da bench/site.mjs (N pagine generate al volo, circa 60 link di template e 40 link deterministici per pagina, 404, reindirizzamenti, quasi duplicati; nessun sito reale viene mai contattato).

Misurato con npm run bench -- --pages 200000 su un sito sintetico locale generato da bench/site.mjs (nessun sito reale viene contattato). I tuoi valori dipendono dalla tua macchina, dal sito e dalle opzioni (il rendering JavaScript è molto più lento).

Il budget predefinito è volutamente basso. Alza Opzioni → Limiti → Totale del crawl per un sito grande, mantieni da 2 a 5 thread su un server di un cliente, e ricorda che il rendering JavaScript è molto più lento dell’HTML grezzo.

I sei passi

1. 3.16, niente più crash alla fine: un Math.min(...) su un valore per URL sollevava Maximum call stack size exceeded oltre circa 125 000 URL, dopo ore di crawl; quattordici piccole correzioni lo hanno eliminato insieme ai cicli quadratici (job di correzione, esempi per l’IA, link verso reindirizzamenti, URL più vicino per i 404, ordinamento delle tabelle, conteggio delle cartelle). I file dei crawl vengono scritti in modo atomico (file temporaneo e poi rinomina).
2. 3.17, un grafo dei link compatto: i link vivono in colonne di array tipizzati (URL e testi di ancoraggio memorizzati una volta sola, 14 byte per link) e l’analisi lavora su un grafo CSR. Misurato su 50 000 pagine × 100 link: memoria dei link 690 MB → 55 MB, analisi 29 s / 2,5 GB → 5,5 s / 647 MB, risultati identici.
3. 3.18, un crawl scritto man mano: i risultati sono salvati in NDJSON gzip (.jsonl.gz, un oggetto JSON per riga, i link a blocchi), scritti e letti in streaming; la cronologia legge solo la prima riga. Un diario di ripresa registra ogni URL messo in coda e ogni pagina completata; --resume (o la schermata iniziale) riprende un crawl interrotto da dove si era fermato. I vecchi crawl .json si aprono ancora.
4. 3.19, un’analisi che scala: tutte le pagine vengono confrontate per i quasi duplicati (il vecchio controllo si fermava a 5 000 pagine senza dirlo) con una ricerca esatta per bande sul simhash a 64 bit; la cannibalizzazione si calcola in tempo lineare; i contatori di link dei segmenti sono calcolati in un solo passaggio.
5. 3.20, il browser non riceve mai l’intero crawl: il server conserva il crawl e il suo grafo; il browser riceve un risultato leggero in streaming e chiede il resto su richiesta (i link di una pagina paginati a 200, la scheda completa della pagina al clic, gli archi della mappa solo per i nodi mostrati, il confronto calcolato lato server). Importazione ed esportazione passano per il server.
6. 3.21, protezioni del crawl: il budget di pagine conta le pagine effettivamente scaricate; i parametri URL sono ordinati e quelli di tracciamento rimossi per impostazione predefinita; le trappole a faccette vengono segnalate; un robots.txt irraggiungibile vieta tutto come richiede la RFC 9309, con una via d’uscita esplicita; i 5xx e le interruzioni di rete ricevono un nuovo tentativo differito; i corpi delle risposte sono limitati; un Chrome che muore viene riavviato e segnalato; una regex impazzita viene interrotta in un worker; la modalità elenco sale a 500 000 URL e --sitemap scansiona esattamente una sitemap.

Formati

• Crawl salvato (.jsonl.gz): la riga 1 è l’intestazione (meta e riepilogo), poi una riga per problema, una per pagina, URL, anchor e link a blocchi di 100 000 (a colonne), poi immagini, link esterni, reindirizzamenti, link rotti. Nessuna riga supera pochi megabyte, qualunque sia il sito.
• Diario di ripresa (.ndjson, solo in aggiunta): una riga start (URL, opzioni), una riga q per ogni URL messo in coda, una riga p per ogni pagina elaborata con i suoi link e le sue immagini. Un arresto brutale perde solo gli ultimi secondi.
• Segmenti modificati dopo il crawl vanno in un piccolo file a fianco <name>.segments.json; il crawl non viene mai riscritto.
• Le vecchie esportazioni .json (formato 1 e 2) vengono rilevate e si aprono ancora.

Modalità elenco e sitemap

La modalità elenco scansiona esattamente gli URL che fornisci (incollati nell’app, --list file.txt nella CLI, urls per gli agenti), fino a 500 000, senza seguire i link; il linking interno è allora non misurato. La modalità sitemap (--sitemap URL, sitemapUrl, sitemap_url) legge una sitemap o un indice di sitemap e scansiona esattamente i suoi URL, deduplicati e normalizzati. In entrambe le modalità il robots.txt viene letto una volta per host.

Protezioni da conoscere

• Budget: maxPages conta le pagine scaricate; gli URL bloccati da robots.txt vengono registrati ma non lo consumano. La scoperta resta limitata in memoria (4 × il budget).
• Parametri: ?a=1&b=2 e ?b=2&a=1 sono una sola pagina; utm_*, gclid, fbclid, msclkid, mc_cid, srsltid, _ga… vengono rimossi. --keep-params ripristina il comportamento grezzo.
• Faccette: un percorso che produce 200 varianti di parametri viene segnalato una sola volta (fino a 20 percorsi).
• robots.txt in 5xx o irraggiungibile: tutto è vietato, con un avviso; --robots-unavailable allow o la modalità segnala / ignora lasciano passare il crawl.
• Rendering: Chrome riavviato ogni 500 pagine renderizzate e una volta se muore; una seconda morte viene segnalata invece di lasciare pagine non renderizzate in silenzio.
• Risposte: corpi letti in streaming e abbandonati oltre maxPageSizeKb; sitemap e robots.txt limitati da maxSitemapKb (50 MB).
• Sicurezza: gli header personalizzati non vengono più memorizzati nel browser, come la password HTTP.

Limiti noti

Gli elenchi di URL dei problemi viaggiano ancora per intero verso il browser (la pagina dei problemi, il motore di correzione, i segmenti e il colore della mappa per problema); paginarli è il prossimo perfezionamento, non necessario sotto le 200 000 pagine. Aprire un file dal pulsante Importa lo carica sul server, che conserva l’intero crawl in memoria, come dopo un crawl. Riproduci tu stesso il benchmark con npm run bench -- --pages 200000 (richiede circa 8 GB di heap, impostati dallo script).