Speed tricks for web development
Speed is important on the web. It is one of the most important things for a new website to be accepted and remembered by the visitors. Especially when coming from a search engine, a site loading a few seconds can result in the visitor leaving and checking out another result. Existing visitors can get frustrated by slow sites. This list will hopefully give you some ideas towards some speed improvements you can do on your (new) website.
Take a better look at your requests
A common practice for speed optimization is: Reducing requests. But take a better look and see if you can optimize them as well.
Are those requests going to different domains? Your browser has to build up a connection with each of them, this means: Resolving the host name at a DNS server, do a TCP handshake (and optionally a SSL handshake) followed by the actual request. Note that in old browsers, there was a low connection limit for each domain, so splitting them out over multiple hosts was actually beneficial because your browser will use parallel connections to retrieve content. Nowadays the limit has been increased. Always see if content is worth hosting it yourself. It will also give you more control on the caching headers and other optimizations. Using a CDN can be useful as they are usually located more nearer to the visitor and are optimized for serving content quick.
Serving static html pages is no shame
Some website which don't have a lot of often updating dynamic content (like a blog) can be easily be saved as simple html pages. You can see this as some form of caching: Everything a new post is added, the pages are generated once and saved as raw .html file, instead of generating the same page every time a request is made. The core web technology is already build and optimized for serving simple static files. It takes almost no resources at all for a web server to serve them meaning you suddenly host your site on cheaper or more power efficient saving hardware.
Optimize this trick by throwing in some extra HTTP caching headers when you know your site (or a part of it like an old article) gets rarely updated. Now your web site can be cached by proxy servers and visitor browsers as well.
Make your site useful even while loading
Make your site as useful as possible even when partially loaded. Don't insert a bar at the top of the page (pushing everything down) when loading is finished. Do you need that bar? Overlay it or reserve the space already. Images can already be given the right size using width/height or inline CSS before they are loaded. Reducing the amount of 'jumping' will make any visitor a lot happier, especially the ones on a mobile device.
Don't retrieve your main content using Ajax. A browser will have to load the page and all resources, run the scripts, and then realize it has to do another request. Of course, loading content when interacting (when scrolling for example) can be beneficial: The browser only has to do a single request and does not have to run all scripts again. A small note when making navigation possible using Ajax: Use the window.location.hash property to allow back/forward navigation in your site.
Reduce the amount of resources a browser needs
Resources are all loaded in memory by the browser, including all images. Those have to be accessed when rendering (scrolling, switching between tabs) and unloaded when navigating. A lot of resources usually mean: Your site will feel sluggish on a slow device. Don't use very large photo's if you're only going to display them small and don't load too many photo's at once.
Do you really need that jQuery script just to show or hide a text on the page? I wrote about it before, libraries aren't always useful. See if you can reduce them.
Server side page generation
Some pages can't be cached and always need to be generated on the fly. Still those pages can be optimized by looking at the code. Reduce the amount of work and round trips the code has to do. Any time your code wants to retrieve something from a database it has to create (or re-use) a connection, send the data, the database server has to parse the query, generate an execution plan, execute it (including retrieving data from usually multiple places on a hard drive), return it and then your code can continue. Of course there is some caching in the database engine and storage mechanism but when having multiple queries it still quickly adds up. Combine multiple queries into one or even better: Load the results you need in memory (for example with Memcached). It can also be worthwhile to see if you can use another database type to store your data like NoSQL.
Optimize the amount of work your code has to do by moving work to an earlier stage, for example during the initializing of your website or in a cron job. For the search feature on Miageru the sites creates a key->page dictionary in memory when initializing and refresh it when needed. That way it can quickly look up results (including the auto complete ones) without having to ask the database server. The data in the charts in the Learn Center are generated once a day by a cron job.
Think what a browser has to do step by step and reduce those steps. This will make your site feel quicker than those of your competitors, making it more likely for visitors to choose your site above theirs (if your site has the right content of course, speed is not everything).