Análisis técnico web: Rendimiento, stack y SEO de Oechsle, Ripley y Falabella (mayo 2026)

Nota metodológica y de transparencia. Este es un análisis técnico independiente con fines informativos y educativos. Todas las métricas fueron medidas directamente por KOM Agencia Digital el 16 de mayo de 2026 usando GTmetrix (servidor Seattle, WA — Chrome 142.0.0.0, Lighthouse 12.6.1, conexión sin caché, con exportación de waterfall y archivo HAR), Wappalyzer (detección de stack tecnológico), Moz (perfil de enlaces) y una extensión de auditoría SEO on-page. Los valores reflejan el estado de cada sitio en esa fecha y hora puntual; el rendimiento web es variable. KOM Agencia Digital no presta ni ha prestado servicios para Oechsle, Ripley ni Falabella, no compite con ellas en el mercado retail y no ha recibido contraprestación de terceros para publicar este análisis. Si representas a alguna de estas marcas y deseas comentar o corregir algún dato, escríbenos a hola@kom.pe: publicaremos tu respuesta sin edición.

Resumen ejecutivo

Analizamos las páginas de inicio de tres de los retailers más importantes del Perú —Oechsle, Ripley y Falabella— combinando medición de rendimiento real (waterfall y datos de red HAR), detección de stack tecnológico, perfil de autoridad de dominio y auditoría SEO on-page. Cuatro hallazgos rápidos:

• Tres arquitecturas tecnológicas distintas, un mismo problema. Oechsle corre sobre VTEX con Alpine.js y jQuery; Ripley y Falabella son aplicaciones modernas React + Next.js. Pese a la diferencia de modernidad, los tres fallan en lo mismo: peso excesivo de JavaScript de terceros.
• El tiempo de carga real es alto en los tres. El waterfall de GTmetrix muestra que Oechsle tarda 14.1 s en cargar completamente (Onload 4.2 s), Ripley 8 s (Onload 834 ms) y Falabella 35.1 s (Onload 5.9 s). Onload es lo que siente el usuario; «fully loaded» es lo que sigue ejecutándose en segundo plano consumiendo recursos.
• Falabella transfiere 22.5 MB sin comprimir en la home y arrastra 11 herramientas de analítica simultáneas detectadas por Wappalyzer. Es el caso más extremo de sobrecarga de tags.
• El gran ausente transversal es el SEO on-page básico: Oechsle y Falabella no tienen H1 en su home y Falabella carga sin atributo lang. Son fallos de higiene técnica de bajo costo de corrección y alto impacto.

Metodología

El HAR registra cada petición de red con tiempos, tamaños y códigos de estado; el waterfall visualiza la cascada de carga recurso por recurso; Wappalyzer identifica el stack real sin suposiciones. La combinación permite ir mucho más allá de un «Grade» y señalar el recurso, el dominio y la tecnología exacta detrás de cada cuello de botella.

Stack tecnológico confirmado (Wappalyzer)

A diferencia de un análisis superficial, aquí el stack no se infiere: se confirma con detección directa.

Oechsle — plataforma VTEX sobre AWS

Oechsle es la arquitectura más «tradicional» del trío: VTEX como motor de tienda, jQuery aún presente y Alpine.js como capa de interactividad ligera. El número de redes publicitarias (cinco distintas) es notable y explica parte de la sobrecarga.

Ripley — React + Next.js sobre infraestructura híbrida

Ripley tiene la arquitectura más moderna y mejor optimizada: stack React/Next.js, HTTP/3 activo (mejora la multiplexación de conexiones), Rocket Loader de Cloudflare para diferir JS, y el perfil de analítica más contenido de los tres (solo 4 herramientas). No es casualidad que sea el de mejor rendimiento.

Falabella — React + Next.js con sobrecarga de tags

Falabella tiene un stack moderno y potente —incluso usa Priority Hints para optimizar— pero lo neutraliza con dos gestores de etiquetas en paralelo (GTM + Adobe Launch) y once herramientas de analítica simultáneas. Es el ejemplo de manual de cómo la capa de medición termina pesando más que el producto.

Conclusión de stack: la modernidad del framework no garantiza rendimiento. Ripley (React/Next.js bien optimizado, HTTP/3, Rocket Loader, 4 tags) rinde mejor que Falabella (mismo framework base pero 11 tags y doble tag manager). La diferencia no está en la tecnología sino en la disciplina de gobierno de etiquetas.

Rendimiento de carga: del Grade al waterfall real

Comparativa de métricas core

Lo que revela el waterfall (dato que el Grade oculta)

El waterfall de GTmetrix muestra el tiempo total de carga, que es muy distinto del Onload:

La cifra crítica es Falabella: 35.1 segundos hasta «fully loaded». Aunque el contenido principal aparece antes (Onload 5.9 s), la página sigue descargando y ejecutando recursos durante medio minuto más —scripts de analítica, píxeles, personalización— consumiendo batería, datos y CPU del usuario mucho después de que parece «lista».

Detalle del waterfall por sitio:

• Oechsle (14.1 s): el documento HTML pesa 26.1 KB y se entrega en 254 ms (TTFB sano). El problema viene después: una larga cascada de scripts VTEX (vtex.min.js, vtexid-jquery.min.js, vtex-analytics.js, vtex-events-all.min.js) y fuentes Gelion de 111–116 KB cada una servidas como CSS. El CPU llega a 5.2% y la memoria a 580 MB en una sola pestaña.
• Ripley (8 s, Onload 834 ms): el más eficiente. El HTML (29.3 KB) carga en 624 ms y aparece un hint de speculation (prefetch especulativo, buena práctica moderna). La dependencia pesada es api-pe.ripley.com: una sola llamada de 1.43 MB (aggCQKYof...) que es el recurso individual más grande del análisis. Aun así, Rocket Loader y Next.js mantienen el Onload por debajo del segundo.
• Falabella (35.1 s): el HTML (113 KB) ya es 4× el de Oechsle. Le siguen ~15 chunks de JavaScript desde static.falabella.io (webpack, framework, main, _app y bundles con hash de 73–481 KB cada uno) que se descargan en serie en los primeros ~500 ms y bloquean. La cola de 35 s es analítica y media ejecutándose en segundo plano.

El factor común cuantificado: scripts de terceros

Cruzando el HAR con Wappalyzer:

La correlación es directa y demostrable: a más herramientas de analítica y mayor peso de terceros, peor Total Blocking Time. Ripley (4 herramientas, mejor gobierno de tags, Rocket Loader) logra el mejor rendimiento; Falabella (11 herramientas, doble tag manager) el peor TBT pese a tener el mismo framework base que Ripley.

Autoridad de dominio y perfil de enlaces (Moz)

Ripley domina el perfil de autoridad (DA 65) y su curva histórica en Moz muestra crecimiento sostenido desde mediados de 2025, mientras Oechsle y Falabella se mantienen estables. El Spam Score de Oechsle (1%) es el más limpio. En una búsqueda competitiva no de marca, Ripley parte con ventaja estructural de autoridad.

SEO on-page (auditoría de encabezados y metadatos)

Hallazgos clave:

• Oechsle y Falabella no tienen H1 en la home. Dos de los tres retailers más grandes del país omiten la señal semántica más básica en su página más importante. Es de los fallos más baratos de corregir y de mayor impacto.
• Falabella carga sin atributo lang. Fallo de accesibilidad (WCAG) y de internacionalización trivial de resolver.
• Jerarquía rota en Oechsle: 8 H2 sin ningún H1 que los anteceda.
• Ripley es el más ordenado on-page (H1 presente, jerarquía coherente, metadatos completos), aunque abusa de H6 para listar productos individuales.
• Ninguno declara Publisher: oportunidad clara de reforzar señales de entidad y E-E-A-T con datos estructurados.

Oportunidades de mejora (constructivo y accionable)

Recomendaciones técnicas estándar, aplicables a cualquier e-commerce de esta escala:

1. Gobierno de etiquetas de terceros. La palanca de mayor impacto. Falabella podría recortar TBT significativamente consolidando GTM + Adobe Launch y auditando sus 11 herramientas de analítica (¿se usan todas?). Diferir y agrupar tags no críticos no afecta el negocio.
2. Reducir el JavaScript de bloqueo. En Falabella, los ~15 chunks de static.falabella.io se cargan en serie; code-splitting más agresivo y carga diferida ayudarían.
3. Agregar H1 único y descriptivo (Oechsle y Falabella). Corrección de minutos.
4. Declarar lang="es" (Falabella).
5. Optimizar imágenes (Falabella transfiere 7.8 MB en imágenes; AVIF/WebP + srcset + lazy load).
6. Estabilizar layout en Oechsle (CLS 0.28: reservar dimensiones de banners e imágenes hero).
7. Reducir la cola de «fully loaded» posponiendo todo lo no esencial fuera del Onload (Falabella: 35.1 s).
8. Datos estructurados de Organización y señales de entidad (Author/Publisher) en los tres.

Conclusión: qué nos dice esto sobre el e-commerce peruano

El hallazgo de fondo: la tecnología moderna no salva a nadie del mal gobierno de etiquetas. Ripley y Falabella corren el mismo stack base (React + Next.js), pero Ripley rinde casi el doble porque mantiene 4 herramientas de analítica, usa Rocket Loader y HTTP/3, mientras Falabella arrastra 11 herramientas, doble tag manager y una cola de carga de 35 segundos. Oechsle, con una arquitectura más antigua (VTEX + jQuery), sufre de estabilidad visual y de un exceso de redes publicitarias.

No es un problema de presupuesto —los tres tienen recursos de sobra— es un problema de disciplina técnica y de prioridad. Y es precisamente donde una optimización enfocada genera retorno medible: cada segundo de Total Blocking Time recortado es conversión recuperada en móvil, que en el Perú sigue siendo la mayoría del tráfico.

En KOM Agencia Digital convertimos este tipo de diagnóstico en una ruta de trabajo concreta: gobierno de etiquetas, optimización de Core Web Vitals, arquitectura AI-ready (Schema, llms.txt, HTML semántico) y stack de alto rendimiento. Si una marca de este tamaño tiene espacio para mejorar, el caso para una empresa mediana que aún no posiciona es todavía más urgente.

¿Quieres un análisis técnico como este para tu sitio web? Escríbenos a hola@kom.pe o al WhatsApp +51 923 222 223. Hacemos que tus clientes te encuentren.

Ficha resumen rápida

Análisis independiente de KOM Agencia Digital — Otorongo Negro E.I.R.L., RUC 20604716595. Datos medidos el 16 de mayo de 2026 con GTmetrix, Wappalyzer y Moz. Para correcciones o derecho de réplica: hola@kom.pe.