Consejos de optimización de aplicaciones web

Autor: Fenng | Puede reimprimir. Al reimprimir, asegúrese de indicar la fuente original y la información del autor del artículo y la declaración de derechos de autor en forma de hipervínculo: http://www.dbanotes.net/web/flickr_web_tech. .html
Cal Henderson es uno de los desarrolladores del famoso sitio web Flickr. En un artículo llamado Serving JavaScript Fast, presentó técnicas para optimizar las aplicaciones del sitio Flickr. Sentí que me beneficié mucho al leerlo. "Masticar bollos ajenos", resume el contenido principal del artículo.

Flickr es un sitio representativo de la Web 2.0. Además de la optimización del contenido común a los sitios web generales, los problemas de red que se enfrentan también deben manejar de manera flexible la complejidad de la implementación y distribución causada por los frecuentes cambios en JavaScript y CSS.

La primera pregunta que surge al configurar la estrategia de tamaño de archivo es si colocar todo JavaScript y CSS en un solo archivo o dividirlo en varios archivos. Desde la perspectiva de reducir las solicitudes de red, el primero es mejor y el segundo es peor. Sin embargo, desde una perspectiva paralela, tanto IE como Firefox solo pueden solicitar dos recursos de un dominio al mismo tiempo de forma predeterminada. Esto traerá una mala experiencia a los usuarios en muchos casos: todos los archivos deben descargarse en una página decente. utiliza un compromiso: dividir JavaScript y CSS en múltiples subarchivos manteniendo la cantidad de archivos lo más pequeña posible. Esto genera complejidad en el desarrollo, pero los beneficios de rendimiento son enormes.

Problema de optimización de la compresión No hay duda de que comprimir el contenido de un sitio es un método de optimización web relativamente común. Sin embargo, no siempre es posible lograr el efecto deseado. La razón es que el módulo mod-gzip no solo consume recursos de la CPU del lado del servidor, sino que también consume recursos de la CPU del lado del cliente. Además, los archivos temporales creados después de que mod_gzip comprime los archivos se colocan en el disco, lo que también causará problemas graves. para disco IO Flickr Se utiliza el módulo mod_deflate compatible con Httpd 2.x y versiones posteriores. Todas las operaciones de compresión se realizan en la memoria. mod_deflate no está disponible en Httpd 1.x, pero puedes mejorar indirectamente el rendimiento creando un disco RAM.

Por supuesto, mod_gzip no es inútil. Sigue siendo beneficioso para archivos precomprimidos. Además, cuando se utiliza la compresión, también se debe prestar atención a la estrategia. No es necesario comprimir archivos de imágenes (hay muchas imágenes en Flickr).

nuevas

de mod_gzip pueden manejar automáticamente archivos precomprimidos configurando la opción mod_gzip_update_static.

compresión Un medio principal es la compresión de contenido. Para JavaScript, puede hacerlo reduciendo comentarios, fusionando espacios, usando sintaxis compacta y otros trucos (todos los scripts de Google son muy difíciles de leer y muy compactos, por supuesto, después). procesar de esta manera JavaScript puede tener muchos paréntesis que son difíciles de analizar. Flickr utiliza Dojo Compressor para crear un árbol de análisis. Dojo Compressor tiene una sobrecarga muy baja y es transparente para los usuarios finales. Se ha introducido el método de procesamiento de JavaScript y el procesamiento de CSS es relativamente simple mediante el reemplazo simple de expresiones regulares (como reemplazar varios espacios con un carácter de espacio). al 50% de relación de compresión.

Optimización del almacenamiento en caché Los desarrolladores de Flickr han aprovechado al máximo los mecanismos Etag y Last-Modified definidos por la especificación HTTP 1.1 para mejorar la eficiencia del almacenamiento en caché. Vale la pena señalar que Cal introdujo un truco de e-Tag en condiciones de equilibrio de carga. Puede configurar Apache para que obtenga E-Tag mediante el ajuste del tiempo y el tamaño del archivo. De forma predeterminada, Apache obtiene e-Tag a través del nodo de archivo. Por supuesto, esto no es perfecto, porque afectará si se modifica desde entonces.

Uso flexible de mod_rewrite Se dice que la aplicación del sitio web de Flickr se crea diariamente (Daily Build). Esto sería impensable sin un mecanismo flexible. Además, en sitios como Flickr, sincronizar modificaciones de contenido es un dolor de cabeza. Su arma es el uso flexible de mod_rewrite. Al configurar reglas de reescritura de URL, es fácil cambiar a diferentes entornos. Suena muy simple, pero ¿qué tan fácil es hacerlo sin ciertas habilidades en tecnología web?

A través de la aplicación de estos métodos principales, hemos visto un Flickr de ensueño y de alto rendimiento.

Por cierto: debido a que Flickr no tiene un servidor en China, no se puede mencionar la velocidad de acceso para los usuarios del continente :(

--Fin.

Este artículo [Consejos de optimización de aplicaciones web para desarrolladores de Flickr] proviene de dbanotes.net