Estudio propio: más de 20.000 sitios WordPress chilenos medidos con PageSpeed. Solo el 4% llega al verde en celular. Ver el estudio

Casos

Caso real · inspección de viviendas

13 segundos para abrir la portada en celular

Pablo me contactó porque su negocio crecía y los formularios entraban menos seguido. Algo no le cuadraba: el sitio funcionaba, pero la gente que llegaba desde el celular se iba antes de ver el contenido. Acá está lo que encontré, lo que hice y cómo quedó medido.

Testimonio

"La página quedó más rápida de como cuando se desarrolló por primera vez."

Pablo Martínez, dueño de 2eme.cl

Qué es 2eme

2eme.cl es una empresa chilena que inspecciona viviendas antes de que las compres. Si estás por firmar la compra de una casa o un departamento, van, la revisan a fondo y te entregan un informe con lo que encontraron: humedades, fallas eléctricas, problemas estructurales.

Sus clientes están por firmar la compra de una casa o un departamento, así que buscan ayuda profesional, y muchos lo hacen desde el celular.

Cuando alguien busca en Google y hace clic en 2eme.cl, espera una respuesta rápida y profesional. Si el sitio se demora demasiado, se va a la siguiente opción.

Qué pasaba

Pablo me contactó porque su negocio crecía y los formularios entraban menos seguido. Cuando medí el sitio, esto es lo que encontré.

  • La página principal tardaba 13 segundos en cargar en celular.

    Algunas páginas, como Quiénes Somos, llegaban a 28 segundos.

  • El contenido saltaba mientras se cargaba.

    El visitante empezaba a leer y los bloques aparecían y se movían de lugar. En celular es especialmente molesto.

  • El video de fondo de la portada pesaba 42 MB.

    Cada visitante en celular descargaba esa carga completa sin necesitarla.

  • El sitio le pedía 174 archivos de fuentes a Google en cada visita.

    Lo habitual, según lo que veo en los sitios que mido, son 4 a 6.

  • La base de datos pesaba 91 MB de versiones viejas acumuladas.

    Según lo que veo habitualmente, una base de datos sana de un sitio de este tamaño pesa entre 10 y 25 MB.

Nada de esto era visible para Pablo. El sitio funcionaba, solo que lento, y los clientes que se iban antes de llegar al formulario no aparecían en ningún reporte.

Qué hice

Antes de partir quedaron tres cosas acordadas:

  • Sin tocar el diseño. El sitio queda igual a la vista.
  • De noche. Trabajé entre las 00:00 y las 06:00 para no afectar a nadie que estuviera navegando.
  • Backup primero. Copia completa guardada antes de cualquier cambio, por si había que volver atrás.

El trabajo se repartió en varias sesiones nocturnas, cada una con un foco: diagnóstico inicial, la portada, revisión completa del estado intermedio, las 7 páginas restantes, validación con mediciones repetidas y un arreglo posterior detectado en producción. Esto es lo más importante:

Achiqué las imágenes

Las fotos de fondo pesaban entre 200 KB y 1,3 MB cada una. Las redimensioné para celular y las convertí a un formato más liviano. Quiénes Somos: de 1,3 MB a 17 KB. Pagos: de 735 KB a 10 KB.

Ver el detalle técnico

308 imágenes procesadas con Imagify Pro Unlimited (remuestreo Lanczos, calidad 75, generación WebP automática). Para los heroes móviles generé derivadas -mobile.webp de 900 px de ancho, con override de CSS condicional vía wp_is_mobile() && is_page(). Los originales quedan como respaldo.

Comprimí el video de la portada

El video de fondo pesaba 42 MB. Con la misma calidad visual quedó en 8 MB. Y en celular ahora se muestra solo una imagen previa: el video se arma si el visitante interactúa.

Ver el detalle técnico

Recodificación con ffmpeg (H.264 CRF 28, preset slow, dos pasadas): 42 MB a 8 MB sin pérdida visual perceptible. En móvil, una rama del JS detecta matchMedia('(max-width: 768px)') y reemplaza el <video autoplay> por un <img> WebP precargado de 58 KB; el video se monta a demanda en el primer touchstart. Resultado: el elemento LCP en móvil pasa a ser la imagen, nunca el video.

Saqué los saltos del contenido

El tema cargaba parte de los estilos demasiado tarde, así que los bloques aparecían sin tamaño y se movían cuando llegaba el estilo. Lo corregí, y ahora todo se ve estable desde el primer instante.

Ver el detalle técnico

Divi inyecta estilos inline dentro del <body> durante el render del shortcode et_pb_section, con CLS sobre 1,0 en 6 de las 8 páginas. Capturo la salida de et_builder_inner_content, extraigo esos <style> y los repongo vía wp_head con prioridad 1. Resultado: CLS bajo 0,01 en las 8 páginas.

Los videos de YouTube ya no cargan al inicio

Antes, al abrir una página con un video de YouTube embebido, el reproductor entero se cargaba aunque nadie le diera play. Ahora se muestra una imagen plana y el reproductor aparece solo si la persona hace clic.

Ver el detalle técnico

Patrón de fachada: reemplazo los <iframe src="youtube.com/embed/..."> por un <div> con la miniatura maxresdefault.jpg y un botón de play en SVG. Al primer click, cambio al <iframe> con autoplay=1. Ahorro aproximado: 600 KB del JS de YouTube más 400 KB de compatibilidad que YouTube sigue cargando. El INP mejora alrededor de 300 ms.

Las fuentes vienen del mismo servidor

Antes el sitio le pedía 174 archivos de fuentes a Google en cada visita. Ahora se sirven desde el servidor del cliente, en 20 archivos. Más rápido, y sin pasar los datos del visitante por Google.

Ver el detalle técnico

Poppins y Open Sans autoalojadas en woff2, subset Latin-Extended-A. Saqué el @import de fonts.googleapis.com y el preconnect a fonts.gstatic.com. Las dos críticas (400 y 700) con <link rel="preload" as="font" crossorigin>; el resto con font-display: swap.

El menú móvil abre en 150 milisegundos

Antes tardaba entre 500 y 800 milisegundos en abrirse en celular. Es la diferencia entre un menú que responde y uno que parece pegado.

Ver el detalle técnico

Divi fija jQuery.fn.slideDown(500) dentro de su scripts.min.js sin opción de configurarlo. Parcheo $.fn.slideDown y slideUp en wp_footer con prioridad 1, condicionado a que el destino tenga la clase .et_mobile_menu. Ningún otro slide del sitio se ve afectado.

Arreglé los videos de Testimonios

En esa página había varios videos que no se podían reproducir desde el celular: un detalle del tema bloqueaba el toque. Lo aislé para que esa página deje pasar el clic al video.

Ver el detalle técnico

El et_pb_video_overlay de Divi inserta un <a href="#"> que captura el evento táctil antes que el botón de play del <video controls> dentro del slider. CSS acotado por body.page-id-12 .et_pb_video_overlay { display: none; pointer-events: none; } más reordenar el z-index de la fachada de YouTube. Después del cierre detecté que /portafolio/ también necesitaba MediaElement, porque usa el shortcode [video] nativo de WordPress: lo corregí en una sesión aparte.

Limpieza interna y caché

Saqué 778 versiones viejas de páginas que WordPress guarda solo. La base de datos pasó de 91 MB a 19,6 MB. Dejé el caché configurado y desactivé los plugins que no se usaban.

Ver el detalle técnico

WP-CLI: wp post delete sobre la papelera y las revisiones, wp transient delete --all y wp db optimize. Migración de WP Fastest Cache a LiteSpeed Cache (compatible con el LSWS del hosting), Object Cache sobre Memcached y 7 reglas de exclusión para los endpoints AJAX. En wp-config.php, 7 constantes de ajuste (WP_CACHE, WP_POST_REVISIONS=5, DISALLOW_FILE_EDIT, AUTOSAVE_INTERVAL=300, entre otras).

El detrás de cámara Cómo lo hice: método, herramientas y vuelta atrás Abrir el detalle

Detrás de cada cambio del bloque anterior hay una medición y una forma de volver atrás. Esto es lo que hago para que el número no dependa de la suerte de una corrida.

Método

  • Mediana de 3 mediciones por página antes de declarar un resultado. Una sola medición es ruido.
  • Registro inicial completo antes de tocar nada: configuración de WordPress, plugins activos, estructura de la base de datos y mapeo del uso de video.
  • Cambios de a uno y medidos. Cada modificación se valida con PageSpeed antes de pasar a la siguiente. Si un cambio empeora un puntaje, se revierte y se busca por qué.
  • Revisión completa entre sesiones. Varios cuellos de botella aparecen recién cuando el anterior ya está resuelto.

Lo que no salta a la vista

  • Una revisión intermedia marcaba 99 y 100 en 4 páginas. Lo verifiqué revirtiendo todo: era variabilidad de PageSpeed con el caché caliente, no resultado real. Quedarse con la primera medición buena es entregar un número que no se sostiene.
  • El problema de los videos de Testimonios no era del video. Era una capa invisible de Divi que capturaba el toque antes que el botón de play.
  • El video del slider de Portafolio dejó de funcionar después del despliegue. La regla condicional asumía el módulo de video de Divi, y esa página usa el shortcode nativo de WordPress.

Herramientas

  • WP-CLI para las operaciones masivas sobre base de datos y contenidos.
  • cPanel UAPI a través de un wrapper propio en Python, con registro de cada operación.
  • ffmpeg con codificación en dos pasadas para el video, e Imagify Pro con remuestreo Lanczos para las imágenes.
  • LiteSpeed Cache con Object Cache sobre Memcached.
  • Un mu-plugin propio (wprapido-perf.php, 26 KB) con 12 reglas específicas de este sitio, en vez de un plugin genérico que aplica cosas a ciegas.
  • La API de PageSpeed Insights con un script propio: 3 corridas por 8 páginas por 2 formatos, 48 mediciones por iteración.

Poder volver atrás

  • Backup completo antes de tocar nada: 2,85 GB de archivos comprimidos más el respaldo de la base de datos. Restaurable en pocos minutos.
  • 9 puntos de vuelta atrás creados durante el trabajo, uno antes de cada tramo delicado.
  • Cada archivo modificado con su versión previa guardada, para revertir un cambio puntual sin tocar el resto.
  • Bitácora cronológica con cada cambio, su motivo y su resultado medido.
47

cambios anotados en la bitácora del trabajo

9

puntos de vuelta atrás creados durante el trabajo

96

mediciones de PageSpeed: mediana de 3 corridas, 8 páginas, 2 formatos, antes y después

El resultado, medido

El sitio se ve exactamente igual que antes: mismo diseño, mismo contenido, mismo tema. Lo que cambió es el tiempo que tarda en aparecer.

Tiempo en mostrar la portada en celular

Antes 13 segundos Después 2,3 segundos Antes 13 segundos Después 2,3 segundos

Fuente: caso 2eme, WP Rápido. Portada del sitio medida con PageSpeed Insights: corrida del 9 de abril de 2026 contra medianas de 3 corridas del 14 de abril de 2026.

ANTES DESPUÉS 45 Promedio, celular 94 47 Promedio, escritorio 98,8 18 Portada, celular 96 Escala 0 a 100
Promedio, celular ANTES 45 DESPUÉS 94 Promedio, escritorio ANTES 47 DESPUÉS 98,8 Portada, celular ANTES 18 DESPUÉS 96 Escala 0 a 100

Fuente: caso 2eme, WP Rápido. Promedio de las 8 páginas del sitio. Antes: corrida de PageSpeed Insights del 9 de abril de 2026, con el archivo crudo guardado. Después: medianas de 3 corridas con caché caliente del 14 de abril de 2026, registradas en el informe de cierre.

96

de PageSpeed en celular en la portada. Antes: 18.

2 s

tarda hoy Quiénes Somos en celular. Antes tardaba 28 segundos.

94

de promedio en celular en las 8 páginas. Antes: 45.

Página por página, medido con Google PageSpeed. Más alto es más rápido. La meta práctica del plan era 90 o más en escritorio y 70 o más en celular.

Página Celular antes Celular ahora Escritorio antes Escritorio ahora
Página principal18961898
Construcciónsin dato9969100
Contáctanos829970100
Quiénes Somos32963898
Pagos38975399
Gracias por cotizar599865100
Testimonios31691499
Portafolio57984996
Promedio45944798,8

Condiciones de medición

Antes: promedio de 8 páginas, 45 en celular y 47 en escritorio, corrida de PageSpeed Insights del 9 de abril de 2026, con el archivo crudo guardado. La página principal partía en 18 en celular y 18 en escritorio.

Después: promedio 94 en celular y 98,8 en escritorio, medianas de 3 corridas con caché caliente del 14 de abril de 2026, registrado en el informe técnico del cierre.

La nota honesta: una página quedó por debajo

De las 8 páginas, 7 quedaron sobre 90 en celular. La excepción es Testimonios, que quedó en 69 puntos. Subió desde 31, así que la mejora es real, pero no llegó a la meta de 70.

El motivo es el tema del sitio. Divi construye esa página de una forma que obliga a cargar varios archivos pesados antes de mostrar el contenido, y para pasar de 90 ahí habría que cambiar el tema entero, que es bastante más trabajo del que estaba en el plan.

Lo dejo escrito porque corresponde: si algo no llegué a resolver, aparece acá igual.

¿Tu sitio se parece al de Pablo antes?

Mídelo gratis con el analizador: te da el puntaje de PageSpeed en celular y escritorio, más el detalle de qué está pesando. Tarda menos de dos minutos y no necesito acceso a tu sitio.