Dónde se gastan los milisegundos de una búsqueda

En resumen

• El presupuesto útil de una búsqueda que responde mientras se escribe son los 100 ms que una persona lee como respuesta inmediata, y el servidor solo puede gastar una parte de ellos.
• En una medición de producción, la mediana del lado del servidor se quedó en 24 ms, y el motor de búsqueda fue menos de un tercio de eso.
• Lo que marca la diferencia no es una caché: es no hacer trabajo innecesario en cada tecla.
• Una caché de resultados rinde menos de lo que se piensa, porque las búsquedas de una tienda tienen cola larga y el stock cambia.
• El tiempo que el visitante siente incluye la red y el dibujado en el navegador, y esa parte se pierde más deprisa de lo que se gana en el servidor.

Prometer «búsqueda instantánea» es fácil, y nosotros también lo prometemos. Lo que interesa es el presupuesto que hay detrás de la promesa: cuántos milisegundos existen, en qué se gastan, y qué se decide no hacer para no gastarlos. Este artículo es esa contabilidad, sin marketing.

El presupuesto no es una elección nuestra. Viene de un límite conocido desde 1993, cuando Jakob Nielsen fijó los tres límites del tiempo de respuesta: 0,1 segundos es el límite para que una persona sienta que el sistema reacciona al instante. Una búsqueda que responde mientras se escribe tiene que caber ahí, y el servidor no es el único invitado a la mesa: la red y el dibujado en el navegador también quieren su parte.

Qué medimos, y en qué condiciones

Los números que siguen no son de una prueba sintética. Se sacaron de un servidor de producción el 9 de agosto de 2026, con 84 peticiones de búsqueda a una tienda PrestaShop nuestra, y vienen de la cabecera Server-Timing que el servicio envía en todas las peticiones, sin puerta de acceso.

Antes de leerlos, tres salvedades que cambian la interpretación:

• El catálogo era pequeño, con 19 productos. Es la parte del motor de búsqueda la que más crece con el tamaño del índice; las otras casi no se mueven.
• El servidor estaba sin carga, con una media de carga por debajo de 0,2 en cuatro núcleos. Estos números son un suelo, no una promesa en hora punta.
• Las marcas miden tiempo de pared de cada operación, y muchas corren en paralelo a propósito. Por eso la suma de las porciones es mayor que el total, y se lee así: una porción grande dice cuánto se esperó por aquello, no cuánto retrasó aquello la respuesta.

El camino de una tecla hasta la respuesta

Cada tecla escrita en la caja dispara el mismo recorrido:

1. El layer en la tienda espera un instante corto para no enviar una petición por letra, y junta lo que se escribió mientras tanto.
2. La petición llega a nuestro servicio, que identifica la tienda por la clave pública y elige el índice correcto (tienda, idioma y moneda).
3. La consulta se prepara: normalización del texto, sinónimos de la tienda, reglas de merchandising activas, filtros ya elegidos.
4. El motor de búsqueda responde con productos, recuentos por faceta y destacados.
5. La respuesta se monta con los campos que ese diseño de resultados necesita, y ninguno más.

Aquí no hay ningún paso que sea opcional ni sorprendente. El tiempo se gana dentro de cada uno.

Dónde se gastan los milisegundos

Dos líneas merecen explicación, y son las dos que sorprenden.

La del registro para analítica es la que suele estropear sistemas de este tipo. Guardar la búsqueda antes de responder añade una escritura al camino crítico, y una base de datos con un mal minuto pasa a ser una búsqueda con un mal minuto para todo el mundo. Esos 2,5 ms existen, son reales, y no los paga el visitante: la escritura arranca después de que la respuesta ya haya salido. Es el ejemplo más claro de aquella salvedad sobre las porciones en paralelo.

La del segundo intento es la parte que más gente no espera encontrar. Cuando la primera búsqueda iba a acabar en poco o nada, se corre otra, más tolerante, para no devolver una pantalla vacía a quien cambió una letra. Cuesta casi tanto como la búsqueda principal, y es dinero bien gastado: la pantalla sin resultados es cara de otra manera.

Fíjate en lo que la tabla no muestra: ningún paso domina. No hay un cuello de botella que atacar, y por eso la única forma de bajar de aquí es quitar trabajo, no optimizar un sitio.

Pros y contras de una caché de resultados

La pregunta aparece siempre: ¿por qué no guardar las respuestas más pedidas? Guardamos algunas cosas, pero no los resultados de búsqueda, y vale la pena explicar el razonamiento.

La tercera línea de la columna izquierda es la más peligrosa, porque una caché mejora las medias sin mejorar la experiencia de quien escribió algo raro, que es precisamente quien más necesita una buena búsqueda.

Lo que hacemos en su lugar es mantener en memoria lo que cambia poco (configuración de la tienda, sinónimos, reglas) y no repetir trabajo por petición. La ganancia es parecida y no hay nada que invalidar.

Lo que el visitante siente

Esos 24 ms son nuestra parte, y son la más fácil de las tres. Lo que la persona siente incluye dos más:

• La red. Una petición desde un móvil en red móvil gasta fácilmente más tiempo viajando que nosotros respondiendo. Por eso las peticiones son pequeñas y la respuesta trae solo los campos de la ficha de producto. Del lado de la tienda no hay ningún trabajo que añadir: el módulo para PrestaShop inyecta una única etiqueta de script y el procesamiento ocurre fuera del servidor de la tienda.
• El dibujado en el navegador. Una cuadrícula con imágenes grandes puede gastar más tiempo componiéndose que todo lo demás junto. Imágenes con tamaño declarado y carga diferida valen más que cualquier optimización nuestra del lado del servidor.

Por eso la única medición que respetamos es la que incluye las tres partes. Una mediana de servidor bonita con una tienda lenta sigue siendo una tienda lenta.

Lo que decidimos no hacer

• No hacemos una búsqueda por petición en cada tecla sin esperar: el intervalo corto ahorra la mayoría de las peticiones y nadie lo nota.
• No devolvemos el producto entero. La ficha necesita siete campos y es eso lo que viaja.
• No escribimos analítica en el camino crítico.
• No guardamos resultados en caché, por las razones de arriba.
• No precalculamos facetas para combinaciones que nadie pidió.

Ninguna de estas decisiones es espectacular. Sumadas, son la diferencia entre una búsqueda que responde mientras se escribe y una que responde cuando se acaba de escribir.

Preguntas frecuentes

¿Cuánto debe tardar la búsqueda de una tienda online?

Por debajo de 100 ms desde el teclado hasta la pantalla es el objetivo razonable para una búsqueda que responde mientras se escribe, porque es ahí donde la respuesta deja de sentirse como espera. En una medición de producción con 84 peticiones, nuestra mediana del lado del servidor se quedó en 24 ms, de los cuales menos de 7 ms fueron del motor de búsqueda. El resto del presupuesto es de la red y del navegador, y es ahí donde casi todas las tiendas lo pierden.

¿Una caché de resultados hace la búsqueda más rápida?

Mejora las medias y poco más. Las búsquedas de una tienda tienen una cola muy larga, los precios y el stock cambian durante el día, y los filtros multiplican las combinaciones a guardar. El trabajo de invalidar la caché suele ser mayor que la ganancia.

¿Qué hace que una búsqueda se vuelva lenta?

Índices con demasiados campos buscables, facetas con miles de valores, escrituras de analítica en el camino de la respuesta, y respuestas que traen el producto entero cuando la ficha solo usa un puñado de campos.

¿La búsqueda hace la tienda más lenta?

No debería. El procesamiento ocurre fuera del servidor de la tienda y la respuesta es pequeña. Lo que suele pesar en la página es el dibujado de los resultados: imágenes sin tamaño declarado y sin carga diferida cuestan más que la búsqueda entera.

¿Medís el tiempo del lado del servidor o del visitante?

Los dos. El tiempo de servidor es el que podemos optimizar directamente, y va en todas las respuestas en la cabecera Server-Timing, desglosado por paso y sin puerta de acceso: quien quiera confirmar los números de este artículo abre las herramientas del navegador en una tienda con Buskara instalado. El tiempo del visitante incluye la red y el dibujado en el navegador, y es el único que corresponde a lo que la persona siente.

¿Los números de este artículo valen para mi catálogo?

La parte del motor de búsqueda, no necesariamente: se midió en un catálogo de 19 productos y es la parte que más crece con el tamaño del índice. Las otras partes (identificar la tienda, elegir el índice, aplicar reglas, contar facetas) dependen poco del número de productos y mucho de la configuración. La forma de la tabla se mantiene; la primera línea es la que cambia.