Hoy navegué brevemente por "Sitios web de alto rendimiento". La versión china de este libro es "Guía para la construcción de sitios web de alto rendimiento".
Este libro también tiene un capítulo avanzado "Sitios web aún más rápidos" que explora en profundidad problemas individuales, y la traducción al chino es "Guía avanzada para crear sitios web de alto rendimiento".
El autor lo presentó en el enlace de Douban anterior, por lo que no lo copiaré aquí.
Este libro ofrece 14 principios para mejorar el rendimiento de un sitio web; cada principio es un capítulo independiente con ejemplos. La mayoría de estos principios son muy prácticos y adecuados para arquitectos de sitio e ingenieros de front-end. Es de mayor importancia para los ingenieros de front-end.
Esta vez vi la versión original. Carezco de experiencia práctica en desarrollo web y lo leo con prisa, por lo que puede haber omisiones y expresiones inapropiadas. Espero que los internautas se sientan libres de corregirme.
Principio 1 Reducir la cantidad de solicitudes HTTP
Se necesita tiempo para elaborar una solicitud y esperar una respuesta, por lo que cuantas menos solicitudes, mejor. La idea general de reducir las solicitudes es fusionar recursos y reducir la cantidad de archivos necesarios para mostrar una página.
1. Mapa de imágenes
Al configurar el atributo usemap de la etiqueta <img> y usar la etiqueta <map>, puede dividir una imagen en múltiples áreas y apuntar a diferentes enlaces. En comparación con el uso de varias imágenes para construir enlaces por separado, la cantidad de solicitudes se reduce.
2. CSS SPRite (integración de texturas CSS/costura de texturas/posicionamiento de texturas)
Esto se hace estableciendo el estilo de posición de fondo del elemento. Generalmente se utiliza para iconos de interfaz. Los típicos pueden referirse a los pequeños botones encima del editor TinyMCE. Básicamente, varias imágenes pequeñas se cortan de una imagen grande unificada con diferentes desplazamientos. De esta manera, muchos botones en la interfaz de carga en realidad solo necesitan solicitarse una vez (solicitando la imagen grande una vez), lo que reduce la cantidad de solicitudes HTTP.
3. Imagen en línea
No especifique la URL del archivo de imagen externo en el src de <img>, coloque directamente la información de la imagen. Por ejemplo, src="data:image/gif;base64,R0lGODlhDAAMAL..." es útil en algunos casos especiales (por ejemplo, una imagen pequeña solo se usa en la página actual).
Principio 2: utilizar CDN multilínea
Proporcione a su sitio acceso a múltiples líneas (como telecomunicaciones nacionales, China Unicom, China Mobile) y múltiples ubicaciones geográficas (norte, sur, oeste) para que todos los usuarios puedan acceder a él rápidamente.
Principio 3: utilizar la caché HTTP
Agregue información de encabezado de Expires más larga a los recursos que no se actualizan con frecuencia (como imágenes estáticas). Una vez que estos recursos se almacenen en caché, no se volverán a transmitir durante mucho tiempo en el futuro.
Principio 4: utilice la compresión Gzip
Utilice Gzip para comprimir mensajes HTTP y reducir el tamaño y el tiempo de transmisión.
Principio 5: Coloque las hojas de estilo al principio de la página
Cargue primero la hoja de estilo para que la representación de la página pueda comenzar antes, dando a los usuarios la sensación de que la página se carga más rápido.
Principio 6: coloque los guiones al final de la página
El motivo es el mismo que el 5. La visualización de la página se procesa primero, la representación de la página se completa antes y la lógica del script se ejecuta más tarde, lo que le da al usuario la sensación de que la página se carga más rápido.
Principio 7 Evite el uso de expresiones CSS
La lógica de script JavaScript demasiado compleja, la búsqueda DOM y las operaciones de selección reducirán la eficiencia del procesamiento de la página.
Principio 8 Utilice Javascript y CSS como recursos externos
Esto parece ser contrario a la idea de fusión del principio 1, pero no lo es: considerando que cada página introduce un recurso público de JavaScript (como jQuery o una biblioteca de JavaScript como ExtJS), a juzgar por el rendimiento de una sola página, en línea (es decir, incrustar JavaScript en HTML) las páginas se cargarán más rápido (debido a su menor número de solicitudes HTTP) que las páginas salientes (introducidas mediante etiquetas <script>). Pero si muchas páginas introducen este recurso público de JavaScript, entonces el esquema en línea provocará una transmisión repetida (debido a que este recurso está incrustado en cada página, esta parte del recurso debe transmitirse cada vez que se abre una página, lo que provoca un desperdicio de transmisión de red). recursos). Este problema se puede resolver haciendo que este recurso sea independiente y haciendo referencia a él externamente.
Dado que JavaScript y CSS son relativamente estables, podemos establecer fechas de vencimiento más largas para sus recursos correspondientes (consulte el Principio 3).
Principio 9 Reducir las búsquedas de DNS
El consejo del autor es:
1. Utilice Keep-Alive para mantenerse conectado
Si la conexión se desconecta, se deberá realizar una búsqueda de DNS la próxima vez que se establezca la conexión. Incluso si la asignación de nombre de dominio-IP correspondiente se ha almacenado en caché, la búsqueda llevará algún tiempo.
2. Reducir los nombres de dominio
Cada vez que solicita un nuevo nombre de dominio, necesita buscar un nombre de dominio diferente a través de DNS y la caché de DNS no puede funcionar. Por lo tanto, debe hacer todo lo posible para organizar el sitio bajo un nombre de dominio unificado y evitar el uso de demasiados nombres de subdominio.
Principio 10 Minimiza tu JavaScript
Utilice la herramienta de compresión JS para comprimir su JavaScript, es muy efectiva. Basta mirar las dos distribuciones diferentes de jQuery para ver la diferencia:
http://code.jquery.com/jquery-1.6.2.js versión de lectura del código jQuery, 230 KB
http://code.jquery.com/jquery-1.6.2.min.js versión comprimida del código jQuery (para implementación real), 89,4 KB
Principio 11 Intenta evitar redirecciones
Una redirección significa que se agrega una ronda adicional de solicitudes HTTP antes de que usted acceda realmente a la página que desea ver (el cliente inicia una solicitud HTTP → el servidor HTTP devuelve una respuesta de redirección → el cliente inicia una solicitud de una nueva URL → el servidor HTTP El servidor devuelve contenido, las partes subrayadas son solicitudes adicionales), por lo que consume más tiempo (lo que también da a las personas la sensación de una respuesta más lenta). Así que no utilices redireccionamientos a menos que sea necesario. Varias situaciones "necesarias":
1. Evite las URL no válidas
Después de migrar el sitio anterior, para evitar que la URL anterior deje de ser válida, las solicitudes de la URL anterior generalmente se redirigen a la dirección correspondiente del nuevo sistema.
2. Embellecimiento de URL
Convierta entre URL legibles y URL de recursos reales. Por ejemplo, para la barra Google, los usuarios recuerdan http://toolbar.google.com, que es una dirección semántica para humanos, pero es difícil recordar http://www.google. .com/tools/Firefox/toolbar/FT3/intl/en/index.html es la dirección real del recurso. Por tanto, es necesario conservar los primeros y redirigir las solicitudes de los primeros a los segundos.
Principio 12 Eliminar scripts duplicados
No incluyas el mismo guión repetidamente en una página. Por ejemplo, las secuencias de comandos B y C dependen de A, por lo que puede haber referencias repetidas a A en páginas que usan B y C. La solución es verificar manualmente las dependencias de los sitios simples y eliminar las introducciones repetidas de los sitios complejos; necesita crear su propio mecanismo de gestión de dependencias/control de versiones.
Principio 13 Maneje las ETags con cuidado
ETag es otro método de caché HTTP además de Última modificación. Identifique si el recurso ha sido modificado mediante hash. Pero existen algunos problemas con ETag, como por ejemplo:
1. Inconsistencia: diferentes servidores web (Apache, IIS, etc.) definen diferentes formatos de ETag
2. El cálculo de ETag es inestable (debido a que se consideran demasiados factores), como por ejemplo:
1) Los mismos recursos tienen diferentes ETag calculadas en diferentes servidores, y las aplicaciones web a gran escala generalmente son atendidas por más de un servidor. Esto hace que los recursos almacenados en caché del cliente en el servidor A sigan siendo válidos, pero la próxima vez que solicite B Porque. la ETag es diferente, se considera inválida, lo que resulta en la transmisión repetida del mismo recurso.
2) El recurso permanece sin cambios, pero la ETag cambia debido a cambios en algunos otros factores, como cambios en el archivo de configuración. La consecuencia directa es que después de la actualización del sistema, se producen fallas en la caché del cliente a gran escala, lo que resulta en un gran aumento en el volumen de transmisión y una disminución en el rendimiento del sitio.
La sugerencia del autor es: mejorar el método de cálculo de ETag existente de acuerdo con las características de su aplicación, o simplemente no usar ETag y usar la Última Modificación más simple.
Principio 14 Aproveche la caché HTTP con Ajax
Ajax es una solicitud asincrónica. Las solicitudes asincrónicas no bloquearán sus operaciones actuales y, cuando se complete la solicitud, podrá ver los resultados de inmediato. Pero asincrónico no significa que se pueda completar instantáneamente, ni que se pueda tolerar y que tarde una cantidad infinita de tiempo en completarse. Por lo tanto, también se debe prestar atención al rendimiento de las solicitudes de Ajax. Hay muchas solicitudes Ajax que acceden a recursos relativamente estables, así que no olvide hacer un buen uso del mecanismo de caché HTTP para solicitudes Ajax. Para obtener más detalles, consulte los Principios 3 y 13.
Autor: Yang Mengdong
Fuente del artículo: blog de Yang Mengdong. Indique el enlace de la fuente al reimprimir.