Are We There Yet? The Tale of a Slow Website
For a company selling a time-keeping device, having a fast website is crucial to brand reputation. This is my account of the recent Seiko website latency.
If you have kids and have gone on a long car ride with them, you know the drill; every few minutes you hear, “Are we there yet?”
Something happened to me last night as I was reading a Business Insider article about a new Seiko watch for travelers, which is targeted to people who travel a lot and have to juggle with multiple timezones.
Excited to see the watch I clicked on the link, and waited, and waited, and waited…
But then I found myself asking, “Am I there yet?”
It took 44 seconds to load. I repeated this exercise a few times to makes sure it was not a fluke, and it became clear that it wasn’t.
Now if I were selling a timepiece, I would make sure that my page loads very, very fast. Watch makers are selling amazing time-keeping machines that are feature rich and there to make sure I arrive on time. What they are not selling is a time travel machine or some kind of diabolical device that can completely stop time.
In this instance, every HTTP request was served with a HTTP close connection. It’s also worth mentioning that I was traveling from Los Angeles all the way to Japan to download all the web assets. So, imagine the impact of the latency of LAX to TOK when you amplify it with the HTTP Close Connection. I had to re-open those expensive TCP connections for 100’s of requests.
- traceroute to 18.104.22.168 (22.214.171.124), 64 hops max, 52 byte packets
- 1 192.168.1.1 (192.168.1.1) 1.289 ms 1.856 ms 1.354 ms
- 2 rrcs-.com () 6.865 ms 3.182 ms 6.553 ms
- 3 126.96.36.199 (188.8.131.52) 20.922 ms 15.441 ms 19.109 ms
- 4 agg58.lsapcawv02h.socal.rr.com (184.108.40.206) 29.969 ms 19.461 ms 25.655 ms
- 5 agg20.lsaicaev02r.socal.rr.com (220.127.116.11) 20.443 ms 37.684 ms 22.189 ms
- 6 agg26.tustcaft01r.socal.rr.com (18.104.22.168) 29.547 ms 36.572 ms 23.438 ms
- 7 bu-ether16.tustca4200w-bcr00.tbone.rr.com (22.214.171.124) 40.091 ms 29.470 ms 26.030 ms
- 8 bu-ether14.lsancarc0yw-bcr00.tbone.rr.com (126.96.36.199) 30.713 ms 24.653 ms 24.795 ms
- 9 0.ae1.pr1.lax00.tbone.rr.com (188.8.131.52) 25.366 ms 29.551 ms 29.383 ms
- 10 ix-ae-24-0.tcore1.lvw-los-angeles.as6453.net (184.108.40.206) 40.033 ms 39.816 ms 50.443 ms
- 11 softbank221111203069.bbtec.net (220.127.116.11) 241.931 ms 223.479 ms 325.417 ms
- 12 *
Location, location, location is so important and even more when it comes to delivering an amazing digital user experience. It would be worth for Seiko to get a CDN in place to serve this content close to your end users.
I tested the time it took to download just the base html. The results are below:
- Tokyo: 30 ms
- Los Angeles: 762 ms
- New York: 969 ms
- London: 1,042 ms
- Paris: 1,071 ms
When you serve a 350Kb image with a 300 ms roundtrip-time, that image took in total 6.91 seconds.
So, here we are in 2016; everyone is talking about HTTP/2, but HTTP/1.1 and basic web performance practices are still a mystery to so many.
Seiko is another example of a company that thinks global but does not act local when it comes to web performance.
I was looking forward to discovering their time-keeping device, but ended up very frustrated, and I doubt I will ever go back there unless I am looking for a time stopping machine.
Mehdi – A watch aficionado, but a guy that cares about web speed first!