I played with static pages using Jekyll, which has some interesting benefits but a fair amount of initial setup complexity and annoying deployment process, the benefits are:
- No database to setup or configure
- All posts and files are in version control
- Editing posts in Vim, I love vim!
and last but certainly not least
- Speed! Super Zippy Website Performance!
I would not recommend running a Jekyll site for everyone, especially if you don't like the command-line and coding, WordPress is far easier setup and more powerful - plus using WordPress.com hosted blogs, it couldn't be simpler.
But for performance junkies, static pages are enticing - no server-side, no database calls, no loading of numerous includes or plug-ins, authentication or permissions. Just plain old HTML - and it is wicked fast!
my tests had a Google PageSpeed score of 96 out of 100. Average page load is <400ms, less than half a second!
I worked at ETRADE in the early days, for a time I was in charge of Site Performance, we were in an epic battle with Ameritrade to claim the title of fastest on-line broker. Each of us would make crazier claims on ability to trade quicker, I think it got down to two-second guarantees! A big chunk of that time has to do with trades actually going through the clearing house, which has nothing to do with the web site. However it was my job to make sure the web site added the least possible time to the transaction.
Here are some tips I've picked up along the way to squeeze the most performance out of your website.
Front-end Performance
The biggest increases in site performance are typically on the front-end, page weight and objects. You get the most bang for your buck by reducing the number of includes, the overall number of images and javascript, the less you have to send to the browser the better.
Use Text and Fonts for design elements instead of images - Avoid throwing images around just for flair, such as icons, bullets, or headers. Use text and html elements when possible, it may require to change the design slightly, but users will prefer a faster site than a stylish bullet. On my site I use the » as my bullet, small simple and a little style.
Don't use custom fonts - All the rage lately seems to be using custom fonts, don't do it. It requires at least one additional file to load, typically a 100kb font file; plus Typekit and Google Fonts both require loading additional Javascript. Try to use fonts already installed on a user's computer, a majority of computers have Microsoft Office installed, check out these lits of available fonts:
Use Sprite Maps if you must have images - A sprite map is a collection of small images, such as icons or tool bars, so if you must use images as decorators on your site, gather them up in a sprite map. This allows the browser to only make one request and retrieve numerous images. Typically the largest time suck is the number of requests a browser has to make to go back to the server and not the file size, this is especially true for mobile.
- CSS Sprite Maps
- Even better than Sprite Maps, use the Data URI Scheme trick
Use font file instead of Sprite Map - Here's a really interesting trick I came across recently, it was to embed your icons, widgets and styles as vector images in a font file. This font file becomes your sprite map, and allows you to easily scale and size icons on the page, since you have all your CSS and text formatting.
Don't use too much Javascript - This one is relatively obvious, reduce the number of javascript files you require on your site. Ideally you have none, but that's not realistic these days. Find one library and stick to using it, don't mix libraries such as using both JQuery and YUI, this just increases the overall number of files to download.
If you use JQuery, or other common libraries, load them from Google. The more people who use Google as the host, the more likely it will already be in the user's cache. I'd love to see the browsers have a local embed built-in and load JQuery from there. Google Library Hosting
Use CSS, early and often - There is so much CSS can do these days, learn it. Using CSS can give you very inexpensive ways to develop style without affecting performance.
Minify Everything - Minify just means to reduce the size of what you are sending, by removing comments, spaces and other unused items in a file. You should minify your Javascript, CSS and HTML. This is another benefit to using Jekyll, I can add hooks in when generating the site to automatically minify files.
A little overboard - If you want to go crazy, reduce the name of directories, files, etc. For my assets, I simply use the directory letter "a" instead of the longer "images". This saves 5-bytes in every load, not a huge difference but its simple enough to do, so why not.
Apache Configuration
Configure your web server, most likely Apache, to cache your static objects for long periods. By increasing the cache length, you tell your users browsers to keep a copy of images, javascript and css around longer. So on repeat visits, or just when browsing the site they won't have to download the files again.
Here's the Apache config I use to cache my HTML, Images, Javascript and CSS
ExpiresActive On
ExpiresDefault "access plus 1 days"
ExpiresByType text/css "access plus 7 days"
ExpiresByType text/javascript "access plus 7 days"
ExpiresByType application/javascript "access plus 7 days"
ExpiresByType image/gif "access plus 3 months"
ExpiresByType image/png "access plus 3 months"
ExpiresByType image/jpg "access plus 3 months"
ExpiresByType image/jpeg "access plus 3 months"
Cache Bustings - If you make changes to your Javascript and CSS, the long cache may prevent your visitors from seeing the changes; to solve this you need to bust the cache. This means to force the browser to reload the file. You can do this a couple ways, one way is to create a new file every time you make a change, for example style-001.css, style-002.css, etc...
An easier way is to keep the file name the same and lie to the browser that it changed, you can do so using Apache rewrites. Keep the filename the same, but when loading the file in your HTML include the verison number, style-001.css. You then setup a rewrite rule in Apache to ignore that number and load the file, the browser thinks the file is new and loads it, but you don't have to create new files on every change.
Each time you do a deployment, change the number. At work we have an automated process that inserts our subversion number into this spot, so each release we get a fresh cache.
Apache Rewrite Rule for Cache Busting RewriteRule /a/style-\d+.css /a/style.css
Default Character Set - Google's Page Speed and Microsoft both say weird things about specifying the charcter set. Due to browser wonkiness, its best not to set within a meta tag, but to do so from the web server. Read more at Google Here is the Apache config for setting the default characyer set to UTF-8 AddDefaultCharset UTF-8
Compression - Setup Apache to compress files before sending to the clients. This reduces the size of the files before sending to the browser, the browser than unzips the files and displays them. This works best for text files such as HTML, Javascript and CSS.
WordPress Optimization
One WordPress tip, you can get some great performance out of WordPress by using batcache. or WP Super Cache
For BabyCenter's Blog, we saw an 40x increase in ability to handle load when using batcache. This allowed us to scale our WordPress blog to handle Yahoo referral traffic without adding any additional servers, though we already had a couple servers to start. Batcache Plugin
Google Page Speed or YSlow
Use Google Page Speed or YSlow to test your site, they offer up a good set of ideas and suggestions on how to improve. Google's Page Speed is available as an online test at: https://developers.google.com/pagespeed/
Additional Resources
- Web Page Analyzer - Testing Tool
- Google Page Speed Best Practices - Documentation
- Website Optimization: Speed, Search Engine & Conversion Rates - Book [Amazon]
- Even Faster Web Sites - Book [Amazon]
I’ve been readying a lot about icon fonts lately. They seem to be a hot topic lately. Interesting that you were talking about them in 2011! What else is new…