Por qué la velocidad de página es un problema de negocio, no solo técnico
La mayoría de las empresas trata la velocidad del sitio web como un asunto técnico, algo que le corresponde al desarrollador y que no afecta los ingresos. Ese enfoque pasa por alto lo directamente que la velocidad influye en los resultados del negocio.
Google confirmó la velocidad de página como factor de posicionamiento en 2010 y ha aumentado progresivamente su peso en el algoritmo con la introducción de los Core Web Vitals como señales de posicionamiento en 2021. Un sitio que carga lento no solo ofrece una peor experiencia al usuario: se posiciona activamente por debajo de competidores más rápidos, lo que significa que menos personas llegan a encontrarlo.
El impacto en la conversión es igual de significativo. Estudios en múltiples industrias muestran de forma constante que cada segundo adicional de carga reduce la tasa de conversión. Un sitio que carga en 1 segundo convierte 3 veces mejor que uno que carga en 5 segundos. Para un negocio de servicios que paga por tráfico, ya sea mediante anuncios pagados, inversión en SEO o ambos, un sitio lento descarta literalmente un porcentaje de cada dólar invertido en adquisición.
La velocidad importa más en celulares que en computadoras porque las redes móviles son más lentas, los procesadores de los celulares son menos potentes que las CPU de escritorio y los usuarios móviles tienen más probabilidades de estar en un contexto en el que abandonarán de inmediato si una página no carga rápido. Desde que Google adoptó el indexado móvil primero en 2019, el rendimiento móvil de su sitio determina cómo se evalúa para el posicionamiento, no su rendimiento en escritorio.
Cómo entender Core Web Vitals
Los Core Web Vitals de Google son las métricas de rendimiento específicas que se usan en el algoritmo de posicionamiento. Entender qué miden es esencial para entender qué corregimos.
Largest Contentful Paint (LCP)
LCP mide cuánto tarda en cargar el elemento visible más grande de la ventana de visualización, normalmente la imagen principal o el encabezado principal. Google considera “bueno” todo lo que está por debajo de 2.5 segundos, “necesita mejorar” de 2.5 a 4 segundos y “deficiente” más de 4 segundos. El LCP suele ser la métrica con la mayor brecha entre lo que tienen las empresas y lo que Google quiere ver.
Los problemas de LCP más comunes son imágenes principales sin optimizar (de tamaño excesivo, en el formato equivocado, sin precarga), CSS y JavaScript que bloquean el renderizado e impiden que la página se muestre mientras se cargan los recursos, tiempos de respuesta lentos del servidor (TTFB, Time to First Byte) y scripts de terceros que bloquean el renderizado. Cada uno tiene soluciones específicas, y identificar cuál es el problema principal de su sitio determina el enfoque de optimización.
Cumulative Layout Shift (CLS)
CLS mide la estabilidad visual: cuánto se desplaza el diseño de la página mientras carga. Seguramente lo ha vivido cuando va a tocar un botón y este se mueve antes de que su toque llegue, llevándolo a un lugar que no quería. Google considera “bueno” un CLS menor a 0.1 y “deficiente” uno mayor a 0.25.
Los desplazamientos de diseño se deben a imágenes sin dimensiones especificadas (el navegador no sabe cuánto espacio reservar hasta que la imagen carga), anuncios o banners insertados en la página después de que carga el contenido, fuentes web que hacen que el texto se reacomode al cargar (el problema del “flash de texto sin estilo”) y contenido inyectado dinámicamente que empuja otros elementos hacia abajo. Identificamos los desencadenantes específicos de desplazamiento en su sitio y los eliminamos.
Interaction to Next Paint (INP)
INP reemplazó a FID (First Input Delay) como Core Web Vital en marzo de 2024. Mide la capacidad de respuesta de su página ante las interacciones del usuario durante toda la visita, no solo en el primer clic. Cuando un usuario toca un botón o un enlace, INP mide cuánto tarda el navegador en responder visualmente. Google considera “bueno” menos de 200 milisegundos y “deficiente” más de 500 milisegundos.
Un INP deficiente casi siempre lo causa la ejecución pesada de JavaScript en el hilo principal del navegador. Entre los culpables más comunes están los paquetes grandes de JavaScript (en particular de scripts de seguimiento, widgets de chat y herramientas de marketing), los controladores de eventos de larga duración y la evaluación excesiva de JavaScript que se dispara con la interacción del usuario. Estos casos requieren correcciones a nivel de código, no compresión de imágenes ni ajustes del servidor.
Qué significa realmente un puntaje “bueno” en Core Web Vitals: El ajuste de posicionamiento de Google basado en Core Web Vitals se aplica cuando una página obtiene puntajes “buenos” en las tres métricas. Mejorar solo el LCP sin corregir el CLS no desbloquea el beneficio de posicionamiento. Las tres deben alcanzar el umbral “bueno” para obtener la ventaja completa, lo que significa que nuestro trabajo de optimización atiende las tres métricas, no solo la que tiene el peor puntaje.
Qué auditamos y corregimos
Nuestro servicio de optimización de velocidad web comienza con una auditoría de rendimiento integral y luego implementa las correcciones específicas que necesita su sitio. Esto es lo que examinamos.
Rendimiento del servidor y alojamiento
TTFB (Time to First Byte) es el tiempo que transcurre desde que un navegador solicita una página hasta que recibe el primer byte de respuesta de su servidor. Si el TTFB supera los 600 ms, será casi imposible lograr un buen puntaje de LCP sin importar qué más se optimice. Evaluamos el tiempo de respuesta del servidor de su entorno de alojamiento, identificamos si se necesita una CDN (red de distribución de contenido) para servir el contenido desde servidores más cercanos a sus usuarios y evaluamos si su nivel de alojamiento es adecuado para su volumen de tráfico.
Muchas empresas del sur de Florida están en planes básicos de hosting compartido que eran aceptables cuando lanzaron su sitio, pero que se han convertido en el principal cuello de botella de rendimiento a medida que ha crecido su tráfico. Identificamos cuándo el alojamiento es la causa raíz y damos recomendaciones específicas para migrar a configuraciones que realmente resuelvan el problema.
Optimización de imágenes
Las imágenes son la causa más común de velocidades de página lentas y malos puntajes de LCP. El sitio web típico de una empresa del sur de Florida tiene imágenes que son: demasiado pesadas (subir una foto de 4 MB directamente de la cámara cuando una versión comprimida de 120 KB se vería idéntica en pantalla), del formato equivocado (JPG/PNG cuando WebP o AVIF serían entre 30 % y 70 % más livianos con la misma calidad visual), sin carga diferida (todas las imágenes se cargan al abrir la página en lugar de hacerlo solo cuando entran en la ventana de visualización) y sin los atributos de ancho y alto que previenen el CLS.
Convertimos las imágenes a formatos modernos, las comprimimos a tamaños de archivo adecuados, implementamos carga diferida para las imágenes que quedan fuera de la primera pantalla, añadimos dimensiones explícitas para eliminar los desplazamientos de diseño e implementamos la precarga de la imagen LCP para que empiece a descargarse antes de que el navegador termine de analizar el HTML.
Recursos que bloquean el renderizado
Los recursos que bloquean el renderizado son archivos CSS y JavaScript que el navegador debe descargar y procesar antes de poder mostrar cualquier contenido de la página. Cada recurso que bloquea el renderizado se suma al tiempo de LCP. Identificamos qué archivos CSS y JS bloquean el renderizado, diferimos los scripts no críticos, eliminamos el CSS sin usar, incorporamos en línea el CSS crítico (los estilos necesarios para mostrar el contenido de la primera pantalla) e implementamos resource hints (preconnect, preload, prefetch) que indican al navegador que empiece antes a cargar los recursos importantes.
Auditoría de scripts de terceros
Los scripts de terceros (Google Analytics, Facebook Pixel, widgets de chat, herramientas de pruebas A/B, scripts de seguimiento de CRM, widgets de reseñas) están entre los mayores lastres de rendimiento de los sitios web empresariales. Cada uno se sirve desde un servidor externo que su sitio no controla, puede bloquear el hilo principal y puede ejecutar operaciones de JavaScript costosas.
Auditamos cada script de terceros de su sitio, medimos el costo de rendimiento de cada uno e identificamos cuáles pueden diferirse, eliminarse o cargarse de otra manera. Muchos scripts pueden cargarse de forma asíncrona o diferida sin perder funcionalidad. Algunos (en particular los scripts de seguimiento redundantes) pueden eliminarse por completo. Solo esta auditoría suele reducir los puntajes de INP de manera drástica.
Implementación de caché
El caché del navegador y el caché del servidor garantizan que los visitantes recurrentes y los usuarios de una misma red no vuelvan a descargar recursos que no han cambiado. Sin encabezados de caché adecuados, los navegadores vuelven a descargar su CSS, JavaScript e imágenes en cada carga de página. Implementamos encabezados cache-control apropiados para cada tipo de recurso, configuramos el caché de páginas del lado del servidor donde su entorno de alojamiento lo permite y configuramos el caché de CDN para los recursos estáticos.
Optimización de JavaScript
Los paquetes grandes de JavaScript son la causa principal de los malos puntajes de INP. Cuando un navegador descarga un archivo JavaScript grande, debe analizarlo, compilarlo y ejecutarlo, y todo eso ocurre en el hilo principal y bloquea cualquier respuesta a la interacción. Identificamos qué archivos JavaScript son los más grandes, analizamos qué código se usa realmente en cada página (el código sin usar debe eliminarse o dividirse con code-splitting), diferimos los scripts no críticos hasta que la página haya cargado y sea interactiva y, cuando es posible, implementamos worker threads para sacar del hilo principal las operaciones costosas de JavaScript.
Qué cubre nuestro servicio de optimización de velocidad
- Auditoría de Core Web Vitals con diagnóstico específico de LCP, CLS e INP
- Evaluación del tiempo de respuesta del servidor y recomendaciones de alojamiento
- Compresión de imágenes, conversión de formato (WebP/AVIF) y carga diferida
- Eliminación de CSS/JS que bloquean el renderizado e incorporación del CSS crítico
- Auditoría de scripts de terceros y análisis de su costo de rendimiento
- Implementación de caché en el navegador y en el servidor
- Análisis de paquetes de JavaScript y estrategia de diferimiento
- Implementación de CDN para la entrega de recursos estáticos
- Mediciones de rendimiento antes y después con validación en Google Search Console
Por qué importa la plataforma en la que está
El enfoque de optimización para un sitio WordPress es distinto al de un sitio Webflow, y ambos difieren del de un sitio con código a la medida o una tienda Shopify. Cada plataforma tiene características de rendimiento distintas, diferentes palancas disponibles para optimizar y diferentes restricciones sobre lo que puede cambiarse sin romper la funcionalidad.
Los sitios WordPress son particularmente comunes entre las pequeñas empresas del sur de Florida y a menudo sufren problemas de rendimiento por exceso de plugins: demasiados plugins que añaden scripts a cada página, sin importar si esos scripts se necesitan en esa página específica. WordPress también requiere una configuración específica de plugins de caché, optimización a nivel de tema y optimización de la base de datos, aspectos que plataformas como Webflow manejan automáticamente.
Le decimos desde el principio qué es alcanzable en su plataforma actual y qué requeriría una reconstrucción en una plataforma de mayor rendimiento. En algunos sitios, el trabajo de optimización es sencillo. En otros, lograr puntajes “buenos” de Core Web Vitals exige resolver problemas de arquitectura de fondo que no se corrigen con plugins ni con cambios de configuración. Somos honestos con esta diferencia en lugar de prometer resultados que no podemos entregar.
Medición de resultados
Establecemos mediciones de rendimiento de referencia antes de iniciar cualquier trabajo, usando Google PageSpeed Insights, el informe de Core Web Vitals de Google Search Console y los datos de campo del Chrome User Experience Report. Esta referencia documenta sus puntajes actuales de LCP, CLS, INP y rendimiento general, tanto en celular como en escritorio.
Una vez completado el trabajo de optimización, volvemos a medir y entregamos una comparación documentada del antes y el después. Damos seguimiento a los cambios en el informe de Core Web Vitals de Google Search Console durante los siguientes 28 días (el período que Google usa para evaluar los datos de rendimiento de usuarios reales) para confirmar que los datos de campo, y no solo los datos de laboratorio, han mejorado.
En los negocios que ya miden su tasa de conversión, también verificamos si esta mejora después de la optimización de velocidad. En la mayoría de los casos, una mejora significativa en la velocidad de la página produce una mejora medible en la tasa de conversión dentro de 30 a 60 días.
Optimización de velocidad y tasa de conversión: el argumento de negocio directo
Cada segundo de tiempo de carga tiene un costo medible en la tasa de conversión. Los datos de múltiples estudios del sector muestran de forma consistente el mismo patrón: cuando el tiempo de carga pasa de 1 a 3 segundos, la probabilidad de que un visitante móvil abandone el sitio aumenta aproximadamente un 32%. A los 5 segundos, el aumento es del 90%. A los 10 segundos, es del 123%. Para un negocio de servicios en el que cada cliente potencial vale cientos o miles de dólares, incluso una mejora modesta en la tasa de rebote gracias a una mejor velocidad se traduce directamente en más consultas calificadas con el mismo volumen de tráfico.
La relación entre velocidad y tasa de conversión es especialmente marcada en los formularios y los flujos de reserva. Un formulario de contacto en una página lenta sufre más abandono en cada paso del proceso: los visitantes pierden la paciencia entre un campo y otro, entre hacer clic en enviar y la carga de la confirmación, y entre cualquier elemento interactivo y su respuesta visual. Las mejoras de velocidad en estos flujos suelen producir aumentos desproporcionadamente grandes en la tasa de conversión, porque se elimina la fricción justo en los momentos en que los visitantes están más cerca de convertirse en clientes potenciales.
Para los negocios que usan Google Ads, la optimización de velocidad tiene un segundo beneficio financiero: el Nivel de Calidad (Quality Score). Google incluye la experiencia de la página de destino, que abarca la velocidad de la página y los Core Web Vitals, en el Nivel de Calidad, la calificación de 1 a 10 que determina el costo por clic de su anuncio. Un Nivel de Calidad más alto significa CPC más bajos y mejores posiciones para sus anuncios. Mejorar la velocidad de la página puede reducir su costo por cliente potencial del tráfico pagado y, al mismo tiempo, aumentar la tasa de conversión de ese tráfico: un doble retorno sobre la inversión en optimización.
Estrategia de CDN y rendimiento geográfico
Una red de entrega de contenido (CDN) es una red de servidores distribuida globalmente que almacena en caché los recursos estáticos (imágenes, archivos CSS, archivos JavaScript y fuentes) y los entrega desde el servidor más cercano al usuario que los solicita. Sin una CDN, cada visitante carga los recursos de su sitio desde su servidor de origen, sin importar dónde esté ubicado físicamente. Un negocio de Miami con un servidor en Virginia agrega entre 50 y 100 ms de latencia de red a cada solicitud de recursos de cada visitante local, y mucho más para los visitantes internacionales.
El mercado de South Florida, con tanto turismo, hace que la configuración de la CDN sea especialmente importante. Llegan visitantes de Latinoamérica, Europa y Canadá en cifras significativas, y esperan sitios web que funcionen bien en su ubicación. Una CDN que almacena sus recursos en nodos de borde en Miami, Nueva York, Londres y São Paulo garantiza que los visitantes internacionales tengan tiempos de carga comparables a los de los usuarios locales. Esto importa tanto para la experiencia del usuario como para los datos de campo de Core Web Vitals, que agregan la experiencia real de todos los visitantes sin importar desde dónde se conecten.
Cloudflare es nuestra principal recomendación de CDN para la mayoría de los negocios de South Florida porque combina la funcionalidad de CDN con protección contra DDoS, WAF (firewall de aplicaciones web) y funciones de optimización del rendimiento como la compresión de imágenes y la minificación. En los sitios que ya usan Cloudflare, las decisiones de configuración (qué recursos almacenar en caché, durante cuánto tiempo y qué ajustes de compresión activar) tienen un impacto significativo en el rendimiento real. Auditamos y optimizamos la configuración de la CDN como parte de cada proyecto de optimización de velocidad, y no solo la entrega de recursos.
Optimización de velocidad en WordPress: el enfoque específico para la plataforma
WordPress impulsa una parte importante de los sitios web de negocios de South Florida, desde sitios de servicios sencillos en hosting compartido hasta plataformas complejas con múltiples servicios y decenas de plugins. La optimización de velocidad en WordPress es una disciplina especializada, porque la flexibilidad de la plataforma genera fallas de rendimiento específicas que no existen en los sitios hechos a la medida ni en las plataformas SaaS administradas.
Los problemas de rendimiento más comunes que encontramos en WordPress son: exceso de plugins (demasiados plugins que cargan sus scripts y hojas de estilo en todas las páginas, sin importar si esos recursos se necesitan en esa página en particular), consultas de base de datos sin optimizar (la base de datos de WordPress crece y se vuelve más lenta con el tiempo, sobre todo en sitios con muchas publicaciones, múltiples revisiones o acumulación de borradores abandonados), temas sin optimizar (muchos temas populares se diseñan para la riqueza visual y no para el rendimiento, y cargan grandes frameworks de CSS y bibliotecas de JavaScript sin importar qué funciones se usen realmente) e infraestructura de hosting insuficiente (muchos negocios siguen en un hosting compartido básico mucho después de que su tráfico creció hasta el punto en que ese hosting causa problemas de rendimiento constantes).
Nuestro proceso de optimización de WordPress aborda todo esto de forma sistemática: auditoría de plugins y eliminación de los redundantes o innecesarios, optimización de la carga de recursos mediante carga condicional para que los scripts solo se ejecuten en las páginas que los usan, optimización y limpieza de la base de datos, extracción del CSS crítico y priorización del renderizado de la parte superior de la página, y recomendaciones de infraestructura de hosting cuando el propio servidor es el techo de rendimiento. En los sitios donde el exceso del tema es el problema principal, evaluamos si es factible optimizar el tema o si la migración a un tema más ligero o a un desarrollo a la medida es la solución más práctica a largo plazo.
Cuando la optimización de velocidad requiere reconstruir el sitio
Algunos sitios web tienen problemas de rendimiento tan arraigados en su arquitectura que optimizar dentro de la estructura existente no logra una mejora significativa. Los sitios creados con constructores de páginas como Elementor o Divi con cientos de secciones apiladas, los sitios en CMS obsoletos que carecen de funciones modernas de rendimiento o los sitios con código heredado que acumulan deuda de rendimiento más rápido de lo que la optimización puede saldarla son candidatos a una reconstrucción en lugar de una optimización.
Somos honestos en cuanto a esta distinción. Cuando la arquitectura fundamental de un sitio impide alcanzar puntajes "buenos" de Core Web Vitals sin importar el esfuerzo de optimización, la mejor inversión suele ser reconstruirlo sobre una plataforma de alto rendimiento (HTML estático con una CDN, o un sitio en Webflow bien configurado o con un tema moderno de WordPress y un uso disciplinado de plugins) en lugar de seguir sumando optimizaciones sobre una base defectuosa. Entregamos esta evaluación como parte de nuestra auditoría inicial, antes de comenzar cualquier trabajo de optimización, para que usted pueda tomar una decisión informada sobre dónde invertir.
Para los negocios que consideran una reconstrucción, entregamos las especificaciones de los requisitos de rendimiento del nuevo sitio y podemos administrar el proceso de desarrollo para que el nuevo sitio alcance los puntajes objetivo de Core Web Vitals desde el primer día, y no como un ajuste posterior al lanzamiento. Un sitio construido para el rendimiento desde cero, con HTML limpio, JavaScript mínimo, imágenes optimizadas y un almacenamiento en caché adecuado, superará de forma constante a un sitio modificado después, con un menor costo de mantenimiento a largo plazo.
Preguntas Frecuentes
Establecemos líneas base documentadas antes de comenzar cualquier trabajo: datos de campo de Core Web Vitals del informe de CWV de Google Search Console, datos de laboratorio de Google PageSpeed Insights tanto para móvil como para escritorio, y mediciones de TTFB de las páginas clave. Después de la optimización, medimos las mismas métricas y entregamos una comparación del antes y el después. La métrica principal de éxito es la mejora en los datos de campo (CrUX), y no solo en los datos de laboratorio, porque los datos de campo son los que afectan el posicionamiento. También damos seguimiento al estado de Core Web Vitals en Search Console (páginas que pasan de "deficiente" a "necesita mejorar" y a "bueno") y, donde hay seguimiento de conversiones, a las métricas de negocio posteriores que la velocidad influye.
En la mayoría de los casos, la optimización de velocidad es invisible para los visitantes: el sitio se ve y funciona igual, pero carga más rápido. La conversión de formato de imágenes (a WebP o AVIF) es visualmente imperceptible con los niveles de compresión que usamos. La carga diferida de JavaScript no cambia lo que hacen los scripts, solo cuándo se ejecutan. La carga diferida de imágenes (lazy loading) no cambia su aspecto, solo cuándo se cargan. La excepción es cuando la propia funcionalidad es el problema de rendimiento, por ejemplo, un widget de chat que aporta 800 ms a su puntaje de INP. En ese caso, le presentamos la disyuntiva con transparencia: el widget genera una penalización de rendimiento significativa, y usted decide si el beneficio justifica el costo.
Un plugin de caché atiende un solo componente de la optimización del rendimiento: el almacenamiento en caché de páginas del lado del servidor. No resuelve la optimización de imágenes, el tamaño del paquete de JavaScript, los recursos que bloquean el renderizado, el impacto de los scripts de terceros, el TTFB causado por un hosting inadecuado ni el INP causado por tareas largas de JavaScript. Un plugin de caché configurado sin optimizar los recursos que almacena mejorará el Time to First Byte solo de forma marginal, pero no moverá los puntajes de Core Web Vitals en los sitios donde las imágenes, los recursos que bloquean el renderizado o el JavaScript son los principales cuellos de botella. Nuestro servicio realiza un análisis de rendimiento completo, identifica los cuellos de botella reales de su sitio y los resuelve de forma integral, y no solo el único cuello de botella que un plugin puede atender.
