- html: Turn on output compress (such as use gzip module on Nginx: Nginx gzip) on the server-side
- images: use third-party software to compress or write a program to compress (such php, use gd library or imagemagick library) by yourself
Sometimes, you will separate them into dynamic contents and static files, and put them on the different servers respectively. After separate, one server serves static files directly and the other forwards the responses to FastCGI server or Proxy server. Here, I use PHP FastCGI + Nginx architecture to build web application.
Adjust Nginx buffering
I forward all requests ended with ".html" or ".php" to FastCGI Server. Generally speaking, the page size will be small after put the static files on the dedicated server with another subdomain (In other words, there only leaves dynamic contents).
fastcgi_buffers 8 8k;
According to the above directive, if a PHP script generated by the page size of 64k, Nginx will allocate 8*8k buffers to cache them, if more than 64k, the rest of them will be saved into a temporary file on the disk. Writing to temporary files is controlled by the fastcgi_max_temp_file_size and fastcgi_temp_file_write_size directives. Of course, it is not wise for the load on the server, because process data of the memory is faster than the hard disk. You can track page sizes of your website, and find distributed situations of the page sizes. After you know the possible sizes, you can adjust the fastcgi_buffers to save all data in memory and avoid to save on the disk with disk I/O. For example, if the page size is 77k, you can set this value to 8 16k, or 16 8k or 32 4k, but obviously, the second will be better, because if the page is only 6k, it will allocate one 8k buffer to cache; and if you use the first, it will allocates one 16k buffer to cache. While if the page is only 18k, the second will allocate three 8k (3*8 > 18) to cache, but the first will allocate two 16k (2*16 > 18) to cache. So (number * 8k) seems to be more reasonable.