Cliente real · Caso de éxito publicado

El sitio que parecía caído

Pablo nos contactó porque su negocio crecía pero los formularios entraban menos seguido. Algo no le cuadraba — el sitio "funcionaba", pero los clientes que entraban desde el celular se iban antes de ver el contenido. Esto es lo que encontramos, qué hicimos, y qué pasó después. En lenguaje normal arriba, con la capa técnica plegable para quien quiera profundizar.

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 departamento, vienen, la revisan a fondo y te entregan un informe con todo lo que encontraron: humedades, fallas eléctricas, problemas estructurales, lo que sea.

Sus clientes están a punto de firmar la compra más cara de su vida. Lo último que quieres es entregar plata por algo que termina con problemas escondidos. Por eso buscan ayuda profesional. Y casi siempre la buscan desde el celular.

Cuando alguien hace una búsqueda en Google y hace clic en 2eme.cl, está esperando una respuesta rápida y profesional. Si el sitio se demora demasiado, se va a la siguiente opción. Así de simple.

Lo que pasaba

Pablo nos contactó porque su negocio crecía pero los formularios entraban menos seguido. Algo no le cuadraba.

Cuando medimos el sitio, encontramos esto:

⏱️
La página principal se demoraba 13 segundos en cargar en celular. Algunas páginas, como "Quiénes Somos", se demoraban hasta 28 segundos. La gente abandona después de 3 segundos en promedio.
↕️
El contenido "saltaba" mientras se cargaba. Mientras el usuario empezaba a leer, los bloques aparecían y se movían. Mala experiencia, especialmente en móvil.
📦
El video del fondo de la home pesaba 42 MB. Eso es 5 veces lo que debería pesar. Cada visitante en celular descargaba toda esa carga sin necesidad.
🗂️
El sitio cargaba 174 archivos de fuentes diferentes desde Google cada vez que alguien entraba. Lo normal son 4 a 6.
🗄️
La base de datos pesaba 91 MB de versiones viejas y basura acumulada. Una base de datos sana de un sitio de este tamaño pesa entre 10 y 25 MB.

Ninguna de estas cosas era visible para Pablo. El sitio "funcionaba" — solo que muy lento. Y los clientes que se iban antes de ver el formulario, simplemente no aparecían en ningún reporte.

El acuerdo, simple

Sin tocar el diseño. El sitio queda igual visualmente.
De noche. Trabajamos entre 00:00 y 06:00 para no afectar a nadie que esté navegando.
Backup primero. Antes de cualquier cambio, copia completa guardada por si hay que volver atrás.
Si no se nota, no paga. Pago en dos cuotas: 50% al inicio, 50% al terminar.

Lo que hicimos

Repartimos el trabajo en varias sesiones nocturnas, cada una con un foco específico: análisis inicial y diagnóstico, optimización de la página principal, audit completo del estado intermedio, optimización de las 7 páginas restantes, validación con mediciones repetidas y un hotfix posterior detectado en producción. Acá las cosas más importantes:

🖼️

Achicamos las imágenes

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

Ver detalle técnico

308 imágenes procesadas con Imagify Pro Unlimited (resampling Lanczos, calidad 75, generación WebP automática). Para los heroes mobile creamos derivativas -mobile.webp de 900 px de ancho con CSS override condicional vía wp_is_mobile() && is_page(). Originales preservadas para fallback.

🎬

Comprimimos el video del hero

El video de fondo de la página principal pesaba 42 MB. Con la misma calidad visual lo dejamos en 8 MB. Y en celular, mostramos solo una imagen previa: el video se activa solo si el usuario interactúa.

Ver detalle técnico

Re-encoding con ffmpeg (H.264 CRF 28, preset slow, two-pass): 42 MB → 8 MB sin pérdida visual perceptible. Para mobile, branch del JS detecta matchMedia('(max-width: 768px)'): el <video autoplay> se reemplaza por un <img> WebP poster preloadeado (58 KB), y el video se monta on-demand al primer touchstart. Resultado: LCP element en mobile pasa a ser la imagen, jamás el video.

↕️

Eliminamos los saltos del contenido

El theme tenía un problema: cargaba parte de los estilos demasiado tarde, así que los bloques aparecían sin tamaño y luego "saltaban" cuando llegaba el estilo. Lo corregimos. Ahora todo se ve estable desde el primer instante.

Ver detalle técnico

Divi inyecta estilos inline dentro del <body> durante el render del shortcode et_pb_section, generando CLS > 1.0 en 6 de 8 páginas (peor que el threshold catastrófico que reporta Google). Capturamos el output de et_builder_inner_content, extraemos los <style> tags inline con regex, y los reposicionamos vía wp_head priority 1. Resultado: CLS < 0.01 en las 8 páginas.

📺

Los videos de YouTube ya no cargan al inicio

Antes, cada vez que alguien abría una página con un video de YouTube embebido, el reproductor entero se cargaba aunque el usuario no le diera play. Ahora se muestra una imagen plana y el reproductor solo aparece si la persona hace clic.

Ver detalle técnico

YouTube facade pattern: reemplazamos los <iframe src="youtube.com/embed/..."> por un <div> con thumbnail maxresdefault.jpg + botón play SVG. Al primer click, swap a <iframe> con autoplay=1. Ahorro: ~600 KB de JS de YouTube + ~400 KB de Flash compatibility shims que YouTube sigue cargando. INP mejora ~300 ms.

🔤

Las fuentes ahora vienen del mismo servidor

Antes el sitio le pedía 174 archivos de fuentes a Google cada vez que alguien entraba. Ahora las servimos desde el mismo servidor del cliente, en 20 archivos. Más rápido y más privado.

Ver detalle técnico

Self-hosting de Poppins + Open Sans en formato woff2 desde /wp-content/themes/wprapido/assets/fonts/. Subset Latin-Extended-A. Eliminamos el @import de fonts.googleapis.com y bloqueamos el preconnect a fonts.gstatic.com. Las 2 críticas (400 y 700) con <link rel="preload" as="font" crossorigin>; el resto con font-display: swap. Beneficio adicional: GDPR-compliant (sin tracking de Google Fonts).

📱

Menú móvil 5 veces más rápido

El menú de hamburguesa en celular tardaba entre 500 y 800 milisegundos en abrir. Ahora abre en 150 milisegundos: la diferencia entre "responde" y "está bugeado".

Ver detalle técnico

Divi hardcodea jQuery.fn.slideDown(500) en su scripts.min.js sin opción de override. Solución: monkey-patch de $.fn.slideDown y slideUp en wp_footer priority 1, condicionado a que el target tenga clase .et_mobile_menu. Override transparente para el resto del sitio: ningún otro slide se afecta.

🎞️

Arreglamos los videos de Testimonios

En la página de Testimonios había varios videos que no se podían reproducir desde el celular: un detalle del theme bloqueaba el clic. Lo aislamos para que esa página específica deje pasar el toque al video.

Ver detalle técnico

Diagnóstico no-obvio: el et_pb_video_overlay de Divi inserta un <a href="#"> que captura el touch event antes que el botón play del <video controls> dentro del slider. CSS scoped por body.page-id-12 .et_pb_video_overlay { display: none; pointer-events: none; } + reorder de z-index del facade YT. Bonus: detectamos post-cierre que /portafolio/ también necesitaba MediaElement (shortcode [video] nativo de WP, no et_pb_video) — hotfix aislado en sesión posterior.

🧹

Limpieza interna y caché

Sacamos 778 versiones viejas de páginas que WordPress guarda automáticamente. La base de datos pasó de 91 MB a 19,6 MB. Activamos caché profesional y desactivamos plugins que no se usaban.

Ver detalle técnico

WP-CLI: wp post delete $(wp post list --post_status=trash,inherit --format=ids) + wp transient delete --all + wp db optimize. Migración de WP Fastest Cache a LiteSpeed Cache (compatible con LSWS del hosting), config Object Cache vía Memcached, 7 reglas custom de exclude para AJAX endpoints. wp-config.php: 7 defines de tuning (WP_CACHE, WP_POST_REVISIONS=5, DISALLOW_FILE_EDIT, AUTOSAVE_INTERVAL=300, etc.).

El detrás de cámara Cómo lo hicimos: método, stack y reversibilidad Abrir detalle técnico ↓

Llegar a estos números no es activar un plugin de caché y rezar. Detrás de cada cambio del bloque anterior hay un trabajo específico, medido y reversible. Esto es lo que diferencia la optimización profesional del "puse W3 Total Cache y a ver qué pasa".

Método

Mediana de 3 mediciones por página antes de declarar un resultado. Una sola medición es ruido, mediana es señal.
Snapshot inicial completo antes de tocar nada: configuración WP, plugins activos, estructura de la base de datos, mapeo de uso de video.
Cambios atómicos y medidos. Cada modificación se valida con PSI antes de pasar a la siguiente. Si un cambio empeora un score, se revierte y se piensa por qué.
Audit completo entre sesiones. Cada sesión nueva empieza con un análisis full del estado post-sesión anterior — varios bottlenecks aparecen solo cuando el cuello de botella original ya está resuelto.

Diagnóstico no-obvio

Un audit intermedio mostraba scores 99-100 en 4 páginas. Lo verificamos con un rollback completo: era PSI variability con cache caliente, no resultado real. Si te quedas con la primera medición buena, mientes a tu cliente.
El bug de los videos de Testimonios no era un bug del video. Era un overlay invisible de Divi (z-index: 99) que capturaba el touch event antes que el botón play.
El video del slider de Portafolio dejó de funcionar post-deploy. El dequeue condicional de MediaElement asumía solo Divi Video module, pero Portafolio usa el shortcode [video] nativo de WP. Hotfix aislado en sesión específica.

Stack profesional

WP-CLI para batch operations en base de datos y posts (no plugins de UI lentos).
cPanel UAPI via wrapper Python propio para cambios server-side sin SSH directo, con logging de cada operación.
ffmpeg con two-pass encoding para video. Imagify Pro con resampling Lanczos para imágenes.
LiteSpeed Cache con Object Cache via Memcached (no shared file cache).
mu-plugin propio (`wprapido-perf.php`, 26 KB) con 12 reglas específicas, no un plugin off-the-shelf que aplique cosas a ciegas.
PageSpeed Insights API con script propio (3 runs × 8 páginas × 2 form-factors = 48 mediciones por iteración) en vez de clic-y-rezar en pagespeed.web.dev.

Reversibilidad total

Backup full pre-cambios: 2,85 GB de archivos comprimidos + dump de base de datos. Restaurable en menos de 5 minutos.
9 puntos de rollback intermedios creados durante la sesión: pre-DB-cleanup, pre-config, pre-htaccess, pre-LSCache, pre-YouTube facade, pre-poster, pre-portafolio fix, etc.
Cada archivo modificado tiene una versión .bak-fecha en el server. Reversibilidad granular: si un cambio puntual da problemas en producción, se revierte ese sin tocar el resto.
Bitácora cronológica con cada cambio, su razón y su resultado medido. Si el cliente futuro pregunta "¿qué hicieron exactamente?", la respuesta está documentada.

sesiones de optimización dedicadas, cada una con foco específico

cambios documentados en bitácora cronológica

puntos de rollback creados durante el trabajo

mediciones de PageSpeed (mediana 3 runs × 8 páginas × 2 form-factors × 2 fases)

El cambio, en una imagen

Antes 13 segundos

Tiempo en mostrar la página principal en celular. La mayoría de la gente abandona después de 3 segundos.

Después 2,3 segundos

Aparece casi al instante. El sitio se ve exactamente igual que antes — solo cambió la velocidad.

5 veces más rápido · mismo diseño · mismo contenido · mismo theme

El resultado en detalle

La barra de arriba es el resumen visual. Acá los números página por página, medidos con Google PageSpeed (mediana de 3 mediciones por página). Más alto = más rápido. La meta práctica es 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 principal	18	96	18	98
Construcción	—	99	69	100
Contáctanos	82	99	70	100
Quiénes Somos	32	96	38	98
Pagos	38	97	53	99
Gracias por cotizar	59	98	65	100
Testimonios	31	69*	14	99
Portafolio	57	98	49	96
Promedio	45	94	47	98,8

Puntos promedio en celular (era 45)

98,8

Puntos promedio en escritorio (era 47)

5/8

Páginas en escritorio con casi 100

−26 s

Quiénes Somos: pasó de 28 segundos a 2 segundos

En palabras simples: el sitio pasó de "lento e inusable" a "instantáneo". El cliente que llega desde Google ya no espera. Ve la información y decide.

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

De las 8 páginas, 7 quedaron en zona "verde" de Google en celular. La excepción es Testimonios en celular, que quedó en 69 puntos (subió de 31 — mejora real, pero no llegó a 70).

¿Por qué? El theme actual del sitio (Divi) le pone un techo a esa página específica. Está construido de una forma que obliga a cargar varios archivos pesados antes de poder mostrar el contenido. Para llegar a 90+ en esa página habría que cambiar el theme entero, lo cual era mucho más trabajo del que estaba en el plan.

Lo decimos clarito porque es importante: no vendemos magia. Si algo no llegamos a hacer, te lo decimos.

¿Tu sitio se parece al de Pablo antes?

Análisis gratuito en menos de 2 minutos. Te decimos qué está mal, qué se puede arreglar y cuánto demora — sin compromiso.

Analizar mi sitio gratis

O escríbenos a hola@wprapido.cl