Web Application Optimization Tips_PHP Tutorial

Author: Fenng|You can reprint. When reprinting, be sure to indicate the original source of the article, author information and copyright statement in the form of a hyperlink
Website: http://www.dbanotes.net/web/flickr_web_tech.html
Cal Henderson is one of the developers of the famous Flickr website. In an article called Serving JavaScript Fast, he introduced techniques for optimizing Flickr site applications. I felt that I benefited a lot from reading it. "Chew other people's buns", summarize the main content of the article.

Flickr is a representative site of Web 2.0. In addition to the content optimization common to general Web sites, the network problems faced must also flexibly handle the complexity of deployment and distribution caused by frequent changes in JavaScript and CSS.

The first question faced when setting the file size strategy is whether to put all JavaScript and CSS into one file, or split it into multiple files? From the perspective of reducing network requests, the former is better, and the latter The difference is. However, from a parallel perspective, both IE and Firefox can only request two resources from one domain at the same time by default. This will bring a bad experience to users in many cases - all files must be downloaded. See a decent page. Flickr takes a compromise by splitting JavaScript and CSS into multiple sub-files while keeping the number of files as small as possible. This brings complexity in development, but the performance gains are Huge.

Compression optimization issue There is no doubt that compressing site content is a relatively common web optimization method. However, it is not always possible to achieve the desired effect. The reason is that the mod-gzip module not only consumes server-side CPU resources, but also consumes client-side CPU resources. Moreover, the temporary files created after mod_gzip compresses the files are placed on the disk, which will also cause serious problems for disk IO. Flickr The mod_deflate module supported by Httpd 2.x and later is used. Compression operations are all performed in memory. mod_deflate is not available in Httpd 1.x, but you can indirectly improve performance by creating a RAM disk.

Of course, mod_gzip is not useless. It is still beneficial for pre-compressed files. Moreover, when using compression, you should also pay attention to the strategy. There is no need to compress image files (there are many images on Flickr, and they are very compressed). Not much benefit). Flickr only compresses JavaScript and CSS. Newer versions of mod_gzip can automatically handle precompressed files by configuring the mod_gzip_update_static option. Cal also pointed out that this feature may cause problems in some older browsers.

Another main means of compression is content compression. For JavaScript, you can do small tricks such as reducing comments, merging spaces, and using compact syntax (all Google scripts are very difficult to read and very compact, with similar ideas). Of course, the JavaScript processed in this way may have a lot of parentheses that are difficult to parse. Flickr uses Dojo Compressor to build the parse tree. Dojo Compressor has very low overhead and is transparent to end users. The JavaScript processing method has been introduced, and the CSS processing is relatively simple. Through simple regular expression replacement (such as replacing multiple spaces with one space character), you can get up to 50% compression ratio.

Caching optimization Flickr developers have made full use of the Etag and Last-Modified mechanisms defined by the HTTP 1.1 specification to improve the efficiency of Caching. It is worth noting that Cal introduced an e-Tag tip under load balancing conditions. . That is, you can set Apache to obtain the E-Tag through the file adjustment time and file size. By default, Apache obtains the e-Tag through the file node. Of course, this is not perfect, as it affects if-modified-since .

Flexible use of mod_rewrite It is said that the Flickr website application is built daily (Daily Build). I'm afraid this would be unimaginable without a flexible mechanism. Moreover, on sites like Flickr, synchronizing content modifications is a headache. Their weapon is the flexible use of mod_rewrite. By configuring URL rewriting rules, it is easy to switch to different environments. It sounds simple, but how easy is it to do without certain web technology skills?!

Through the application of these main methods, we have seen a dreamlike and high-performance Flickr.

BTW: Because Flickr does not have a server in China, the access speed for mainland users cannot be mentioned :(

--End.

This article [Web application optimization tips for Flickr developers] comes from dbanotes.net

http://www.bkjia.com/PHPjc/486629.htmlwww.bkjia.comtruehttp: //www.bkjia.com/PHPjc/486629.htmlTechArticleAuthor: Fenng|You can reprint. When reprinting, be sure to indicate the original source of the article, author information and copyright statement in the form of a hyperlink. Website: http://www.dbanotes.net/web/flickr_web_tech.html Cal Hende...