Recientemente, he estado estudiando el libro "Guía para la construcción de sitios web de alto rendimiento". Este artículo es una nota de estudio. Me clasificaré lo que he aprendido para ver fácilmente más adelante.
Performance Golden Regla explica que solo el 10% al 20% del tiempo de respuesta del usuario final se dedica a aceptar los documentos HTML del usuario solicitados, mientras que el 80% al 90% restante del tiempo se gasta en las solicitudes HTTP para todos los componentes (imágenes, scripts, hojas de estilo, etc.) referenciado por el documento HTML, y el tiempo de respuesta final se gasta en los componentes de la página.
--Steve Sounders
1 Fusionar de archivo (reduzca el número de solicitudes HTTP)
Sprites CSS
Use Sprites CSS para fusionar las imágenes utilizadas en el sitio web en una imagen y use un icono a través de la posición de fondo, el ancho y la altura para controlar la posición de la imagen de fondo. Este método puede reducir múltiples solicitudes de imagen a una sola vez. Hay muchas herramientas para generar sprites CSS. Hay complementos relacionados en Grunt y Gulp, y CSSGAGA también es bueno.
Fusionar JS y CSS
Al igual que el mapa Sprite, fusionar archivos CSS y JS también es una forma importante de reducir las solicitudes HTTP. No existe controversia sobre la fusión de los archivos CSS en la actualidad, pero para la prevalencia actual de la modularidad JS, fusionar todos los archivos JS en un archivo parece estar al revés. La forma correcta es cumplir con el patrón de lenguaje compilado, mantener la modularidad de JS y generar archivos de destino solo para los archivos JS utilizados en la solicitud inicial durante el proceso de generación.
2 Use contenido para publicar la red (reduzca el tiempo de solicitud HTTP)
Otro factor que influye en el tiempo de solicitud HTTP es la distancia que está del servidor web del sitio web. Obviamente, cuanto más larga sea la distancia, más larga lleva la solicitud, lo que puede mejorar enormemente a través de CDN.
CDN es un servidor web distribuido en múltiples ubicaciones geográficas, utilizadas para publicar contenido a los usuarios de manera más efectiva. La función principal de CDN es almacenar archivos estáticos para usuarios finales, y también proporciona descarga, servicios de seguridad y otras funciones.
3 Establecer caché del navegador (evite las solicitudes HTTP duplicadas)
Usando expirar/caché-control
Los navegadores pueden evitar solicitudes repetidas cada vez usando caché. HTTP 1.0 y HTTP 1.1 tienen diferentes métodos de implementación de caché, vencen (1.0) y el control de caché (1.1). El servidor web usa expiras para decirle al cliente que todas las copias en caché del archivo se utilizarán dentro de un tiempo especificado y ya no realiza repetidas solicitudes al servidor, por ejemplo:
Expira: Jue, 01 de diciembre de 2016 16:00:00 GMT (formato GMT)
Esta configuración significa que al 1 de diciembre de 2016, la copia en caché está disponible sin hacer más solicitudes.
Expires tiene una limitación en la forma de pasar los plazos: requiere una sincronización estricta entre el cliente y los relojes del servidor, mientras que el control de caché introducido por HTTP 1.1 especifica una fecha de caché al especificar una hora en segundos, por lo que esta limitación no está presente, por ejemplo:
Cache-Control: Max-Age = 31536000
Esta configuración significa que el tiempo de caché es de un año, y se recomienda usar el control de caché, pero cuando se admite HTTP 1.1, otra cosa a tener en cuenta: el control de caché y el expirado existen al mismo tiempo, el control de caché tiene mayor prioridad.
Configurar o eliminar ETAG
El uso de expire/caché-control puede evitar la segunda visita, usar caché local para evitar solicitudes HTTP duplicadas y mejorar la velocidad del sitio web. Sin embargo, si el usuario hace clic en el navegador actualiza o expira, aún se emitirá una solicitud HTTP Get al servidor. Si el archivo no cambia en este momento, el servidor no devolverá el archivo completo pero devolverá un código de estado no modificado 304.
Hay dos bases para el servidor para determinar si el archivo ha cambiado: último modificado (última fecha de modificación) y ETAG (etiqueta de entidad);
ETAG (etiquetas de entidad) se introdujo en HTTP 1.1 y tiene una prioridad más alta cuando existe al mismo tiempo que el último modificado. El servidor compara el ETAG (if-None-Match) enviado por el cliente con el ETAG actual, y devuelve 304 no modificado si lo mismo es verdadero, de lo contrario se devolverá todo el archivo y 200 OK.
Hay un problema con ETAG: cuando el navegador envía una solicitud GET a un servidor y luego solicita el componente de otro servidor, Etag no coincide. Por supuesto, si su sitio web está alojado en un servidor, y ahora muchos sitios web usan múltiples servidores, la existencia de ETAG reduce en gran medida la tasa de éxito de la validez de verificación.
La solución a este problema es configurar ETAG, eliminar el valor de Innode del servidor y retener la marca de tiempo y el tamaño de modificación como el valor ETAG, o eliminar directamente ETAG, y usar el último modificado para verificar la validez del archivo.
4 componentes de comprimir (reduzca el tamaño de la solicitud HTTP)
Al comprimir archivos transmitidos por HTTP, reduciendo el tamaño de las solicitudes HTTP y mejorando la velocidad de solicitud, GZIP es el método de compresión más utilizado y más efectivo en la actualidad.
Sin embargo, no todos los archivos de recursos deben comprimirse. El costo de la compresión incluye que el servidor debe gastar ciclos de CPU para comprimir, y el cliente también necesita descomprimir los archivos comprimidos, que deben pesarse en combinación con su propio sitio web. Ahora, la mayoría de los sitios web comprimen sus documentos HTML, y algunos sitios web eligen comprimir JS y CSS. Casi ningún sitio web usa compresión GZIP para imágenes, PDF y otros archivos. La razón es que estos archivos se han comprimido, y el uso de HTTP para comprimir las cosas que han sido exageradas no pueden hacerlo más pequeño. De hecho, agregar encabezados, comprimir diccionarios y verificar el cuerpo de respuesta en realidad lo hace más grande, y también desperdiciando CPU.
Cómo habilitar GZIP en el sitio web requiere configuración en el servidor web (IIS, NGINX, Apache, etc.).
Primero se colocan 5 archivos CSS
Poner el archivo CSS en el primero y el último no afecta las solicitudes HTTP, por lo que es consistente en términos de tiempo de solicitud. Sin embargo, desde la perspectiva de la experiencia del usuario, poner el archivo CSS en el primero le dará una mejor experiencia de usuario.
La razón es que el navegador analiza el documento HTML de arriba a abajo y coloca el archivo CSS en la cabeza. La página primero hará una solicitud al archivo CSS, luego cargará el árbol DOM y lo representará. La página se presentará gradualmente al usuario.
Por el contrario, si el archivo CSS se coloca al final, la página carga el DOM completo y solicita el archivo CSS, y luego lo convierte en todo el árbol DOM y lo presenta al usuario. Desde la perspectiva del usuario, antes de que se solicite el archivo CSS, toda la página está en un estado de pantalla blanca. La pantalla blanca es un comportamiento del navegador. La explicación de David Hyatt para ello es así
Antes de que el árbol de estilo esté completamente cargado, la representación del árbol DOM es un desperdicio, ya que volverá a ser cargado después de cargar el árbol de estilo, y se produce el problema de Fouc (sin contenido de estilo).
Otra cosa a tener en cuenta es usar enlace en lugar de @import para introducir hojas de estilo CSS. Incluso si el estilo introducido por @import está escrito en el encabezado, se cargará al final del documento.
El archivo JS se coloca al final
Las solicitudes HTTP son paralelas, y el número de descargas paralelas de diferentes navegadores es diferente (2, 4 u 8). Las descargas paralelas mejoran la velocidad de las solicitudes HTTP. Poner el archivo JS en primer lugar no solo bloqueará la descarga del archivo posterior, sino que también bloqueará la representación de la página.
¿Por qué está sucediendo esto? Hay dos razones:
Document.Write puede existir en el archivo JS para modificar el contenido de la página, por lo que la página no se representará después de ejecutar el script.
Los diferentes archivos JS pueden tener dependencias independientemente del tamaño, por lo que deben ejecutarse en orden, por lo que están prohibidos al cargar scripts.
Por lo tanto, la mejor manera es colocar el archivo JS al final y esperar hasta que se carguen todos los componentes visuales de la página antes de realizar solicitudes para mejorar la experiencia del usuario.
Los anteriores son algunas sugerencias para mejorar el rendimiento del sitio web de JavaScript que el editor le presentó (1). Espero que te sea útil. Si desea saber más, preste atención a Wulin.com. En el próximo artículo, el editor le presentará las sugerencias para mejorar la optimización del rendimiento del sitio web de JavaScript (ii)