Existe una auditoría técnica para verificar la velocidad del sitio e identificar las causas de los retrasos. Se recomienda realizarlo incluso si el sistema parece funcionar correctamente y no hay problemas de rendimiento. El hecho es que aún se puede mejorar: la optimización de la infraestructura acelerará la entrega de código y la refactorización de la base de código ayudará a reducir los costos de mantenimiento.
En este artículo, mostraremos cómo una auditoría técnica de un sitio se basa en el ejemplo de un recurso de noticias popular, que es visitado por decenas de miles de usuarios por hora. Consideremos las etapas independientes de verificación y análisis, como resultado de lo cual mostraremos claramente cómo puede mejorar el proyecto y eliminar los cuellos de botella que ralentizan la carga de la página.
Recopilación de métricas y análisis de recursos de sitios estáticos.
Asegúrese de recopilar métricas y medir todo lo que pueda utilizando herramientas listas para usar como Google Page Speed, Lighthouse y Web.dev. Esta es la forma más rápida de obtener métricas que servirán como punto de partida para su investigación. Con su ayuda, comprenderá a qué vale la pena prestar atención en primer lugar, qué se puede optimizar.
Le recomendamos que ejecute el análisis con el bloqueador de anuncios encendido y apagado. Como resultado, descubrirá qué tan rápido ocurre la primera representación del contenido y cuántos scripts de terceros están conectados en el sitio.
En esta etapa, también verá cuántas operaciones básicas ocurren al renderizar el sitio:
Es probable que las métricas recopiladas indiquen espacio para mejorar los activos estáticos del sitio: imágenes, videos, guiones, estilos y fuentes. Analice estos datos y asegúrese de seguir las prácticas generales para trabajar con recursos estáticos. Sin embargo, recuerde que estas son solo pautas, no requisitos estrictos.
En nuestro ejemplo, todas las imágenes se almacenan en formato jpg. Si utiliza webp, que los navegadores admiten perfectamente, el tamaño del archivo se reducirá en una media del 20%. Puede configurar la compresión webp automática solo para imágenes de alta resolución. Se recomienda convertir videos de alta resolución a webm para navegadores que admitan este formato. Para reducir la carga en la red, es recomendable desactivar la reproducción automática de videos que no son visibles. Esto se puede hacer usando la API de Intersection Observer.
Asegúrese de que su sitio tenga descargas progresivas y agregue compresión en todas partes si es posible. Asegúrese de utilizar técnicas modernas de compresión de scripts como brotli, gzip y deflate.
No cargue lo que no se usa. Esto puede aplicarse a códigos, estilos, símbolos e imágenes. Si, por ejemplo, el sitio tiene un botón que aparece en uno de mil casos, entonces el script que lo procesa debe conectarse solo a pedido.
En el ejemplo anterior, puede ver que ~ 93% del código total no se usa (~ 340 kb). Un paquete con un código se considera ideal si su cobertura es del 100% mientras cubre todos los casos sin recargar la página. Esto puede suceder si el código no se usa en absoluto o si la división del código está configurada incorrectamente, o se usa, pero en otras páginas, o cuando se alcanza un determinado escenario.
La solución a este problema es mover los componentes reutilizables a archivos separados (fragmentos), que luego se conectan solo en los lugares donde se necesitan.
Como dijimos, estos requisitos son opcionales, pero la optimización de los recursos estáticos es importante, ya que el usuario los advierte primero.
Tomemos las fuentes como ejemplo: en este proyecto, tardaron demasiado en cargarse. Dado que no queremos que el usuario vea fuentes estándar, las cargamos desde el principio, en la sección de css crítico. ¿Cómo resolver este problema? Puede optimizar las fuentes a nivel de código, cambiar el orden de conexión, reemplazar ttf con woff2.
También puedes intentar reducir el número de fuentes utilizadas, lo que supondrá un rediseño, pero esto no siempre está justificado. Si el sitio utiliza la biblioteca de fuentes de Google, elimine los caracteres no utilizados de los archivos, esto no está prohibido por los derechos de autor.
Pero a veces es más fácil dejar las cosas como están y concentrarse en otras posibilidades.
Examinando solicitudes HTTP
En esta etapa, verificamos si el frontend interactúa correctamente con el backend, a saber:
- compresión configurada para solicitudes de API;
- no hay consultas parásitas que cargan la conexión, cuyos resultados no se utilizan en ninguna parte;
- no hay solicitudes que se devuelvan con un error sin que el usuario complete un caso comercial específico;
- cuando la página se carga inicialmente, el navegador no envía solicitudes a la API (si el sitio utiliza la representación del lado del servidor, como en nuestro ejemplo);
- no hay solicitudes duplicadas. Si se realiza una solicitud al ir a cualquier página, es mejor enviarla una vez y guardar los datos para su reutilización;
- pending , . , , , . , — , .
Las solicitudes que están bloqueadas están resaltadas en rojo, pero el sitio continúa funcionando.
Además, al analizar las solicitudes, es posible que encuentre errores. Así es como nos encontramos con el funcionamiento incorrecto de la aplicación frontend, que podía enviar más de 100 solicitudes por segundo, lo que cargaba mucho el servidor. La pantalla parpadeó, el cargador giró sin cesar, etc. El motivo estaba oculto en un pergamino implementado incorrectamente. El navegador mantuvo su posición en la parte inferior de la página cuando aparecieron nuevos elementos. Es decir, al desplazarse por la página, se inició un cargador, por lo que la página se empujó hacia abajo. El controlador de Javascript reenvió la solicitud, que a su vez activó la animación del cargador nuevamente, debido a que el tamaño de la página cambió, y así sucesivamente ad infinitum.
Debido al funcionamiento incorrecto del cargador, el número de solicitudes crece infinitamente
Análisis de scripts y recursos externos
En esta etapa, debe determinar qué recursos de sitios de terceros tardan más en cargarse.
La web moderna le permite priorizar cualquier descarga. A menudo, las métricas y los anuncios se cargan antes de que se muestre la página, lo que en sí mismo no tiene sentido, ya que el usuario aún no podrá ver el anuncio, pero el sitio tardará más en cargarse. Recomendamos mostrar anuncios inmediatamente después de renderizar el sitio, lo que no afectará las estadísticas de ninguna manera; de lo contrario, el usuario verá una pantalla en blanco durante algún tiempo.
Páginas de perfiles
Utilice las herramientas de desarrollo de Chrome para crear un perfil de las páginas de su sitio para realizar un seguimiento de las solicitudes largas y un mayor uso de la CPU. Como resultado, verá claramente lo que está cargando el sitio.
La captura de pantalla muestra que se necesitan 19 milisegundos para cargar Jquery, que no es necesario en este momento. Es mejor cargar jquery después de los recursos principales, preferiblemente después de un evento de carga exitoso (por ejemplo, onload, domcontentloaded).
Análisis del número y duración de las solicitudes
En esta etapa, exploraremos cómo interactúa el frontend con el backend. Para hacer esto, debe analizar el número y la duración de todas las solicitudes. Para obtener una imagen más completa, debe medir el tiempo de respuesta promedio para una solicitud y para las paralelas.
Para mayor claridad, combine los datos obtenidos en un cuadro de resumen. De esa manera, puede identificar rápidamente qué consultas están demorando mucho más que otras.
Si el sitio está instalado en un servidor potente, el tiempo de ejecución de 100 solicitudes paralelas no debe exceder en gran medida el tiempo de ejecución de una solicitud. En el ejemplo, vemos una diferencia de 30 veces. Primero se deben investigar las consultas de más larga duración.
En este proyecto, para algunas solicitudes, se produjo el tiempo de espera de la puerta de enlace, es decir, la respuesta del servidor no llegó en absoluto.
Los gastos generales en proyectos de alta carga son normales. Sin embargo, si es posible, debe intentar dividir las solicitudes en sus partes componentes en los casos en que una solicitud sea responsable de varias acciones. Ejecute estas partes en hilos paralelos.
¿Qué se puede hacer para mejorar el servidor? Conecte la biblioteca para monitorear el servidor y reiniciar la aplicación (en el caso de node.js, esto es pm2). También se recomienda conectar una herramienta de monitoreo de errores como Sentry. Configure la salida de errores y el registro de fallos. De esta forma, puede realizar un seguimiento del tiempo de inactividad de su aplicación.
Idealmente, configure un registrador asincrónico para monitorear cualquier actividad en el sitio (solicitudes de API, solicitudes a la base de datos, API externas, al sistema de archivos o servicios para trabajar con el sistema de archivos), que los registrará en una base de datos separada.
Análisis estático del código fuente
Este análisis lo realizan utilidades que señalarán el código incorrecto y ayudarán a deshacerse del "código muerto". Vale la pena señalar que estas herramientas deben usarse automáticamente durante el desarrollo, pero no siempre tiene que confiar en la integridad de los desarrolladores, por lo que es mejor no omitir esta verificación.
Para realizar un análisis estático, debe utilizar eslint linters y otras utilidades de formato de código como más bonito y sonar que rastrean las violaciones del código.
Como resultado, según las violaciones identificadas, puede redactar un documento:
Por lo general, tales violaciones no afectan el rendimiento del sitio, pero complican la lectura y escritura del código, lo que significa que será más costoso de mantener. Por ejemplo, en este proyecto, encontramos una función en la que había tres argumentos, uno de los cuales no se usó; tales trivialidades juntas aumentan la deuda técnica del proyecto.
Análisis semántico de código fuente
En este punto, el programador deberá examinar manualmente los archivos del proyecto. Vale la pena señalar que solo se evaluarán los errores obvios en el comportamiento del código fuente; para un análisis más profundo, es necesario conocer bien la lógica del proyecto. En esta etapa, puede encontrar código repetitivo que se puede mover a un lugar (clase, función o constante) para reducir el número de líneas y reducir la posibilidad de errores.
A veces, este análisis ayudará a determinar si el equipo de desarrollo tiene problemas. A partir de las líneas de código de Git, puede determinar quién es el autor y determinar el desempeño de los empleados individuales. Puede encontrar que más de la mitad de los comentarios se refieren a un desarrollador.
Por ejemplo, aquí identificamos diez operaciones asincrónicas que actualizan la base de datos, pero se realizaron una a la vez, sin estar relacionadas entre sí. Esto significa que su rendimiento se puede duplicar ejecutándolos en paralelo. Utilice el paralelismo siempre que sea posible, porque incluso en las versiones actuales de PHP, puede ajustar el paralelismo artificial para mejorar el rendimiento del sistema.
Salir
El desarrollo de software implica muchos riesgos y, en realidad, a menudo es necesario hacer concesiones para que un proyecto esté listo y funcionando a tiempo. Por lo tanto, la documentación se suele preparar de forma retroactiva y la optimización del sitio se pospone hasta el último momento.
Pero nunca es demasiado tarde para abordar las mejoras de rendimiento. Acelerar su sitio web mejorará la experiencia del usuario y dará una respuesta positiva a la audiencia. Con la ayuda de una auditoría técnica, puede determinar qué está causando los retrasos en el trabajo del sitio: una aplicación frontend o backend. Aquí se han recopilado recomendaciones sobre cómo realizar una auditoría frontend. Son de naturaleza general y son adecuados para realizar pruebas en cualquier sitio.
Pronto le diremos cómo realizar una auditoría técnica del backend en nuestra próxima publicación.