Diagnóstico por capas
Una web lenta no tiene una sola causa
La misma sensación de lentitud puede venir de un script de terceros, de una consulta mal resuelta o de un servidor saturado. Por eso el primer paso no es optimizar: es saber en qué capa está el problema.
Experiencia percibida · «la web va lenta»
- Capa 01
Frontend
Lo que el navegador tiene que descargar, ejecutar y pintar antes de que la página sea usable.
- CSS / JS
- imágenes
- terceros
- Capa 02
Aplicación
El tiempo que el proyecto tarda en construir la respuesta: lógica, plugins, módulos y llamadas externas.
- PHP / runtime
- plugins
- APIs
- Capa 03
Datos
Cómo se consulta la información. Muchas webs lentas lo son por la forma en que acceden a sus propios datos.
- consultas
- índices
- volumen
- Capa 04
Caché y entrega
Qué se puede reutilizar, durante cuánto tiempo y cómo se invalida cuando el contenido cambia.
- página / objetos
- CDN
- invalidación
- Capa 05
Infraestructura
Los recursos y la configuración sobre los que se ejecuta todo lo anterior.
- runtime
- CPU / memoria
- TTFB
Las capas no son independientes: una caché mal invalidada puede parecer un problema de servidor, y una consulta lenta puede parecer un problema de plugin. El diagnóstico consiste en separar causa de síntoma.
Punto de partida
¿Reconoces alguno de estos síntomas?
Cada síntoma apunta a una capa distinta del sistema. No confirma la causa, pero orienta por dónde empezar a medir.
- 01
PageSpeed devuelve malos resultados y no está claro qué hacer con ese informe.
frontend · medición Intensidad del síntoma: 1 de 3 - 02
La web se percibe lenta en móvil, aunque en escritorio parezca aceptable.
frontend Intensidad del síntoma: 2 de 3 - 03
El tiempo de respuesta del servidor es alto antes incluso de empezar a pintar la página.
infraestructura · aplicación Intensidad del síntoma: 3 de 3 - 04
Las categorías, el buscador o los filtros tardan mucho más que el resto del sitio.
datos · caché Intensidad del síntoma: 3 de 3 - 05
El checkout se ralentiza justo en el paso donde se pierde la venta.
aplicación · APIs Intensidad del síntoma: 3 de 3 - 06
El panel de administración o el back office también van lentos.
datos · aplicación Intensidad del síntoma: 2 de 3 - 07
El rendimiento empeora cuando sube el tráfico o hay campaña.
infraestructura · caché Intensidad del síntoma: 3 de 3 - 08
Aparecen picos de CPU o de memoria sin una explicación clara.
infraestructura Intensidad del síntoma: 2 de 3 - 09
Se han ido acumulando scripts, plugins y módulos que ya nadie revisa.
frontend · aplicación Intensidad del síntoma: 2 de 3 - 10
Ya hay un plugin de caché instalado y la web sigue yendo lenta.
caché · diagnóstico Intensidad del síntoma: 3 de 3
«Ya tenemos caché, pero la web sigue lenta»
Es el punto de partida más habitual. La caché acelera lo que se puede reutilizar, pero no arregla una consulta pesada, un proceso que se ejecuta en cada carga o una página que por definición no se puede cachear, como un carrito o un checkout. Cuando la caché ya no aporta más, lo que falta es diagnóstico.
Medición
Primero medimos. Después decidimos qué merece la pena optimizar
Ninguna fuente cuenta la historia completa. El laboratorio explica el detalle técnico, los usuarios reales explican la experiencia y el servidor explica lo que ocurre antes de que el navegador reciba nada. El diagnóstico surge al cruzar las tres.
- Fuente 01
Laboratorio
Entorno controlado y repetible para aislar comportamientos y comparar antes y después.
Lighthouse / PageSpeed · waterfall de peticiones · tiempos por recurso · CPU y red simuladas · profiling de frontend
- Fuente 02
Usuarios reales
Cómo se comporta la web con dispositivos, redes y recorridos reales, no en condiciones ideales.
Core Web Vitals · señales de campo disponibles · Search Console · móvil vs. escritorio · plantillas críticas
- Fuente 03
Aplicación y servidor
Lo que ocurre por dentro: dónde se va el tiempo antes de generar la respuesta.
tiempos de backend · logs y errores · consultas a base de datos · consumo de recursos · caché · APIs externas
Diagnóstico
Una única lectura: qué es percepción y qué es medición, en qué capa se está yendo el tiempo y qué hipótesis merece la pena comprobar primero.
- documento
- estilos.css
- app.js
- vendor.js · terceros
- fuentes.woff2
- imagen principal
- xhr · datos de sesión
- Espera
- Transferencia
- Candidato a cuello de botella
Este bloque está preparado para mostrar la evidencia real y anonimizada de cada proyecto — una traza de DevTools, un informe de Lighthouse, una captura de Query Monitor o el profiling del servidor — en lugar del esquema que aparece mientras no hay medición del caso.
El punto clave
No todo lo lento tiene la misma causa ni la misma prioridad
Cuando se reparte el tiempo de una petición entre sus fases, casi siempre aparece un tramo que pesa mucho más que el resto. Ahí está la mejora real; el resto suele ser ruido.
-
Red latencia y entrega
dentro de lo esperado -
Aplicación lógica, plugins, módulos
cuello de botella · 52 % del tiempo -
Base de datos consultas y accesos
margen de mejora -
Renderizado construcción de la página
dentro de lo esperado -
JavaScript ejecución en el navegador
segundo foco · 30 %
La mayor oportunidad de mejora casi nunca está donde se espera al principio. Por eso identificamos el cuello de botella antes de aplicar ningún cambio: optimizar una fase que ya es rápida no mejora la experiencia, solo consume presupuesto.
Valores relativos · sin datos reales- Qué obtienes
- Un reparto claro del tiempo entre fases, con el tramo dominante identificado.
- Qué decidimos
- Qué se ataca primero según impacto real, riesgo técnico y coste de implementación.
- Qué descartamos
- Cambios cosméticos que mejoran una métrica sintética sin mover la experiencia.
Alcance técnico
Qué podemos optimizar
Del navegador a la infraestructura. Trabajamos sobre la capa donde está el problema, no sobre la que resulta más cómoda de tocar.
Entra la petición · navegador del usuario
- Capa 01
Frontend
Reducir y ordenar lo que el navegador necesita para mostrar la página, sin romper el diseño ni la funcionalidad.
- CSS / JS
- renderizado crítico
- imágenes
- fuentes
- scripts de terceros
- carga de recursos
- Capa 02
Aplicación
Revisar cómo se construye la respuesta: lógica propia, extensiones instaladas, procesos pesados y dependencias externas.
- lógica de aplicación
- PHP / runtime
- plugins y módulos
- APIs externas
- procesos costosos
- Capa 03
Base de datos
Localizar las consultas que dominan el tiempo de respuesta y corregir la forma en que se accede a los datos.
- consultas lentas
- consultas duplicadas
- índices
- accesos innecesarios
- Capa 04
Caché
Definir qué se cachea, dónde y durante cuánto tiempo, con una estrategia de invalidación que no rompa contenido dinámico.
- caché de página
- caché de objetos
- Redis cuando aporta
- CDN
- invalidación
- Capa 05
Infraestructura
Ajustar el entorno de ejecución y los recursos disponibles cuando el límite está realmente ahí.
- configuración de servidor
- runtime
- CPU / memoria
- TTFB
- proxy inverso
- CDN / entrega
…hasta el entorno donde se ejecuta todo lo anterior
Cómo trabajamos
Medir, diagnosticar, priorizar, optimizar y volver a medir
Un proceso cerrado: cada cambio se aplica sobre una hipótesis medida y se comprueba con una nueva medición.
- 01
Medición
Establecemos la línea base con datos de laboratorio, campo y servidor.
- 02
Diagnóstico
Localizamos los cuellos de botella y separamos causa de síntoma.
- 03
Priorización
Evaluamos impacto, riesgo y coste de implementación de cada mejora.
- 04
Optimización
Aplicamos cambios controlados, verificables y reversibles.
- 05
Validación
Volvemos a medir y comprobamos que nada ha dejado de funcionar.
- 06
Seguimiento
Identificamos qué puede volver a degradar el rendimiento con el tiempo.
↺ El proceso termina volviendo a medir
Validación
Antes y después, con la misma medición
No comparamos sensaciones ni titulares. Comparamos la misma medición, en las mismas condiciones, antes y después de los cambios, y documentamos lo que no ha podido mejorarse.
Antes Línea base
- Red
- Aplicación
- Datos
- Renderizado
- JavaScript
- Medición inicial en condiciones controladas
- Cuellos de botella identificados y priorizados
- Limitaciones conocidas del proyecto
Optimización controlada
Después Nueva medición
- Red
- Aplicación
- Datos
- Renderizado
- JavaScript
- Nueva medición con el mismo método
- Cambios validados también a nivel funcional
- Limitaciones restantes documentadas, no ocultadas
Metodología ilustrada · las barras no representan datos de un cliente
- TTFB
- Core Web Vitals
- consultas a base de datos
- respuesta de aplicación
- nº de peticiones
- peso transferido
- tiempo de ejecución en frontend
Ecommerce
Rendimiento donde ocurre la venta
En una tienda online, el rendimiento no se juega en la home. Se juega en el listado, en el buscador, en la ficha y sobre todo en el checkout, que es justo lo que no se puede cachear sin más.
- Etapa 01
Categoría
Listados, paginación, filtros y ordenaciones que multiplican consultas y combinaciones.
- base de datos
- caché
- buscador
- Etapa 02
Producto
Variantes, stock, precios, recomendaciones y contenido enriquecido de la ficha.
- stock
- precios
- ERP
- Etapa 03
Carrito
Contenido dinámico por usuario: reglas, promociones, portes y recálculos constantes.
- sesión
- reglas
- envío
- Etapa 04
Checkout
Validaciones, pasarela de pago y servicios externos encadenados en el peor momento posible.
- pago
- envío
- APIs
Cada etapa se apoya en base de datos, caché, ERP, pasarela de pago y servicios de envío. Una etapa lenta rara vez lo es por sí sola: suele estar esperando a otro sistema. Por eso el análisis incluye también las operaciones de stock, precios y las llamadas a APIs externas, especialmente en picos de campaña.
Criterio técnico
Lo que no hacemos
Parte del valor de un trabajo de rendimiento está en las decisiones que se descartan. Estas son las nuestras.
- No 01
No perseguimos un 100/100
Si esa puntuación no mejora la experiencia real de quien usa la web, no es un objetivo: es una métrica bonita.
- No 02
No instalamos plugins al azar
Añadir capas sin diagnóstico previo suele desplazar el problema, no resolverlo, y complica el mantenimiento posterior.
- No 03
No desactivamos funcionalidad crítica
Apagar lo que molesta al test sintético mejora el informe y empeora el negocio. No es una optimización.
- No 04
No prometemos un resultado universal
Antes de analizar el proyecto no sabemos hasta dónde se puede llegar. Después, sí, y lo explicamos con datos.
- No 05
No recomendamos cambiar de hosting por defecto
Si el cuello de botella está dentro de la aplicación, un servidor más grande solo hace más caro el mismo problema.
Plataformas y tipos de proyecto
Optimización adaptada a la arquitectura real del proyecto
Trabajamos con distintas plataformas, pero el enfoque no cambia: primero entender cómo está construido el proyecto, después decidir qué se puede mejorar.
-
WordPress
Temas, plugins, hooks y capas de caché acumuladas con el tiempo.
-
WooCommerce
Catálogo, carrito y checkout: dinámico por definición.
-
PrestaShop
Módulos, overrides e integraciones con ERP o stock.
-
Aplicaciones a medida
El rendimiento depende del diseño del sistema y de sus datos.
La estrategia de optimización depende de la arquitectura del proyecto, no de la etiqueta del CMS.
Colaboración técnica
Optimización de rendimiento para agencias
Si gestionáis proyectos de cliente y necesitáis apoyo especializado en rendimiento, podemos asumir la capa técnica: auditoría, diagnóstico, implementación y validación antes/después, en segundo plano y con vuestra marca por delante.
- diagnóstico
- implementación
- validación antes/después
- informe comparativo
- marca blanca
Servicios relacionados
El rendimiento casi nunca va solo
Según dónde esté el cuello de botella, el trabajo continúa en infraestructura, en mantenimiento o en el propio desarrollo.
- Capa de servidor
Infraestructura web gestionada
Cuando el límite está en el entorno de ejecución, los recursos o la configuración del servidor.
Infraestructura - Continuidad
Mantenimiento web
Para que las mejoras no se degraden con el tiempo a base de actualizaciones y añadidos.
Mantenimiento - Análisis previo
Auditoría técnica WordPress
Revisión completa del estado técnico cuando el problema va más allá del rendimiento.
Diagnóstico - Desarrollo
Desarrollo WordPress
Cuando la solución pasa por rehacer una parte del código en lugar de parchearla.
Implementación - Desarrollo
Desarrollo PrestaShop
Módulos, overrides e integraciones revisados desde el impacto que tienen en rendimiento.
Ecommerce - Ecommerce
Desarrollo WooCommerce
Catálogo, checkout y procesos de tienda pensados para sostener el crecimiento.
Ecommerce
Todos estos servicios comparten el mismo criterio: primero medir, después decidir qué se toca.
Dudas frecuentes
Preguntas sobre rendimiento web
Lo que más nos preguntan antes de empezar un trabajo de optimización. Si tu duda no está aquí, escríbenos y te respondemos directamente.
WPO (Web Performance Optimization) es el trabajo de analizar y mejorar el rendimiento de una web: cuánto tarda en responder, en mostrarse y en volverse usable. No es una herramienta ni un plugin: es un proceso de medición, diagnóstico y optimización sobre frontend, aplicación, datos, caché e infraestructura.
No siempre. PageSpeed es una medición de laboratorio muy útil como indicador, pero puede subir sin que la experiencia real mejore, y también puede quedarse baja en webs que funcionan bien para sus usuarios. Nosotros la usamos como una fuente más, junto con datos de campo y del servidor.
No. Cualquiera que garantice una cifra antes de analizar el proyecto está prometiendo algo que no puede saber. Lo que sí hacemos es medir el estado actual, decir con claridad qué margen de mejora existe, priorizar los cambios y demostrar el resultado con una nueva medición.
Son un conjunto de métricas centradas en la experiencia de uso: cuánto tarda en aparecer el contenido principal, cómo responde la página a la interacción y cuánta inestabilidad visual hay durante la carga. Se miden con usuarios reales, así que reflejan dispositivos y redes reales, no un entorno ideal.
A veces sí y a veces no. Si el cuello de botella está en la aplicación o en la base de datos, cambiar de servidor solo desplaza el problema y encarece la factura. Si el límite está de verdad en los recursos o en la configuración del entorno, lo decimos y lo justificamos con la medición.
En la mayoría de casos, sí. Buena parte del trabajo es invisible: cómo se cargan los recursos, cómo se resuelven las consultas, qué se cachea o cómo se ejecuta el código. Si alguna mejora relevante implicara tocar el diseño o alguna funcionalidad, lo planteamos antes como una decisión, no como un efecto secundario.
No. Trabajamos con WordPress y WooCommerce, con PrestaShop y con aplicaciones web a medida. El método es el mismo en todos los casos; lo que cambia es la arquitectura sobre la que se aplica y, con ella, las prioridades.
Es un escenario habitual. Identificamos qué componente concreto está consumiendo el tiempo y valoramos las opciones: ajustarlo, sustituirlo, limitar su alcance o reescribir esa parte. Como también desarrollamos, podemos intervenir en el código en lugar de limitarnos a informar del problema.
Con la misma medición que usamos para la línea base, repetida en las mismas condiciones después de los cambios: tiempos de servidor y aplicación, comportamiento de las consultas, peticiones y peso transferido, ejecución en el navegador y métricas de experiencia. Y documentamos también lo que no ha mejorado.
Sí. El rendimiento se degrada con el tiempo: nuevos plugins, más contenido, más scripts de marketing, más tráfico o cambios en servicios externos. Por eso la última fase del proceso es identificar qué puede volver a degradarlo y, si el proyecto lo necesita, mantener un seguimiento periódico.
Siguiente paso
Antes de optimizar, hay que saber dónde está el problema
Revisamos el estado actual de tu web, identificamos los principales cuellos de botella y definimos qué mejoras merece la pena implementar y en qué orden.
Sin compromiso · Revisión inicial del caso · Respuesta en 24h laborables