Continuing the earlier theme of Optimizing Images to Save Bandwidth and Speed Page Load, you can also encode small (background) images directly in your stylesheets. For each image / page element encoded within a stylesheet, it means one less HTTP connection for content, which in turn means pages finish loading faster. These images should generally be small and downloadable quickly — what you want to save is the HTTP connection overhead, not the download time (both images and stylesheets are generally cached after downloading). The images should also be encoded within sourced stylesheet files, so the stylesheet files can be cached by the browser. If you encode images within your content (using <style></style> tags for example), the encoded image will have to be downloaded for every page view, so although you’re saving HTTP connections, your page size has increased. By encoding images in sourced stylesheet files instead, the browser (and content delivery services) can cache the whole stylesheet, including the encoded image(s).
Surnia Ulula
Encode Small Images in Stylesheets
Optimize Images to Save Bandwidth and Speed Page Load
A few weeks ago I mentioned the wesley.pl script from GitHub to optimize images, and how I had modified it to keep (or discard) the EXIF / XMP information. Making sure images are as small as possible is important to save bandwidth and improve page load times (and google rank), so I think it’s worth discussing my image optimization process in more detail.
Save Memory with Alternative PHP Cache (APC)
I’ve been looking for ways to improve the performance of my websites — several of them using PHP (WordPress), a few using mod_perl, and all running under the same Apache Httpd web server. The first thing I did was to sync all the static content to a Virtual Machine (VM) off-site, and redirect all requests for that content to the VM. Using redirects has several advantages, that (to me) outweigh the small disadvantage that all requests for static content still come to my web server, which then responds with a permanent redirect. The upside (to using a perl based rewrite map, for example) is that any change to the static content is immediately apparent to new visitors — excluding the usual browser cache issues. ;-)
I also wrote a script to check the Apache Httpd MPM config limits (prefork, worker, and event) and issue a warning or error message if those limits were set too high for the server’s memory. Writing this script made me realize just how much more memory each process was using since adding those PHP websites. Switching from the prefork MPM to the worker or event MPMs (where each process manages multiple threads / connections instead of just one) could have been one possible solution, but using PHP in a threaded environment is highly discouraged by the PHP team.



