I have always had trouble remembering the correct order for CSS shortcuts like this:
margin: 3px 4px 2px 3px;
The order is Top, Right, Bottom, Left.
I have just found two ways to remember this.
The first is using the word trouble:
T R o u B L e
The consonants give the order.
The second (pointed out by a colleague this morning) is using a clockface starting at the top and going clockwise.
12 is at the Top
3 is on the Right side
6 is at the Bottom
9 is on the Left.
Friday, October 9, 2009
Thursday, August 13, 2009
Speeding up content delivery on the Radio NZ website
We've made a few changes to the way content is served on radionz.co.nz
1. The first is that all static content is now served from a separate domain (static.radionz.net.nz). We are using Nginx for this task because it is faster and more light-weight than Apache.
One benefit is that the browser can make more connections to the site for downloading page elements in parallel.
The second reason we used a completely different domain (instead of a sub-domain such as static.radionz.co.nz) is that it is cookie-less.
The browser does not send any cookies with requests for this static content. If it was on a sub-domain, then any cookies for the domain would be sent with each request. In the case of our home page, this added about 6k to every page request.
One of the NZ sites I tested while working on this has 65K of cookies sent for static assets on the home page. Someone has to pay for that wasted bandwidth.
2. The expiry date of static content is set one year in the future, and assets are marked as Cache-Control: Public.
This tells any application that the content passes through (including the end-user's browser) that the content can be cached, and that it won't expire for a year.
Intermediate caches (like the ones most ISPs have) are more likely to keep a copy of the assets and pass them on instead coming back to our servers. The browser will also check the content in its local cache and only fetch items that have expired.
The net effect is fewer requests for static assets. The makes for less bandwidth used by the client, and less bandwidth paid for by us.
Initial tests show that browsing between two recently visited pages (or pages that are cached locally) is about 100% faster than before the changes. Pages that are not already cached are about 15% faster due to nginx serving files more efficiently and the gzipping of our HTML content. Previously we did not gzip html content because of the relatively high server load, but nginx seems to be able to do this without any impact.
In fact, the overall server load has been reduced by about 10%.
For those who are interested, browse around the site with the Firebug Net tab open and watch how the content loads. You'll notice two things. The first is that subsequent visits to the page only get the main page and the two analytic scripts. The second is that the page fully renders quickly, even though the browser is still getting content. This was achieved by careful placement of the CSS and JS files in the HTML markup.
The site now gets a YSlow 'A' rating (excluding the CDN test, which is not relevant to us).
1. The first is that all static content is now served from a separate domain (static.radionz.net.nz). We are using Nginx for this task because it is faster and more light-weight than Apache.
One benefit is that the browser can make more connections to the site for downloading page elements in parallel.
The second reason we used a completely different domain (instead of a sub-domain such as static.radionz.co.nz) is that it is cookie-less.
The browser does not send any cookies with requests for this static content. If it was on a sub-domain, then any cookies for the domain would be sent with each request. In the case of our home page, this added about 6k to every page request.
One of the NZ sites I tested while working on this has 65K of cookies sent for static assets on the home page. Someone has to pay for that wasted bandwidth.
2. The expiry date of static content is set one year in the future, and assets are marked as Cache-Control: Public.
This tells any application that the content passes through (including the end-user's browser) that the content can be cached, and that it won't expire for a year.
Intermediate caches (like the ones most ISPs have) are more likely to keep a copy of the assets and pass them on instead coming back to our servers. The browser will also check the content in its local cache and only fetch items that have expired.
The net effect is fewer requests for static assets. The makes for less bandwidth used by the client, and less bandwidth paid for by us.
Initial tests show that browsing between two recently visited pages (or pages that are cached locally) is about 100% faster than before the changes. Pages that are not already cached are about 15% faster due to nginx serving files more efficiently and the gzipping of our HTML content. Previously we did not gzip html content because of the relatively high server load, but nginx seems to be able to do this without any impact.
In fact, the overall server load has been reduced by about 10%.
For those who are interested, browse around the site with the Firebug Net tab open and watch how the content loads. You'll notice two things. The first is that subsequent visits to the page only get the main page and the two analytic scripts. The second is that the page fully renders quickly, even though the browser is still getting content. This was achieved by careful placement of the CSS and JS files in the HTML markup.
The site now gets a YSlow 'A' rating (excluding the CDN test, which is not relevant to us).
Thursday, July 9, 2009
Browser and OS trends visitor trends at Radio NZ
Yesterday I took a look back at browser and OS usage changes over the last couple of years to evaluate any useful trends.
Here are the browser stats from the last month, and the same period 1 & 2 year's ago:
IE version 5.x is virtually extinct.
Looking at the underlying data I'd draw the following conclusions:
Around 73% of Windows users still use XP, and only 56% of Mac users are on OSX 10.5. The lower rate of Mac upgrades could limited by hardware restrictions.
For many website developers these figures will represent a significant challenge - you can no longer design your website for any one browser or OS. The days of 'best viewed in browser X' are gone.
And yes, I still see sites that only work in IE. I went to get an on-line quote for something last week, and the site simply would not work in Firefox or Safari. I took my business elsewhere. The average punter isn't going to know why - they'll just think the site doesn't work. Is this the branding message you want to send to visitors?
Based on these stats, failing to design cross-platform websites will give at least 15% of your users an inferior experience. That is a lot of lost traffic (and business).
Here are the browser stats from the last month, and the same period 1 & 2 year's ago:
| Type | 2007 | 2008 | 2009 |
|---|---|---|---|
| IE | 70% | 65% | 58% |
| Firefox | 22% | 27% | 27% |
| Safari | 4% | 5.4% | 8.6% |
| Chrome | - | - | 3.1% |
| Opera | .93% | 1% | .96% |
Looking at the underlying data I'd draw the following conclusions:
- IE use is on the decline generally, and IE users are the slowest at upgrading
- Firefox usage appears to have plateaued (and they are the fastest to upgrade)
- Most growth is in new browser entrants.
- There is greater market fragmentation (more choice for consumers)
| Type | 2007 | 2008 | 2009 |
|---|---|---|---|
| Windows | 91.8% | 90.4% | 86.6% |
| Macintosh | 7% | 8% | 10.7% |
| GNU/Linux | .98% | 1.3% | 1.83% |
| iPhone | - | .06% | 0.33% |
Around 73% of Windows users still use XP, and only 56% of Mac users are on OSX 10.5. The lower rate of Mac upgrades could limited by hardware restrictions.
For many website developers these figures will represent a significant challenge - you can no longer design your website for any one browser or OS. The days of 'best viewed in browser X' are gone.
And yes, I still see sites that only work in IE. I went to get an on-line quote for something last week, and the site simply would not work in Firefox or Safari. I took my business elsewhere. The average punter isn't going to know why - they'll just think the site doesn't work. Is this the branding message you want to send to visitors?
Based on these stats, failing to design cross-platform websites will give at least 15% of your users an inferior experience. That is a lot of lost traffic (and business).
Saturday, July 4, 2009
Rails Active Directory Authentication
Radio New Zealand has released a rails plugin to allows user to authenticating to Active Directory from a Rails Application.
We use it with the restful authentication plugin to allow a single set of credentials to be used for each person, regardless of the application.
Michael Koziarski wrote the plugin, and we (RNZ) are releasing it under the MIT license.
The source is available on GitHub.
We use it with the restful authentication plugin to allow a single set of credentials to be used for each person, regardless of the application.
Michael Koziarski wrote the plugin, and we (RNZ) are releasing it under the MIT license.
The source is available on GitHub.
Friday, July 3, 2009
Deploying Acts as Solr on Tomcat with Rails
At Radio NZ we have a number of small Rails applications that need really good search. In several cases we want field-based searching.
e.g. title:"A Blog Post"
to look only in the field 'title' for "A Blog Post".
Apache Solr is:
"an open source enterprise search server based on the Lucene Java search library, with XML/HTTP and JSON APIs, hit highlighting, faceted search, caching, replication, a web administration interface and many more features."
Acts as Solr is plugin for Rails that provides a Rails interface to Solr. The plugin includes Solr, and provides rake tasks to start, stop and reindex the Solr index.
This works fine in development, but gets tricky in production. If you have several apps, it does not really make sense to have several instances of Solr running on the same server (and you have to change the port number for each so they don't clash). There is also the question of how to ensure Solr restarts if the server reboots.
Because of this I decided to run the production instance of Solr in a Tomcat container. Each app has there own index on the development machine, and when deployed the solr.yml file tells each app to use the single Slor/Tomcat instance instead.
We use Debian Lenny on our production server. You should read these instructions first. Twice. They work for Lenny, and only a few minor tweaks are required to adapt them for Acts as Solr.
The first thing is to use the version of Solr that comes with the plugin - it has changes in the config files that make it work correctly with the plugin. I found this out the hard way.
Deploy your Rails app first and install Tomcat as outlined above. Then do this:
Then carry on with the rest of the recipe and you are done.
e.g. title:"A Blog Post"
to look only in the field 'title' for "A Blog Post".
Apache Solr is:
"an open source enterprise search server based on the Lucene Java search library, with XML/HTTP and JSON APIs, hit highlighting, faceted search, caching, replication, a web administration interface and many more features."
Acts as Solr is plugin for Rails that provides a Rails interface to Solr. The plugin includes Solr, and provides rake tasks to start, stop and reindex the Solr index.
This works fine in development, but gets tricky in production. If you have several apps, it does not really make sense to have several instances of Solr running on the same server (and you have to change the port number for each so they don't clash). There is also the question of how to ensure Solr restarts if the server reboots.
Because of this I decided to run the production instance of Solr in a Tomcat container. Each app has there own index on the development machine, and when deployed the solr.yml file tells each app to use the single Slor/Tomcat instance instead.
We use Debian Lenny on our production server. You should read these instructions first. Twice. They work for Lenny, and only a few minor tweaks are required to adapt them for Acts as Solr.
The first thing is to use the version of Solr that comes with the plugin - it has changes in the config files that make it work correctly with the plugin. I found this out the hard way.
Deploy your Rails app first and install Tomcat as outlined above. Then do this:
sudo cp path/to/your/app/vendor/plugins/acts_as_solr/solr/webapps/solr.war /usr/local/tomcat6/webapps/solr.war
sudo cp -r path/to/your/app/vendor/plugins/acts_as_solr/solr/solr /usr/local/tomcat6/solr/
Then carry on with the rest of the recipe and you are done.
Subscribe to:
Posts (Atom)
