En julio de 2025, el HTTP Archive revisó con datos de visitantes reales casi un millón de tiendas hechas con WooCommerce. En celular, 35 de cada 100 aprobaban las tres métricas de Core Web Vitals de Google. En Shopify, 76.
La brecha tiene un lugar exacto. En INP, la métrica de respuesta, la diferencia es de 2 puntos. En CLS, la de estabilidad, de 7. En LCP, la que mide cuánto tarda en aparecer lo más grande de la pantalla, de 47. De cada 100 tiendas WooCommerce que reprueban en celular, 94 reprueban el LCP.
Y hay un dato de Google que reordena el trabajo. En la mayoría de los sitios con LCP malo, el tiempo no se va en descargar la imagen principal. Se va esperando al servidor y esperando a pedirla. Por eso este artículo no empieza por comprimir fotos. Empieza por medir, sigue por el servidor y llega a las fotos después.
Esto vas a encontrar abajo.
- 35 de cada 100 tiendas WooCommerce aprueban Core Web Vitals en celular, contra 76 de Shopify y 51 de Tiendanube, en el Web Almanac 2025.
- 94 de cada 100 que reprueban, reprueban el LCP. En Shopify, 58. Es una cuenta propia sobre la tabla del HTTP Archive.
- El carrito, la cuenta del cliente y el pago no se pueden guardar en caché. Lo dice la documentación de WooCommerce, y ahí la velocidad depende del servidor.
- En el pago, la caché de objetos baja de 172 a 115 las consultas a la base de datos para guardar el pedido, en la medición de WooCommerce 10.7.
- Cada megabyte tarda 5 segundos en la conexión que simula PageSpeed Insights para celular.
- PHP 8.2 deja de recibir parches de seguridad el 31 de diciembre de 2026, y El Buen Fin, según la prensa, va del 13 al 17 de noviembre. Son las dos fechas para planear este trabajo.
En México, el 97.3 % de quienes usan internet se conecta con un celular inteligente, según el INEGI. Por eso, en este artículo, la medición que manda es la de celular.
Dos avisos antes de empezar. Todo lo que sigue se prueba primero en una copia de la tienda, no en la que está vendiendo. Y no reviso ni recomiendo proveedores de hosting: las preguntas para el tuyo están en «El orden de trabajo, de lo que más gana a lo que menos».
Las citas de documentos en inglés van en su idioma original, seguidas de una traducción nuestra, y cada una está enlazada en «Fuentes y metodología».
Lo que dicen los datos de las tiendas WooCommerce
Antes de tocar tu tienda, conviene saber dónde fallan las demás. El HTTP Archive publica cada año el Web Almanac, un informe sobre cómo está hecha la web, con datos de millones de sitios. Su capítulo de comercio electrónico de 2025 trae una tabla que ninguna de las guías de velocidad que revisé usa.
35 de cada 100 aprueban en celular
La tabla cuenta orígenes: cada dominio o subdominio, con su protocolo, cuenta una vez. Para cada plataforma dice qué porcentaje tiene buenas las tres métricas de Core Web Vitals, medidas con visitantes reales de Chrome. Los datos son de julio de 2025: la metodología del Almanac dice que «all metrics were sourced from the July 2025 crawl». Traducción nuestra: todas las métricas salieron del rastreo de julio de 2025.
Las tres métricas miden cosas distintas. El LCP, cuánto tarda en aparecer el elemento más grande de la pantalla. El INP, cuánto tarda la página en responder cuando alguien toca algo. Y el CLS, cuánto se mueven las cosas mientras carga. Una tienda aprueba si las tres están en verde.
Así quedaron las plataformas de comercio electrónico en celular.
| Plataforma | Orígenes medidos | LCP bueno | INP bueno | CLS bueno | Aprueba las tres |
|---|---|---|---|---|---|
| Shopify | 567,932 | 86 % | 90 % | 92 % | 76 % |
| Squarespace Commerce | 209,650 | 76 % | 96 % | 89 % | 69 % |
| OpenCart | 32,914 | 80 % | 93 % | 88 % | 68 % |
| Wix eCommerce | 234,055 | 76 % | 85 % | 95 % | 66 % |
| Tiendanube | 21,836 | 60 % | 95 % | 84 % | 51 % |
| PrestaShop | 87,486 | 65 % | 89 % | 81 % | 50 % |
| WooCommerce | 995,782 | 39 % | 88 % | 85 % | 35 % |
| Magento | 50,983 | 52 % | 87 % | 64 % | 35 % |
WooCommerce es la plataforma con más tiendas de la tabla: 995,782 orígenes en celular, el 44.4 % de los sitios de comercio electrónico que detectó el rastreo. Y comparte con Magento la tasa más baja. Shopify aprueba 2.17 veces lo que WooCommerce.
El puntaje de laboratorio cuenta lo mismo. La mediana de Lighthouse, la prueba que da el número del 0 al 100, es de 38 para WooCommerce en celular y de 55 para Shopify. En escritorio, 61 y 71.
Hay un tercer número que ayuda a leer los dos primeros. En el capítulo de gestores de contenido de la misma edición, WordPress en general aprueba en 45 % de los casos en celular. El capítulo lo dice así: «WordPress remains among the lowest-ranked with a pass rate of 45%». Traducción nuestra: WordPress sigue entre los peor clasificados, con una tasa de aprobación de 45 %.
Las tiendas WooCommerce, que corren sobre WordPress, quedan 10 puntos abajo. Son dos capítulos y dos formas de detectar sitios, así que no lo leería como una resta exacta. Pero apunta a lo mismo que este artículo: una tienda es más difícil de acelerar que un sitio de contenido.
Si todavía estás eligiendo plataforma, en la comparativa de WooCommerce contra otras plataformas están los costos de cada una. Esta tabla es la otra mitad de la cuenta: lo que cuesta en velocidad administrar la tuya.
La diferencia está en el LCP
Pon a WooCommerce y a Shopify lado a lado, métrica por métrica.
| Métrica | WooCommerce, celular | Shopify, celular | Diferencia | WooCommerce, escritorio | Shopify, escritorio | Diferencia |
|---|---|---|---|---|---|---|
| LCP bueno | 39 % | 86 % | 47 puntos | 45 % | 92 % | 47 puntos |
| INP bueno | 88 % | 90 % | 2 puntos | 99 % | 99 % | 0 puntos |
| CLS bueno | 85 % | 92 % | 7 puntos | 68 % | 82 % | 14 puntos |
| Aprueba las tres | 35 % | 76 % | 41 puntos | 33 % | 76 % | 43 puntos |
En respuesta al toque, las dos plataformas están casi empatadas. En estabilidad, la distancia es corta. En el LCP, Shopify le saca 47 puntos a WooCommerce, en celular y en escritorio. Ahí está la brecha.
Ahora la cuenta que no viene en el Almanac. Para aprobar hay que aprobar las tres métricas, así que toda tienda que reprueba el LCP reprueba el conjunto. En celular reprueban 65 de cada 100 tiendas WooCommerce, y 61 de esas 65 reprueban el LCP. Es el 93.85 %.
En Shopify reprueban 24 de cada 100, y 14 reprueban el LCP: el 58.33 %. Magento tiene la misma tasa de aprobación que WooCommerce, 35 %, pero sus fallas están más repartidas: el LCP explica el 73.85 %.
El dato también funciona al revés. De las tiendas WooCommerce que aprueban el LCP en celular, el 89.74 % aprueba las tres. El LCP es la puerta.
Dicho para tu tienda: si reprueba, la primera sospecha es el LCP. Por ahí empieza el trabajo.
Por qué el LCP de una tienda falla
El LCP tiene cuatro partes. Google las describe en su guía para optimizarlo, con el reparto que debería tener una página sana sobre los 2.5 segundos del umbral.
| Parte del LCP | Qué es | Parte ideal | Sobre 2.5 segundos |
|---|---|---|---|
| Tiempo hasta el primer byte | Lo que tarda el servidor en empezar a contestar | ~40 % | 1.00 s |
| Retraso de la carga | Lo que pasa entre ese primer byte y el momento en que el navegador pide la imagen | <10 % | 0.25 s |
| Duración de la carga | Lo que tarda en bajar la imagen | ~40 % | 1.00 s |
| Retraso del pintado | Lo que tarda en aparecer en pantalla ya descargada | <10 % | 0.25 s |
Un análisis publicado por Google en web.dev, actualizado en agosto de 2024, revisó datos reales de Chrome y encontró que los sitios con LCP malo no se parecen a ese reparto. En la mitad de ellos, el tiempo hasta el primer byte en el percentil 75 era de 2,270 milisegundos o más. En el sitio mediano, eso dejaba 230 milisegundos para todo lo demás: el 9.2 % del umbral. Casi nada.
La descarga de la imagen, que es lo que arregla la compresión, pesaba poco. El análisis lo dice así: «The majority of origins with poor LCP spend less than 10% of their p75 LCP time downloading the LCP image». Traducción nuestra: la mayoría de los orígenes con LCP malo pasa menos del 10 % de su LCP en el percentil 75 descargando la imagen del LCP.
Y añade dónde sí se va el tiempo: el sitio mediano con LCP malo pasa «almost four times as long waiting to start downloading the LCP image». Traducción nuestra: casi cuatro veces más tiempo esperando a empezar a descargar la imagen del LCP. La comparación es contra lo que tarda la descarga misma. Y el mismo análisis pone esa espera en 1.3 segundos, entre el primer byte y la petición de la imagen.
Ese análisis es de todos los sitios, no solo de tiendas. Pero en una tienda las dos causas tienen nombre propio. El tiempo hasta el primer byte es tu servidor armando una página de WooCommerce, con su catálogo, su carrito y sus precios. Y el retraso antes de pedir la imagen puede venir de una foto principal escondida detrás de un carrusel, de una galería que arma JavaScript o de una carga diferida que no le tocaba.
Lo que eso cambia en el orden de trabajo
Dos de las guías que revisé empiezan por cambiar de hosting, y otra por las imágenes. Los datos sugieren otro orden.
Mi criterio, y va como criterio: primero mediría, para saber cuál de las cuatro partes del LCP es la mía. Después atacaría el servidor y la caché, porque el tiempo hasta el primer byte pesa en todas las páginas de la tienda. Luego la foto principal: que no se difiera y que el navegador la pida pronto. Y al final, el peso de las fotos y el resto de la lista. Es el orden que sugieren los datos de casi un millón de tiendas; el de la tuya lo dice tu medición.
Por qué una tienda es más lenta que un blog
Un blog en WordPress y una tienda en WooCommerce se ven parecidos por fuera. Por dentro, no. La tienda guarda un carrito para cada visitante, calcula precios y envíos, descuenta inventario y escribe un pedido en la base de datos. Y todo eso, mientras otros clientes navegan. Eso cambia las reglas.
La caché de página, que acelera un blog sirviendo copias ya armadas, no llega a todas esas partes.
Las páginas que no se pueden guardar en caché
WordPress arma cada página en el momento: ejecuta código PHP, consulta la base de datos y entrega el resultado. Si quieres el detalle de cómo funciona por dentro, está en qué es WordPress y por qué sigue siendo útil. La caché de página se salta ese trabajo: guarda una copia de la página ya armada y se la entrega al siguiente visitante sin volver a ejecutar nada.
En un blog, casi cualquier página se puede guardar así, porque todos ven lo mismo. En una tienda, no. La guía de WooCommerce para configurar plugins de caché pide excluir tres páginas: el carrito, la cuenta del cliente y la de finalizar compra. Explica el motivo. «These pages need to stay dynamic since they display information specific to the current customer and their cart». Traducción nuestra: estas páginas tienen que seguir siendo dinámicas porque muestran información propia del cliente y de su carrito.
Son las páginas por donde pasa el dinero. Y en cada visita a cualquiera de ellas, el servidor arma la página desde cero.
Las cookies que saltan la caché
La misma guía pide excluir cinco cookies de WooCommerce.
| Cookie | Para qué sirve, según la documentación de cookies de WooCommerce | Duración |
|---|---|---|
| woocommerce_cart_hash | Saber cuándo cambia el contenido del carrito | La sesión |
| woocommerce_items_in_cart | Saber cuándo cambia el contenido del carrito | La sesión |
| wp_woocommerce_session_ | Un código único por cliente para encontrar su carrito en la base de datos | 2 días |
| woocommerce_recently_viewed | Mostrar los productos vistos hace poco | La sesión |
| store_notice | Dejar que el cliente cierre el aviso de la tienda | La sesión |
En un plugin de caché, excluir una cookie quiere decir no servir páginas guardadas a quien la trae. La consecuencia es incómoda. Desde que alguien agrega un producto al carrito, puede seguir navegando la tienda sin caché, según cómo esté configurado tu plugin. Ese visitante, el que ya eligió algo, le cuesta a tu servidor más trabajo que uno que solo mira.
Y si tu sistema de caché también guarda consultas a la base de datos, la guía sugiere excluir de ese almacenamiento las sesiones de WooCommerce.
Lo que pasa en el servidor cuando alguien compra
Durante el pago, WooCommerce guarda un borrador del pedido. Su equipo midió cuántas consultas a la base de datos hacen falta para guardarlo. Lo publicó en las notas de la versión 10.7, de abril de 2026. «Checkout performance without object cache enabled can drop SQL queries from the 204 to 172 range». Traducción nuestra: sin caché de objetos, el rendimiento del pago puede bajar las consultas SQL del rango de 204 al de 172.
Son más de cien consultas para un solo paso del pago, en la versión mejorada. Lo que hace la caché de objetos con ese número está en «Caché de objetos: lo que acelera el carrito y el pago».
A eso se suma lo que tu tienda agregue. Si cotizas envíos en tiempo real con una paquetería, cada cotización es una llamada a otro servidor. Si el pago usa un formulario de la pasarela, su código se carga en esa página. Las cotizaciones cambian con cada cliente, y las dos cosas pasan en páginas que la caché de página no cubre.
Clientes con sesión iniciada
Hay una cuarta categoría: el cliente que entra a su cuenta. WordPress lo trata como usuario con sesión, y cada plugin de caché decide si le sirve páginas guardadas o no.
Revisa esa opción en el tuyo. Si no las sirve, cada cliente que inicia sesión navega todo el catálogo sin caché, aunque solo esté mirando.
Mi criterio, y va como criterio: en una tienda donde los clientes frecuentes compran con su cuenta, esa casilla pesa tanto como el plugin entero. Antes de activarla, comprueba en una copia de la tienda que la cuenta y el carrito de un cliente no se le muestren a otro. Si no puedes comprobarlo, déjala apagada. Un carrito ajeno en pantalla es peor que una página lenta.
Antes de tocar nada: medir
Cada cambio de esta guía se puede medir. Si no mides antes, no vas a saber cuál funcionó, ni si alguno empeoró algo. Son quince minutos y te ahorran semanas.
Laboratorio y campo
PageSpeed Insights, la herramienta gratuita de Google, da dos mediciones distintas en la misma pantalla, y conviene no confundirlas.
La primera son datos de campo: lo que vivieron visitantes reales de Chrome en tu página. La documentación de la herramienta dice que esos datos cubren lo ocurrido «over the previous 28-day collection period». Traducción nuestra: durante el periodo de recolección de los 28 días anteriores. Y Google mide en el percentil 75: según web.dev, «a good threshold to measure is the 75th percentile of page loads, segmented across mobile and desktop devices». Traducción nuestra: un buen umbral para medir es el percentil 75 de las cargas de página, separado entre dispositivos móviles y de escritorio.
En palabras simples: tres de cada cuatro visitas tienen que estar dentro del umbral. Estos son los umbrales que usa la herramienta.
| Métrica | Bueno | Necesita mejorar | Malo |
|---|---|---|---|
| LCP | Hasta 2.5 segundos | De 2.5 a 4 segundos | Más de 4 segundos |
| INP | Hasta 200 milisegundos | De 200 a 500 milisegundos | Más de 500 milisegundos |
| CLS | Hasta 0.1 | De 0.1 a 0.25 | Más de 0.25 |
La segunda medición es de laboratorio: el número del 0 al 100. Sale de Lighthouse, que simula una sola carga. La misma documentación lo describe así: «Lighthouse simulates the page load conditions of a mid-tier device (Moto G4)». Traducción nuestra: Lighthouse simula las condiciones de carga de un dispositivo de gama media, un Moto G4.
El laboratorio sirve para diagnosticar y el campo dice si el arreglo llegó a tus clientes. Como el campo junta 28 días, un cambio de hoy tarda semanas en verse completo. La explicación larga de las dos mediciones está en cómo mejorar la velocidad de tu sitio web.
Una advertencia para tiendas chicas: los datos de campo necesitan visitas. Si tu tienda tiene poco tráfico, puede que PageSpeed no muestre datos de campo de una página concreta, y entonces el laboratorio es lo único que tienes.
Cinco segundos por megabyte
La conexión que simula PageSpeed para celular está documentada en el repositorio de Lighthouse. Da dos valores. «Latency: 150ms». «Throughput: 1.6Mbps down / 750 Kbps up». Traducción nuestra: latencia de 150 milisegundos; velocidad de 1.6 megabits por segundo de bajada y 750 kilobits por segundo de subida. Además, «Lighthouse uses a constant 4x CPU multiplier». Traducción nuestra: Lighthouse usa un multiplicador constante de 4 en el procesador. Es decir, lo hace cuatro veces más lento.
Un megabyte son 8 megabits. A 1.6 megabits por segundo, cada megabyte tarda 5 segundos en bajar, y cada 100 kilobytes, medio segundo.
| Lo que baja | Tiempo de descarga en la conexión simulada |
|---|---|
| 60 KB | 0.30 s |
| 100 KB | 0.50 s |
| 300 KB | 1.50 s |
| 400 KB | 2.00 s |
| 1,000 KB | 5.00 s |
| 1,500 KB | 7.50 s |
No es la conexión de tus clientes: es una vara fija para que dos mediciones se puedan comparar. Pero da escala. Una foto de producto de 400 KB se come 2 de los 2.5 segundos del umbral del LCP, antes de contar el servidor.
Y en México esa vara importa. La ENDUTIH 2025 del INEGI, publicada el 16 de junio de 2026, lo deja claro. «97.3 % de las personas usuarias de internet se conectó a la red mediante un teléfono celular inteligente (smartphone)». Por computadora, el 36.2 %. La misma encuesta reporta que «37.3 % de las personas usuarias reportó hacer compras por internet». Sobre 104.9 millones de usuarios, son unos 39.13 millones de personas, en una cuenta propia.
Las cinco páginas que hay que medir
Una tienda no es una página. Estas cinco cubren el camino de una compra.
- La página de inicio, a donde llega quien escribe el nombre de tu tienda. Si tiene carruseles, videos o avisos, ahí pesan.
- Una categoría con muchos productos, porque junta una foto por producto en una sola página.
- La ficha de producto más visitada, donde el cliente ve el producto antes de agregarlo al carrito y donde la foto principal puede ser el LCP.
- El carrito con un producto adentro.
- La página de finalizar compra.
Las dos últimas tienen un problema: PageSpeed carga la página como un visitante nuevo, sin carrito, así que no mide el pago de alguien que ya eligió productos. Para esas dos, la medición que sirve es la del servidor.
Medir el servidor
Para ver lo que pasa dentro del servidor hace falta otra herramienta. Una opción gratuita es Query Monitor, un plugin que se presenta así: «Query Monitor is the developer tools panel for WordPress and WooCommerce». Traducción nuestra: Query Monitor es el panel de herramientas de desarrollo para WordPress y WooCommerce. Muestra las consultas a la base de datos, los errores de PHP, los scripts y estilos que carga cada página y las llamadas a otros servidores.
Con Query Monitor activo y tu sesión de administrador, agrega un producto al carrito y entra al pago. Anota tres cosas: el tiempo que tardó en generarse la página, el número de consultas y qué componente hizo las más lentas. Así mides, desde adentro, las dos páginas que PageSpeed no puede.
WordPress también trae una revisión propia, en Herramientas, Salud del sitio. Desde la versión 6.1, revisa si tu sitio tiene caché de página y caché de objetos, y considera aceptable una respuesta del servidor por debajo de 600 milisegundos.
Para el tiempo hasta el primer byte, web.dev da una referencia: «most sites should strive to have a TTFB of 0.8 seconds or less». Traducción nuestra: la mayoría de los sitios debería aspirar a un tiempo hasta el primer byte de 0.8 segundos o menos. La misma página aclara que no es una de las tres Core Web Vitals, así que es una guía, no un examen.
Una hoja para medir antes y después
Mi criterio, y va como criterio: haría una hoja con las cinco páginas en filas y cuatro columnas: LCP de laboratorio, tiempo hasta el primer byte, consultas y tiempo de generación en Query Monitor. Mediría cada página tres veces y anotaría la del medio. Y cambiaría una sola cosa a la vez, para que cada mejora tenga dueño. Si cambias cinco cosas un viernes y el lunes la tienda va más lenta, no vas a saber cuál fue.
El servidor: PHP, memoria y base de datos
Si el tiempo hasta el primer byte se come el presupuesto del LCP, el primer lugar donde buscar es el servidor. No hace falta mudarse para mejorarlo. Hay tres revisiones que se hacen desde el panel del hosting.
La versión de PHP, y la fecha del 31 de diciembre
PHP es el lenguaje en el que está escrito WordPress, y cada página de tu tienda lo ejecuta. La página de WordPress que explica por qué actualizarlo lo resume en una frase: «PHP becomes more efficient with each new version». Traducción nuestra: PHP se vuelve más eficiente con cada versión nueva.
Cada versión tiene fechas de soporte publicadas por el propio proyecto. Durante el soporte activo recibe correcciones de todo tipo; después, solo parches de seguridad; y después, nada.
| Versión de PHP | Salió | Soporte activo hasta | Parches de seguridad hasta | El 7 de octubre de 2026 |
|---|---|---|---|---|
| 8.2 | 8 de diciembre de 2022 | 31 de diciembre de 2024 | 31 de diciembre de 2026 | Solo seguridad, por 85 días más |
| 8.3 | 23 de noviembre de 2023 | 31 de diciembre de 2025 | 31 de diciembre de 2027 | Solo seguridad |
| 8.4 | 21 de noviembre de 2024 | 31 de diciembre de 2026 | 31 de diciembre de 2028 | Soporte activo |
| 8.5 | 20 de noviembre de 2025 | 31 de diciembre de 2027 | 31 de diciembre de 2029 | Soporte activo |
Las versiones 8.1 y anteriores ya no aparecen en la tabla de versiones con soporte: no reciben ni parches de seguridad.
La fecha que importa este año es el 31 de diciembre de 2026. Es una fecha fija. Ese día, PHP 8.2 deja de recibir parches de seguridad. Si tu tienda corre en 8.2 o en una versión anterior, el cambio de versión es a la vez una mejora de velocidad y una obligación de seguridad.
Lo que recomiendan las dos partes es parecido. WordPress recomienda PHP 8.3 o más, y documenta soporte completo para PHP 8.4 desde su versión 6.8 y para PHP 8.5 desde la 6.9. WooCommerce recomienda «PHP version 8.3 or greater (tested up to PHP 8.4)». Traducción nuestra: PHP 8.3 o más, probado hasta PHP 8.4. Las dos coinciden en 8.3.
Para saber cuál usa tu tienda, entra a Herramientas, Salud del sitio, pestaña Información, sección Servidor. El cambio se hace en el panel del hosting, y antes de hacerlo conviene tener un respaldo que ya hayas restaurado alguna vez. Los tropiezos de una actualización mal hecha están en errores comunes que tiran un sitio.
Mi criterio, y va como criterio: con una tienda que vende, iría a PHP 8.4. Es la versión más nueva que WooCommerce dice haber probado, y tiene parches de seguridad hasta el 31 de diciembre de 2028. Pero primero, en una copia de la tienda. Ahí haría una compra de prueba completa, con la pasarela en modo de prueba, antes de cambiar la tienda real. Un plugin viejo que no soporta la versión nueva puede fallar en el pago y no en la portada.
Lo que piden WooCommerce y WordPress
Las dos documentaciones publican requisitos recomendados. No son los mínimos para que la tienda arranque: son los que piden para que funcione bien.
| Requisito | WooCommerce recomienda | WordPress recomienda |
|---|---|---|
| PHP | 8.3 o más, probado hasta 8.4 | 8.3 o más |
| Base de datos | MySQL 8.0 o más, o MariaDB 10.6 o más | MySQL 8.0 o más, o MariaDB 10.11 o más |
| Versión de WordPress | 6.9 o más | No aplica |
| Memoria para WordPress | 256 MB o más | No lo fija en esta página |
| HTTPS | Sí | Sí |
La página de requisitos de WooCommerce tiene como fecha de modificación el 25 de mayo de 2026. Desde entonces, la versión 11.1.2 del plugin, publicada en el directorio de WordPress, ya pide WordPress 7.0 o más para instalarse, y PHP 7.4 como mínimo. Son mínimos, no recomendaciones. Que la tienda arranque con PHP 7.4 no quiere decir que deba correr así.
Un renglón fácil de pasar por alto es la memoria. WooCommerce recomienda «WordPress memory limit of 256 MB or greater». Traducción nuestra: un límite de memoria de WordPress de 256 MB o más. Ese límite aparece en Salud del sitio, en la pestaña Información, y si es menor, se ajusta en la configuración de WordPress o se le pide al hosting.
La distancia tiene un piso
Hay una parte del tiempo hasta el primer byte que ningún plugin puede bajar: la distancia entre tu cliente y tu servidor. La luz viaja por la fibra óptica a unos 204,000 kilómetros por segundo. Y antes de recibir el primer byte de una página, una conexión nueva hace varios viajes de ida y vuelta: abrir la conexión, negociar el cifrado y pedir la página.
Con eso se puede calcular un piso. La tabla supone un cliente en la Ciudad de México, la distancia en línea recta y tres viajes de ida y vuelta.
| Si el servidor está en | Distancia en línea recta | Ida y vuelta mínima | Piso con tres viajes |
|---|---|---|---|
| Querétaro | 184 km | 1.8 ms | 5 ms |
| Monterrey | 706 km | 6.9 ms | 21 ms |
| Dallas | 1,502 km | 14.7 ms | 44 ms |
| El norte de Virginia | 3,012 km | 29.5 ms | 89 ms |
| Ámsterdam | 9,217 km | 90.4 ms | 271 ms |
Son pisos físicos, no mediciones. La ruta real de los cables es más larga que la línea recta, y cada equipo de red en el camino agrega tiempo. Pero la escala sirve: un servidor en Europa le cuesta a tu cliente en México más de una cuarta parte de segundo antes de que tu tienda haga cualquier cosa. Ningún plugin baja ese número.
Para las fotos, los estilos y el código, la solución es un CDN, una red que guarda copias de esos archivos cerca de quien los pide. La guía de web.dev sobre las mejoras más efectivas propone dos cosas: servir el contenido lo más cerca posible de los usuarios y guardarlo en caché. Su conclusión es corta. «The best way to do both of these things is to use a CDN». Traducción nuestra: la mejor forma de hacer las dos cosas es usar un CDN.
Pero el carrito y el pago no se guardan en caché, así que para esas páginas la distancia hasta tu servidor sigue contando. Es una pregunta para tu proveedor, junto con las demás de cómo elegir un hosting para una tienda en línea: dónde están físicamente los servidores.
Caché de página: qué sí y qué no
Para las páginas que sí se pueden guardar, la caché de página ataca directo el tiempo hasta el primer byte. En lugar de armar la página con PHP y la base de datos en cada visita, el servidor entrega una copia ya hecha. No recalcula nada. En una tienda, eso cubre la página de inicio, las categorías, las fichas de producto y las páginas informativas, para quien todavía no tiene carrito.
Qué guardar y qué excluir
La lista de exclusiones es la de «Por qué una tienda es más lenta que un blog»: las páginas de carrito, cuenta del cliente y finalizar compra, y las cinco cookies de WooCommerce. Revisa en la configuración de tu plugin que estén excluidas. No des por hecho que lo hace solo.
Hay una prueba de cinco minutos para comprobarlo. Abre la tienda en una ventana privada, agrega un producto al carrito y entra al carrito. Luego ábrela en otro navegador, sin sesión. Si en el segundo ves el carrito del primero, la caché está guardando lo que no debe. Corrígelo antes de cualquier otra cosa.
Un solo sistema de caché
La guía de rendimiento de WooCommerce da dos caminos. Uno es un plugin: «Install and configure a WordPress caching plugin, such as WP Rocket, W3 Total Cache, or WP Super Cache». Traducción nuestra: instala y configura un plugin de caché de WordPress, como WP Rocket, W3 Total Cache o WP Super Cache. El otro es el servidor: «Enable server-side caching through your hosting provider or by using server-level caching solutions like Varnish, NGINX FastCGI Cache, or Redis». Traducción nuestra: activa la caché del lado del servidor con tu proveedor de hosting o con soluciones de servidor como Varnish, NGINX FastCGI Cache o Redis.
Mi criterio, y va como criterio: los trataría como dos caminos, no como dos capas que se suman. Dos sistemas guardando la misma página pueden estorbarse. Y cuando algo falla, no sabes cuál fue. Si tu hosting ofrece caché a nivel de servidor, usaría esa y no instalaría un plugin de caché de página encima. Si no la ofrece, un solo plugin. Y en los dos casos haría la prueba del carrito en dos navegadores el mismo día del cambio.
Minificar y combinar, con cuidado
Algunos plugins de caché traen casillas para minificar y combinar archivos de JavaScript. En una tienda, esas casillas tocan el código del carrito y de la pasarela de pago. La guía de WooCommerce sobre plugins de caché tiene un apartado para WP Rocket. Su recomendación es directa. «We recommend avoiding JavaScript file minification». Traducción nuestra: recomendamos evitar la minificación de archivos JavaScript.
Además, ahí no está la brecha. En el Web Almanac, el 88 % de las tiendas WooCommerce tiene buen INP en celular, la métrica de respuesta, en la que pesa el JavaScript, contra 90 % de Shopify. El hueco grande es el LCP: 47 puntos.
Si de todos modos activas la minificación, haz una compra de prueba completa después, con la pasarela en modo de prueba.
Cómo saber si la caché funciona
Salud del sitio, en Herramientas, revisa desde WordPress 6.1 si detecta caché de página y mide el tiempo de respuesta del servidor, con 600 milisegundos como límite de lo aceptable. Es una revisión gruesa. Pero es gratis y ya está instalada. La medición fina es la de tu hoja: el tiempo hasta el primer byte de la página de inicio, de una categoría y de una ficha, antes y después.
Caché de objetos: lo que acelera el carrito y el pago
La caché de página no llega al carrito ni al pago. La caché de objetos sí llega. No guarda páginas: guarda en memoria los resultados de consultas a la base de datos, para que la siguiente petición no tenga que repetirlas.
Qué es y qué hace falta
WordPress ya guarda resultados en memoria mientras arma una página, pero los olvida al terminar. Su documentación lo dice en una línea. «By default, the object cache is non-persistent». Traducción nuestra: por defecto, la caché de objetos no es persistente. Según la misma página, los datos viven en memoria solo mientras dura la petición. Una caché de objetos persistente los conserva entre visitas, en un servicio como Redis o Memcached. La guía de WooCommerce sobre la tabla de opciones lo explica. «To set up object caching, you can use a third-party caching tool like Redis or Memcached and install a WordPress caching plugin». Traducción nuestra: para configurar la caché de objetos, puedes usar una herramienta de terceros como Redis o Memcached e instalar un plugin de caché de WordPress.
Hacen falta dos piezas: el servicio en el servidor, que pone el hosting, y un plugin que conecte WordPress con él. Sin el servicio, el plugin no tiene dónde guardar.
Cuándo la recomienda WordPress
Salud del sitio recomienda una caché de objetos persistente cuando el sitio pasa ciertos umbrales. En el código de WordPress están así.
| Lo que cuenta | Umbral |
|---|---|
| Filas de la tabla de entradas | 1,000 |
| Filas de la tabla de opciones | 1,000 |
| Filas de comentarios, de términos o de usuarios | 1,000 cada una |
| Opciones que se cargan solas en cada página | 500 |
| Tamaño de esas opciones | 100,000 bytes |
El código cuenta todas las filas de cada tabla, sin importar su tipo. Y en una tienda, la tabla de entradas no guarda solo páginas. Antes de HPOS, el sistema que se explica en «Pedidos en tablas propias: HPOS», WooCommerce guardaba cada pedido en esa misma tabla.
Un ejemplo inventado: una tienda con el esquema anterior que recibe 100 pedidos al mes llega a 1,000 filas solo con pedidos en 10 meses, y en un año suma 1,200.
WooCommerce pone una vara más estricta para la tabla de opciones: «ideally less than 500 rows». Traducción nuestra: idealmente, menos de 500 filas.
Lo que midió WooCommerce en el pago
WooCommerce publicó la cuenta en las notas de su versión 10.7, de abril de 2026. Contó cuántas consultas hacen falta para guardar el borrador de un pedido en el pago, con y sin caché de objetos. Sobre la caché de objetos, escribieron esto. «However, with object cache enabled, the reduction is more noticeable, ranging from 127 queries to as low as 115». Traducción nuestra: con la caché de objetos activa, la reducción es más notoria, de 127 consultas a tan pocas como 115.
| Antes de la mejora de la 10.7 | Después | |
|---|---|---|
| Sin caché de objetos | 204 consultas | 172 consultas |
| Con caché de objetos | 127 consultas | 115 consultas |
| Lo que ahorra la caché de objetos | 37.7 % | 33.1 % |
La mejora del código bajó las consultas 15.7 % sin caché de objetos y 9.4 % con ella. La caché de objetos, por su parte, ahorró entre 33.1 % y 37.7 %. Con las dos cosas, de 204 a 115 consultas: 43.6 % menos, 89 consultas menos por cada borrador de pedido.
Una precisión: son consultas, no segundos. WooCommerce no publicó ahí el tiempo. Y no todas las consultas tardan lo mismo. Pero en el pago no hay caché de página. Ahí, cada consulta menos es trabajo que el servidor no hace.
Cómo saber si tu hosting la ofrece
Entra a Salud del sitio y mira si te recomienda una caché de objetos persistente. Si lo hace, pregúntale a tu hosting si tiene Redis o Memcached disponibles en tu plan y qué plugin sugiere para conectarlo. Si tu plan no la incluye, anótalo. Es un dato para decidir si cambias de hosting.
Mi criterio, y va como criterio: si el hosting la ofrece y tu tienda pasa los umbrales, activaría la caché de objetos antes que cualquier plugin de optimización del frente. Llega al pago; la caché de página, no. Y después de activarla haría dos compras de prueba seguidas: si la segunda muestra precios, existencias o carritos viejos, algo quedó mal conectado.
Las fotos de producto
Las fotos van después del servidor. El motivo está en «Por qué el LCP de una tienda falla»: en la mayoría de los sitios con LCP malo, la descarga de la imagen pesa poco al lado de la espera. Pero en una tienda, las fotos son el producto. Y una foto mal subida puede comerse lo que ganaste en el servidor.
Los tres tamaños de WooCommerce
Cuando subes una foto, WordPress guarda el original y crea copias más chicas. WooCommerce registra tres tamaños propios para los temas clásicos. Su documentación los describe así.
- La miniatura de catálogo: «woocommerce_thumbnail defaults to 300px width, square cropped so the product grids look neat». Traducción nuestra: la miniatura mide por defecto 300 píxeles de ancho, recortada en cuadrado para que las cuadrículas de productos se vean ordenadas.
- La foto de la ficha: «woocommerce_single shows the full product image, as uploaded, so is always uncropped by default». Traducción nuestra: la foto de la ficha muestra la imagen completa, como se subió, así que por defecto siempre queda sin recortar. Según la misma documentación, su ancho por defecto es de 600 píxeles.
- La miniatura de la galería: «woocommerce_gallery_thumbnail is always square cropped and defaults to 100×100 pixels». Traducción nuestra: la miniatura de la galería siempre se recorta en cuadrado y mide por defecto 100 por 100 píxeles.
Los anchos se cambian en el personalizador del tema, en la sección de WooCommerce. Si los cambias, las copias se rehacen solas. La documentación lo fecha. «WooCommerce 3.3 introduced thumbnail regeneration functionality». Traducción nuestra: WooCommerce 3.3 introdujo la función de regenerar miniaturas. Según la misma página, WooCommerce detecta los cambios de tamaño que publicas en el personalizador, o los de un cambio de tema, y rehace las copias en segundo plano.
Cuántos píxeles sobran
Un ejemplo inventado: subes una foto de 2,000 por 2,000 píxeles, cuatro millones de píxeles, y el tema la muestra completa en un espacio de 300 por 300. La miniatura que hacía falta tenía 90,000.
| Dónde se ve | Tamaño de WooCommerce | Píxeles de más con el original, pantalla normal | Con pantalla de alta densidad, que pide el doble de ancho |
|---|---|---|---|
| Cuadrícula del catálogo | 300 px | 44.44 veces | 11.11 veces |
| Ficha de producto | 600 px | 11.11 veces | 2.78 veces |
| Galería de la ficha | 100 px | 400 veces | 100 veces |
La comparación justa es la de la derecha. Supone una pantalla de alta densidad, que pide el doble de píxeles de ancho para verse nítida. Aun así, el original en la cuadrícula lleva 11 veces más de lo necesario.
El tamaño correcto existe. El problema aparece cuando el tema o un plugin piden el original en lugar de la copia. PageSpeed puede señalarlo en su diagnóstico, con la lista de imágenes que se descargan más grandes de lo que se muestran.
WebP y AVIF
El formato es la segunda palanca. La documentación de Google sobre WebP da la cifra. «WebP lossy images are 25-34% smaller than comparable JPEG images at equivalent SSIM quality index». Traducción nuestra: las imágenes WebP con pérdida son entre 25 y 34 % más ligeras que imágenes JPEG comparables, con un índice de calidad SSIM equivalente. Y para las que no tienen pérdida: «WebP lossless images are 26% smaller in size compared to PNGs». Traducción nuestra: las imágenes WebP sin pérdida son 26 % más ligeras que las PNG.
AVIF comprime más. WordPress lo acepta desde su versión 6.5. Su anuncio lo pone así. «AVIF images can be up to 50% smaller than JPEGs while maintaining the same image quality». Traducción nuestra: las imágenes AVIF pueden ser hasta 50 % más ligeras que las JPEG con la misma calidad. Pero depende de tu servidor. El mismo anuncio explica cómo comprobarlo: en Herramientas, Salud del sitio, pestaña Información, sección de manejo de medios, buscando AVIF en la lista de formatos.
Un ejemplo inventado, con la conexión simulada de PageSpeed: una foto de producto de 400 KB en JPEG tarda 2.00 segundos en bajar. En WebP pesaría entre 264 y 300 KB, de 1.32 a 1.50 segundos. En AVIF, con el ahorro máximo, bajaría a 200 KB y 1.00 segundo. Redimensionada al tamaño en que se muestra, digamos a 60 KB, tarda 0.30 segundos.
El formato ahorra hasta un tercio en WebP o hasta la mitad en AVIF. El tamaño correcto ahorra mucho más. Por eso, en este orden, primero el tamaño y después el formato.
La primera foto de la ficha
En una ficha de producto, el elemento que mide el LCP puede ser la foto principal. PageSpeed te dice cuál es en su diagnóstico. Confírmalo antes de tocar nada.
Si es la foto, hay dos reglas de Google para ella. Ninguna tiene que ver con comprimir. La primera es no diferir su carga. La guía para optimizar el LCP es tajante. «Never lazy-load your LCP image, as that will always lead to unnecessary resource load delay, and will have a negative impact on LCP». Traducción nuestra: nunca apliques carga diferida a la imagen del LCP, porque siempre agrega un retraso innecesario a su carga y empeora el LCP.
La segunda es darle prioridad, con el atributo fetchpriority="high". WordPress lo agrega solo desde la versión 6.3 a la imagen que considera candidata a LCP, y su equipo de rendimiento estimó que eso «typically improves LCP by 5-10%». Traducción nuestra: por lo general mejora el LCP entre 5 y 10 %.
Comprueba las dos cosas en el código de tu ficha: que la foto principal no lleve loading="lazy" y que lleve fetchpriority="high". Si tu tema arma la galería con JavaScript, como carrusel o con efectos, puede que la foto no exista para el navegador hasta que ese código corre. Es el tipo de retraso que mide el análisis de Google: 1.3 segundos de espera en el sitio mediano con LCP malo.
Mi criterio, y va como criterio: en la ficha, la primera foto la mostraría como imagen normal, sin carrusel, y dejaría las demás en miniaturas de galería. No encontré datos de que un carrusel en la ficha venda más que una foto quieta. Lo que sí documenta Google es lo que cuesta que el navegador tarde en pedir la imagen.
Una categoría con dieciséis productos
Otro ejemplo inventado, con la misma conexión simulada. Una categoría muestra 16 productos. Si cada foto llega como un archivo de 250 KB, porque el tema pide una copia demasiado grande, la cuadrícula pesa 4,000 KB. Tarda 20.00 segundos en bajar. Con miniaturas de 25 KB, pesa 400 KB y tarda 2.00 segundos. Son 18 segundos de diferencia, sin tocar el servidor.
En la categoría, a diferencia de la ficha, la carga diferida sí ayuda: las fotos de abajo no se descargan hasta que el cliente baja. Lo que no conviene es aplicarla a las primeras fotos de la cuadrícula, las que se ven sin desplazarse. Una de ellas puede ser el elemento del LCP.
La base de datos de una tienda
Una tienda acumula datos que un blog no tiene: pedidos, sesiones de clientes, tareas en segundo plano. Ese peso puede no verse en PageSpeed. Pega donde no hay caché: en el pago, en la cuenta del cliente y en el panel de administración.
Pedidos en tablas propias: HPOS
Durante años, WooCommerce guardó los pedidos con el mismo sistema que WordPress usa para las entradas del blog: en sus tablas de entradas y de metadatos, un dato por fila. Con cientos de miles de pedidos, como en la prueba de abajo, buscar uno se vuelve lento.
HPOS, las siglas en inglés de almacenamiento de pedidos de alto rendimiento, los pasa a cuatro tablas propias: una de pedidos, una de direcciones, una de datos operativos y una de metadatos. Las notas de la versión 8.2, de octubre de 2023, lo anunciaron. «High-Performance Order Storage (HPOS) is officially released in 8.2.0 under the stable flag and is enabled by default for new installations». Traducción nuestra: HPOS se lanza oficialmente como estable en la 8.2.0 y viene activado por defecto en las instalaciones nuevas.
Si tu tienda es anterior a esa versión, puede seguir con el sistema viejo. Revísalo. Lo ves en WooCommerce, Ajustes, Avanzado, Características: la documentación en inglés lo ubica en Settings, Advanced, Features.
La promesa de WooCommerce fue grande. «up to 5x improvement in order creation speed and up to 1.5x faster checkout». Traducción nuestra: hasta 5 veces más rápido para crear pedidos y hasta 1.5 veces más rápido en el pago. Y para buscar: «finding an order will now be up to 40x faster». Traducción nuestra: encontrar un pedido será hasta 40 veces más rápido.
Esas cifras salen de una prueba que el equipo de WooCommerce publicó en marzo de 2023. Usó una tienda de 400,000 pedidos y 30,000 productos, en un plan Business de WordPress.com con Memcached activo.
| Operación | Con HPOS | Con las tablas de entradas | Veces más rápido |
|---|---|---|---|
| Crear 1,000 pedidos | 15.18 s | 78.12 s | 5.15 |
| Procesar 10 pagos | 0.99 s | 1.51 s | 1.52 |
| Buscar 1,000 pedidos por metadatos | 0.053 s | 0.64 s | 12.09 |
| Filtrar 1,000 pedidos por cliente | 0.016 s | 0.60 s | 37.52 |
Ahora la cuenta que no viene en el anuncio. En el pago, la diferencia fue de 51.70 milisegundos por compra: 99.17 contra 150.87 milisegundos. Es una vigésima de segundo. Donde HPOS cambia las cosas es en el panel: buscar y filtrar pedidos fue de 12.09 a 37.52 veces más rápido, en una tienda de 400,000 pedidos. Con menos pedidos, la distancia debería achicarse. Pero WooCommerce no publicó pruebas con tiendas chicas.
Hay un detalle más. La migración trae un modo de compatibilidad. En la documentación, su casilla se llama «Enable compatibility mode (synchronizes orders to the posts table)». Traducción nuestra: activar el modo de compatibilidad, que sincroniza los pedidos con la tabla de entradas. Mantiene una copia de cada pedido en las tablas viejas, para los plugins que todavía no leen las nuevas. Esa copia es trabajo extra en cada pedido.
Mi criterio, y va como criterio: si tu tienda viene de antes de la 8.2 y tus plugins de pago, envíos y facturación ya son compatibles, migraría a HPOS en una copia. Revisaría que los pedidos se vean completos. Y después de unas semanas sin problemas, apagaría la sincronización. Pero no lo haría pensando en la velocidad que ve el cliente, sino en la del panel.
La cola de tareas programadas
WooCommerce y sus plugins hacen trabajo en segundo plano. Lo organizan con Action Scheduler. Su sitio lo describe así. «A scalable, traceable job queue for background processing large queues of tasks in WordPress». Traducción nuestra: una cola de trabajos escalable y rastreable para procesar en segundo plano grandes colas de tareas en WordPress.
Cada tarea terminada queda registrada. El código de Action Scheduler borra por defecto las tareas completadas y canceladas después de 31 días, 2,678,400 segundos, en lotes de 20. Si la cola funciona, se limpia sola.
El problema es cuando no funciona. La pantalla está en WooCommerce, Estado, Acciones programadas. Si se acumulan miles de tareas pendientes con fechas pasadas, la cola no está corriendo al día. Y las fallidas no entran en esa limpieza por defecto, que solo borra las completadas y las canceladas.
Las opciones que se cargan en cada página
WordPress guarda configuraciones en una tabla de opciones. Algunas se cargan en cada página. La guía de WooCommerce explica el riesgo. «When options have autoload set to yes, WordPress loads this data on every page, which can slow down the site if there’s too much data marked for autoload». Traducción nuestra: cuando una opción tiene la carga automática activada, WordPress carga esos datos en cada página, lo que puede hacer lento el sitio si hay demasiados datos marcados así.
WordPress 6.6 cambió dos cosas. Una opción de más de 150,000 bytes ya no se carga sola salvo que el plugin lo pida: «a value that is greater than 150k bytes will no longer be set to autoload». Traducción nuestra: un valor de más de 150,000 bytes ya no se marcará para carga automática. Y Salud del sitio muestra un problema crítico, «Autoloaded options could affect performance», cuando el total pasa de 800 KB. Traducción nuestra: las opciones de carga automática podrían afectar el rendimiento.
Esas opciones se quedan cuando desinstalas un plugin que no las borra. Si Salud del sitio te muestra el aviso, un origen posible son plugins que ya no usas. La limpieza se hace con un respaldo reciente. Mejor, con ayuda de quien sepa leer la tabla.
WP-Cron
Las tareas programadas de WordPress no tienen reloj propio. La documentación para desarrolladores lo explica. «WP-Cron does not run continuously, which can be an issue if there are critical tasks that must run on time». Traducción nuestra: WP-Cron no corre de forma continua, lo que puede ser un problema si hay tareas críticas que deben ejecutarse a tiempo. Corre cuando alguien visita el sitio.
Y Action Scheduler depende de él. «The scheduler will attempt to run every minute by attaching itself as a callback to the ‘action_scheduler_run_schedule’ hook, which is scheduled using WordPress’s built-in WP-Cron system». Traducción nuestra: el programador intenta correr cada minuto, colgado de un evento que se programa con el WP-Cron integrado de WordPress.
En una tienda con pocas visitas de madrugada, las tareas esperan. Y en una con muchas, cada visita puede cargar con trabajo que no es suyo. La documentación da la salida: desactivar el WP-Cron que depende de las visitas, con la línea define( 'DISABLE_WP_CRON', true ); en la configuración, y pedirle al servidor que lo llame con una tarea programada real. Pídeselo a tu hosting. Es la pregunta 5 de la lista de «El orden de trabajo, de lo que más gana a lo que menos».
El catálogo, el carrito y los scripts
Después del servidor, la caché y las fotos quedan las piezas propias de WooCommerce. Algunas corren en el navegador. Otras le piden trabajo extra al servidor desde la página. Son cinco revisiones.
Los fragmentos del carrito
El carrito del encabezado, el que muestra el número de productos, se actualiza sin recargar la página. Detrás hay un mecanismo. El equipo de WooCommerce lo explicó en 2023. «WooCommerce cart fragments is a script that uses the WordPress admin-ajax API to update the cart without refreshing the page». Traducción nuestra: los fragmentos del carrito son un script que usa la interfaz admin-ajax de WordPress para actualizar el carrito sin recargar la página.
Cada una de esas actualizaciones es una petición más al servidor, fuera de la caché de página. Hasta la versión 7.8, de junio de 2023, el script se cargaba aunque la página no mostrara el carrito. El mismo equipo lo reconoció. «This was less than ideal leading to unnecessary additional AJAX requests to the server». Traducción nuestra: no era lo ideal, porque provocaba peticiones AJAX adicionales e innecesarias al servidor.
Desde la 7.8 cambió. «Going forward the script will now only be enqueued if the Cart Widget is rendered in a view». Traducción nuestra: de aquí en adelante, el script solo se cargará si el widget del carrito aparece en la página.
La pregunta para tu tienda es otra. ¿Tu tema usa ese widget clásico? La alternativa que propone WooCommerce es el bloque de minicarrito, que según el mismo texto «does not use the cart fragments API». Traducción nuestra: no usa la interfaz de fragmentos del carrito. Query Monitor te dice qué scripts carga cada página. Revisa la portada. Si el de fragmentos aparece ahí, tu tema o algún plugin todavía lo usa.
Productos con muchas variaciones
Un ejemplo inventado: una playera en cinco colores y seis tallas tiene 30 variaciones. WooCommerce tiene un límite justo ahí. Lo fija su documentación. «By default, if a Variable product has 30 or fewer variations, the dropdowns for selecting variations on the frontend will be dynamic». Traducción nuestra: por defecto, si un producto variable tiene 30 variaciones o menos, los menús para elegir la variación son dinámicos. Y del otro lado: «However, if there are more than 30 variations, the dropdowns will be static and will display all attributes». Traducción nuestra: con más de 30, los menús son estáticos y muestran todos los atributos.
Con menús estáticos, el cliente puede elegir una combinación que no existe y recibir un error. Por eso es tentador subir el límite, con el filtro woocommerce_ajax_variation_threshold. La documentación advierte el costo. «Choose the lowest value that works for your store, because higher values can affect product-page performance». Traducción nuestra: elige el valor más bajo que funcione para tu tienda, porque los valores altos pueden afectar el rendimiento de la ficha de producto.
| Producto inventado | Combinaciones | Frente al límite de 30 |
|---|---|---|
| Playera, 5 colores por 6 tallas | 30 | Dentro |
| Playera, 5 colores por 7 tallas | 35 | Fuera |
| Tenis, 4 colores por 6 tallas por 3 anchos | 72 | Fuera |
| Pantalón, 8 colores por 6 tallas por 3 largos | 144 | Fuera |
Mi criterio, y va como criterio: antes de subir el límite, revisaría si el producto tiene que ser uno solo. El pantalón de la tabla, dividido por largo, daría tres productos de 48 combinaciones. Siguen fuera. Dividido por color, daría ocho productos de 18 combinaciones cada uno, y cada ficha quedaría dentro del límite de 30. Si de todos modos subes el límite, mide la ficha antes y después, como en «Una hoja para medir antes y después».
Los filtros por atributo
Filtrar el catálogo por talla o por color puede ser una consulta pesada. Desde la versión 5.6 existe, como opción, una tabla dedicada a esas búsquedas. En la 6.3, anunciada en febrero de 2022, pasó a activarse sola. Su opción se llama «Use the product attributes lookup table for catalog filtering». Traducción nuestra: usar la tabla de búsqueda de atributos de producto para filtrar el catálogo.
El anuncio de esa versión explicó que la opción «will have been enabled automatically after the database migration finishes». Traducción nuestra: quedará activada automáticamente cuando termine la migración de la base de datos. Revisa que siga activa. Está en WooCommerce, Ajustes, Productos, Avanzado. Si alguien la apagó para resolver un problema y no la volvió a encender, tus filtros trabajan de más.
Los scripts de terceros
El píxel de publicidad, el chat, las reseñas, el mapa de calor, el código de la pasarela. Cada uno es un archivo más que el navegador descarga y ejecuta. La guía de web.dev sobre las mejoras más efectivas lo pone en contexto. «Websites are shipping more JavaScript than ever before». Traducción nuestra: los sitios cargan más JavaScript que nunca.
En las tiendas WooCommerce, el INP, la métrica de respuesta, en la que pesa el JavaScript, está bien en 88 de cada 100 en celular. En INP, la distancia con Shopify es de 2 puntos. Pero pueden competir por la conexión con la foto principal. Y eso sí pega en el LCP.
La revisión es un inventario. Abre la portada con Query Monitor, anota cada script que no es de tu tema ni de WooCommerce, y pregunta para qué sirve. El código de la pasarela de pago, por ejemplo, hace falta en el pago. Si también se carga en la portada, pregúntale al plugin o a la pasarela si se puede limitar.
Mantener WooCommerce al día también es velocidad
Una parte de la velocidad llega sola con las actualizaciones. Desde la versión 8.3, de noviembre de 2023, las tiendas nuevas traen el carrito y el pago en bloques. Las notas de esa versión lo anunciaron. «Starting with WooCommerce version 8.3, we’ve integrated Cart, Checkout, and Order Confirmation blocks as the default checkout experience for new installations». Traducción nuestra: desde la versión 8.3, el carrito, el pago y la confirmación del pedido en bloques son la experiencia de pago por defecto en las instalaciones nuevas.
Esos bloques hablan con el servidor a través de la Store API. Según la documentación de WooCommerce, cada cambio de cupón, envío o cantidad es una petición a esa interfaz. La versión 11.1, del 1 de septiembre de 2026, aceleró esas peticiones. El equipo lo explicó en su blog para desarrolladores. «Store API and WooCommerce REST requests are 13–18 ms (30–42%) faster in our measurements». Traducción nuestra: las peticiones a la Store API y a la API REST de WooCommerce son de 13 a 18 milisegundos (de 30 a 42 %) más rápidas en nuestras mediciones. El cambio fue dejar de registrar bloques y patrones en las peticiones que no dibujan una página.
El porcentaje suena grande. En tiempo, son menos de dos centésimas de segundo por petición. Pero en el pago, el cliente puede hacer varias.
Antes, la 10.7, de abril de 2026, había bajado las consultas del pago, como se ve en «Lo que midió WooCommerce en el pago». Ninguna llega a una tienda que no actualiza.
Plugins: no es cuántos, es qué hacen
El consejo de tener pocos plugins es fácil de dar y difícil de aplicar, porque no dice cuáles. El número dice poco. Lo que pesa es lo que cada plugin hace en cada página: cuántas consultas agrega a la base de datos, cuántos scripts carga y cuántas veces llama a otros servidores.
Y en una tienda hay plugins que trabajan producto por producto. Uno de precios dinámicos o de conversión de moneda puede tener que calcular algo en cada producto que muestra la categoría. Uno que agrega opciones a la ficha puede consultar sus propias tablas cada vez que la ficha se arma.
Cómo medir un plugin
Query Monitor, el plugin de «Medir el servidor», está pensado justo para esto. Su página lo describe. «Query Monitor focuses heavily on presenting its information in a useful manner, for example by showing aggregate database queries grouped by the plugins, themes, or functions that are responsible for them». Traducción nuestra: Query Monitor se concentra en presentar su información de forma útil, por ejemplo, mostrando las consultas a la base de datos agrupadas por los plugins, temas o funciones responsables. Según la misma página, también marca las lentas, duplicadas o con error.
Con eso, el método es sencillo. Abre la portada, una categoría, una ficha y el pago con Query Monitor activo. Anota qué plugins aparecen arriba en consultas y en tiempo. Luego, en una copia de la tienda, desactiva uno, mide otra vez, reactívalo y sigue con el siguiente. El procedimiento completo, y cómo leer los datos del directorio antes de instalar, está en qué son los plugins y cuáles sí valen la pena.
Mi criterio, y va como criterio: para cada plugin que aparezca arriba en Query Monitor haría una sola pregunta: ¿qué pasa en la tienda si lo apago una semana? Si la respuesta es nada que un cliente note, lo desinstalaría, no solo lo desactivaría. Y si la respuesta es que deja de cobrar o de calcular envíos, lo dejaría y buscaría el ahorro en otra parte de esta lista.
Probar sin afectar a los clientes
Todo lo anterior se hace en una copia de la tienda, un entorno de pruebas. Pregúntale a tu hosting si tu plan lo incluye. En la copia puedes desactivar plugins, cambiar la versión de PHP o activar la caché de objetos sin que un cliente vea el error.
Hay una alternativa: el modo de solución de problemas, que desactiva plugins solo para tu sesión de administrador mientras los visitantes ven la tienda normal. Nació en el plugin Health Check & Troubleshooting. Su página en el directorio de WordPress avisa que no se ha actualizado en más de dos años. Hoy existe también como plugin aparte. Para una tienda que vende, la copia sigue siendo más segura. El modo de solución de problemas trabaja sobre la base de datos real, así que cualquier ajuste que cambies ahí lo ven tus clientes.
Una última regla, que viene de las demás: después de cada cambio, una compra de prueba completa. Agregar al carrito, aplicar un cupón, elegir envío y pagar con la pasarela en modo de prueba. Si sale bien, el cambio se queda. Si no, se revierte.
Cuánto vale una tienda más rápida
Acelerar una tienda cuesta: horas de alguien, un plan de hosting mejor, un servicio de caché. La pregunta razonable es cuánto devuelve. Hay un estudio que responde una parte, y una cuenta que responde la otra.
Lo que midió el estudio de Deloitte
Hay un estudio de 2020 que mide esto. También lo cita la guía de velocidad de esta serie. Se llama «Milliseconds make millions». El resumen que publicó web.dev, el sitio de Google para desarrolladores, aclara quién lo hizo. «The study was commissioned by Google and conducted by 55 and Deloitte». Traducción nuestra: el estudio lo encargó Google y lo hicieron 55 y Deloitte. 55 es una agencia de análisis. Midió sitios de comercio, lujo, viajes y generación de contactos en Europa y Estados Unidos, con «37 brands accounting for 30m user sessions over a 4 week period». Traducción nuestra: 37 marcas, con 30 millones de sesiones, durante un periodo de 4 semanas. Según el informe, fueron del 28 de octubre al 24 de noviembre de 2019.
Su resultado para el comercio minorista: con una mejora de una décima de segundo en la velocidad móvil, «An 8.4% increase in conversions with retail consumers was observed». Traducción nuestra: se observó un aumento de 8.4 % en las conversiones de los consumidores de comercio minorista. El resumen de web.dev agrega dos cifras: un gasto 9.2 % mayor y el paso de la ficha al carrito. «a 9.1% increase from Product Details Page to Add To Basket Page». Traducción nuestra: un aumento de 9.1 % en el paso de la ficha de producto a agregar al carrito.
Ahora, lo que dice el informe completo. Aclara que no fue un experimento. «Fluctuations in speed all occurred naturally and were not artificially created on any of the sites». Traducción nuestra: las variaciones de velocidad ocurrieron de forma natural y no se provocaron en ninguno de los sitios. Lo que encontró fue una relación. «The study managed to find statistically significant correlation between site speed and revenue-related metrics». Traducción nuestra: el estudio encontró una correlación estadísticamente significativa entre la velocidad del sitio y métricas relacionadas con los ingresos.
Y la décima de segundo no es la de hoy. El informe midió cuatro indicadores de 2019: la latencia máxima del servidor, la primera pintura significativa, la latencia estimada de entrada y la carga del observador. Ninguno es una Core Web Vital. Y aclara otra cosa. «The 0.1 second improvement was the cumulative impact of all four speed metrics». Traducción nuestra: la mejora de 0.1 segundos fue el efecto acumulado de las cuatro métricas de velocidad.
Hay una operación tentadora que conviene ver para no hacerla. Si multiplicas el 8.4 % de conversiones por el 9.2 % de ticket, te da 18.37 % más venta por cada décima de segundo. No se puede. Las dos cifras son correlaciones medidas sobre las mismas sesiones, en marcas europeas y estadounidenses, con métricas que ya no se usan. Sirven para saber que la velocidad y la venta se mueven juntas, no para prometerle un porcentaje a tu tienda.
Para tu tienda, lo útil es pensar en pesos. Una venta extra no vale solo esa compra: un cliente que vuelve vale más que uno que compra una vez. Cuánto más se calcula con el método de cuánto vale un cliente.
La cuenta que sí puedes hacer
En lugar de adivinar cuánto vas a vender de más, se puede calcular cuánto tienes que vender de más para que la mejora se pague.
Venta extra para que se pague = costo mensual de la mejora ÷ margen.
El margen es lo que te queda de cada peso vendido, después del costo del producto. Si no lo tienes calculado, está explicado en cómo calcular el margen de ganancia de un producto.
Esta tabla usa costos y márgenes inventados, para que pongas los tuyos.
| Costo de la mejora al mes | Con margen de 20 % | Con margen de 30 % | Con margen de 40 % |
|---|---|---|---|
| 300 pesos | 1,500 pesos | 1,000 pesos | 750 pesos |
| 600 pesos | 3,000 pesos | 2,000 pesos | 1,500 pesos |
| 1,200 pesos | 6,000 pesos | 4,000 pesos | 3,000 pesos |
La siguiente muestra lo mismo como porcentaje de la venta de una tienda inventada de 100,000 pesos al mes.
| Costo de la mejora al mes | Con margen de 20 % | Con margen de 30 % | Con margen de 40 % |
|---|---|---|---|
| 300 pesos | 1.50 % | 1.00 % | 0.75 % |
| 600 pesos | 3.00 % | 2.00 % | 1.50 % |
| 1,200 pesos | 6.00 % | 4.00 % | 3.00 % |
Léelo así: si una mejora cuesta 600 pesos al mes y tu margen es de 30 %, se paga con 2,000 pesos de venta extra, el 2 % de lo que vende esa tienda. Si vendes 300,000 al mes, la misma mejora se paga con 0.67 %. Si vendes 50,000, necesitas 4 %.
La cuenta tiene un límite claro: no te dice si la mejora va a traer ese 2 %. Te dice cuánto tiene que traer. Y eso se compara con algo que sí puedes medir: tu propia tasa de conversión, antes y después, en las páginas que cambiaste.
Mi criterio, y va como criterio: con una tienda que reprueba el LCP en celular, haría primero lo que cuesta horas y no pesos. Medir, la foto principal, la versión de PHP, la cola de tareas. Y solo pagaría algo cada mes cuando la cuenta pida un porcentaje que me parezca alcanzable y tenga cómo medirlo. Si la cuenta me pide 6 % más de venta, primero buscaría la mejora gratis.
El calendario: Buen Fin y fin de PHP 8.2
Este trabajo tiene dos fechas este año. Ninguna es opinión: las dos son de calendario.
La primera es El Buen Fin. La edición 2026 va del viernes 13 al martes 17 de noviembre, cinco días y 120 horas, según las fechas que publicó la prensa a partir del anuncio de sus organizadores. No pude abrir el sitio oficial para confirmarlas. Revísalas ahí antes de planear. Desde el 7 de octubre, son 37 días.
La segunda es el 31 de diciembre de 2026, un jueves, cuando PHP 8.2 deja de recibir parches de seguridad. Desde el 7 de octubre, son 85 días. Si tu tienda corre en 8.2 o en algo más viejo, ese cambio tiene fecha.
Entre las dos hay un problema: la temporada de compras no termina con El Buen Fin. Diciembre trae Navidad, y enero, Reyes. Cambiar la versión de PHP a mitad de diciembre es arriesgar la tienda en plena temporada.
Mi criterio, y va como criterio: haría el trabajo en tres tramos. Del 7 al 30 de octubre, medir y hacer los cambios grandes en una copia: versión de PHP, caché, caché de objetos y la foto principal. Del 2 al 5 de noviembre, pasar a la tienda real lo que funcionó y hacer compras de prueba. Y desde el viernes 6 de noviembre, una semana antes de El Buen Fin, congelar: ni actualizaciones de plugins ni cambios de tema hasta el miércoles 18. Si el cambio de PHP no alcanzó a entrar antes, lo haría del 19 al 30 de noviembre, antes de que arranque diciembre. No en la semana de una campaña.
Si además vas a preparar promociones para esas fechas, el método para armarlas está en cómo crear una oferta para tus clientes.
El orden de trabajo, de lo que más gana a lo que menos
Todo lo anterior, en el orden en que lo haría. Cada paso dice qué parte del problema ataca, para que lo saltes si tu medición dice que esa parte ya está bien.
| Paso | Qué hacer | Qué mejora | Dónde está en esta guía |
|---|---|---|---|
| 1 | Medir las cinco páginas y llenar la hoja | Te dice cuál es tu problema | Antes de tocar nada: medir |
| 2 | Revisar las exclusiones de la caché y hacer la prueba de los dos navegadores | Evita servirle a un cliente el carrito de otro | Qué guardar y qué excluir |
| 3 | Activar la caché de página del servidor o un solo plugin | Tiempo hasta el primer byte del catálogo | Un solo sistema de caché |
| 4 | Pasar a PHP 8.3 o 8.4 en una copia, con compra de prueba | Servidor en todas las páginas, y seguridad | La versión de PHP, y la fecha del 31 de diciembre |
| 5 | Activar la caché de objetos, si tu hosting la ofrece | Carrito, cuenta y pago | Caché de objetos: lo que acelera el carrito y el pago |
| 6 | Quitar la carga diferida y el carrusel de la foto principal, y darle prioridad | Retraso antes de pedir la imagen | La primera foto de la ficha |
| 7 | Revisar tamaños y formato de las fotos | Duración de la descarga | Las fotos de producto |
| 8 | Revisar la cola de tareas, las opciones autocargadas y el WP-Cron | Servidor y panel | La base de datos de una tienda |
| 9 | Migrar a HPOS si la tienda es anterior a la 8.2 | Panel de pedidos | Pedidos en tablas propias: HPOS |
| 10 | Revisar fragmentos del carrito, variaciones, filtros y scripts | Peticiones extra y competencia con la foto | El catálogo, el carrito y los scripts |
| 11 | Medir los plugins uno por uno | Lo que quede | Plugins: no es cuántos, es qué hacen |
| 12 | Cambiar de hosting, si el tiempo hasta el primer byte sigue alto después de los pasos 3 a 5 | El techo del servidor | El servidor: PHP, memoria y base de datos |
El paso 12 va al final a propósito. Cambiar de hosting puede dar la mejora más grande cuando el servidor es el problema. Cuando no lo es, cuesta dinero y tiempo sin resolver nada. Los pasos 3, 4 y 5 te dicen cuál es tu caso sin mudarte.
Estas son las preguntas para tu hosting actual. Hazlas por escrito. Si llegas al paso 12, sirven también para comparar uno nuevo.
- ¿Qué versiones de PHP ofrece mi plan, y desde cuándo puedo usar la 8.4?
- ¿Tienen caché de página en el servidor, y cómo excluye el carrito, la cuenta, el pago y las cookies de WooCommerce?
- ¿Hay Redis o Memcached disponibles en mi plan para una caché de objetos?
- ¿Cuál es el límite de memoria de PHP, y puede llegar a 256 MB?
- ¿Pueden llamar al WP-Cron con una tarea programada del servidor?
- ¿Dónde están físicamente los servidores?
- ¿Incluye un entorno de pruebas para copiar la tienda?
Los errores que se cometen al arrancar una tienda, y que no tienen que ver con la velocidad, están en errores comunes al empezar un negocio en línea.
Ocho mitos sobre la velocidad de WooCommerce
Ocho ideas sobre la velocidad de una tienda, y el dato de esta guía que corrige cada una.
«Más plugins, tienda más lenta»
El número de plugins no dice cuánto trabajo hacen. Un plugin que solo agrega un campo en el panel no pesa lo mismo que uno que calcula un precio en cada producto de la categoría. Lo que sirve es medir. Query Monitor agrupa las consultas por el plugin que las hizo. Ahí se ve quién pesa. El método está en «Cómo medir un plugin».
«Un plugin de caché lo resuelve todo»
La caché de página no llega al carrito, a la cuenta del cliente ni al pago. La guía de WooCommerce pide excluirlos, porque muestran información de cada cliente. Tampoco llega a quien trae alguna de las cinco cookies de WooCommerce. Para esas páginas, lo que ayuda es el servidor. Cuentan la versión de PHP y la caché de objetos. En la medición de la versión 10.7, la caché de objetos bajó de 172 a 115 las consultas para guardar el borrador de un pedido.
«Comprimir las fotos es lo primero»
El análisis de Google sobre los sitios con LCP malo encontró tres cosas. En la mayoría de los orígenes, la descarga de la imagen ocupa menos del 10 % del LCP. En el sitio mediano, la espera antes de pedirla es casi cuatro veces más larga que la descarga. En la mitad de esos sitios, el servidor tardaba 2,270 milisegundos o más en dar el primer byte, en el percentil 75. Comprimir ayuda. Pero va después de que el servidor conteste rápido y de que la foto se pida pronto.
«WooCommerce es lento por naturaleza»
En el Web Almanac, 35 de cada 100 tiendas WooCommerce aprueban en celular. No es la mayoría. Pero tampoco es cero: más de un tercio de las tiendas con la misma plataforma lo logra. En INP, las tiendas WooCommerce están a 2 puntos de Shopify. La brecha está en el LCP, que depende del servidor, de la caché y de cómo se muestra la foto principal: de cómo está montada cada tienda.
«La meta es el 100 de PageSpeed»
El número del 0 al 100 sale de una sola carga simulada, en un teléfono de gama media y con una conexión de 1.6 megabits por segundo. Sirve para diagnosticar. La evaluación de Core Web Vitals usa los datos de campo de los 28 días anteriores, en el percentil 75. Una tienda que aprueba con visitantes reales y saca 70 en el laboratorio está mejor que una con 100 en el laboratorio y datos de campo en rojo.
«Minificar y combinar el JavaScript acelera la tienda»
La guía de WooCommerce sobre plugins de caché, en su apartado de WP Rocket, recomienda evitar la minificación de archivos JavaScript. Y el INP, la métrica de respuesta, en la que pesa el JavaScript, está bien en 88 de cada 100 tiendas WooCommerce en celular. Minificar puede ahorrar algunos kilobytes. También puede romper el código del carrito o de la pasarela. Si lo activas, compra de prueba completa.
«HPOS acelera la tienda para tus clientes»
En la prueba de WooCommerce con 400,000 pedidos, procesar 10 pagos tomó 0.99 segundos con HPOS y 1.51 con las tablas de entradas: 51.70 milisegundos de diferencia por compra. Para el panel, la diferencia fue grande. Buscar pedidos por metadatos fue 12.09 veces más rápido, y filtrarlos por cliente, 37.52 veces. HPOS es una mejora para quien administra la tienda más que para quien compra.
«Lo primero es cambiar de hosting»
Puede ser lo último que necesites. Antes de mudarte, la caché de página, una versión reciente de PHP y la caché de objetos te dicen cuánto puede dar tu servidor actual. Si después de eso el tiempo hasta el primer byte sigue lejos de los 0.8 segundos que propone web.dev, la mudanza tiene una razón medida. Y si el servidor está en otro continente, la tabla de «La distancia tiene un piso» dice cuánto cuesta esa distancia antes de que tu tienda haga nada.
Preguntas frecuentes
¿Por qué mi tienda WooCommerce es lenta?
Lo más probable, según los datos, es el LCP: de cada 100 tiendas WooCommerce que reprueban Core Web Vitals en celular, 94 reprueban esa métrica. Y en la mayoría de los sitios con LCP malo, el tiempo se va en el servidor y en la espera antes de pedir la foto principal, más que en descargarla. Mide antes de suponer. PageSpeed Insights te dice cuál es tu elemento LCP, y Query Monitor, cuánto tarda tu servidor en armar cada página.
¿Qué es un buen tiempo de carga para una tienda en línea?
Core Web Vitals no usa un tiempo de carga total. Usa tres métricas. En las tiendas WooCommerce, la que más falla es el LCP. Debería quedar en 2.5 segundos o menos en el percentil 75 de tus visitas reales: tres de cada cuatro visitas dentro de ese tiempo. Para el tiempo hasta el primer byte, web.dev propone 0.8 segundos o menos como guía.
¿Cuál es el mejor plugin de caché para WooCommerce?
No hay uno mejor para todas las tiendas. La guía de rendimiento de WooCommerce menciona WP Rocket, W3 Total Cache y WP Super Cache como ejemplos de plugins, y la caché del servidor de tu hosting como otra opción. Lo que propone esta guía es usar uno solo, que excluya el carrito, la cuenta y el pago. Después, prueba que un cliente no vea el carrito de otro.
¿Qué páginas de WooCommerce no se deben guardar en caché?
El carrito, la cuenta del cliente y la página de finalizar compra, según la guía de WooCommerce para configurar plugins de caché. También pide excluir cinco cookies: woocommerce_cart_hash, woocommerce_items_in_cart, wp_woocommerce_session_, woocommerce_recently_viewed y store_notice.
¿Qué versión de PHP necesita WooCommerce?
WooCommerce recomienda PHP 8.3 o más, y dice haberlo probado hasta PHP 8.4. El plugin arranca con PHP 7.4 como mínimo. Ese mínimo no es una recomendación. WordPress también recomienda 8.3 o más. La versión que usa tu tienda aparece en Herramientas, Salud del sitio, pestaña Información.
¿Qué pasa si sigo con PHP 8.2 después del 31 de diciembre de 2026?
Ese día, PHP 8.2 deja de recibir parches de seguridad, según la tabla de versiones del proyecto PHP. Tu tienda no se apaga. Pero corre sobre una versión que ya no se corrige si aparece una falla. Conviene cambiar antes, en una copia y con una compra de prueba, y no durante El Buen Fin ni en diciembre.
¿Qué es la caché de objetos y la necesito?
Es una memoria que guarda resultados de consultas a la base de datos entre una visita y otra, con un servicio como Redis o Memcached. A diferencia de la caché de página, llega al carrito y al pago. WordPress la recomienda en Salud del sitio cuando la tabla de entradas, la de opciones, la de comentarios, la de términos o la de usuarios pasa de 1,000 filas, entre otros umbrales. En la medición de WooCommerce 10.7, la caché de objetos bajó de 172 a 115 las consultas para guardar un borrador de pedido.
¿Redis o Memcached?
La guía de WooCommerce menciona los dos como opciones para la caché de objetos, sin preferir uno. La pregunta práctica es cuál ofrece tu hosting en tu plan y qué plugin recomienda para conectarlo con WordPress.
¿Qué es HPOS y conviene activarlo?
Es el sistema de WooCommerce para guardar los pedidos en cuatro tablas propias en lugar de las tablas de entradas de WordPress. Viene activado en las tiendas nuevas desde la versión 8.2. En la prueba de WooCommerce con 400,000 pedidos, filtrar pedidos por cliente fue 37.52 veces más rápido. En el pago, la diferencia fue de 51.70 milisegundos por compra. Conviene, sobre todo para el panel, si tus plugins ya son compatibles.
¿WebP o AVIF para las fotos de producto?
Los dos son más ligeros que JPEG. Google documenta que WebP con pérdida pesa entre 25 y 34 % menos que un JPEG comparable, y WordPress, que AVIF puede pesar hasta 50 % menos. AVIF depende de que tu servidor lo soporte: lo ves en Salud del sitio, pestaña Información, sección de manejo de medios. Pero antes del formato va el tamaño. Una foto de 2,000 píxeles en un espacio de 300 lleva 44 veces más píxeles de los que se ven en una pantalla normal, y 11 en una de alta densidad.
¿De qué tamaño subo las fotos de producto?
WooCommerce usa por defecto 300 píxeles de ancho en el catálogo y 600 en la ficha. Para pantallas de alta densidad conviene el doble del ancho en que se muestra. Subir originales muy grandes no es el problema mientras el tema muestre las copias de WooCommerce. El problema es cuando muestra el original. Revisa en PageSpeed qué imágenes se descargan más grandes de lo que se ven.
¿La carga diferida acelera o frena la tienda?
Las dos cosas, según dónde. En las fotos de abajo de una categoría, ayuda, porque no se descargan hasta que el cliente baja. En la foto principal de la ficha, frena: la guía de Google para optimizar el LCP pide no aplicarla a la imagen del LCP. Revisa que tu foto principal no lleve loading="lazy".
¿Qué son los fragmentos del carrito y conviene desactivarlos?
Son un script de WooCommerce que actualiza el carrito del encabezado sin recargar la página, con peticiones al servidor. Desde la versión 7.8 solo se carga si la página muestra el widget clásico del carrito. Si tu tema lo usa, la alternativa que propone WooCommerce es el bloque de minicarrito, que no usa ese mecanismo. Desactivarlos a mano puede dejar el carrito del encabezado sin actualizar.
¿Cuántas variaciones puede tener un producto?
La documentación que revisé no fija un máximo de rendimiento. Sí fija un límite de comportamiento: con 30 variaciones o menos, los menús de la ficha son dinámicos; con más, son estáticos. Se puede subir con un filtro, y la documentación advierte que los valores altos pueden afectar el rendimiento de la ficha. Antes de subirlo, considera dividir el producto.
¿Cuántos plugins son demasiados?
No hay un número. Lo que importa es qué hace cada uno en cada página. Query Monitor agrupa las consultas por el plugin que las hizo, y con eso puedes probar uno por uno en una copia de la tienda.
¿Sirve un CDN para una tienda en México?
Para las fotos, los estilos y el código, sí: los sirve desde un punto cercano a tu cliente. La guía de rendimiento de WooCommerce lo recomienda para los archivos estáticos. Pero el carrito y el pago no se guardan en caché. Esas páginas siguen saliendo de tu servidor, y su distancia cuenta. Con los supuestos de «La distancia tiene un piso», un servidor en Ámsterdam tiene un piso físico de unos 271 milisegundos para un cliente en la Ciudad de México.
¿Cómo mido el carrito y el pago si PageSpeed no puede?
PageSpeed entra como un visitante nuevo, sin carrito. Para esas dos páginas, activa Query Monitor y agrega un producto al carrito con tu sesión de administrador. Anota el tiempo de generación de la página y el número de consultas. Hazlo antes y después de cada cambio.
¿Cuánto tarda en verse una mejora en PageSpeed?
En el laboratorio, de inmediato. En los datos de campo, semanas. PageSpeed reporta lo que vivieron visitantes reales durante los 28 días anteriores, así que la mejora entra poco a poco. Si mediste el laboratorio antes y después, ya tienes una primera señal.
¿Cuánto voy a vender de más con una tienda más rápida?
No hay una cifra que se pueda prometer. El estudio de Deloitte para Google encontró en comercio minorista 8.4 % más conversiones con una décima de segundo menos. Pero era una correlación, con variaciones naturales de velocidad y métricas de 2019. La cuenta que sí puedes hacer es al revés: cuánto tienes que vender de más para que la mejora se pague, dividiendo su costo mensual entre tu margen.
¿Debo cambiar de hosting?
Primero prueba lo que se hace sin mudarte: caché de página, una versión reciente de PHP y caché de objetos. Si después de eso el tiempo hasta el primer byte sigue alto, el cambio tiene una razón medida. Las preguntas para tu proveedor, actual o nuevo, están al final de «El orden de trabajo, de lo que más gana a lo que menos».
¿Cuándo hago los cambios si se acerca El Buen Fin?
El Buen Fin 2026 va del 13 al 17 de noviembre, según las fechas publicadas por la prensa. La propuesta de esta guía: los cambios grandes en octubre, en una copia. Del 2 al 5 de noviembre, a la tienda real. Y congelar todo desde el viernes 6 hasta el miércoles 18.
¿Shopify es más rápido que WooCommerce?
En los datos del Web Almanac 2025, sí: 76 de cada 100 tiendas Shopify aprueban Core Web Vitals en celular, contra 35 de WooCommerce. La brecha más grande está en el LCP: 47 puntos. Pero en Shopify el servidor y la caché los administra la plataforma, y en WooCommerce los administras tú. Con el servidor, la caché y la foto principal bien resueltos, una tienda WooCommerce puede estar del lado que aprueba.
Lo que este artículo no pudo verificar
Esto quedó fuera o a medias. Conviene saberlo antes de usar cualquier cifra de arriba.
- La tasa de aprobación de las tiendas WooCommerce de México. El informe de tecnologías del HTTP Archive permite filtrar por país, pero su página carga las cifras con código y no se pudieron leer. Las tasas de esta guía son globales.
- La velocidad mediana de las conexiones móviles en México en una fuente oficial que se pudiera leer. Por eso las cuentas de descarga usan la conexión que simula PageSpeed, que es una vara de comparación y no la conexión de tus clientes.
- Cuánto más rápida es una tienda WooCommerce con PHP 8.4 que con 8.2 u 8.3. No encontré una medición publicada por WooCommerce, por WordPress o por el proyecto PHP. WordPress solo dice que cada versión es más eficiente.
- Cuánto tiempo ahorra la caché de objetos en el pago. WooCommerce publicó consultas, no milisegundos.
- Cuánto mejora HPOS una tienda chica. La prueba de WooCommerce usó 400,000 pedidos y 30,000 productos.
- En qué condiciones midió WooCommerce los 13 a 18 milisegundos de la versión 11.1. El texto de su equipo da la cifra sin describir la prueba.
- El efecto de la velocidad en las ventas de tiendas mexicanas. El estudio de Deloitte es de marcas de Europa y Estados Unidos, de 2019, y encontró una correlación.
- Si los plugins de caché aplican solos las exclusiones de WooCommerce. No revisé su documentación uno por uno; por eso la guía pide comprobarlo con la prueba de los dos navegadores.
- Las fechas de El Buen Fin 2026 en el sitio oficial. No se pudo abrir; se usaron las que publicó la prensa.
- Cuánto mejora la prioridad de carga en una ficha de WooCommerce. El 5 a 10 % que estimó WordPress para la versión 6.3 es general, no de tiendas.
Fuentes y metodología
Las traducciones del inglés de este artículo son nuestras, y cada cita está enlazada a su original en esta sección. Las fuentes se consultaron el 7 de octubre de 2026, salvo donde se indica otra fecha.
Fuentes primarias
Datos de tiendas y sitios reales
- HTTP Archive, Web Almanac 2025, capítulo de comercio electrónico, de Amandeep Singh, publicado el 15 de enero de 2026. Figuras 13.10 y 13.11: orígenes y tasas de LCP, INP, CLS y Core Web Vitals por plataforma, cuota de WooCommerce y medianas de Lighthouse.
- HTTP Archive, Web Almanac 2025, capítulo de gestores de contenido, figura 12.8: WordPress aprueba en 45 % en celular.
- HTTP Archive, metodología del Web Almanac 2025: rastreo y datos de usuarios reales de julio de 2025.
- INEGI, Encuesta Nacional sobre Disponibilidad y Uso de Tecnologías de la Información en los Hogares 2025, resultados, del 16 de junio de 2026. Usuarios de internet, conexión por celular y por computadora, y compras por internet.
Google y la medición
- web.dev, «Web Vitals»: umbrales y percentil 75.
- web.dev, «Optimize Largest Contentful Paint»: las cuatro partes del LCP y la regla de no diferir la imagen del LCP.
- web.dev, «Common misconceptions about how to optimize LCP», de Brendan Kenny, actualizado el 20 de agosto de 2024: tiempo hasta el primer byte, espera y descarga en los sitios con LCP malo.
- web.dev, «Time to First Byte (TTFB)» y «The most effective ways to improve Core Web Vitals».
- Google, «About PageSpeed Insights»: datos de campo de 28 días, laboratorio y umbrales.
- Lighthouse, documentación de la limitación de red: 150 milisegundos, 1.6 megabits por segundo y procesador cuatro veces más lento.
- Google, WebP: ahorro frente a JPEG y PNG.
WooCommerce
- «How to configure caching plugins for WooCommerce», «How to optimize performance for WooCommerce stores» y la documentación de cookies.
- «WooCommerce Server Recommendations», con fecha de modificación del 25 de mayo de 2026, y la página del plugin en el directorio de WordPress, versión 11.1.2.
- Documentación de HPOS, notas de la versión 8.2.0, «Platform Upgrade: High-Performance Order Storage for WooCommerce», del 11 de octubre de 2023, y «Performance Benchmarking for WooCommerce HPOS», del 17 de marzo de 2023.
- Texto sobre los fragmentos del carrito, de Darren Ethier, del 16 de junio de 2023.
- Límite de variaciones dinámicas, tamaños de imagen y regeneración de miniaturas.
- Tabla de búsqueda de atributos: anuncio como opción en la versión 5.6, del 12 de agosto de 2021, y anuncio de la 6.3, del 2 de febrero de 2022.
- Notas de las versiones 8.3.0, 10.7 y 11.1.0, y la guía del flujo de datos de los bloques de carrito y pago.
- Texto del equipo sobre la mejora de la Store API en la 11.1, del 31 de agosto de 2026.
- «WP_options table and site speed».
- Action Scheduler: sitio, pantalla de administración y código de la limpieza de la cola.
WordPress y PHP
- WordPress, requisitos, «Get a faster, more secure website: update your PHP today» y aclaración sobre el soporte de PHP, del 22 de mayo de 2026.
- PHP, tabla de versiones con soporte.
- Make WordPress Core: mejoras de imagen de la 6.3, AVIF en la 6.5, carga automática de opciones en la 6.6 y revisiones de caché en Salud del sitio en la 6.1.
- Referencia de código de WordPress: umbrales de la caché de objetos persistente y caché de objetos.
- Manual para desarrolladores, «Hooking WP-Cron Into the System Task Scheduler».
- Directorio de plugins: Query Monitor, Health Check & Troubleshooting y Troubleshooting.
Velocidad y ventas
- Deloitte, informe «Milliseconds make millions» y su página de presentación.
- web.dev, «Milliseconds make millions», del 24 de junio de 2020.
Calendario
- El Buen Fin 2026, del 13 al 17 de noviembre, según Uno TV y Chilango, los dos del 31 de agosto de 2026.
Cálculos y supuestos
Todas las cuentas son propias y están en un guion que las recalcula.
- Proporción de fallas por LCP = (100 − tiendas con LCP bueno) ÷ (100 − tiendas que aprueban las tres). WooCommerce: 61 ÷ 65 = 93.85 %; Shopify: 14 ÷ 24 = 58.33 %. Como el Almanac publica las tasas redondeadas, la proporción real de WooCommerce puede estar entre 92.37 y 95.35 %, y la de Shopify entre 55.10 y 61.70 %.
- Tiempo de descarga = kilobytes × 8 ÷ 1,600 kilobits por segundo. Un megabyte se toma como 1,000 kilobytes. No incluye la latencia ni el procesador.
- Piso de latencia = 2 × distancia ÷ velocidad de la luz en fibra, por tres viajes de ida y vuelta: abrir la conexión, negociar el cifrado y pedir la página. Velocidad en fibra: 299,792 km/s ÷ 1.47, unos 203,940 km/s. Distancias en línea recta desde el centro de la Ciudad de México, calculadas con coordenadas. Es un mínimo físico, no una medición.
- Píxeles de más = (ancho del original ÷ ancho en que se muestra) al cuadrado. Una pantalla de alta densidad se toma como el doble del ancho.
- Ejemplos de fotos: los tamaños de archivo de 400, 250, 60 y 25 KB son inventados; los porcentajes de WebP y AVIF son los de Google y WordPress.
- Consultas del pago: porcentaje de ahorro = 1 − después ÷ antes.
- HPOS por compra = (1.5087 − 0.9917) segundos ÷ 10 pagos = 51.70 milisegundos.
- Venta extra para que una mejora se pague = costo mensual ÷ margen. Costos, márgenes y ventas inventados.
- Compradores por internet = 104.9 millones × 37.3 % = 39.13 millones.
- Store API: los 13 a 18 milisegundos son de WooCommerce; 18 milisegundos son menos de dos centésimas de segundo.
- Días: contados desde el 7 de octubre de 2026.
- Redondeo: a dos decimales, hacia arriba desde el medio.
Comprobaciones cruzadas
- Cada cita se leyó dos veces, en fragmentos cortos. Cuando una lectura resumía en lugar de citar, se pidió el texto exacto.
- Los umbrales de la caché de objetos. Dos lecturas del anuncio de WordPress 6.1 dieron cifras distintas, probablemente porque el texto incluye un ejemplo de cómo cambiarlas. Se usaron las del código de WordPress, leído dos veces: 1,000 filas y 500 opciones o 100,000 bytes.
- La tabla de PHP. La herramienta de lectura etiquetó una versión con un estado que no correspondía a sus fechas; el estado de cada versión se calculó con las fechas de la tabla.
- Los requisitos de WooCommerce. Su página de recomendaciones pide WordPress 6.9; el plugin, en el directorio, ya pide 7.0. Se citan los dos con su fecha.
- Las cifras de HPOS. El anuncio dice hasta 5, 1.5 y 40 veces; la prueba que las respalda da 5.15, 1.52 y 37.52. Se usaron las de la prueba.
- Coherencia con la serie. La guía de velocidad de esta serie usa, del mismo Almanac, la tasa de todos los sitios: 48 % en celular. De otra fuente, toma una tasa de WordPress en escritorio de 50 %. La comparativa de WooCommerce cita 53.3 % en escritorio y 48.8 % en celular para WordPress, con datos de junio de 2026 tomados de un blog. Esta guía usa las tasas por plataforma del capítulo de comercio electrónico. Son bases y fechas distintas, y por eso no se restan entre sí.
Limitaciones
- Los datos del Almanac son de julio de 2025, globales y por origen: no dicen nada de una tienda concreta ni de México en particular. La detección de WooCommerce la hace una herramienta automática.
- El análisis de Google sobre los sitios con LCP malo es de todos los sitios, no solo de tiendas.
- La conexión de PageSpeed es simulada. Tus clientes tienen conexiones mejores y peores.
- Esta guía no prueba ninguna tienda en un laboratorio propio. Las cifras de HPOS, de la caché de objetos y de la Store API son de pruebas de WooCommerce, con condiciones descritas en el caso de HPOS y sin describir en los otros dos.
- Los planes de hosting y sus precios no se revisaron: el método para compararlos está en la guía de hosting de esta serie.
- Los documentos de WooCommerce, WordPress, PHP, Google, Action Scheduler y Deloitte se leyeron en inglés; las traducciones son nuestras.
Declaración de intereses
Este artículo no contiene enlaces de afiliado, y no hay relación comercial con WooCommerce, Automattic, ningún proveedor de hosting, los autores de los plugins mencionados, Google ni Deloitte. Si en el futuro se agregan enlaces de afiliado, esta declaración se cambia el mismo día.