When it comes to programming, there are two things that I enjoy doing the most: making things faster and improving security. The two sometimes come into conflict, because security often requires validation overhead, and performance often leads to cutting corners. Balancing the two is often loads of “fun.”
That said, when it comes to security, things are relatively straightforward. Filter your input, escape your output, and don’t trust your users. On the performance side, things are not nearly as straightforward, especially when it comes to web apps.
The basic approach is fairly simple; just profile your app, determine the slow areas, optimize them, and voila, things are faster. Alas, even when this approach is followed, the results don’t necessarily eliminate the “your site is slow” feedback.
For any app, the measure of speed is ultimately all about user perception. In a traditional environment where binaries are deployed on a user’s machine, you control the app, so optimizing the interaction is part of the optimization process. If a report screen takes too long to load, your profiling efforts will identify that, and you speed up the rendering function.
For web apps, things are a little different, because the UI is controlled by a web browser — a 3rd party app that you have no control over — and it is responsible for rendering your data for your users. Even if you output your content in one hundredth of a second, by the time the content is downloaded, parsed, executed, and rendered, a few seconds may have passed, and the user experience is diminished. This is something most web app optimization attempts miss, since they focus almost exclusively on how quickly content is generated.
In fact, for web apps, it is often better to start your optimization efforts from the user side of things rather than the server.
Making things better
Making the user experience better — and by better I mean faster — is not too complicated.
Load time optimizations
Enable compression using something like
mod_gzip. It’ll speed up page loading by significantly reducing the size of text content. Send caching headers (
Check your cookies
While broadband connections can download hundreds of kilobytes per second, uploading is another matter entirely; most DSL and cable connections can only upload 20 to 30 kilobytes per second. If your page contains 10 resources, and the size of all the cookies is a mere 1 kilobyte, sending the requests alone can still take over half a second. Keep in mind there are also 400 to 500 bytes of headers per request. Therefore, it is important that you reduce your cookie sizes to just the session identifier. A slightly more complex solution is to move your static content to another domain, so your cookies are only sent to the pages that need them instead of all of the static resources as well.
Reduce request count
<head> that will register a
window.onload callback that writes the necessary
These small optimizations can make a big difference. I hope they’re helpful!