Page Speed
Average
First contentful paint: 2.6s
DOM content loaded: 1.1s
Page Load Distributions

FCP

30%
40%
30%

DCL

0% 25% 50% 75%
30%
40%
30%

Fast

Average

Slow

Start monitoring your website’s health

page_speed Start monitoring

Optimization Suggestions

Descubra todas las formas de acelerar la carga de un sitio web

Descubra todas las formas de acelerar la carga de un sitio web
1 Star2 Stars3 Stars4 Stars5 Stars (56 votes, average: 4.25 out of 5)

5

Loading...
Table of Contents Tabla de contenido

 

Todos saben que un sitio web lento es malo. Cuando una plataforma de este tipo se frena al cargar, surgen problemas serios en la solución de las tareas cotidianas. A veces es simplemente molesto.

A menudo, el frenado del sitio es un colapso, y con este existe un servicio negativo: las personas no esperan las descargas y deciden irse. Esto es relevante para los casos donde hay un frenado radical en el sitio, por ejemplo, cuando el inicio del procesamiento de la página comienza entre 8 y 10 segundos después del clic.

Incluso con una situación relativamente favorable hacia el sitio (con una descarga rápida en Internet por cable y una computadora moderna), las demoras en la descarga pueden provocar la pérdida de audiencia y también generar menores tasas de conversión. Por ejemplo, Amazon llevó a cabo un experimento en el que descubrió que cada retraso de 100 ms (0,1s) generaba una disminución de las ventas en un 1%.

Incluso, más de la mitad de la audiencia del Internet hoy usa dispositivos móviles para acceder a las plataformas web, de modo que pueden acceder a canales lentos para el ingreso y proceso de descargar el sitio.

Otra razón de gran importancia sobre la velocidad del sitio es la técnica. Normalmente, los sitios lentos consumen una mayor cantidad de recursos de alojamiento, lo que genera costos adicionales. En sí, los frenos por parte del servidor reducen la capacidad de experimentar picos de carga problemáticos en el sitio.

Por lo tanto, la velocidad del sitio debe abordarse desde un punto de vista técnico y económico. En este artículo nos concentraremos en el aspecto técnico de la aceleración de los sitios web.

 

Velocidad del sitio web: los componentes principales

 

La velocidad del sitio se compone de dos partes: el cliente y el servidor. Hasta la fecha, cada una de estas partes es equivalente al resultado final, y cada una viene con sus propias características.

Para entender cuál es el tiempo de carga de una página web, echemos un vistazo al proceso. Como resultado, podremos entender dónde se encuentran las capacidades de optimización del servidor y del cliente.

El proceso completo de descarga del sitio (en la primera visita) es el siguiente:

  •  Se consulta alcDNS por nombre del sitio.
  •  Se establece una conexión al servidor por IP (conexión TCP).
  •  Se establece una conexión segura cuando se usa HTTPS (conexión TLS).
  •  Se realiza una solicitud de página HTML por la URL y posteriormente, se espera el servidor (solicitud HTTP).
  •  Se establece la carga del HTML.
  •  Se realiza un análisis del documento HTML por parte del navegador, y luego se crea una lista de consulta en los recursos del documento.
  •  Se carga y analiza el estilo CSS.
  •  Se carga y ejecuta el código JS.
  •  Inicio de la representación de la página, y posterior ejecución del código JS.
  •  Descarga de las fuentes de la web.
  •  Carga de imágenes y otros elementos.
  •  Final de la representación de la página y ejecución del código JS diferido.

En este proceso, algunas fases ocurren en paralelo y algunas pueden cambiar lugares, pero la esencia sigue siendo la misma.

La optimización del servidor se ocupa de la primera y hasta la cuarta etapa. Los pasos que transcurren del 5 a 12 son referidos a la optimización del cliente. El tiempo dedicado a cada una de estas etapas es individual para cada sitio, por lo que se debe obtener sus métricas e identificar la fuente principal de los problemas.

Y aquí pasamos a la pregunta de cómo obtener estas métricas e interpretarlas.

 

Medición de la velocidad del sitio web

 

La pregunta principal es: ¿qué debe ser medido?

Hay muchas métricas para la velocidad de sitios web, pero no muchas de ellas son básicas.

Primero, el Time To de First Byte (TTFB – tiempo hasta el primer byte) es el tiempo desde el inicio del proceso de descarga hasta la recepción de la primera porción de datos del servidor. Esta es la métrica principal para que se dé la optimización del servidor.

En segundo lugar, se da el comienzo de la representación –o rendering– de la página (representación de inicio – primera pintura). La métrica muestra el tiempo hasta el final del período de “pantalla blanca” en el navegador, que es cuando la página comienza a dibujarse.

En tercer lugar, se cargan los elementos principales de la página (tiempo de carga). Esto incluye establecer e interpretar todos los recursos para trabajar con la página, después de esta señal, el indicador de carga de la página deja de girar.

En cuarto lugar esta la carga completa de la página: el tiempo antes del final de la principal actividad del navegador, en la que todos los recursos principales y diferidos se cargan.

Estas métricas o medidas básicas son medidas (valga la redundancia) en segundos. También es útil tener una estimación de la cantidad de tráfico para la tercera y cuarta métrica. Es necesario conocer el tráfico para evaluar el efecto de la velocidad de conexión en el tiempo de carga.

Ahora tenemos que comprender cómo probar la velocidad; hay muchos servicios y herramientas para evaluar las métricas de la velocidad de descarga de sitios, cada uno de los cuales sea mejor para su tarea o rol principal.

Una de las herramientas más potentes es el panel de desarrolladores en el navegador. La funcionalidad más avanzada en el panel está en Chrome. En la pestaña Red se puede obtener métricas sobre el tiempo de carga de todos los elementos, incluido el mismísimo documento HTML. Cuando se pasa el cursor sobre un elemento, se puede ver cuánto tiempo se dedica a cada paso para obtener el recurso que se espera. Para evaluar todo del proceso de carga de la página, se puede usar la pestaña Rendimiento, la cual proporciona completos detalles sobre el momento de la decodificación de las imágenes.

Si necesita evaluar la velocidad de un sitio web, pero sin su granularidad completa, es útil comenzar una auditoría del sitio (en la pestaña Auditorías). Esta se llevará a cabo utilizando el plug-in Lighthouse. En el informe, usted obtendrá una estimación de la velocidad en los dispositivos móviles (integral en los puntos, por lo tanto con nuestras métricas básicas), así como varios otros informes.

Para evaluar rápidamente la optimización del cliente, puede usar los servicios de Google PageSpeed Insights o Sitechecker (utilizamos el API de Google PageSpeed Insights). Finalmente, es útil analizar el tiempo de descarga del sitio de usuarios reales. Para esto, hay informes especiales en los sistemas de análisis web Yandex.Metrics y Google Analytics.

Los puntos de referencia para el tiempo de carga del sitio son los siguientes: el inicio de la presentación es de aproximadamente 1 segundo, cargando la página luego de 3-5 segundos. En dicho marco, los usuarios no se quejarán de la velocidad del sitio y el tiempo de descarga no limitará la efectividad del sitio.

Estas cifras deben ser alcanzadas por usuarios reales, incluso en condiciones difíciles de conexión móvil y dispositivos desactualizados.

 

Optimización del servidor

 

Pasemos ahora a la aceleración del propio sitio. La optimización de la parte del servidor es la medida más comprehensible y obvia para los desarrolladores. En primer lugar, la parte del servidor se supervisa y controla fácilmente por parte de los administradores del sistema. En segundo lugar, con serios problemas con el tiempo de respuesta del servidor, la desaceleración es notable para todos, independientemente de la velocidad de la conexión o el dispositivo.

Si bien las razones para frenar el servidor pueden ser muy diversas, hay problemas típicos a los que estar atentos mirar.

 

Hosting (recursos del servidor)

Esta es la razón número uno del frenado en sitios web pequeños. Ocurre que para cargar el sitio simplemente no hay suficientes recursos de alojamiento (por lo general, la CPU y la velocidad del sistema de disco). Si puede aumentar rápidamente estos recursos, vale la pena intentarlo. En algunos casos, el problema será resuelto. Si el costo de los recursos adicionales supera el costo del trabajo de optimización, debe continuar con los siguientes métodos.

 

 

DBMS (base de datos del servidor)

Aquí ya estamos entrando a la fuente del problema: la baja velocidad del código fuente. A menudo, una aplicación web se gasta en solicitudes de bases de datos. Esto es lógico, ya que la tarea de una aplicación web es recopilar datos y convertirlos según un patrón determinado.

Resolver el problema de respuestas lentas por parte de la base de datos generalmente se divide en dos etapas: ajuste del DBMS y optimización de las consultas y esquemas de datos.

Afinar el DBMS (por ejemplo, usando MySQL) puede dar datos de aceleración varias veces, en caso de que la sintonización no se haya realizado previamente. La afinación puede dar un efecto dentro del 12%.

La optimización de consultas y esquemas de datos es una forma radical de acelerar. Debido a esta optimización, es posible obtener una magnitud de aceleración de diversos campos. Si el cambio en la estructura de la base de datos puede ocurrir sin intrusión en el código del programa del sitio, entonces la optimización de solicitudes requerirá tal intervención.

Para identificar las consultas lentas, se debe recopilar estadísticas sobre su carga en la base de datos durante un período bastante largo de tiempo. Luego, se analiza el registro y se identifican los candidatos para recibir una optimización.

 

Efecto del CMS y código fuente

Se cree que la velocidad del sitio depende solo del CMS (motor). Los propietarios del sitio a menudo intentan dividir el CMS en rápido y lento. Pero actualmente esto no es verdad.

Por supuesto, la carga en el servidor depende del código que se incluye en el CMS en uso. Sin embargo, los sistemas más populares intentan optimizarse para obtener la máxima velocidad, así que no debería haber problemas fatales con la velocidad del sitio.

Sin embargo, además del código CMS principal, el sitio puede contener módulos adicionales (complementos o plug-ins), extensiones y modificaciones añadidas por parte de los desarrolladores del sitio. Este código puede tener un impacto negativo en la velocidad del sitio.

Además, los problemas de velocidad ocurren cuando el sistema es mal utilizado. Por ejemplo, el sistema de blogs se usa para crear una tienda, así como el sistema para sitios pequeños se usa para desarrollar un portal.

 

Caching o Almacenamiento de Caché

El medio más poderoso y universal para aumentar la velocidad del servidor es tradicionalmente el almacenamiento en caché. Aquí estamos hablando de caché del lado del servidor, y no del almacenamiento de caché que se basa en encabezados de páginas. Si el cálculo del resultado (ensamblaje de la página o bloque) requiere de recursos significativos, coloque el resultado en el caché y actualícelo periódicamente.

La idea es simple y compleja al mismo tiempo: los sistemas de almacenamiento en caché están construidos en los lenguajes de programación, también los sistemas de administración de sitios y los servidores web.

Normalmente, el caching de las páginas le permite reducir el tiempo de “renderización” a decenas de milisegundos. Naturalmente, en este caso, el servidor experimenta fácilmente picos de concurrencia.

Aquí hay dos problemas: no todo se puede almacenar en el caché y la memoria caché se debe deshabilitar correctamente (o descartar). Si se resuelven los problemas, se puede recomendar el almacenamiento en caché como un medio eficaz de aceleración del servidor.

 

Optimización de TCP, TLS, HTTP/2

En esta parte, combinamos optimizaciones sutiles de red que dan aceleración al servidor. El efecto aquí no es tan grande como en otros métodos, pero se logra exclusivamente por configuración, es decir, ¡gratis!

Hoy se necesita ajustar el TCP para grandes proyectos y servidores con una conexión de 10G o más. Por esto debemos recordar: el subsistema de red se actualiza regularmente con el lanzamiento de nuevos núcleos de Linux, por lo que vale la pena actualizarlo. La configuración correcta del TLS (HTTPS) permite obtener un alto nivel de seguridad y minimizar el tiempo para establecer una conexión segura.

Mozilla hace muy buenas recomendaciones al respecto.

La nueva versión del protocolo HTTP – HTTP/2 está diseñada para acelerar la descarga de sitios web. Este protocolo apareció recientemente y ahora se usa activamente (alrededor del 20% del total de los sitios web). En general, en el protocolo HTTP/2 los mecanismos de aceleración están establecidos, el objetivo principal es reducir el efecto de los retrasos de la red en el tiempo de carga de la página (solicitudes multiplexadas). Pero la aceleración gracias al HTTP/2 no siempre es exitosa, así que mejor no confíe del todo en este protocolo.

 

Optimización del cliente

 

A diferencia de la optimización del servidor, el cliente se refiere a todo lo que sucede en el navegador del usuario. Debido a esto, el control se hace complicado (diferentes dispositivos y navegadores) y surgen muchas reglas diferentes de optimización.

A continuación veremos los métodos más efectivos y universales que se pueden usar en casi cualquier proyecto.

 

Optimización de ruta crítica en CSS y JS

Ruta crítica de representación (o ruta crítica de interpretación): un conjunto de recursos para iniciar la representación de la página en el navegador. Normalmente, esta lista incluye el documento HTML, estilos CSS, fuentes y código JS.

Nuestra tarea como optimizadores de velocidad es acortar este camino, tanto en tiempo (teniendo en cuenta los retrasos de la red) como en tráfico (tener en cuenta las conexiones lentas).

La forma más fácil de determinar la ruta crítica es iniciar una auditoría en Chrome (en el Panel del desarrollador), ya que el plug-in Lighthouse determina su composición y el tiempo de arranque, teniendo en cuenta las conexiones lentas.

La técnica principal para reducir la ruta crítica es: eliminar todo lo que no es necesario o todo lo que pueda posponerse. Por ejemplo, la mayor parte del código JS puede diferirse antes de que se cargue la página. Para hacer esto, coloque la llamada de recurso JS al final del documento HTML o use el atributo “async”.

Para la carga diferida o retrasada del CSS, es posible utilizar una conexión dinámica de estilos a través de JS (esperando el evento domContentLoaded).

 

Optimizando las fuentes web

La conexión de fuentes web hoy en día se ha convertido casi en un estándar en diseño. Desafortunadamente, afectan negativamente la velocidad de la representación de la página. Las fuentes web son recursos adicionales que se deben obtener antes de comenzar a dibujar el texto.

La situación empeora porque a menudo los punteros de los archivos de fuentes están ocultos en un archivo CSS, y su carga tampoco ocurre al instante. A muchos desarrolladores les gusta usar servicios públicos de fuentes web (por ejemplo, Google Fonts), que causan aún más retrasos (conexiones adicionales y más archivos CSS).

Las reglas de optimización consisten en reducir el tamaño del tráfico de fuentes web y obtenerlas lo más rápido posible.

Para reducir el tráfico, se debe usar formatos modernos: WOFF2 para navegadores modernos, o WOFF para lograr compatibilidad. Además, solo necesita incluir aquellos juegos de caracteres que se usan en el sitio (por ejemplo, latín ó cirílico).

Para influir en la rápida visualización de las fuentes web, se puede usar el nuevo enlace de especificación rel=”preload” y la propiedad font-display de CSS. Esta pre-carga (preload) permitirá expresarle al navegador lo antes posible la necesidad de descargar un archivo de fuentes, mientras que font-display proporciona una forma flexible de controlar el comportamiento del navegador en caso de retrasos del archivo (esperar, usar un repuesto, no esperar una fuente de más de tres segundos).

 

Optimizando las imágenes

Las imágenes son la mayor parte del peso de un sitio moderno. Por supuesto, las imágenes no son recursos tan extremos para una página como CSS y código JS. Pero para muchos sitios, las imágenes son una parte importante del contenido: recuerde que cualquier tarjeta de producto en una tienda en línea tiene una imagen.

La técnica principal para optimizar imágenes es reducir su tamaño. Para hacer esto, use los formatos correctos y herramientas de compresión:

  •  PNG para imágenes con transparencia y texto;
  • JPEG para fotos e imágenes complejas;
  • SVG para gráficos y vectores.

Además de estos formatos, se están desarrollando otros nuevos: por ejemplo, el WebP de Google. Este formato puede cubrir el área de uso de PNG y JPEG: admite compresión con perdida y sin perdida, transparencia e incluso animación. Para usarlo, es suficiente crear una copia de las imágenes en WebP y dárselas a los navegadores que las admiten.

Para el formato PNG hay muchas utilidades de optimización que se pueden usar para reducir el tamaño web, por ejemplo, OptiPNG, PNGout, EWWW Image Optimizer y otros. Además, la optimización interna de la compresión de datos se puede realizar utilizando zopfliPNG.

La idea principal de dicho software es seleccionar los parámetros de compresión óptimos, eliminando datos innecesarios del archivo. Debes tener cuidado aquí: algunas utilidades sufren pérdida de calidad, lo cual puede no ser adecuado para ti (si esperas que salga la misma imagen).

La optimización de JPEG también se divide en dos tipos: con pérdida y sin pérdida. En general, podemos recomendar el paquete Mozilla JPEG, que está especialmente diseñado para una mejor compresión en este formato. Para la optimización sin pérdida, se puede usar jpegtran, y para la optimización con pérdidas, se puede utilizar cjpeg.

 

Encabezados Caché

Este es el método más simple de optimización para el cliente. Su efectividad radica en el almacenamiento de recursos excepcionales en el caché del navegador: imágenes, CSS y archivos JS, fuentes, a veces incluso el documento HTML en sí mismo. Como resultado, cada recurso se solicita del servidor solo una vez.

Si está usando Nginx, simplemente agregue el comando:

add_header Cache-Control "max-age=31536000, immutable";

Si está usando Nginx, simplemente agregue el comando:

A partir de ahora, el navegador tiene derecho a almacenar en el caché los recursos hasta por un año (lo cual es casi para siempre). El nuevo parámetro “inmutable” indica que el recurso no va a cambiar.

Por supuesto, surge la pregunta: ¿y si necesitamos cambiar el recurso almacenado? La respuesta es simple: cambie su dirección URL.

Por ejemplo, puede agregar una versión a un nombre de archivo. Para los documentos HTML, este método también es aplicable, pero, como regla general, se utiliza un período más corto de almacenamiento en caché (por ejemplo, un minuto o una hora).

 

Compresión de datos

Una práctica obligatoria es la compresión de cualquier información de texto cuando se transfiere desde el servidor al navegador. La mayoría de los servidores web tienen una implementación de respuestas en gzip-compression.

Sin embargo, la activación de una compresión simple no es suficiente.

Primero, la relación de compresión es ajustable y debe estar cerca del máximo.

En segundo lugar, se puede usar la compresión estática, es decir, precomprimir archivos y colocarlos en el disco. Luego, el servidor web buscará la versión comprimida y la hará llegar de inmediato.

En tercer lugar, se puede utilizar algoritmos de compresión más eficientes: zopfli (compatible con gzip) y brotli (un nuevo algoritmo de compresión). Brotli solo funcionará con HTTPS.

Como estos algoritmos (especialmente zopfli) son costosos cuando se trata de comprimir, siempre los usamos en la versión estática.

Para maximizar el efecto de la compresión de archivos, el proceso de “minificación” se aplica de manera preliminar: elimina traducciones innecesarias de cadenas, espacios y otros caracteres innecesarios. Este proceso es específico para cada formato. Además, se debe comprimir otros datos de texto en el sitio.

 

Usando el CDN

 

Aplicar el CDN (red de entrega de contenido) para la aceleración del sitio web es una medida muy punlicitada, que tiene un montón de marketing en torno a su esencia tecnológica.

 

Teoría: el porqué

Inicialmente, los CDN se diseñaron para descargar los canales de Internet de los sitios web de medios de difusión. Por ejemplo, cuando se ve un video en vivo, varios miles de espectadores crean una carga muy pesada en el ancho de la banda del servidor.

Además, se pensaron para garantizar la calidad ininterrumpida de la comunicación con grandes clientes y la eliminación del servidor que es extremadamente difícil (debido a retrasos e inestabilidad de la red).

La solución a este problema fue crear un CDN, es decir, una red distribuida a la que los clientes (por ejemplo, los espectadores) estaban conectados, y los hosts de esta red ya están en el servidor (origen). Al mismo tiempo, el número de conexiones al servidor se redujo a uno (de varios), y el número de conexiones al CDN podría llegar a millones debido al almacenamiento en caché del contenido de la red.

Hoy en día, la mayoría de los CDN se posicionan como un medio para acelerar los sitios web, principalmente al reducir la distancia entre el contenido y el cliente (el visitante del sitio).

 

Posibles efectos

¿Cómo se puede acelerar un sitio usando CDN?

Sí, de hecho, por regla general, el usuario se conecta al servidor de red más cercano (según su tiempo de acceso) y obtiene un rápido procesamiento para establecer la conexión TCP y TLS. Además, si el contenido está en el servidor CDN, el usuario puede recibirlo rápidamente. Por lo tanto, la carga en nuestro propio servidor se reduce.

En segundo lugar, el CDN no puede simplemente distribuir contenido sin cambios, sino optimizarlo por su lado y entregarlo en una forma más compacta: este comprime imágenes, aplica compresión a la prueba, entre tantas otras prácticas. Debido a tales optimizaciones, puede obtener un tiempo de descarga más corto.

 

Desventajas del uso de CDN

Las desventajas, como de costumbre, siguen tras las ventajas: el objeto puede no estar en la memoria caché del nodo CDN. Por ejemplo, aún no se ha solicitado o no se puede almacenar en caché (como un documento HTML). En este caso, tenemos retrasos adicionales entre el nodo CDN y nuestro servidor.

A pesar de que las CDN están diseñadas para acelerar el acceso al sitio, hay situaciones en las que la ruta de la red será menos óptima que sin la CDN. Es especialmente importante para las CDN globales, para lo cual Rusia no es un mercado prioritario.

Finalmente, las redes de entrega de contenido son sistemas muy complejos, donde los bloqueos, la inestabilidad y otros problemas también son posibles en todas partes. Usando CDN, agregamos un nivel más de complejidad.

 

Nosotros optimizamos los resultados

 

Digamos que usted logró alcanzar una buena velocidad en su sitio web. Los usuarios y los propietarios del lugar están contentos. ¿Significa que puede olvidarse del problema de la velocidad? Por supuesto que no. Por supuesto no. Para lograr una calidad constante en el trabajo del sitio, debe monitorear el sitio web de forma permanente.

 

Soporte de aceleración

Cualquier proyección web en vivo se actualiza regularmente, los cambios ocurren tanto en plantillas comunes (temas de diseño, interfaces) como en contenido. Además, el código fuente (tanto en cliente como en servidor) está cambiando activamente.

Cada cambio puede afectar la velocidad del sitio. Para monitorear este impacto, se debe implementar un sistema de monitoreo de velocidad sintética de sitio sintético en la etapa de desarrollo. Por lo tanto, los problemas de velocidad pueden ser interceptados antes de que los usuarios los noten.

Para optimizar el contenido entrante o nuevo, se requiere la integración de procedimientos de optimización en el sistema de gestión de contenido. En primer lugar, esto se refiere al procesamiento de imágenes.

La aceleración de sitios es un área muy dinámica; están surgiendo nuevos estándares y su soporte por parte de los navegadores está cambiando. Por lo tanto, es importante auditar periódicamente la tecnología del proyecto, los procesos y el software utilizado.

 

Monitoreo de la velocidad real del usuario

Las pruebas sintéticas en condiciones ideales de laboratorio son muy útiles para evaluar los cambios en el código fuente, pero no son suficientes. Al final, queremos que el sitio funcione rápido para usuarios reales. Para recopilar estos datos, hay un control de velocidad en el lado del usuario (RUM – monitoreo real del usuario).

Para organizar el RUM, basta con conectar uno de los sistemas de análisis web (Yandex.Metrica, Google Analytics) y ver informes sobre el momento de la descarga del sitio. Para obtener datos más detallados y precisos, se pueden usar servicios especializados de monitoreo de velocidad.

 

Conclusiones

El tema de velocidad del sitio web es extenso y afecta muchos aspectos del desarrollo y soporte de una aplicación web: desde el código del servidor hasta el contenido del mismo. Esto significa que obtener buenos resultados es imposible sin involucrar al equipo de desarrollo.

Lo más importante: recuerde a los usuarios y tenga en cuenta las diversas condiciones para usar el sitio.

La aceleración del sitio es un proceso que ocurre con diferente intensidad a lo largo del ciclo de vida del proyecto.

email__icon

Sé el primero en enterarte de nuevos artículos

Reset Password

Enter your e-mail to reset your password

Your email

Check Your Email

We have sent you a new link to change your password. Check your email and follow instructions envelope

Your password has been reset successfully!

close
conversation

Contáctenos

Consulte a nuestros expertos en inteligencia de mercado y descubra cómo puede beneficiarse de Sitechecker.

ERROR: The Name field is empty.

ERROR: The Last Name field is empty.

ERROR: The Work Email field is empty.

ERROR: The Message field is empty.

Thank you for registration!

We are redirecting you to PayPal

Check Your Website SEO Performance

analytics

Launch website audit to find issues and increase website SEO score

Must be a valid URL with http:// or https://
No limits! Upgrade your account to crawl this domain