Onde se gastam os milissegundos de uma pesquisa

Em resumo

• O orçamento útil de uma pesquisa que responde enquanto se escreve são os 100 ms que uma pessoa lê como resposta imediata, e o servidor só pode gastar uma parte deles.
• Numa medição de produção, a mediana do lado do servidor ficou nos 24 ms, e o motor de pesquisa foi menos de um terço disso.
• O que faz a diferença não é uma cache: é não fazer trabalho desnecessário em cada tecla.
• Uma cache de resultados rende menos do que se pensa, porque as pesquisas de uma loja têm cauda longa e o stock muda.
• O tempo que o visitante sente inclui rede e desenho no browser, e essa parte perde-se mais depressa do que se ganha no servidor.

Prometer «pesquisa instantânea» é fácil, e nós também o prometemos. O que interessa é o orçamento por trás da promessa: quantos milissegundos existem, em que é que são gastos, e o que se decide não fazer para os não gastar. Este artigo é essa contabilidade, sem marketing.

O orçamento não é uma escolha nossa. Vem de um limite conhecido desde 1993, quando Jakob Nielsen fixou os três limites do tempo de resposta: 0,1 segundo é o limite para uma pessoa sentir que o sistema reage instantaneamente. Uma pesquisa que responde enquanto se escreve tem de caber aí, e o servidor não é o único convidado à mesa: a rede e o desenho no browser também querem a parte deles.

O que medimos, e em que condições

Os números que se seguem não são de um teste sintético. Foram tirados de um servidor de produção a 9 de agosto de 2026, com 84 pedidos de pesquisa a uma loja PrestaShop nossa, e vêm do cabeçalho Server-Timing que o serviço envia em todos os pedidos, sem porta de acesso.

Antes de os ler, três ressalvas que mudam a interpretação:

• O catálogo era pequeno, com 19 produtos. É a parcela do motor de pesquisa que mais cresce com o tamanho do índice; as outras quase não se mexem.
• O servidor estava sem carga, com uma média de carga abaixo de 0,2 em quatro núcleos. Estes números são um piso, não uma promessa em hora de ponta.
• As marcas medem tempo de parede de cada operação, e muitas correm em paralelo de propósito. Por isso a soma das fatias é maior do que o total, e lê-se assim: uma fatia grande diz quanto se esperou por aquilo, não quanto aquilo atrasou a resposta.

O caminho de uma tecla até à resposta

Cada tecla escrita na caixa dispara o mesmo percurso:

1. O layer na loja espera um instante curto para não enviar um pedido por letra, e junta o que foi escrito entretanto.
2. O pedido chega ao nosso serviço, que identifica a loja pela chave pública e escolhe o índice certo (loja, língua e moeda).
3. A consulta é preparada: normalização do texto, sinónimos da loja, regras de merchandising ativas, filtros já escolhidos.
4. O motor de pesquisa responde com produtos, contagens por faceta e destaques.
5. A resposta é montada com os campos que aquele desenho de resultados precisa, e mais nenhum.

Não há passo nenhum aqui que seja opcional ou surpreendente. O tempo ganha-se dentro de cada um.

Onde se gastam os milissegundos

Duas linhas merecem explicação, e são as duas que surpreendem.

A do registo para analytics é a que costuma estragar sistemas destes. Gravar a pesquisa antes de responder acrescenta uma escrita ao caminho crítico, e uma base de dados com um mau minuto passa a ser uma pesquisa com um mau minuto para toda a gente. Aqueles 2,5 ms existem, são reais, e não são pagos pelo visitante: a escrita parte depois de a resposta seguir. É o exemplo mais claro daquela ressalva sobre fatias em paralelo.

A da segunda tentativa é a parcela que mais gente não espera encontrar. Quando a primeira pesquisa ia acabar em pouco ou nada, corre-se outra, mais tolerante, para não devolver um ecrã vazio a quem trocou uma letra. Custa quase tanto como a pesquisa principal, e é dinheiro bem gasto: o ecrã sem resultados é caro de outra maneira.

Repare no que a tabela não mostra: nenhum passo domina. Não há um gargalo a atacar, e é por isso que a única forma de descer daqui é tirar trabalho, não otimizar um sítio.

Prós e contras de uma cache de resultados

A pergunta aparece sempre: porque não guardar as respostas mais pedidas? Guardamos algumas coisas, mas não os resultados de pesquisa, e vale a pena explicar o raciocínio.

A terceira linha da coluna esquerda é a mais perigosa, porque uma cache melhora as médias sem melhorar a experiência de quem escreveu uma coisa rara, que é precisamente quem mais precisa de uma boa pesquisa.

O que fazemos em vez disso é manter em memória o que muda pouco (configuração da loja, sinónimos, regras) e não repetir trabalho por pedido. O ganho é parecido e não há nada para invalidar.

O que o visitante sente

Aqueles 24 ms são a nossa parte, e são a mais fácil das três. O que a pessoa sente inclui mais duas:

• A rede. Um pedido de um telemóvel em rede móvel gasta facilmente mais tempo a viajar do que nós a responder. É por isso que os pedidos são pequenos e a resposta traz só os campos do cartão de produto. Do lado da loja não há trabalho nenhum a acrescentar: o módulo para PrestaShop injeta uma única tag de script e o processamento acontece fora do servidor da loja.
• O desenho no browser. Uma grelha com imagens grandes pode gastar mais tempo a compor do que tudo o resto junto. Imagens com tamanho declarado e carregamento adiado valem mais do que qualquer otimização nossa do lado do servidor.

Por isso a única medição que respeitamos é a que inclui as três partes. Uma mediana de servidor bonita com uma loja lenta continua a ser uma loja lenta.

O que decidimos não fazer

• Não fazemos pesquisa por pedido a cada tecla sem esperar: o intervalo curto poupa a maioria dos pedidos e ninguém o sente.
• Não devolvemos o produto inteiro. O cartão precisa de sete campos e é isso que viaja.
• Não escrevemos analytics no caminho crítico.
• Não guardamos resultados em cache, pelas razões acima.
• Não pré-calculamos facetas para combinações que ninguém pediu.

Nenhuma destas decisões é espetacular. Somadas, são a diferença entre uma pesquisa que responde enquanto se escreve e uma que responde quando se acaba de escrever.

Perguntas frequentes

Quanto tempo deve demorar uma pesquisa de loja online?

Abaixo de 100 ms do teclado até ao ecrã é o objetivo razoável para uma pesquisa que responde enquanto se escreve, porque é aí que a resposta deixa de se sentir como espera. Numa medição de produção com 84 pedidos, a nossa mediana do lado do servidor ficou nos 24 ms, dos quais menos de 7 ms foram do motor de pesquisa. O resto do orçamento é da rede e do browser, e é aí que quase todas as lojas o perdem.

Uma cache de resultados torna a pesquisa mais rápida?

Melhora as médias e pouco mais. As pesquisas de uma loja têm cauda muito longa, os preços e o stock mudam durante o dia, e os filtros multiplicam as combinações a guardar. O trabalho de invalidar a cache costuma ser maior do que o ganho.

O que faz uma pesquisa ficar lenta?

Índices com demasiados campos pesquisáveis, facetas com milhares de valores, escritas de analytics no caminho da resposta, e respostas que trazem o produto inteiro quando o cartão só usa uma mão-cheia de campos.

A pesquisa torna a loja mais lenta?

Não deve. O processamento acontece fora do servidor da loja e a resposta é pequena. O que costuma pesar na página é o desenho dos resultados: imagens sem tamanho declarado e sem carregamento adiado custam mais do que a pesquisa inteira.

Medem o tempo do lado do servidor ou do visitante?

Os dois. O tempo de servidor é o que podemos otimizar diretamente, e vai em todas as respostas no cabeçalho Server-Timing, partido por passo e sem porta de acesso: quem quiser confirmar os números deste artigo abre as ferramentas do browser numa loja com o Buskara instalado. O tempo do visitante inclui rede e desenho no browser, e é o único que corresponde ao que a pessoa sente.

Os números deste artigo valem para o meu catálogo?

A parte do motor de pesquisa, não necessariamente: foi medida num catálogo de 19 produtos e é a parcela que mais cresce com o tamanho do índice. As outras parcelas (identificar a loja, escolher o índice, aplicar regras, contar facetas) dependem pouco do número de produtos e muito da configuração. A forma da tabela mantém-se; a primeira linha é a que muda.