Wednesday, February 18, 2015

Radio NZ Browser and OS stats for February 2015

This is the February 2015 release of browser and OS stats for www.radionz.co.nz and The Wireless.

Overall, the Chrome browser is increasing its market share, and the shift from desktop to mobile continues. Windows has dropped to under 50%.

Browsers

Browser 02/2015 09/2014 03/2014 11/2013 06/2012 11/2011 11/2010 11/2009 11/2008
Chrome 33.6 30.8 25.23 23.7 14.6 13.8 8.75 4.2 1.47
IE 17.2 18.9 24.02 26.3 37.5 41.2 50.6 56 63
Safari 18 18.8 18.94 17.52 17.3 5.6 13.1 10 5.66
Firefox 12.3 14.5 14.81 16.6 19.8 23.2 25.52 27.5 27.73
Android 8.3 9.0 11.71 11 7.5
Opera 0.4 0.4 0.46 0.69 0.7 0.9 1.02 1.08


IE is still in decline, and IE6 is 0.12%, IE7 1.2%, IE8 10%, IE9 16.2%, IE10 9.9%. IE11 is at 61%.

At The Wireless things are very different: Chrome 49%, Firefox 13.03%, Safari 13.8%, Safari (in app) 11.4%, IE 7.6%, Android 3.6%


Operating System

OS 02/2015 09/2014 03/2014 11/2013 06/2012 11/2011 11/2010 11/2009 11/2008
Windows 44.8 48.9 52.9 58 67.3 72 81 84.8 89.3
iOS 21.42 18.4 16.6 14 7.88
Android 20.89 17 16.5 13.7 7.79 3.6 0.3 0.02 0
Mac 9.44 11.7 10.7 13.4 14.7 15.6 14.2 12.6 8.5
iPhone 2.5 1.4 0.56 0.19
iPad 2.4 0.63 0 0
Linux 1.38 1.6 1.9 1.8 1.27 1.53 1.4 1.45 1.72
Win Phone 0.63 0.57 0.44 0.39
iPod 0.5 0.35 0.22 0.08


And at The Wireless, Windows 44.7%, iOS 20.3%, Mac 17.7%, Android 14.35%, Linux 1.37%, Win Phone 0.47%

Mobile

In June 2012 mobile was 16% of our traffic. In November 2013 it was 29%. In March 2014 it was 23.4% mobile and 10.8% for tablet, making 34.2%. In September 2014 it was 61.8%, 26.3% mobile and 11.8% for tablet. Now it is 55.5% desktop, 32.8% mobile and 11.% for tablet.

The most popular devices are - iPhone (27.6%), iPad (20%), and Samsung GT-I9300 Galaxy S III (3.03%)

Over at The Wireless 28% of the traffic is mobile and 6.8% tablet, with popular devices being iPhone (40%), iPad (15.1%) Galaxy S IV (5%).


Saturday, February 14, 2015

Why I'm Fixated with Page Load Times And You Should Be Too

I am fixated with page load times. Why?

There are three main reasons:

  1. Mobile
  2. User experience
  3. SEO 

Mobile

Mobile is the fastest growing market segment for web traffic. Radio NZ has 40% of its traffic from non-desktop browsers.


Desktop is 60%, Mobile at 28% and Tablet at 11.8%.

In the case of devices used over a mobile network, the connection speed is going to be a lot slower than broadband. We also still have people on dial-up, and slow broadband (1-2 Mb/s or less).

These are what I call 'The Slow Networks'. I suspect that up 35-40% of visitors could be using a slow network. That is 40% of visitors who could have a bad experience if no thought was put into their experience of the site.

So, we optimise for page size, deliver speed and rendering time, and this underlies all my technical decision-making. (Edit: You'll probably find Radio NZ is one of the fastest news sites on mobile, and URLs all work between mobile and desktop for ease of sharing.)

User Experience

The psychology of website speed has been long understood. And lately, here, and here. Fast sites are perceived as more credible.

They are also easier to use - visitors can quickly see the page and decide what to do. Now obviously other factors come into play here. Every page needs to treated as page one in a journey - once the visitor has finished with the current page, what can/do they do next? That is a tough question for which there is not a single answer.

SEO

One factor in Search Engine Optimisation (SEO) is page load time. The faster your site is the more pages an indexing bot can crawl in a set time period. Google consider page load time so important they include them in Analytics, and it is believed this is used in calculating your page rank.

We actually use other methods to tell Google what the latest content is, so they can index that first, but this does not remove the need to optimise all pages.

Every few months, to keep on top of performance, I compare the performance of www.radionz.co.nz with other NZ media websites. I also benchmark the site against past performance, and follow a number of thought leaders in the performance area to keep up with the latest thinking and techniques.

This is no longer bleeding edge stuff for nerds to talk about over beer. It is mainstream and every site can benefit from improving page speed.

For some it is as simple as restructuring the order of elements in the head of a HTML page. For others, a few web server configuration options could help. Yet others may be almost beyond help with 10 megabyte pages, duplicate JS library code, unoptimised images, and bloated CSS.

And then there will be those that will not care. All the studies say you are leaving money on the table, but in the end that is your choice.

There are plenty of resources available for free. Just start with a Google search, and good luck!

Wednesday, February 4, 2015

I Found A Lump - Why All Men Should Learn TSE

Normally I write here only on tech issues.

Last year I found a lump and I thought I'd share my experience in the hope that it helps other men. The story does have a happy ending, and I have a challenge for you to complete.

Late last year I started feeling sore on the right side of the scrotum, and so I checked for lumps using a technique called Testicular Self Examination, or TSE. This is not something I have done often, usually only when reminded of it after hearing or reading something about it in the press.

I found several lumps, one about twice the size of a pea. I booked to see the doctor immediately.

The visit was fairly routine. He examined both testicles, carefully as I was in much pain. His initial diagnosis was an infection of the didymus. This is the small tube that transports sperm manufactured in the testicle to inside the body.

He prescribed some fairly strong antibiotics to settle things down, and said I should book for an ultrasound when I got back from holiday.

My main concern was the time-frame. The doctor assured my that if it was cancer - and he was fairly sure at this point that it was not - that a few weeks would not have a negative impact difference in on the outcome.

When I got back from leave I dutifully went and got the ultrasound. The technician told me quite quickly that she could find no lumps at all on either testicle, but did confirm very small remains from the infection.

The doctor called me to confirm the result that day, and said if I have further issues come right back.

What did I learn from this?

Firstly, don't panic. All lumps are not cancer. If they are, you have about a 98% chance of survival if they are caught early. They key word here is early.

You are you own first line of defence.

Secondly, get over any embarrassment.

You will do TSE in private - no one will know you do it unless you blog about it. I think we are past that sort of thing now, aren't we?

Doctors look at body parts all day. They know how to handle patients who may be stressed and/or embarrassed. Get over it.

A special note on having an ultrasound exam. The process was discreet and respectful. Each step was explained before it happened and only the area to be examined is visible. There is no physical contact between you and the technician and it does not hurt.

My challenge to you is this: start TSE today, and do it regularly.

It is vital that you learn what your testicles normally feel like. I'd suggest doing it once a week for a couple of months until you get used it. If I had been doing that already, I don't think this would have been as stressful.

When you find anything of concern get it checked by a doctor as soon as practicable.

If you do take this challenge up, please mention it on social media, link back here and challenge others to do the same.

Can partners help? Yes, you can. If you are woman, perhaps get your man to start when you have your next smear, or you can make breast self exams and TSE something you do together. Guy partners? You are not exempt!

Please, encourage your man to take the challenge today, and stick to it.

Resources

How to do testicular self examination.

And another with links to resources.

The NZ Testicular Cancer Website

Wednesday, November 19, 2014

How to monitor HTTP headers in near real-time

Unix has many tools that you can stitch together to do useful things.

For example, if you want to watch your site headers in near real-time you can use watch and curl.

You might want to do that if you need to build information headers (like X-Cache-Info) and you want to quickly try out different ideas.

In my case I use it during a patch window to monitor when our site's proxy server has changed so that the (now inactive) proxy can have updates applied.

The command that you run in a terminal is:

watch "curl -I -s www.example.com"

-I is headers only, while -s is silent. It'll print the headers every two seconds by default. If you want to update every second it is:



watch -n 1 "curl -I -s www.example.com"

Thursday, October 23, 2014

How to ignore alihack requests using your nginx config

If you are getting the following error in your Rails app:

   unexpected token at 'alihack<%eval request("alihack.com")%>


...it can be blocked in your nginx config.

The following snippet can be placed inside the server block and returns a  '400 Bad Request' with a text message in the body.

A big assumption here is that your app is not using json - it blocks all JSON PUT requests. This could be refined to check for third header that your own app sets, if that is a problem.

You could change this to a redirect or a json response if you want (commented out below).

# ali.txt attempt on any URL
if ($content_type = "application/json") { 
  set $ali_txt JSON; 

if ($request_method = PUT) {
  set $ali_txt "${ali_txt}_PUT"; 

if ($ali_txt = JSON_PUT) {
 return 400 "Bad request - ignoring"; 
 # return 444;
 # return 301 http://www.example.com/some-page
}

This should not be placed inside a location block.