Usamos cookies para mejorar tu experiencia, analizar el tráfico del sitio y personalizar el contenido. Puedes aceptar todas las cookies o elegir qué categorías permitir. Más información
Optimización de INP para Páginas de Detalle de Producto (PDP) en 2026 | Ordiko
Guía
Optimización de INP para Páginas de Detalle de Producto (PDP) en 2026
Una guía enfocada para solucionar la Interacción hasta el Siguiente Pintado (INP) en PDPs de comercio electrónico en 2026, cubriendo el intercambio de variantes, galería, añadir al carrito y los patrones de Componentes del Servidor de React que consistentemente mueven el INP por debajo de 200ms.
PT1H30M
TL;DR. INP en PDP se soluciona enviando menos JavaScript y haciendo que las interacciones sean optimistas. Usa React Server Components para partes estáticas. Usa useOptimistic para el cambio de variante y añadir al carrito. Usa startTransition para actualizaciones no urgentes. Debounce la búsqueda con AbortController. Eleva expresiones regulares y evita el spread en los controladores de eventos. Objetivo: < 200ms p75, alcanzable < 100ms.
Qué mide INP
La Interacción hasta el Siguiente Pintado (INP) mide el tiempo más largo de interacción a pintado en una página durante la visita del usuario. Una "interacción" es un clic, toque o pulsación de tecla que activa JavaScript.
INP se calcula como el peor caso (excluyendo raros valores atípicos), no el promedio. Un clic lento en un filtro puede arruinar tu puntuación INP incluso si 99 otras interacciones fueron rápidas.
Valor de INP
Veredicto
≤ 200ms
Bueno
200ms – 500ms
Necesita mejora
> 500ms
Pobre
Preguntas frecuentes
¿Por qué es el INP mucho más difícil que el LCP?
El LCP es principalmente un problema de CDN y optimización de imágenes con soluciones bien entendidas. El INP es el tiempo de ejecución de JavaScript en la interacción del usuario; cada clic puede tener un cuello de botella diferente. Solucionar el INP requiere disciplina a nivel de componente en cada elemento interactivo de la página.
¿Los Componentes del Servidor de React solucionan automáticamente el INP?
En gran medida sí. RSC reduce el paquete de JS enviado al navegador, lo que reduce el trabajo en el hilo principal, lo que mejora el INP. Pero las partes interactivas de la página aún necesitan JS del cliente; RSC por sí solo no solucionará un componente del cliente mal escrito que crea regex en onClick.
¿Cuál es el mayor asesino de INP en PDPs?
La pesada renderización del lado del cliente de widgets de recomendación ('Frecuentemente comprados juntos', 'También te podría gustar') que envían de 50 a 200KB de JS y se hidratan agresivamente en la primera interacción. Mueve estos a Componentes del Servidor o carga perezosamente detrás de IntersectionObserver.
¿Qué tan rápido puede llegar un PDP bien optimizado en INP?
Un INP p75 del mundo real por debajo de 100ms es alcanzable. Los PDPs de Ordiko tienen un INP p75 predeterminado de 80–160ms sin optimización manual. Los temas personalizados que siguen los patrones de esta guía pueden llegar a estar por debajo de 100ms de manera consistente.
Lecturas relacionadas
Paso 1: Perfila, no adivines
Usa la pestaña de Rendimiento de Chrome DevTools para grabar una sesión de interacción de PDP. Busca:
Tareas largas (barras amarillas > 50ms) durante las interacciones.
Reflujos forzados (barras moradas).
Alta atribución para entradas de INP.
O usa la API de Long Animation Frames (LoAF) en tu RUM:
const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
if (entry.duration > 200) {
console.log('Marco largo:', entry);
}
}
});
observer.observe({ type: 'long-animation-frame', buffered: true });
Paso 2: Aplaza el JS no crítico
Las mayores ganancias de INP en la mayoría de los PDP provienen de eliminar o aplazar scripts que no necesitabas cargar de inmediato:
Solo AddToCartButton y VariantSelector son Componentes del Cliente. Todo lo demás permanece en el servidor. El tamaño del paquete se reduce entre un 60% y un 80% en comparación con un PDP completamente del cliente.
Paso 4: Cambio de variante optimista
El flujo de clic en variante ingenuo:
El usuario hace clic en la variante.
POST a /api/variant/select con el nuevo ID de variante.
El servidor devuelve el precio/SKU/imágen actualizados.
Re-renderiza con el nuevo estado.
Total: 200–500ms de latencia percibida. Puntuación INP: mala.
Paso 7: Eleva expresiones regulares y evita el spread
Malo:
function handleClick(text) {
if (/[<>]/.test(text)) { ... } // regex creado en cada clic
setItems(prev => [...prev, ...newItems]); // spread en el acumulador
}
Bueno:
const TAG_REGEX = /[<>]/; // elevado al ámbito del módulo
function handleClick(text) {
if (TAG_REGEX.test(text)) { ... }
setItems(prev => prev.concat(newItems));
}
Paso 8: Carga perezosa debajo del pliegue
Recomendaciones, reseñas, productos relacionados: colócalos debajo del pliegue y cárgalos de forma perezosa con dynamic + ssr: false para widgets puramente del cliente, o cárgalos en la intersección:
Para secciones renderizadas en el servidor, envuélvelas en <Suspense> con PPR habilitado para que se transmitan después de la estructura estática.
Midiendo el éxito
Después de implementar las correcciones, las mejoras de INP se muestran en:
Chrome DevTools bajo Rendimiento → Supervivencias Web (sintético, inmediato).
Tu propio RUM con la biblioteca web-vitals (usuario real, casi en tiempo real).
Search Console → Core Web Vitals (usuario real, p75 durante 28 días, 2–4 semanas de retraso).
Un PDP típico que comenzó en 350ms p75 INP y sigue esta guía alcanza 80–120ms p75 INP dentro de 2–4 semanas de implementación.
Cómo Ordiko envía PDPs buenos en INP por defecto
Las partes estáticas de PDP son RSC (sin JS del cliente enviado).
El selector de variantes usa useOptimistic + Acciones del Servidor.
La galería usa startTransition + precarga de imágenes al pasar el ratón.
Búsqueda con debounce a 200ms con AbortController.
El cajón del carrito renderiza la última cuenta conocida de forma optimista.
INP p75 por defecto: 80–160ms.
FAQ
¿Por qué es INP mucho más difícil que LCP? LCP es principalmente un problema de CDN y optimización de imágenes con soluciones bien entendidas. INP es el tiempo de ejecución de JavaScript en la interacción del usuario; cada clic puede tener un cuello de botella diferente. Arreglar INP requiere disciplina a nivel de componente en cada elemento interactivo de la página.
¿Los Componentes del Servidor de React arreglan INP automáticamente? En gran medida sí. RSC reduce el paquete de JS enviado al navegador, lo que reduce el trabajo en el hilo principal, lo que mejora INP. Pero las partes interactivas de la página aún necesitan JS del cliente; RSC por sí solo no solucionará un componente del cliente mal escrito que crea expresiones regulares en onClick.
¿Cuál es el mayor asesino de INP en los PDP? La pesada renderización del lado del cliente de widgets de recomendaciones ('Frecuentemente comprados juntos', 'También te podría gustar') que envían de 50 a 200KB de JS y se hidratan agresivamente en la primera interacción. Mueve estos a Componentes del Servidor o cárgalos de forma perezosa detrás de IntersectionObserver.
¿Qué tan rápido puede un PDP bien optimizado alcanzar en INP? Un INP p75 en el mundo real por debajo de 100ms es alcanzable. Los PDP de Ordiko tienen por defecto un INP p75 de 80–160ms sin optimización manual. Los temas personalizados que siguen los patrones de esta guía pueden lograr consistentemente menos de 100ms.