Rendimiento web
Trabajo de velocidad en 4korners.org, el sitio WordPress público de la organización sin fines de lucro donde trabajo. Medí a dónde se iban el tiempo y los bytes, y luego bajé la página de inicio de 14 MB a 3 MB y dejé la respuesta del servidor con caché entre 0.1 y 0.2 s en cada página, frente a 1.3 a 2.8 s antes.
Arquitectura
El sitio corre en WordPress con Elementor Pro, en un VPS. Antes de este trabajo no tenía caché de páginas, así que el servidor construía cada página en cada petición, y las imágenes eran cerca del 90% de los 14 MB de la página de inicio. Activé WP Super Cache con una precarga diaria, desactivé un calendario de eventos sin uso que seguía cargando sus archivos en todas las páginas y reemplacé el logo de un socio, que pesaba unos 5 MB, por una copia de 24 KB. Ahora las imágenes pasan por el CDN de imágenes gratuito de Jetpack, que redimensiona cada una al tamaño en que se muestra y la sirve en WebP.
Decisiones clave
Mantener Elementor y resolver la velocidad aparte
Antes de tocar nada, hice una auditoría para decidir si dejar Elementor. Una exportación estática sumaba una segunda suscripción y un paso más para publicar, y reconstruir el sitio, como tema de bloques o como sitio headless, nunca habría recuperado lo invertido. Las páginas lentas tenían causas más baratas de resolver, sin relación con el constructor de páginas, así que Elementor se quedó.
Medir y atacar primero el costo más grande
El primer plan apuntaba al CSS y al JavaScript. Desactivar el calendario de eventos sin uso redujo en 55% el CSS y el JavaScript de la página de inicio, pero la respuesta del servidor no se movió, y la primera medición en el navegador mostró que las imágenes eran cerca del 90% de la página. Así que puse el esfuerzo en la caché de páginas y en las imágenes, en el servidor actual, sin esperar la mudanza prevista a otro hosting.
Un CDN de imágenes en vez de un plugin optimizador
El hosting bloquea exec() de PHP, así que el plugin optimizador que instalé solo podía correr en un modo en la nube limitado, y una revisión posterior mostró que no hacía nada. En su lugar activé el CDN de imágenes gratuito de Jetpack, y el peso de las imágenes de la página de inicio bajó de 7.6 MB a 1.6 MB. Ignora las imágenes de fondo en CSS, así que la foto principal de 853 KB sigue siendo el archivo más pesado de la página, y decidí dejarla así.
La parte difícil
El sitio en vivo cargaba sus fuentes desde el sitio de pruebas
Las fuentes y las negritas se veían bien en el editor de Elementor y mal en el sitio en vivo. Las 13 hojas de estilo de fuentes que Elementor guarda en el servidor cargaban sus fuentes desde el sitio de pruebas, que no envía encabezado CORS, así que los navegadores las bloqueaban y los visitantes veían una fuente de respaldo, probablemente desde marzo de 2025. La herramienta de regenerar de Elementor no toca esos archivos, así que reemplacé las URL en ellos por el dominio en vivo, guardé respaldos para poder revertir y confirmé cero errores de fuentes en el navegador. La regla desde entonces: las copias van de producción a pruebas, nunca al revés.
Seguridad y rendimiento
- Desactivar un plugin no es lo mismo que quitarlo: sus archivos siguen accesibles desde la web. Borro los plugins que el sitio ya no usa, como hice con un complemento de pago sin uso.
- Cada cambio en el servidor en vivo empieza con un respaldo. El arreglo de las fuentes guardó una copia de cada archivo que reescribió, así que cualquier paso se podía revertir.