Author: Fenng | You can reprint. When reprinting, be sure to indicate the original source and author information of the article and the copyright statement in the form of a hyperlink. URL: 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 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 is worse. 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 uses a compromise - split 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 benefits 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 must also pay attention to the strategy. There is no need to compress image files (there are many images on Flickr, and compression can’t achieve much Benefits). 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 will cause problems on some older versions of browsers.
The other compression One main means is content compression. For JavaScript, you can do this by reducing comments, merging spaces, using compact syntax and other tricks (all Google scripts are very difficult to read and very compact, with similar ideas). Of course, after processing in this way JavaScript may have a lot of parentheses that are difficult to parse. Flickr uses Dojo Compressor to build a 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.
Optimization of Caching 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 trick under load balancing conditions. That is, you can Set Apache to obtain E-Tag through file adjustment time and file size. By default, Apache obtains e-Tag through file node. Of course, this is not perfect, because it will affect if-modified-since.
Flexible use of mod_rewrite It is said that the Flickr website application is built daily (Daily Build). This would be unthinkable 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 very simple, but how easy is it to do it 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