Velocidade vs. Precisão no OCR: A Troca Que Nenhum Fornecedor Explica

Todo fornecedor de OCR diz que sua ferramenta é "rápida" e "precisa" — como se as duas qualidades existissem no mesmo eixo e você ganhasse ambas automaticamente. A realidade é o oposto: velocidade e precisão estão em tensão direta em todo pipeline de OCR, desde uma biblioteca open-source gratuita rodando em um notebook até uma API na nuvem apoiada por milhares de GPUs. Uma instância do Tesseract configurada para máxima velocidade processa uma página em 0,16 segundos, mas erra 1 em cada 8 palavras. Um modelo de IA de visão que lê a mesma página com precisão quase perfeita leva de 30 a 60 vezes mais. Qual é o certo para o seu fluxo de trabalho? A resposta depende do que você está processando, do que está construindo e do que um único dígito errado custa para você. A maioria dos fornecedores pula essa pergunta porque a resposta honesta — "depende" — não cabe em uma tabela comparativa.

Por Que Velocidade e Precisão São Inversamente Proporcionais

A relação de compromisso entre velocidade e precisão não é uma limitação de nenhuma ferramenta específica — é uma consequência de como o OCR funciona em nível arquitetural. Todo sistema de OCR, seja um mecanismo legado de correspondência de padrões ou um modelo moderno de linguagem visual, segue uma sequência de etapas: pré-processamento de imagem, detecção de texto, reconhecimento de caracteres e pós-processamento. Cada etapa consome recursos computacionais, e quanto mais minuciosamente cada etapa é executada, mais preciso é o resultado — e mais tempo leva.

Profundidade do pré-processamento. Um pipeline de OCR otimizado para velocidade pula ou minimiza o pré-processamento: ele reduz a amostragem da imagem para diminuir a contagem de pixels, aplica um limiar de binarização simples e passa o resultado diretamente para o reconhecedor. Benchmarks independentes mostram que pular etapas de pré-processamento como correção de inclinação, remoção de ruído e realce de contraste pode reduzir o tempo de processamento em 40–60% — mas também reduz a precisão em 10–20 pontos percentuais em entradas imperfeitas. A recomendação padrão na literatura de OCR — mínimo de 300 DPI, binarização adaptativa, correção geométrica — é em si um compromisso entre velocidade e precisão. A 300 DPI, um caractere de 10pt abrange aproximadamente 42 pixels, dando ao reconhecedor resolução suficiente para distinguir traços finos. Abaixo de 150 DPI, a precisão cai drasticamente para todos os mecanismos testados. Acima de 300 DPI, os ganhos de precisão se estabilizam enquanto o tamanho do arquivo e o tempo de processamento continuam aumentando.

Complexidade do modelo. É aqui que a relação de compromisso se torna mais visível. O mecanismo legado do Tesseract usa extração de características artesanais — ele corresponde formas de caracteres a uma biblioteca de modelos usando classificadores pré-computados. Isso é rápido (0,1–0,3 segundos por página em uma CPU moderna), mas frágil: a precisão em entradas desafiadoras, como fotos de celular, cai para aproximadamente 70–80%. O mecanismo LSTM do Tesseract 4 adiciona uma camada de rede neural que lê caracteres em contexto sequencial, melhorando a precisão em 5–15 pontos percentuais em documentos ruidosos, enquanto aproximadamente dobra o tempo de processamento. Mecanismos modernos de OCR de aprendizado profundo, como PaddleOCR e EasyOCR, substituem todo o pipeline por redes neurais — detecção de texto baseada em CNN seguida por reconhecimento de sequência baseado em atenção. Esses modelos alcançam precisão substancialmente maior (especialmente em layouts complexos e manuscritos), mas exigem de 3 a 30 vezes mais computação por página. Um benchmark de março de 2026 da Codesota mediu o seguinte em uma única fatura: Tesseract 5.5 em 0,162 segundos com 87,5% de precisão, EasyOCR em 0,656 segundos com 62,5% de precisão e PaddleOCR em 4,85 segundos com 100% de precisão. A correlação não é perfeita — o PaddleOCR dominou neste teste específico — mas o padrão entre os tipos de documento é claro: quanto mais profundo o modelo, mais lento e mais preciso ele tende a ser.

Cadeia de pós-processamento. Pipelines otimizados para precisão adicionam etapas de validação após o reconhecimento: correção ortográfica baseada em dicionário, verificações de consistência entre campos (o total da fatura corresponde à soma dos itens de linha?), validação de formato (a data é analisada corretamente?) e limiarização de pontuação de confiança com roteamento humano no circuito. Cada etapa adiciona latência. Um OCR básico que gera texto bruto em 0,2 segundos pode exigir de 2 a 3 segundos adicionais de pós-processamento para atingir precisão de nível de produção. A latência total do sistema — não apenas a etapa de reconhecimento — é o que determina a taxa de transferência no mundo real.

O Panorama de Velocidade: Como São os Números na Prática

A velocidade bruta de processamento varia em duas ordens de grandeza, dependendo do mecanismo de OCR, hardware e complexidade do documento. A tabela abaixo consolida benchmarks publicados de múltiplas fontes independentes em faixas que refletem condições reais de produção — e não os melhores cenários selecionados.

Mecanismo / API	Velocidade (por página, CPU)	Velocidade (GPU)	Precisão (impresso limpo)	Precisão (desafiador)
Tesseract 5.5 (modo legado)	0,1–0,3s	N/D (somente CPU)	90–96%	50–70%
Tesseract 5.5 (modo LSTM)	0,3–0,8s	N/D (somente CPU)	93–97%	60–80%
EasyOCR	0,6–2,5s	0,2–0,8s	90–95%	55–75%
Google Cloud Vision OCR	1–3s (API)	—	96–99%	75–85%
AWS Textract	2–4s (API)	—	95–98%	78–85%
Azure Document Intelligence	3–5s (API)	—	96–99%	80–88%
PaddleOCR	3–6s	~0,5s (120 páginas/min)	95–99%	75–88%
Modelo de Visão-Linguagem (VLM)	5–15s	2–6s	96–99%	85–95%

Fontes: Codesota (março de 2026), AIMultiple DeltOCR Bench (janeiro de 2026), benchmark GigaGPU PaddleOCR, documentação oficial da AWS/Azure/Google. "Desafiador" inclui digitalizações de baixa resolução, fotos de celular e documentos com layouts mistos. A categoria VLM representa ferramentas como ImageToTable.ai e Qwen-VL.

A principal conclusão desses números: a relação entre velocidade e precisão não é uma curva suave. Ela tem pontos de inflexão. O Tesseract oferece velocidade, mas atinge um teto duro de precisão em documentos imperfeitos. As APIs em nuvem oferecem um teto mais alto com latência moderada. Os VLMs elevam o teto ao máximo, mas exigem mais tempo por página. Escolher entre eles significa saber em qual ponto de inflexão seus documentos e sua tolerância a erros o colocam.

A conclusão prática: O Tesseract processa uma fatura no tempo que um ser humano leva para piscar. Mas se essa fatura for a foto de um recibo amassado tirada por celular, a extração de 0,16 segundo pode ter uma taxa de erro de 20 a 30% — e corrigir esses erros no seu sistema contábil leva minutos por documento. A extração rápida cria um trabalho downstream lento.

Quando a Velocidade Importa Mais

Nem todo fluxo de trabalho com documentos exige perfeição em nível de campo. Vários cenários reais priorizam corretamente a taxa de transferência em detrimento da precisão em nível de caractere — e os fornecedores que comercializam apenas "99% de precisão" estão prejudicando seus usuários ao não reconhecerem esses casos.

Leitura em tempo real no ponto de venda. Um sistema de checkout de varejo que escaneia um recibo para consultar um preço ou validar uma troca precisa de uma resposta em menos de um segundo. Se o OCR ler incorretamente um caractere no nome de um produto, mas o sistema de estoque ainda encontrar o SKU correto por meio de correspondência aproximada, a transação é concluída sem interrupção. A velocidade é a restrição determinante; o sistema processa centenas de transações por hora e 3 segundos extras por leitura criariam uma fila no caixa. Para esses cenários, o modo legado do Tesseract ou uma API de nuvem leve com timeouts agressivos é a escolha correta — mesmo que isso signifique aceitar uma taxa de erro de caractere de 2–5%.

Triagem e roteamento de documentos. Muitos pipelines de processamento de documentos precisam classificar um documento recebido (é uma fatura, um pedido de compra ou um aviso de entrega?) antes de roteá-lo para o processador downstream correto. A etapa de classificação requer a extração de texto suficiente apenas para identificar o tipo de documento — normalmente o cabeçalho, título ou alguns campos-chave — não todos os caracteres da página. Uma passagem rápida de OCR que identifica corretamente 95% dos tipos de documento em 0,2 segundos por página é mais valiosa do que uma passagem lenta que identifica corretamente 98% em 5 segundos por página, porque os 3% classificados incorretamente podem ser capturados na etapa de revisão humana. O Google Cloud Vision OCR, com sua latência de 1 a 3 segundos e amplo suporte a idiomas, é uma escolha comum para essa camada de roteamento.

Arquivamento de alto volume com texto pesquisável. Quando o objetivo é tornar milhões de páginas pesquisáveis em um sistema de gerenciamento de documentos — em vez de extrair campos de dados específicos — o limite de precisão é menor. Um PDF pesquisável gerado pelo Tesseract com 90% de precisão de caractere ainda permite que os usuários encontrem a maioria dos documentos por meio de pesquisa por palavra-chave, porque um documento que contém "Fatura #12345" ainda será encontrado mesmo que o Tesseract leia "Fatura #1234S" em algumas páginas. A diferença de custo entre um pipeline de OCR rápido (milhares de páginas por hora em um único servidor) e um lento (centenas de páginas por hora) determina se o projeto de arquivamento é viável ou não.

OCR móvel em dispositivos com bateria limitada. Executar um modelo de OCR de aprendizado profundo em um smartphone ou scanner portátil exige equilibrar a precisão com o consumo de bateria e o aquecimento. O EasyOCR em um smartphone moderno leva aproximadamente 0,2–0,8 segundos por imagem quando acelerado por GPU, mas ao custo de um consumo significativo de energia. Para trabalhadores de campo que escaneiam centenas de etiquetas por turno, um modelo mais leve que sacrifica 5% de precisão para dobrar a vida útil da bateria é a escolha operacional correta.

Quando a Precisão é Essencial

Cada cenário acima compartilha uma característica: o custo de um único erro é baixo ou facilmente absorvido. Inverta essa premissa, e a troca se inverte completamente.

Documentos fiscais e financeiros. Um único dígito lido incorretamente em uma declaração de IVA, um campo salarial de um W-2 ou o total de uma fatura cria um problema em cascata. O total da fatura de R$ 1.500 que o OCR lê como R$ 15.000 desencadeia um erro de pagamento que exige reconciliação, contato com o fornecedor e, potencialmente, uma correção na declaração de imposto. Uma análise da Gennai em 2025 calculou que um sistema processando 500 faturas com 94% de precisão (30 faturas com erros) gerou 5 horas de trabalho de correção por lote, enquanto um sistema processando 400 faturas com 99% de precisão (4 com erros) gerou apenas 40 minutos de correção — apesar da taxa mais lenta por página. O sistema mais lento foi mais produtivo em termos de saída utilizável por hora. Para documentos fiscais especificamente, o IRS e a maioria das autoridades tributárias esperam 100% de precisão nos valores informados — não "quase certo". Um único erro de campo em uma declaração de imposto anual pode desencadear uma auditoria, multas e juros que superam em muito qualquer economia no custo de processamento.

Contratos legais e documentos de conformidade. A extração de dados de contratos para monitoramento de conformidade, resumo de arrendamentos ou arquivamentos regulatórios é o domínio onde a precisão é inegociável. Uma data de renovação de contrato com um mês de diferença, uma cláusula de indenização classificada incorretamente ou um limite de responsabilidade lido como R$ 500.000 em vez de R$ 5.000.000 cria uma exposição legal que nenhuma velocidade de processamento justifica. Para esses documentos, a abordagem correta é a extração otimizada para precisão com pontuação de confiança e revisão humana obrigatória de qualquer campo de baixa confiança. Modelos de linguagem visual — que leem o documento inteiro em contexto e podem interpretar a estrutura de cláusulas e relações semânticas — são cada vez mais o padrão aqui, mesmo a 10–15 segundos por página, porque o custo de um único erro de extração pode exceder todo o orçamento anual da ferramenta de extração.

Faturamento médico e dados de pacientes. A extração de documentos de saúde fica na interseção dos requisitos de precisão e restrições regulatórias. Um código CPT lido incorretamente em um formulário de reivindicação CMS-1500 pode resultar em negação da reivindicação, atraso no pagamento ou — no pior caso — um procedimento incorreto faturado ao registro do paciente. A conformidade com a HIPAA exige precisão e auditabilidade. O padrão na extração de documentos médicos é precisão em nível de campo acima de 98% com rastreabilidade total de cada valor extraído de volta à sua posição no documento de origem. A velocidade é secundária; uma reivindicação enviada incorretamente é mais cara do que uma reivindicação enviada com atraso.

Transações internacionais e com múltiplas moedas. Documentos que misturam moedas, convenções decimais e formatos numéricos são particularmente implacáveis com OCR otimizado para velocidade. Uma fatura europeia mostrando "€ 1.234,56" (1.234,56 EUR) processada por um sistema treinado em convenções decimais dos EUA pode ler o valor como € 1,23 — um erro de 1.000x. A queda de precisão em documentos multilíngues e multiformato é bem documentada, e corrigir esses erros específicos de formato requer um modelo treinado em formatos internacionais ou regras de validação de pós-processamento que adicionam latência. Neste domínio, a precisão deve vencer porque o custo de um erro de formato não é proporcional à taxa de erro de caractere — uma vírgula decimal mal colocada pode inviabilizar uma transação.

Regra prática: Se um humano leva mais de 30 segundos para revisar um único campo na sua saída, e você processa mais de 200 documentos por semana, otimize pela precisão — o tempo de revisão economizado com menos erros compensará a velocidade de extração mais lenta. Se o humano leva menos de 5 segundos para revisar o mesmo campo e os erros são imediatamente óbvios, otimize pela velocidade.

Um Guia Prático de Decisão

Em vez de perguntar "qual ferramenta OCR é melhor", faça estas três perguntas sobre seu fluxo de trabalho, em ordem:

Qual é o custo de um único erro de extração no seu fluxo de trabalho?

Se um único campo lido incorretamente custa mais de R$ 250 em correções, atrasos a jusante ou risco de conformidade, comece com um pipeline otimizado para precisão e aceite uma taxa de transferência mais lenta. Se os erros são detectados rapidamente e custam pouco para corrigir, um pipeline focado em velocidade é adequado.

Qual é a distribuição de qualidade dos seus documentos de entrada?

Se 90% dos seus documentos são PDFs limpos e impressos com fontes padrão — o Tesseract no modo LSTM a 0,3 segundos por página provavelmente é suficiente, e você só precisa lidar com os 10% restantes de casos extremos com um sistema de fallback mais lento e preciso. Se a maioria são fotos de celular de recibos térmicos amassados, comece com um modelo que lida bem com degradação — o que significa aceitar uma velocidade mais lenta por página.

Você precisa de extração estruturada de campos ou apenas de texto bruto?

Extrair campos específicos (total da fatura, número do pedido, CNPJ) de formatos arbitrários requer compreensão semântica — uma tarefa onde as vantagens de velocidade do OCR tradicional desaparecem, pois o pós-processamento necessário para identificar e validar campos adiciona latência independentemente da velocidade de reconhecimento. É aqui que ferramentas de extração baseadas em VLM e sem template, como o ImageToTable.ai, mudam a equação: elas eliminam a configuração e manutenção de templates que retardam pipelines tradicionais, tornando o processamento de 5 a 10 segundos por página mais rápido no tempo total do fluxo de trabalho.

Aplique este guia como um filtro: se a Pergunta 1 apontar para precisão e a Pergunta 2 confirmar que você tem qualidade de entrada heterogênea, pule as ferramentas focadas em velocidade e vá diretamente para uma plataforma projetada para precisão em documentos diversos. Se a Pergunta 1 apontar para velocidade e a Pergunta 2 confirmar entrada limpa e uniforme, um pipeline leve baseado em Tesseract ou uma API de nuvem rápida é a escolha correta. O erro que a maioria das equipes comete é não avaliar essas perguntas em ordem — elas comparam ferramentas pela velocidade primeiro, e depois descobrem que seus requisitos de precisão as forçam a reconstruir o pipeline.

Como Modelos de Visão-Linguagem Mudam a Equação

A relação velocidade-precisão descrita até agora se aplica a arquiteturas tradicionais de OCR — mecanismos que dividem a leitura de documentos em etapas sequenciais e independentes (detecção → reconhecimento → pós-processamento). Modelos de visão-linguagem (VLMs) abordam o problema de forma diferente: eles leem o documento como uma única cena visual, compreendendo layout, texto e relações entre campos em uma passagem integrada. A consequência prática é que VLMs não enfrentam a mesma curva de relação velocidade-precisão que o OCR tradicional.

Onde a precisão do Tesseract despenca em entradas desafiadoras (50–70% em manuscritos, por exemplo), a precisão de um VLM degrada gradualmente — de 96% em texto impresso limpo para 85–90% em manuscritos moderados e aproximadamente 75–80% no pior caso. Não há um abismo. Onde o EasyOCR requer aceleração por GPU para atingir velocidades aceitáveis em documentos complexos, um VLM rodando em CPU ainda pode produzir resultados utilizáveis — mais lento, mas sem a queda brusca de precisão que o OCR tradicional exibe quando o pré-processamento é ignorado.

Isso muda a estrutura de decisão. Com uma ferramenta baseada em VLM como ImageToTable.ai, a relação velocidade-precisão não é mais uma escolha binária entre "rápido e errado" ou "lento e certo". Em vez disso, o mesmo modelo atende a ambos os cenários: você pode processar uma única fatura em 5–10 segundos com precisão em nível de campo superior a 95%, ou processar 50 faturas em lote e revisar apenas as saídas de baixa confiança. A consistência do modelo entre diferentes qualidades de documento — a ausência de abismos de precisão — é o que torna isso possível. Você não está escolhendo entre dois mecanismos diferentes para triagem rápida e extração de alta precisão; você está escolhendo um mecanismo e ajustando o limite de revisão.

Para equipes avaliando soluções de OCR em 2026, a mudança importante é esta: a relação velocidade-precisão ainda é real, mas a curva se achatou. Ferramentas construídas com modelos de visão-linguagem oferecem um piso de precisão mais alto em todos os pontos de velocidade do que arquiteturas tradicionais de OCR conseguem igualar. A pergunta não é mais "quanta precisão estou disposto a trocar por velocidade?" mas "quanta latência meu pipeline pode tolerar para atingir a precisão que preciso?" — e a resposta, para a maioria dos fluxos de trabalho com documentos, é mais do que você imagina.

Perguntas Frequentes

P: Posso usar o Tesseract para extração de documentos em produção ou é muito impreciso?

Depende dos seus documentos e da sua tolerância a erros. Em PDFs limpos e impressos por máquina, com fontes padrão a 300 DPI, o Tesseract 5.5 em modo LSTM oferece 93–97% de precisão de caracteres — suficiente para muitos fluxos de trabalho internos onde um erro de digitação ocasional não é catastrófico. Em fotos de recibos tiradas com celular, cópias carbono digitalizadas ou documentos com escrita à mão, a precisão cai para 50–80%, o que provavelmente é muito baixo para uso em produção sem uma revisão manual significativa. Para uma comparação detalhada de ferramentas de código aberto, veja nosso guia de ferramentas OCR de código aberto.

P: Qual é mais rápido — AWS Textract ou Google Cloud Vision OCR?

Ambos normalmente processam uma única página em 2–4 segundos no modo síncrono, com o Google sendo ligeiramente mais rápido em documentos simples (1–3 segundos) e o Textract comparável em 2–4 segundos. No modo lote/assíncrono, ambos os serviços podem processar centenas de páginas por hora. A maior diferença não é a velocidade, mas o perfil de precisão: o Google Vision é excelente em documentos multilíngues e imagens ruidosas, enquanto o Textract tem extração de formulários e tabelas mais forte. Para uma comparação direta de APIs de OCR em nuvem, veja nosso guia Melhor API de OCR 2026.

P: Quanto mais lento é o modo "preciso" em comparação com o modo "rápido" na mesma ferramenta de OCR?

O modo LSTM do Tesseract é aproximadamente 2–5x mais lento que o modo legado no mesmo documento — 0,3–0,8 segundos por página contra 0,1–0,3 segundos. O modo "preciso" do ABBYY FineReader é cerca de 2–2,5x mais lento que o modo "rápido". O ganho de precisão é tipicamente de 5 a 10 pontos percentuais em documentos desafiadores. Alguns modos "super-precisos" de ferramentas executam vários mecanismos em paralelo e pegam o melhor resultado, multiplicando o tempo de processamento pelo número de mecanismos. A análise de retornos decrescentes da CVISION se aplica aqui: cada redução pela metade da taxa de erro requer aproximadamente 2x o tempo de processamento.

P: A aceleração por GPU elimina a troca entre velocidade e precisão?

Ela reduz significativamente a lacuna, mas não a elimina. O PaddleOCR em uma GPU RTX 3090 processa ~120 páginas por minuto — cerca de 5x mais rápido que sua velocidade na CPU e quase 5x a taxa de transferência do Tesseract apenas na CPU — mantendo a mesma precisão. A aceleração por GPU permite que as equipes executem modelos de OCR de aprendizado profundo em velocidades comparáveis a mecanismos leves, permitindo efetivamente que tenham velocidade e precisão. No entanto, o custo da GPU, a disponibilidade em ambientes de nuvem e o consumo de energia em dispositivos de borda continuam sendo restrições. Nem todo fluxo de trabalho tem uma GPU disponível.

P: Devo otimizar para velocidade ou precisão ao processar faturas de vários fornecedores com formatos diferentes?

Precisão. O principal desafio do processamento de faturas de múltiplos fornecedores não é a velocidade de leitura — é a variação de formato. Uma ferramenta OCR baseada em modelos que processa cada fatura em 0,5 segundos, mas exige um modelo separado para cada layout de fornecedor, gastará muito mais tempo total com manutenção de modelos do que com processamento real. Uma ferramenta sem modelos, baseada em VLM, que processa cada fatura em 5 a 10 segundos, mas lida com qualquer formato sem configuração, será mais rápida no tempo total do fluxo de trabalho — especialmente à medida que o número de fornecedores cresce. Nosso guia sobre o que a precisão do OCR realmente significa explica por que a precisão em nível de campo é mais importante que a velocidade em nível de caractere em fluxos de trabalho com múltiplos formatos.

P: Quando devo usar uma abordagem híbrida — OCR rápido para triagem e OCR preciso para extração?

Um pipeline híbrido faz sentido quando você tem uma distribuição bimodal de qualidade de documentos: um grande volume de documentos limpos e padronizados (onde uma passagem rápida é suficiente) misturado com um volume menor de documentos complexos ou degradados (onde o processamento otimizado para precisão é necessário). A triagem de documentos via Tesseract ou OCR leve em nuvem classifica cada documento recebido como "limpo" ou "desafiador", direcionando documentos limpos para um pipeline de extração rápida e os desafiadores para revisão por VLM ou humana. Este é um padrão comum em departamentos de AP empresariais que processam tanto faturas eletrônicas de grandes fornecedores quanto faturas em papel de pequenos fornecedores. O problema: a própria lógica de roteamento deve ser altamente precisa, caso contrário, documentos desafiadores passam pelo pipeline rápido e geram erros.

Faça a Troca Deliberadamente

A troca entre velocidade e precisão no OCR não é um problema a ser resolvido — é um parâmetro de design a ser definido deliberadamente. Para cada fluxo de processamento de documentos, existe um ponto de equilíbrio correto. O erro é deixar que as configurações padrão do fornecedor ou um único número de referência tomem a decisão por você.

A maioria das equipes supervaloriza a velocidade durante a avaliação porque a velocidade é fácil de medir (um número, uma execução, um cronômetro) e a precisão não é (varia por tipo de documento, qualidade, campo e definição de erro). O processo de avaliação honesto mede a precisão nos documentos reais que você processa — incluindo os bagunçados — e mede o tempo total do fluxo de trabalho, não apenas a latência do OCR. Esse total inclui o tempo gasto corrigindo erros, que é onde o OCR "rápido" perde sua vantagem.

Os modelos de linguagem visual achataram a curva de precisão, tornando a alta precisão acessível em velocidades toleráveis para a maioria dos fluxos de trabalho de documentos empresariais. Se a precisão é sua restrição — e para a maioria dos casos de uso de extração de documentos, deveria ser — uma ferramenta baseada em VLM que processa uma página em 5 a 10 segundos e oferece precisão em nível de campo acima de 95% é uma escolha melhor do que uma ferramenta que processa a mesma página em 0,2 segundos e deixa você verificando cada 5º valor.

Teste a troca em seus documentos reais. Veja como são 5 segundos por página quando os erros que costumavam levar minutos para encontrar simplesmente não estão mais lá.