Foto por Ludovic Charlet no Unsplash
O Rocket Validator é um web crawler distribuído capaz de percorrer os seus sites de grande dimensão, encontrando milhares de páginas web e verificando cada uma com o validador HTML do W3C e o validador de acessibilidade Axe Core, mediante a sua solicitação.
Com grande poder vem grande responsabilidade, por isso, como todos os web crawlers, o Rocket Validator trabalha sempre dentro dos limites que você define:
- Número máximo de páginas web a incluir no relatório. Você pode decidir quantas páginas web deseja validar: tipicamente começará com um número pequeno, digamos 100 páginas web, mas isto pode ser qualquer valor de 1 a 5.000.
- O que verificar em cada página web. Você decide se quer verificar HTML usando o Validador W3C, acessibilidade usando o Axe Core, ou ambos em cada página web encontrada pelo crawler.
- Velocidade de validação. Define um limite no número de pedidos por segundo que podemos fazer em seu nome. Isto vai desde um mínimo de 1 até um máximo de 15, dependendo do seu nível de subscrição.
Estes três fatores combinados vão determinar como o seu site é analisado pelo Rocket Validator, e também quanto tempo um relatório vai demorar para ser concluído. Mas primeiro, vamos compreender o que acontece quando você submete um relatório de validação de site.
Digamos que está a executar um relatório de site, verificando tanto HTML quanto acessibilidade em cada página web encontrada, e define um limite de taxa de 1 pedido/segundo.
Neste caso, quando cada página web é validada, vai receber até 3 pedidos:
- Uma visita do crawler para obter mais links dela (até que o máximo de páginas seja atingido).
- Uma visita do validador HTML.
- Uma visita do validador de acessibilidade.
Configurar o relatório para executar a 1 pedido por segundo significa que cada página web precisará de 3 segundos para que as suas validações comecem. Isso são 20 páginas web por minuto, ou 1.200 páginas web por hora. Então, para 5.000 páginas, precisará de mais de 4 horas para que todas as validações e rastreamento comecem. Veja abaixo as tabelas de comparação com mais cenários.
Usar sitemaps XML ou de texto para saltar o rastreamento
O Rocket Validator encontrará automaticamente as páginas web internas de um site a partir de um URL inicial, que pode ser qualquer URL do seu site, tipicamente a página inicial, graças à nossa funcionalidade de Deep Crawling. Isto torna mais fácil para você, mas também significa que vamos precisar de solicitar mais páginas web, para descobrir as páginas web internas.
Uma boa forma de acelerar significativamente a validação de site é usar sitemaps XML ou de texto. Se você conseguir fornecer uma lista das páginas web exatas que deseja validar, o Rocket Validator pode então saltar todo o processo de rastreamento, pois não precisamos descobrir as páginas web visitando todas as outras.
Saltar o rastreamento significa que apenas 2 pedidos por página são necessários (validação HTML e de acessibilidade), então são 2 segundos por página em vez de 3, o que equivale a 30 páginas por minuto, 1.800 páginas web por hora. Então, para 5.000 páginas, precisaria de menos de 3 horas para todas as validações começarem.
Mesmo que não tenha uma lista exaustiva de todas as suas páginas web, um sitemap ajuda sempre o crawler ao dar-lhe uma lista de URLs para incluir. O resto, se necessário, pode ser encontrado através de deep crawling.
Vamos fazer alguns cálculos
Com estas ideias em mente, vamos fazer alguns cálculos para ver como os diferentes fatores afetam o tempo de execução do relatório.
HTML + Acessibilidade + Deep Crawling, limitado a 1 pedido/segundo
Neste primeiro cenário, deixamos o deep crawler descobrir as páginas web internas visitando cada uma em busca de links, e realizamos verificações tanto de HTML quanto de acessibilidade em cada página web encontrada, à taxa mais lenta de 1 req/seg. Isto precisará de 3 pedidos por página, então a essa velocidade de validação isto significa 3 segundos por página.
| Páginas web | Total de pedidos | Tempo para iniciar todas as validações |
|---|---|---|
| 100 | 300 | 5 minutos |
| 250 | 750 | 12 minutos |
| 1.000 | 3.000 | 50 minutos |
| 3.000 | 9.000 | 2 horas, 30 minutos |
| 5.000 | 15.000 | 4 horas, 10 minutos |
HTML + Acessibilidade + Deep Crawling, limitado a 3 pedidos/segundo
Neste segundo cenário, aumentamos o limite de taxa para 3 pedidos/segundo. Continuamos a usar deep crawling e a validar tanto HTML quanto acessibilidade em cada página web, então ainda leva 3 pedidos por página, mas como estamos a executar a 3x velocidade, leva 1/3 do tempo anterior, ou seja, 1 segundo por página.
| Páginas web | Total de pedidos | Tempo para iniciar todas as validações |
|---|---|---|
| 100 | 300 | 1 minuto 40 segundos |
| 250 | 750 | 4 minutos |
| 1.000 | 3.000 | 16 minutos |
| 3.000 | 9.000 | 50 minutos |
| 5.000 | 15.000 | 1 hora, 23 minutos |
HTML + Acessibilidade, limitado a 3 pedidos/segundo, saltando o rastreamento
Neste terceiro cenário, mantemos o limite de taxa de 3 reqs/seg, e validamos tanto HTML quanto acessibilidade em cada página web, mas desativamos o deep crawling e fornecemos um sitemap XML com todos os URLs, então apenas leva 2 pedidos por página. Isso significa que estamos fazendo 2/3 dos pedidos do cenário anterior, o que reduz drasticamente o tempo necessário para concluir o relatório de validação.
| Páginas web | Total de pedidos | Tempo para iniciar todas as validações |
|---|---|---|
| 100 | 200 | 1 minuto |
| 250 | 500 | 2 minutos |
| 1.000 | 2.000 | 11 minutos |
| 3.000 | 6.000 | 33 minutos |
| 5.000 | 10.000 | 55 minutos |
Efeitos do limite de taxa em relatórios semelhantes
Neste cenário final, brincamos com o efeito de definir um limite de taxa mais alto no mesmo tipo de relatório (sem deep crawling, verificações HTML e A11Y, 2 reqs/página).
| Páginas web | Limite de taxa | Tempo para iniciar todas as validações |
|---|---|---|
| 1.000 | 1 req/seg | 33 minutos |
| 1.000 | 3 reqs/seg | 11 minutos |
| 1.000 | 5 reqs/seg | 6 minutos |
| 1.000 | 10 reqs/seg | 3 minutos |
| 1.000 | 15 reqs/seg | 2 minutos |
Algumas reflexões finais
Os cálculos acima dão apenas uma estimativa muito aproximada de como as configurações que você define num relatório de validação afetam o tempo necessário para executar um relatório de validação de site. Na prática, há mais fatores a ter em conta.
Estes cálculos levam em consideração quando as validações das páginas web irão começar, mas não quanto tempo levam para ser concluídas. Isto depende de outros fatores:
- Quão rapidamente o seu servidor pode responder aos nossos pedidos.
- Complexidade das páginas sendo validadas. Páginas web simples validarão mais rapidamente, enquanto páginas web com DOMs complexos, tamanho grande ou muitos problemas levarão mais tempo para processar.
- Erros de rede ou proteção DoS podem afetar a validação. Nestes casos, os nossos crawlers de validação tentarão novamente mais tarde.
Você encontrará o ponto ideal dependendo do seu caso de uso. O nosso fluxo de trabalho recomendado ao trabalhar com um site novo é:
- Primeiro, execute um relatório grande cobrindo verificações tanto de HTML quanto de Acessibilidade, a 3 pedidos/segundo. Isto dar-lhe-á uma visão geral dos principais problemas no site.
- Depois disso, trabalhe em pequenos incrementos em secções do site. Talvez foque primeiro em corrigir os problemas de HTML, e depois passe para os problemas de acessibilidade.
- Para manutenção, configure um cronograma de validação mensal ou semanal para ter o seu site validado periodicamente, assim será avisado se novos problemas forem encontrados.
Para a maioria dos casos, uma velocidade de validação de 3 a 5 pedidos/segundo é suficiente para obter resultados rapidamente sem sobrecarregar os servidores.
Esperamos que isto ajude a otimizar o seu fluxo de trabalho de validação!
Sinta-se à vontade para nos contactar se quiser partilhar as suas dicas de validação!