Aceleración de la web y Core Web Vitals

Son tres indicadores con los que Google mide la rapidez y la estabilidad de una web para usuarios reales de Chrome: LCP (con qué rapidez aparece el contenido principal), INP (con qué rapidez responde la web a un clic) y CLS (si la disposición salta durante la carga). Los resultados se ven en Search Console y en PageSpeed Insights. Forman parte de las señales que Google tiene en cuenta, pero no son la única.

El precio se lo doy tras la auditoría de velocidad, como alcance cerrado por escrito, y no como un contador de horas. Depende de la plataforma, del número de plantillas (página de inicio, categoría, producto, entrada), del número de plugins y scripts y de si el problema está en el código o en el servidor. La mayoría de las correcciones las implanto en unas pocas semanas, y los primeros cambios, los más baratos, suelen llegar antes a la web.

Ayuda, pero con franqueza: la velocidad es una de las muchas señales de posicionamiento y no una palanca mágica. Los Core Web Vitals son una parte confirmada de las señales de experiencia de página de Google, así que una web que no las supera compite con una carga adicional. Corregir la velocidad elimina esa carga y mejora la eficiencia del rastreo, pero por sí sola no superará a unos contenidos mejores. Por eso la trato como una disciplina más junto al SEO técnico, y le diré de antemano si su mayor problema está en otro sitio.

WordPress en sí rara vez es el problema; normalmente lo es el peso acumulado encima: temas de constructores de páginas, una docena de plugins que cargan sus propios scripts, imágenes sin optimizar y consultas lentas a la base de datos. La mayoría de las webs en WordPress y WooCommerce que veo tienen un buen margen sin cambiar de plataforma. Cuando el tema o el conjunto de plugins realmente no tiene arreglo, se lo diré y, como comparación, le mostraré cuánto costaría rehacerlo: usted decide con cifras reales.

En la mayoría de los casos, optimizar la web existente es el primer paso adecuado: es más barato, más rápido y las mediciones dicen exactamente hasta dónde puede llegar. Rehacerla tiene sentido solo cuando el cuello de botella es el propio cimiento: un tema que pelea con cada optimización o una tecnología que se le ha quedado pequeña. La auditoría responde a esa pregunta con datos antes de que se comprometa con cualquiera de los dos caminos, y yo no tengo ningún interés en empujarle hacia un proyecto mayor.

Cada encargo empieza con mediciones de partida documentadas: datos de laboratorio de Lighthouse y datos de campo del Chrome UX Report (CrUX) de Google, además de pruebas en dispositivos y conexiones reales, no solo en un simulador de escritorio. Tras cada ronda de correcciones mido las mismas subpáginas del mismo modo y le entrego un informe de antes y después. Si una corrección no mueve las cifras, también lo verá. Los datos de CrUX abarcan los últimos 28 días, así que el efecto completo de los cambios se ve en ellos con retraso y, con poco tráfico, puede que no haya datos; en ese caso lo indico en el informe.

Es un riesgo real con una caché agresiva y al mover scripts, por eso trabajo con cuidado: los cambios los pruebo primero en una copia de la web, los implanto de forma gradual y los verifico en sus flujos clave (formularios, proceso de pago, seguimiento) antes y después de cada paso. Todo queda documentado y es reversible. Todo el trabajo es suyo y nada pasa a producción sin superar las mismas pruebas que haría el navegador de un cliente real.

No. El resultado depende también de cosas ajenas al código: el alojamiento, los scripts externos que usted no quiere eliminar y los dispositivos de sus clientes. Prometo una medición documentada antes de los cambios, correcciones según su impacto en el resultado y la misma medición después. Si algún objetivo es irreal sin rehacer la web, se lo diré antes de presupuestar.