Sites grandes

O formato NDJSON, o diário de retoma, os modos lista e sitemap, o benchmark de 200 000 páginas e as salvaguardas de rastreio adicionadas da 3.16 à 3.21.

O que foi medido

As versões 3.16 a 3.21 formaram um programa de escala em seis passos, cada um medido num site sintético gerado localmente por bench/site.mjs (N páginas geradas na hora, cerca de 60 links de modelo e 40 links deterministas por página, 404, redirecionamentos, quase duplicados; nenhum site real é alguma vez contactado).

Medido com npm run bench -- --pages 200000 num site sintético local gerado por bench/site.mjs (nenhum site real é contactado). Os seus números dependem da sua máquina, do site e das opções (a renderização JavaScript é muito mais lenta).

O orçamento por predefinição é deliberadamente baixo. Aumente Opções → Limites → Total de rastreio para um site grande, mantenha 2 a 5 threads num servidor de cliente, e lembre-se de que a renderização JavaScript é muito mais lenta do que o HTML bruto.

Os seis passos

1. 3.16, sem mais falhas no fim: um Math.min(...) sobre um valor por URL provocava Maximum call stack size exceeded além de cerca de 125 000 URLs, após horas de rastreio; catorze pequenas correções eliminaram-no, bem como os ciclos quadráticos (tarefas de correção, exemplos para a IA, links para redirecionamentos, URL mais próximo para os 404, ordenação das tabelas, contagem das pastas). Os ficheiros de rastreio são escritos de forma atómica (ficheiro temporário e depois renomeação).
2. 3.17, um grafo de links compacto: os links vivem em colunas de arrays tipados (URLs e textos de âncora guardados uma vez, 14 bytes por link) e a análise corre sobre um grafo CSR. Medido em 50 000 páginas × 100 links: armazenamento dos links 690 MB → 55 MB, análise 29 s / 2,5 GB → 5,5 s / 647 MB, resultados idênticos.
3. 3.18, um rastreio escrito à medida que avança: os resultados são gravados em NDJSON gzip (.jsonl.gz, um objeto JSON por linha, links por lotes), escritos e lidos em fluxo; o histórico lê apenas a primeira linha. Um diário de retoma regista cada URL em fila e cada página feita; --resume (ou o ecrã inicial) retoma um rastreio interrompido onde parou. Os antigos rastreios .json continuam a abrir.
4. 3.19, uma análise que escala: todas as páginas são comparadas para quase duplicados (a antiga verificação parava nas 5 000 páginas sem o dizer) com uma pesquisa exata por bandas sobre o simhash de 64 bits; a canibalização corre em tempo linear; os contadores de links dos segmentos são calculados numa única passagem.
5. 3.20, o navegador nunca recebe o rastreio inteiro: o servidor conserva o rastreio e o seu grafo; o navegador recebe um resultado leve em fluxo e pede o resto a pedido (os links de uma página paginados por 200, a ficha completa da página ao clicar, as arestas do mapa só para os nós mostrados, a comparação calculada no servidor). A importação e a exportação passam pelo servidor.
6. 3.21, salvaguardas de rastreio: o orçamento de páginas conta as páginas realmente descarregadas; os parâmetros de URL são ordenados e os parâmetros de acompanhamento removidos por predefinição; as armadilhas de facetas são assinaladas; um robots.txt inacessível proíbe tudo como exige a RFC 9309, com uma saída explícita; os 5xx e os cortes de rede têm uma nova tentativa diferida; os corpos das respostas são limitados; um Chrome que morre é reiniciado e assinalado; uma regex descontrolada é interrompida num worker; o modo lista sobe a 500 000 URLs e --sitemap rastreia exatamente um sitemap.

Formatos

• Rastreio guardado (.jsonl.gz): a linha 1 é o cabeçalho (meta e resumo), depois uma linha por problema, uma por página, URLs, âncoras e links por lotes de 100 000 (em colunas), depois imagens, links externos, redirecionamentos, links quebrados. Nenhuma linha ultrapassa alguns megabytes, seja qual for o site.
• Diário de retoma (.ndjson, apenas acrescentos): uma linha start (URL, opções), uma linha q por URL em fila, uma linha p por página processada com os seus links e imagens. Uma paragem brutal perde apenas os últimos segundos.
• Os segmentos editados depois do rastreio vão para um pequeno ficheiro ao lado, <nome>.segments.json; o rastreio nunca é reescrito.
• As antigas exportações .json (formatos 1 e 2) são detetadas e continuam a abrir.

Modos lista e sitemap

O modo Lista rastreia exatamente os URLs que lhe dá (colados na aplicação, --list file.txt na CLI, urls para os agentes), até 500 000, sem seguir os links; a ligação interna fica então não medida. O modo Sitemap (--sitemap URL, sitemapUrl, sitemap_url) lê um sitemap ou um índice de sitemaps e rastreia exatamente os seus URLs, sem duplicados e normalizados. Em ambos os modos, o robots.txt é lido uma vez por anfitrião.

Salvaguardas a conhecer

• Orçamento: maxPages conta as páginas descarregadas; os URLs bloqueados pelo robots.txt são registados mas não o consomem. A descoberta fica limitada em memória (4 × o orçamento).
• Parâmetros: ?a=1&b=2 e ?b=2&a=1 são uma única página; utm_*, gclid, fbclid, msclkid, mc_cid, srsltid, _ga… são removidos. --keep-params repõe o comportamento bruto.
• Facetas: um caminho que produz 200 variantes de parâmetros é assinalado uma vez (até 20 caminhos).
• robots.txt em 5xx ou inacessível: tudo é proibido, com um aviso; --robots-unavailable allow ou o modo assinalar / ignorar deixam o rastreio passar.
• Renderização: Chrome reiniciado a cada 500 páginas renderizadas e uma vez se morrer; uma segunda morte é assinalada em vez de páginas não renderizadas em silêncio.
• Respostas: corpos lidos em fluxo e abandonados além de maxPageSizeKb; sitemaps e robots.txt limitados por maxSitemapKb (50 MB).
• Segurança: os cabeçalhos personalizados já não são memorizados no navegador, tal como a palavra-passe HTTP.

Lacunas conhecidas

As listas de URLs dos problemas ainda viajam inteiras até ao navegador (a página de problemas, o motor de correções, os segmentos e a cor do mapa por problema); paginá-las é o próximo refinamento, desnecessário abaixo de 200 000 páginas. Abrir um ficheiro a partir do botão Importar carrega-o para o servidor, que conserva o rastreio inteiro em memória, tal como depois de um rastreio. Reproduza o benchmark você mesmo com npm run bench -- --pages 200000 (precisa de cerca de 8 GB de heap, definidos pelo script).