Guía principal Rendimiento web · 1 de 8

Cómo mejorar la velocidad de una web: rendimiento y Core Web Vitals

Cómo mejorar la velocidad de una web: qué es el rendimiento, las Core Web Vitals, herramientas gratuitas para medirlo y qué arreglar primero.

Actualizado el 16 min de lectura Verificado por Dex · 8 afirmaciones, 0 abiertas

Puntos clave

  • Prueba las páginas importantes antes de elegir un arreglo.
  • LCP, INP y CLS miden partes distintas de la experiencia.
  • Compara pruebas en las mismas condiciones y sigue los datos reales.
  • DEX Health incluye análisis de calidad y SEO en el plan gratuito.

El rendimiento web es la rapidez con la que carga una página, la prontitud con la que responde cuando alguien toca o hace clic y la estabilidad de su diseño mientras se usa. Optimizar el rendimiento web es encontrar lo que frena esas tres cosas y corregir la causa. Empieza por probar una página importante, lee la evidencia, haz un cambio concreto y confirma que mejoraron tanto la medición como la tarea del visitante.

Un artículo lento puede esconder su respuesta detrás de una imagen que llega tarde. Una página de servicio puede parecer lista mientras su botón de contacto no responde. Una página puede cargar rápido y aun así moverse cuando aparece un banner. Son problemas distintos, así que necesitan comprobaciones distintas.

Esta guía te lleva de una primera prueba a una lista clara de arreglos. También explica cómo DEX Health ayuda a revisar la calidad y el SEO de la página, también en el plan gratuito, junto a las herramientas que miden la velocidad y las Core Web Vitals.

¿Qué es el rendimiento web y qué es optimizarlo?

La optimización del rendimiento mejora cómo se comporta un sitio en los dispositivos y las redes que usan sus visitantes. La velocidad es parte de ese trabajo. También lo son una respuesta rápida a un toque y un diseño que se queda en su sitio mientras carga la página.

El objetivo es una página usable. Los lectores deben ver la respuesta principal, seguir un enlace, abrir un menú o enviar un formulario sin esperas evitables. Un informe útil conecta un síntoma con un recurso, un script, una respuesta del servidor o una decisión de diseño que alguien puede cambiar.

El rendimiento también importa para el SEO. Google recomienda tener buenas Core Web Vitals como parte de una buena experiencia en la página. Su guía sobre las Core Web Vitals y la Búsqueda explica su papel. Una página rápida sigue necesitando contenido relevante y útil; un buen resultado no promete una posición en la búsqueda.

Separa los problemas de descubrimiento. Si la pregunta es si Google puede encontrar o indexar la URL, usa nuestra guía de rastreo e indexación. Esta guía se centra en lo que pasa cuando alguien carga y usa una página.

¿Por qué es importante la velocidad de una web?

El rendimiento decide si un visitante llega a usar la página. Hasta que aparece el contenido principal, no hay experiencia que valorar, y con una conexión lenta esa espera crece mientras llegan los recursos.

Los visitantes se quedan cuando las páginas cargan y responden rápido

El resumen de Google sobre por qué importa la velocidad cita el dato de la BBC: perdía un 10% más de usuarios por cada segundo extra que tardaba en cargar su sitio. Una carga y una respuesta rápidas hacen que la gente siga leyendo, navegando y haciendo clic.

Las conversiones siguen a la experiencia

El mismo resumen recoge casos que relacionan la velocidad con los ingresos. Vodafone informó de que una mejora del 31% en el LCP aumentó las ventas un 8%, y redBus relacionó una mejora del INP con un aumento del 7% en las ventas. Tus resultados serán distintos, pero la dirección es coherente: un formulario o un proceso de pago lento pierde a personas que ya querían actuar.

Los visitantes en el móvil notan antes los problemas

Los teléfonos tienen menos capacidad de proceso y memoria que la mayoría de los portátiles, y las páginas pesadas consumen más datos del plan del visitante. Un script que funciona bien en tu ordenador puede retrasar los toques en un móvil de gama media. Por eso el resultado en el móvil merece su propia revisión.

La experiencia en la página apoya la búsqueda

Google dice que sus sistemas principales de clasificación buscan premiar una buena experiencia en la página, y que esos sistemas usan las Core Web Vitals. Google también dice que unas buenas puntuaciones no garantizan las primeras posiciones y que el contenido relevante va primero. Trata el rendimiento como apoyo del contenido útil, no como su sustituto.

Cómo medir la velocidad de una web

Elige una página que importe a tu negocio. La página de inicio sola no representa todos los artículos, productos o plantillas de servicio. Incluye una entrada típica del blog y una página donde los visitantes hacen una acción importante.

  1. Copia la URL pública exacta, no una vista previa del editor.
  2. Abre PageSpeed Insights y analiza la página.
  3. Lee por separado los resultados del móvil y del ordenador.
  4. Comprueba si la sección de usuarios reales describe esta URL o todo el origen.
  5. Anota la fecha, las condiciones de la prueba, el problema principal y el enlace del informe.
  6. Abre la página tú mismo y prueba su acción clave.

Lee la evidencia antes de cambiar nada. Si un informe señala la imagen principal, identifica esa imagen. Si marca el tiempo dedicado a ejecutar scripts, busca el trabajo implicado. Una etiqueta como “lento en el móvil” es un punto de partida, no un diagnóstico.

Una sola prueba puede variar. Haz un pequeño grupo de pruebas en las mismas condiciones cuando compares un arreglo y busca un patrón coherente. No cambies ajustes hasta conseguir un resultado favorable.

En un equipo pequeño, guarda un registro sencillo por problema: URL o plantilla afectada, síntoma, evidencia, cambio propuesto, responsable y forma de comprobarlo. Así un informe de rendimiento se convierte en trabajo que se puede terminar.

Herramientas gratuitas para medir el rendimiento web

Google ofrece herramientas gratuitas que responden preguntas distintas. Usa las herramientas de laboratorio para reproducir y depurar un problema, y las de campo para ver lo que viven los visitantes reales.

Herramienta Datos Úsala para
PageSpeed Insights Laboratorio (Lighthouse) y campo (CrUX) Revisar una URL en móvil y ordenador y leer las Core Web Vitals de usuarios reales de los 28 días anteriores.
Lighthouse Laboratorio Hacer auditorías de rendimiento, accesibilidad, SEO y más desde Chrome DevTools, la línea de comandos o un módulo de Node.
Panel Rendimiento de Chrome DevTools Mediciones locales Ver tu LCP y tu CLS en directo, capturar el INP al interactuar y grabar un perfil para encontrar el trabajo que hay detrás de un retraso.
Informe de Core Web Vitals de Search Console Campo (CrUX) Encontrar grupos de URL indexadas parecidas con estado Mala, Necesita mejorar o Buena.
Informe de experiencia de usuario de Chrome (CrUX) Campo Consultar el conjunto público de experiencias reales de usuarios de Chrome que alimenta los datos de campo de las herramientas de Google.

Los datos de campo tienen límites. Una página aparece en CrUX solo cuando se puede descubrir públicamente y tiene suficientes visitas. Cuando una URL no tiene datos, PageSpeed Insights recurre a todo el origen, y Search Console puede mostrar que no hay datos disponibles en una propiedad nueva. En un sitio nuevo o con poco tráfico, apóyate en las pruebas de laboratorio y en tus propias comprobaciones hasta que lleguen los datos de campo.

Las herramientas de terceros pueden añadir vistas como ubicaciones de prueba y gráficos en cascada. Uses lo que uses, mantén la misma herramienta y los mismos ajustes en las comparaciones de antes y después.

Core Web Vitals: las métricas clave que debes seguir

Las Core Web Vitals actuales son LCP, INP y CLS. Describen la carga, la capacidad de respuesta y la estabilidad visual. La guía oficial de Web Vitals define las métricas y sus reglas de medición.

Métrica Qué te dice Objetivo bueno
Largest Contentful Paint (LCP) Cuándo aparece el elemento de contenido visible más grande. 2,5 segundos o menos.
Interaction to Next Paint (INP) Con qué rapidez responde visualmente la página a una acción del usuario. 200 milisegundos o menos.
Cumulative Layout Shift (CLS) Cuánto se mueve de forma inesperada el contenido visible. 0,1 o menos.

En una evaluación de campo, estos objetivos se aplican al percentil 75 de las visitas, con el móvil y el ordenador por separado. No son objetivos para la media de unas pocas pruebas manuales.

LCP: ¿los visitantes ven pronto el contenido principal?

Una imagen grande, un bloque de texto u otro elemento válido puede ser el elemento LCP. Comprueba cuál identifica el informe. Una respuesta lenta del servidor o un recurso que se descubre tarde pueden retrasarlo, aunque el archivo de imagen sea pequeño.

INP: ¿la página responde cuando los visitantes interactúan?

Prueba el menú, los filtros, los acordeones y la llamada a la acción principal. Las tareas largas y los scripts ocupados pueden retrasar la siguiente actualización visible. Una página que parece cargada del todo puede responder mal cuando alguien hace clic.

CLS: ¿el diseño se queda en su sitio?

Una imagen sin espacio reservado o un banner que llega tarde pueden mover el contenido mientras alguien lee. Corrige el origen del movimiento. Ocultar un componente útil solo para quitar un aviso puede perjudicar el propósito de la página.

Otras métricas ayudan a explicar las causas. El Time to First Byte (TTFB) ayuda a investigar la respuesta inicial. El Total Blocking Time (TBT) ayuda a diagnosticar tareas largas que bloquean en el laboratorio. Ninguna forma parte del conjunto actual de Core Web Vitals, y el TBT no es un resultado de INP medido en campo.

¿Por qué las herramientas de rendimiento dan resultados distintos?

Una prueba de laboratorio carga la página en un entorno controlado. Los datos de campo reflejan visitas reales, con dispositivos, redes e interacciones distintos. Ambos son útiles, pero responden preguntas diferentes.

Usa los datos de laboratorio para reproducir un problema y valorar un arreglo propuesto. Usa los datos de campo para entender la experiencia que tienen de verdad los visitantes. PageSpeed Insights puede mostrar ambos, así que lee las etiquetas de cada sección en lugar de tratar todos los números como un solo resultado.

La documentación de PageSpeed Insights explica las fuentes de datos. Sus datos de campo cubren un periodo móvil de 28 días. Un cambio hecho hoy no sustituye al instante todo ese historial.

Algunas URL no tienen suficientes datos de campo válidos. Eso no prueba que la página sea rápida ni lenta. Anota la falta de datos, usa las pruebas disponibles y no presentes datos del origen como la medición de un artículo.

Los ajustes de la prueba también importan. Una prueba de ordenador con una conexión rápida puede salir mucho mejor que una simulación de móvil. Compara lo comparable. Anota el modo de dispositivo y las condiciones antes de afirmar que un resultado mejoró.

¿Qué hace lenta una página web?

Varias causas pueden producir el mismo síntoma. Una imagen principal que llega tarde puede deberse a una descarga grande, a un descubrimiento tardío o a una respuesta inicial lenta. Averigua dónde se va el tiempo antes de elegir un arreglo.

  • Contenido multimedia pesado: las imágenes o los vídeos transfieren más datos de los que necesita la página.
  • JavaScript ocupado: los scripts mantienen ocupado al navegador cuando necesita responder.
  • Recursos que bloquean: los estilos u otros archivos retrasan una visualización útil.
  • Entrega lenta: el servidor tarda demasiado en empezar a responder.
  • Diseño inestable: el contenido llega sin espacio reservado.
  • Añadidos de terceros: los contenidos insertados, los chats, los anuncios o las etiquetas añaden solicitudes y trabajo.

Una prueba controlada del rendimiento de los plugins es más útil que contar plugins. Un componente costoso puede pesar más que varios pequeños. Pregunta qué carga un componente, cuándo se ejecuta y si la página lo necesita.

Busca patrones repetidos. Si todos los artículos tienen el mismo movimiento, revisa la plantilla común. Si una entrada es lenta, compara sus imágenes y contenidos insertados. Corregir en el nivel adecuado evita que los editores traten un problema de todo el sitio artículo por artículo.

Cómo mejorar la velocidad de una web

Usa la evidencia de las pruebas para elegir un cambio. Hazlo en un flujo seguro, confirma el resultado público y revisa los efectos secundarios. Las áreas siguientes son buenos puntos de investigación, no una exigencia de cambiar todos los ajustes.

Ajusta el tamaño de las imágenes y otros contenidos multimedia

Usa un tamaño de imagen acorde con su función en pantalla y un formato adecuado. Deja que el navegador elija las variantes adecuadas cuando el sitio admite imágenes adaptables. Revisa la calidad tras comprimir para que los diagramas y las capturas sigan siendo legibles.

Reserva espacio con dimensiones o una relación de aspecto. La carga diferida de imágenes puede ayudar con las imágenes que quedan más abajo, pero retrasar una imagen que probablemente sea el LCP puede hacer más lenta la primera vista. Confirma cómo se descubre y carga la imagen principal antes de aplicar una regla a todo.

DEX genera y optimiza imágenes dentro de su flujo de artículos. La página publicada sigue dependiendo de cómo las entregan el CMS y el tema. Nuestra guía de SEO de imágenes trata con más detalle el contexto, la accesibilidad y las comprobaciones al publicar.

Reduce el JavaScript innecesario y el trabajo de terceros

Sigue los pasos para encontrar el trabajo costoso de JavaScript cuando una acción de la página se note lenta.

Revisa los scripts que se ejecutan en todas las páginas. ¿Necesita un artículo los mismos widgets que un proceso de pago? Quita las funciones que no se usan mediante la configuración compatible y pide al desarrollador que aplace o divida el trabajo cuando la evidencia lo justifique.

Prueba las interacciones después del cambio. Retrasar un script puede romper un menú o un formulario si las dependencias no son correctas. Sigue la guía oficial para optimizar el INP cuando investigues la capacidad de respuesta y las tareas largas.

Revisa la carga del CSS y de las fuentes

Comprueba los recursos que retrasan la vista inicial. Los estilos que no se usan y el exceso de variantes de fuentes añaden trabajo. Un desarrollador puede valorar qué recursos hacen falta al principio y cuáles pueden cargar después.

Sigue las buenas prácticas para cargar fuentes web para mantener el texto legible y revisa si hay movimientos cuando cambian las fuentes. No borres estilos a ciegas porque un informe marque CSS sin usar en una URL; otra plantilla puede depender de ellos.

Mejora la respuesta del servidor, la caché y la entrega de archivos

Empieza por comprobar la caché de la web para confirmar que se reutiliza y que el contenido está actualizado. Usa el diagnóstico de un TTFB lento cuando la respuesta del documento siga tardando.

Si la respuesta inicial es lenta, implica a la persona que gestiona el alojamiento y el código de la aplicación. Investiga el trabajo del servidor, el comportamiento de la caché y la entrega de los recursos públicos. Contratar un plan nuevo antes de encontrar el retraso puede dejar intacta la causa real.

Las reglas de caché necesitan cuidado en páginas con datos personales o cambiantes. Una respuesta más rápida no es un éxito si sirve el contenido equivocado. Vuelve a probar el comportamiento de la página, además de sus tiempos.

La guía para optimizar el LCP divide el camino de carga en etapas. Úsala para distinguir una respuesta lenta de los retrasos al encontrar, descargar o mostrar el recurso principal.

Reserva espacio y evita movimientos inesperados

Usa la guía para corregir los movimientos de diseño causados por imágenes y contenidos insertados revisando el espacio que necesitan esos elementos. Revisa los banners y los avisos en la primera visita, no solo después de que tu navegador los haya cerrado.

Usa la guía para optimizar el CLS para rastrear las causas habituales. Revisa la página mientras carga y mientras te desplazas. Una sola captura estática no muestra todos los movimientos que puede encontrar un visitante.

¿Qué problemas de rendimiento debes arreglar primero?

Elige el trabajo por su efecto en las tareas reales, la solidez de la evidencia y el número de páginas afectadas. Un componente común que bloquea un formulario de contacto merece atención antes que un aviso menor en un artículo antiguo.

Hallazgo Siguiente acción útil Responsable habitual
Un artículo tiene una imagen principal demasiado grande. Preparar un archivo adecuado y comprobar cómo se entrega una vez publicado. Editor y responsable del CMS.
Un script común retrasa la interacción en varias plantillas. Perfilar el trabajo y probar un cambio de código concreto. Desarrollador.
Las respuestas iniciales son lentas en páginas clave. Investigar el comportamiento de la aplicación, la caché y el alojamiento. Desarrollador o equipo de alojamiento.
Un contenido insertado mueve el artículo al cargar. Reservar espacio y probar el diseño. Responsable del tema o del componente.

Mantén la tarea lo bastante pequeña para poder comprobarla. “Mejorar la velocidad” no tiene un final claro. “Comprobar por qué la imagen principal de este artículo carga tarde, cambiar su entrega y comparar la misma prueba en el móvil” da al responsable un buen punto de partida.

Planifica cómo deshacer los cambios que afectan a muchas páginas. Revisa un artículo, una página de servicio y un formulario representativos antes de dar por terminado un cambio común. Una prueba mejorada no demuestra que todo el sitio funcione mejor.

Ejemplo: cómo diagnosticar un artículo lento del blog

Imagina una pequeña tienda de muebles con una guía para elegir una lámpara de escritorio. El artículo es útil, pero su imagen principal aparece tarde en el móvil. Es un ejemplo hipotético, no el resultado de un cliente.

  1. Guarda el punto de partida: anota la URL pública, la prueba en el móvil, la fecha y el elemento LCP identificado.
  2. Localiza el retraso: revisa cuándo se solicita la imagen y si la plantilla la retrasa.
  3. Elige un arreglo concreto: prepara una imagen adecuada y pide al desarrollador que revise cómo se carga.
  4. Publica y compara: repite la prueba en las mismas condiciones y revisa la primera vista.
  5. Comprueba que todo funciona: confirma que la imagen se ve bien, que el diseño no se mueve y que los enlaces relacionados siguen funcionando.
  6. Sigue las visitas reales: revisa los datos de campo cuando estén disponibles.

El ejemplo no promete un ahorro de tiempo concreto ni una mejora de posiciones. Su valor es el método: un problema visible lleva a un cambio que se puede probar. Si la evidencia apuntara a una respuesta lenta del servidor, cambiar solo la imagen no resolvería esa causa.

Cómo comprobar los arreglos y vigilar el rendimiento web

Guarda un registro de antes y después con la misma URL y condiciones comparables. Compara la métrica afectada y la causa, no solo la puntuación general. Guarda la fecha del cambio para que los datos de campo posteriores tengan contexto.

En las páginas interactivas, no te quedes en una prueba de carga. Abre el menú, usa el formulario y prueba la llamada a la acción principal. Revisa la primera visita y las vistas de los dispositivos importantes. Una mejora de velocidad que rompe un formulario de contacto falla en la tarea del negocio.

Después, vigila las regresiones. Los nuevos contenidos insertados, banners, plantillas y cambios de seguimiento pueden añadir trabajo más adelante. Vuelve a probar tras cambios importantes y programa revisiones según la frecuencia con la que cambia el sitio.

No esperes a una revisión periódica para arreglar un fallo crítico conocido. La revisión más amplia de DEX de las páginas que no ganan posiciones tras unos 30 a 60 días tiene otro propósito. No significa que una interacción rota deba seguir publicada hasta entonces.

Cómo encaja DEX Health en tu flujo de rendimiento

DEX incluye el análisis de calidad y SEO de las páginas incluso en su plan gratuito. Eso da a un equipo pequeño una forma de empezar a revisar las páginas publicadas antes de comprometerse con un flujo de contenido mayor.

Usa DEX Health para revisar la página pública, leer los hallazgos y separar el trabajo del artículo de los problemas del tema o del servidor. Un aviso sobre la entrega de imágenes puede necesitar un cambio en el tema. Un problema de contenido puede corresponder al editor. Asigna a cada tarea un responsable y una forma de confirmar el cambio.

Combina esa revisión con mediciones de rendimiento. Una puntuación SEO de DEX resume sus comprobaciones; no es la puntuación de rendimiento de PageSpeed ni una evaluación de campo de las Core Web Vitals. Lee cada informe por la pregunta que responde.

Así la producción sigue conectada con la calidad. Publica el artículo, revisa su versión pública, comprueba su SEO y usa las herramientas de velocidad cuando la carga o la interacción necesiten investigarse. Nuestra checklist de publicación en el CMS cubre las comprobaciones al publicar, y la guía de auditoría de contenido cubre una revisión editorial más profunda.

Si tu equipo publica con regularidad, empieza con el análisis gratuito para concretar la siguiente mejora. A medida que crezca el flujo, mantén el mismo hábito: un hallazgo claro, una persona responsable y un resultado comprobado.

Checklist para optimizar el rendimiento web

  • Elige páginas importantes y plantillas representativas.
  • Anota por separado los resultados del móvil y del ordenador.
  • Distingue los datos de campo de las pruebas de laboratorio.
  • Identifica el recurso o el comportamiento concreto detrás de un mal resultado.
  • Elige un arreglo respaldado por la evidencia.
  • Asigna un responsable para el trabajo de contenido, tema, código o servidor.
  • Compara los resultados en condiciones parecidas después de publicar.
  • Prueba los formularios, los menús, las imágenes y los enlaces clave.
  • Revisa los datos de usuarios reales y vuelve a probar tras cambios importantes.
  • Usa DEX Health para mantener en el flujo las comprobaciones de calidad y SEO de la página.

Un buen proceso de optimización termina con una página que funciona mejor y un registro de lo que cambió. Empieza por revisar un artículo importante. Empieza con DEX para conectar la revisión de páginas con tus próximas acciones de SEO.

Preguntas frecuentes

¿Necesito una puntuación perfecta en PageSpeed?

No. Céntrate en la experiencia del usuario y en la evidencia. Una puntuación perfecta no prueba que todos los visitantes tengan una buena experiencia.

¿Por qué el resultado móvil es peor que el de escritorio?

Las condiciones de dispositivo y red son distintas. Compara cada modo por separado e investiga los recursos o el trabajo que causan el retraso.

¿Aprobar las Core Web Vitals garantiza el posicionamiento?

No. Un buen rendimiento apoya la experiencia en la página, pero la página también tiene que responder a la búsqueda y competir con otros resultados.

¿Qué es un buen rendimiento web?

Según la guía de Web Vitals, una página es buena cuando, en el percentil 75 de las visitas, el LCP es de 2,5 segundos o menos, el INP de 200 milisegundos o menos y el CLS de 0,1 o menos.

¿Cómo puedo medir la velocidad de mi web gratis?

Analiza la URL en PageSpeed Insights, usa Lighthouse o el panel Rendimiento de Chrome para buscar causas y abre el informe de Core Web Vitals de Search Console para ver grupos de páginas.

¿Puedo analizar la calidad y el SEO de una página con el plan gratuito de DEX?

Sí. DEX incluye ese análisis en el plan gratuito. Úsalo junto a las herramientas de velocidad cuando necesites medir la carga y las interacciones.

Fuentes

  1. Web Vitals · web.dev (Google)
  2. ¿Por qué es importante la velocidad? · web.dev (Google)
  3. Información sobre las Métricas web esenciales y los resultados de búsqueda de Google · Google Search Central
  4. Información sobre PageSpeed Insights · Google for Developers
  5. Informe de Core Web Vitals · Ayuda de Search Console
  6. DEX SEO · DEX

Dex SEO is an AI SEO agent for small businesses. Every article here is planned from search data, drafted by Dex, fact-checked against the sources it cites, and reviewed by the team before it is published.

Cómo se hizo este artículo: planificado y redactado por Dex a partir de datos de búsqueda, verificado por Dex (8 afirmaciones revisadas) y aprobado por el equipo de Dex SEO.

Siguiente en este cluster

Sigue leyendo

Todos los temas