New BBC technique for external links
Blogstorm has a post about a new BBC technique for linking to external sites.
For example, the external links on this story.
What do folks think of it in terms of accessibility?
--
Andy Mabbett
@pigsonthewing
Birmingham, England
For example, the external links on this story.
What do folks think of it in terms of accessibility?
--
Andy Mabbett
@pigsonthewing
Birmingham, England
I thought it had been like that for a long time. Using indirect links when users want to go directly to something is rather dense. I can't think of a benefit to the technique they are using.
Its all about metrics and tracking I'd imaginge. The blog post seems to think this is possible without redirects, but I'd like to know how. To prioritize this over a small degree of usibility is not nesessarily 'dense' as you put it Ben. For one better metrix, can lead to better design and better content. And thereby improve usability in other areas, in other ways. But if there are access issues, I think is worth raising.
However they've been doing this with internal links for ages.
This frustrated me when I was playng with proxy systems that couldn't follow redirects. Their may well be other UAs out there which suffer similaly in some way.
I see absolutely no theoretical value to redirecting in internal links. Although I've frequently come across logistic reasons. And these are more likely to occur in a huge site, with many sub-sites and sub-departments, editing content and devloping systems.
However they've been doing this with internal links for ages.
This frustrated me when I was playng with proxy systems that couldn't follow redirects. Their may well be other UAs out there which suffer similaly in some way.
I see absolutely no theoretical value to redirecting in internal links. Although I've frequently come across logistic reasons. And these are more likely to occur in a huge site, with many sub-sites and sub-departments, editing content and devloping systems.
I suspect the BBC are more interested in where their visitors are visiting.
Interesting that they are using a "302 Found" header, which technically shouldn't redirect automatically. Normally, I wouldn't say that an HTTP redirection like this would cause any accessibility concerns, but a 302 isn't necessarily meant to automatically refer people on to the redirected URL. I think it's when an intermediary page is used and the Refresh meta redirection is employed that it causes an accessibility/usability issue.
Jon Gibbins, dotjay.co.uk, accessibility.co.uk wiki.
Interesting that they are using a "302 Found" header, which technically shouldn't redirect automatically. Normally, I wouldn't say that an HTTP redirection like this would cause any accessibility concerns, but a 302 isn't necessarily meant to automatically refer people on to the redirected URL. I think it's when an intermediary page is used and the Refresh meta redirection is employed that it causes an accessibility/usability issue.
Jon Gibbins, dotjay.co.uk, accessibility.co.uk wiki.
| Phil Teare wrote: |
| Its all about metrics and tracking I'd imaginge. The blog post seems to think this is possible without redirects, but I'd like to know how. |
Unnecessary redirection causes additional HTTP round trips, slowing down navigation. It's a net loss for usability and unnecessary in the first place.
How do you reliably log where someone leaves your site to go to?
There are many good reasons to do this and the additional latency is tiny (much less than 1% of the total latency of response).
(btw sorry for legibility of my posts while my machine is AT free - moved laptop again)
There are many good reasons to do this and the additional latency is tiny (much less than 1% of the total latency of response).
(btw sorry for legibility of my posts while my machine is AT free - moved laptop again)
| Phil Teare wrote: |
| How do you reliably log where someone leaves your site to go to? |
Normally a page view has 1 round trip, with external resources loading in parallel. A redirect takes this from 1 round trip to 2 round trips. It's a doubling effect.
It's been pointed out in a comment on Martin Belam's blog that:
The redirect links also mean browsers can't detect whether a link is 'visited' or not.
--
Andy Mabbett
@pigsonthewing
Birmingham, England
The redirect links also mean browsers can't detect whether a link is 'visited' or not.
--
Andy Mabbett
@pigsonthewing
Birmingham, England
Also, I noticed that Google seem to be doing this for some links from search their results now. Has anyone else seen that?
Jon Gibbins, dotjay.co.uk, accessibility.co.uk wiki.
Jon Gibbins, dotjay.co.uk, accessibility.co.uk wiki.
Re G - yes, they do it for the bigger sites in their normal results, and for most news links.
If your UA can't cope well with redirects tis bad. The visited issue is sort of bad, but I think in practice a small inconvenience its its ever one at all...
Doable, but ugly.
Well this is it. I think there is benefit. In that with better stats re user behaviour it is easier (especially with tons of traffic) to actually know what users like and use. Rather than blindly asuming something is 'good' or 'bad'...
Its an incredibly important part of UI evolution at the big sites (BBC YouTube etc...)
Its a doubling effect on what is fast becoming a negligable part of a request response transaction. The amount of data passed in the redirect phase is likely to be far less than a kb. The rest of the transaction is likely to be well over 100kb...
If your UA can't cope well with redirects tis bad. The visited issue is sort of bad, but I think in practice a small inconvenience its its ever one at all...
| Quote: |
| Javascript, I guess. |
Doable, but ugly.
| Quote: |
| What's the use in knowing that information? |
Well this is it. I think there is benefit. In that with better stats re user behaviour it is easier (especially with tons of traffic) to actually know what users like and use. Rather than blindly asuming something is 'good' or 'bad'...
Its an incredibly important part of UI evolution at the big sites (BBC YouTube etc...)
| Quote: |
| Normally a page view has 1 round trip, with external resources loading in parallel. A redirect takes this from 1 round trip to 2 round trips. It's a doubling effect. |
Its a doubling effect on what is fast becoming a negligable part of a request response transaction. The amount of data passed in the redirect phase is likely to be far less than a kb. The rest of the transaction is likely to be well over 100kb...
Yet breaking the web's natural linking mechanism isn't ugly?
It has nothing to do with the amount of data. It's an additional HTTP request and response round trip. This is where most of the time gets lost in the network effect. (See Yahoo's research into page performance. HTTP round trips are what dominate the timings.)
The web page will render incrementally as soon as the server starts responding, so page size is actually less relevant than round trips. A redirect before the page gets served doubles the time before you see anything starting to render.
It isn't "UI evolution". It's a daft, unnecessary and slow technique.
It has nothing to do with the amount of data. It's an additional HTTP request and response round trip. This is where most of the time gets lost in the network effect. (See Yahoo's research into page performance. HTTP round trips are what dominate the timings.)
The web page will render incrementally as soon as the server starts responding, so page size is actually less relevant than round trips. A redirect before the page gets served doubles the time before you see anything starting to render.
It isn't "UI evolution". It's a daft, unnecessary and slow technique.
| Quote: |
| Yet breaking the web's natural linking mechanism isn't ugly? |
I didn't say that. But it probably is more robust than js.
| Quote: |
| It has nothing to do with the amount of data. It's an additional HTTP request and response round trip. This is where most of the time gets lost in the network effect. (See Yahoo's research into page performance. HTTP round trips are what dominate the timings.) |
not true.
Analyse it youself. I do. Redirects, done right, should add less than 5% to a full request response transaction. Try it. It does very much depend on the amount of data. It dominates when making lots of little ajaxian requests, which I'm guessing is what they're talking about. Not when downloading the average 200kb+ payload versus the little more than a header and a round trip, plus a 200kb+ payload...
http://www.google.com/url?q=http://news.bbc.co.uk/1/hi/default.stm&sa=X&oi=smap&resnum=1&ct=result&cd=1&usg=AFQjCNHm6IIzulYw3SMmtmnozBNsey3gCQ
versus
http://news.bbc.co.uk/
Remembering to clear your local cache properly and fully each test. Your telling me it should take twice as long. I'm saying there will be little difference.
I just used Yahoo's YSLOW ff extention (very good it is too). The results...
for the 3 (count them, 3) redirect from the first link, only 0.6 kb gets bounced around.
However the bulkier and slower jobs involved include:
21 external JavaScript files.
11 external StyleSheets.
32 CSS background images.
each making a round trip.
The upshot? Rather than the 3 requests, 0.6kb taking ~18ms re the redirects, the rest of the page comes to:
564.6K Total size
103 HTTP requests
16300ms (yes, 16+ seconds!)
Nearly 3 orders of magnitude difference. Making, to my mind, the redirects low on the performance enhancing strategy todo list.
Reading is great an all, but doing is often a better way to learn the practicalties I find. But then I don't like reading
for the 3 (count them, 3) redirect from the first link, only 0.6 kb gets bounced around.
However the bulkier and slower jobs involved include:
21 external JavaScript files.
11 external StyleSheets.
32 CSS background images.
each making a round trip.
The upshot? Rather than the 3 requests, 0.6kb taking ~18ms re the redirects, the rest of the page comes to:
564.6K Total size
103 HTTP requests
16300ms (yes, 16+ seconds!)
Nearly 3 orders of magnitude difference. Making, to my mind, the redirects low on the performance enhancing strategy todo list.
Reading is great an all, but doing is often a better way to learn the practicalties I find. But then I don't like reading
I just noticed your mention of time to rendering. Not quite what I was on about, but even if we go by that, rather than time to loaded, or time to responsive:
This lot has to respond before the page will start to render (sceen reader users be warned - the below is an enourmous amount of boring data) the number after the date in each is the number of milliseconds it took for each head loaded resource to responde:
This lot has to respond before the page will start to render (sceen reader users be warned - the below is an enourmous amount of boring data) the number after the date in each is the number of milliseconds it took for each head loaded resource to responde:
| Code: |
|
http://news.bbc.co.uk/nol/ukfs_news/hi/front_page/ticker.stm 11/3/2008 99 3.2K ParamsHeadersPost Response Headers Date: Mon, 03 Nov 2008 18:17:56 GMT Server: Apache Vary: Cookie Accept-Ranges: bytes Cache-Control: max-age=0 Expires: Mon, 03 Nov 2008 18:17:56 GMT Keep-Alive: timeout=10, max=129 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html Loading... js [HTTP headers] http://news.bbc.co.uk/js/newsi/latest/newsi.js?... 11/7/2008 50 25.5K "63b1-45285a0b224c0" ParamsHeadersPost Response Headers Date: Mon, 03 Nov 2008 18:17:51 GMT Server: Apache Last-Modified: Mon, 21 Jul 2008 09:49:47 GMT Etag: "63b1-45285a0b224c0" Accept-Ranges: bytes Content-Length: 25521 Cache-Control: max-age=345600 Expires: Fri, 07 Nov 2008 18:17:51 GMT Keep-Alive: timeout=10, max=130 Connection: Keep-Alive Content-Type: application/x-javascript Loading... js [HTTP headers] http://www.bbc.co.uk/glow/gloader.js gzip 3589 3.1K (9.8K) "c51-53993440" ParamsHeadersPost Response Headers Date: Mon, 03 Nov 2008 18:17:54 GMT Server: Apache/2.0.63 (Unix) Last-Modified: Thu, 30 Oct 2008 12:07:37 GMT Etag: "c51-53993440" Accept-Ranges: bytes Content-Length: 3153 Vary: accept-encoding Content-Encoding: gzip Keep-Alive: timeout=5, max=300 Connection: Keep-Alive Content-Type: application/javascript Loading... js [HTTP headers] http://newsimg.bbc.co.uk/js/app/shared/bbc_fmtj.js?... 11/7/2008 74 0.6K "287-45a8a12c91f80" ParamsHeadersPost Response Headers Date: Mon, 03 Nov 2008 18:17:54 GMT Server: Apache Last-Modified: Fri, 31 Oct 2008 10:29:34 GMT Etag: "287-45a8a12c91f80" Accept-Ranges: bytes Content-Length: 647 Cache-Control: max-age=345600 Expires: Fri, 07 Nov 2008 18:17:54 GMT Keep-Alive: timeout=10, max=59 Connection: Keep-Alive Content-Type: application/x-javascript Loading... js [HTTP headers] http://newsimg.bbc.co.uk/nol/ukfs_news/js/av.js?... 11/7/2008 44 1.7K "6e7-427c618ec7480" ParamsHeadersPost Response Headers Date: Mon, 03 Nov 2008 18:17:54 GMT Server: Apache Last-Modified: Wed, 24 Jan 2007 09:41:22 GMT Etag: "6e7-427c618ec7480" Accept-Ranges: bytes Content-Length: 1767 Cache-Control: max-age=345600 Expires: Fri, 07 Nov 2008 18:17:54 GMT Keep-Alive: timeout=10, max=192 Connection: Keep-Alive Content-Type: application/x-javascript Loading... js [HTTP headers] http://newsimg.bbc.co.uk/js/app/tools/hide_and_show/hide_and_show.js 11/7/2008 45 0.6K "2b4-42dc1f33334c0" ParamsHeadersPost Response Headers Date: Mon, 03 Nov 2008 18:17:55 GMT Server: Apache Last-Modified: Tue, 10 Apr 2007 13:15:39 GMT Etag: "2b4-42dc1f33334c0" Accept-Ranges: bytes Content-Length: 692 Cache-Control: max-age=345600 Expires: Fri, 07 Nov 2008 18:17:55 GMT Keep-Alive: timeout=10, max=45 Connection: Keep-Alive Content-Type: application/x-javascript Loading... js [HTTP headers] http://newsimg.bbc.co.uk/js/app/bookmark/bookmark.js 11/7/2008 46 2.2K "8e2-437bbf9e83780" ParamsHeadersPost Response Headers Date: Mon, 03 Nov 2008 18:17:55 GMT Server: Apache Last-Modified: Wed, 15 Aug 2007 12:19:58 GMT Etag: "8e2-437bbf9e83780" Accept-Ranges: bytes Content-Length: 2274 Cache-Control: max-age=345600 Expires: Fri, 07 Nov 2008 18:17:55 GMT Keep-Alive: timeout=10, max=189 Connection: Keep-Alive Content-Type: application/x-javascript Loading... js [HTTP headers] http://newsimg.bbc.co.uk/nol/shared/js/csf_2.js 11/7/2008 46 3.0K "c18-41bad5ef131c0" ParamsHeadersPost Response Headers Date: Mon, 03 Nov 2008 18:17:55 GMT Server: Apache Last-Modified: Wed, 23 Aug 2006 11:09:03 GMT Etag: "c18-41bad5ef131c0" Accept-Ranges: bytes Content-Length: 3096 Cache-Control: max-age=345600 Expires: Fri, 07 Nov 2008 18:17:55 GMT Keep-Alive: timeout=10, max=74 Connection: Keep-Alive Content-Type: application/x-javascript Loading... js [HTTP headers] http://newsimg.bbc.co.uk/js/app/rss/getrss.js 11/7/2008 45 1.1K "484-449b145dd1b40" ParamsHeadersPost Response Headers Date: Mon, 03 Nov 2008 18:17:55 GMT Server: Apache Last-Modified: Mon, 31 Mar 2008 01:07:17 GMT Etag: "484-449b145dd1b40" Accept-Ranges: bytes Content-Length: 1156 Cache-Control: max-age=345600 Expires: Fri, 07 Nov 2008 18:17:55 GMT Keep-Alive: timeout=10, max=162 Connection: Keep-Alive Content-Type: application/x-javascript Loading... js [HTTP headers] http://newsimg.bbc.co.uk/js/app/radio/aod/radioplayer.js 11/7/2008 41 0.3K "12f-44a709b693ac0" ParamsHeadersPost Response Headers Date: Mon, 03 Nov 2008 18:17:55 GMT Server: Apache Last-Modified: Wed, 09 Apr 2008 13:23:31 GMT Etag: "12f-44a709b693ac0" Accept-Ranges: bytes Content-Length: 303 Cache-Control: max-age=345600 Expires: Fri, 07 Nov 2008 18:17:55 GMT Keep-Alive: timeout=10, max=99 Connection: Keep-Alive Content-Type: application/x-javascript Loading... js [HTTP headers] http://newsimg.bbc.co.uk/js/app/blq/blq_core.js 11/7/2008 47 2.9K "ba8-44a95493a9080" ParamsHeadersPost Response Headers Date: Mon, 03 Nov 2008 18:17:55 GMT Server: Apache Last-Modified: Fri, 11 Apr 2008 09:09:06 GMT Etag: "ba8-44a95493a9080" Accept-Ranges: bytes Content-Length: 2984 Cache-Control: max-age=345600 Expires: Fri, 07 Nov 2008 18:17:55 GMT Keep-Alive: timeout=10, max=109 Connection: Keep-Alive Content-Type: application/x-javascript Loading... js [HTTP headers] http://newsimg.bbc.co.uk/js/app/site_wide_alert/site_wide_alert.js 11/7/2008 45 1.4K "5c1-45a635938cf00" ParamsHeadersPost Response Headers Date: Mon, 03 Nov 2008 18:17:55 GMT Server: Apache Last-Modified: Wed, 29 Oct 2008 12:17:32 GMT Etag: "5c1-45a635938cf00" Accept-Ranges: bytes Content-Length: 1473 Cache-Control: max-age=345600 Expires: Fri, 07 Nov 2008 18:17:55 GMT Keep-Alive: timeout=10, max=146 Connection: Keep-Alive Content-Type: application/x-javascript Loading... js [HTTP headers] http://news.bbc.co.uk/nol/shared/js/livestats_v1_1.js?... 11/7/2008 50 3.5K "de9-449cc930b7400" ParamsHeadersPost Response Headers Date: Mon, 03 Nov 2008 18:17:55 GMT Server: Apache Last-Modified: Tue, 01 Apr 2008 09:41:36 GMT Etag: "de9-449cc930b7400" Accept-Ranges: bytes Content-Length: 3561 Cache-Control: max-age=345600 Expires: Fri, 07 Nov 2008 18:17:55 GMT Keep-Alive: timeout=10, max=172 Connection: Keep-Alive Content-Type: application/x-javascript Loading... js [HTTP headers] http://newsimg.bbc.co.uk/nol/shared/js/nol4.js?... 11/7/2008 48 11.8K "2e3a-458e5235e99c0" ParamsHeadersPost Response Headers Date: Mon, 03 Nov 2008 18:17:55 GMT Server: Apache Last-Modified: Fri, 10 Oct 2008 12:17:51 GMT Etag: "2e3a-458e5235e99c0" Accept-Ranges: bytes Content-Length: 11834 Cache-Control: max-age=345600 Expires: Fri, 07 Nov 2008 18:17:55 GMT Keep-Alive: timeout=10, max=200 Connection: Keep-Alive Content-Type: application/x-javascript Loading... js [HTTP headers] http://newsimg.bbc.co.uk/js/app/av/emp/properties/default.js?... 11/7/2008 45 2.6K "a40-459ec1860e5c0" ParamsHeadersPost Response Headers Date: Mon, 03 Nov 2008 18:17:55 GMT Server: Apache Last-Modified: Thu, 23 Oct 2008 14:01:03 GMT Etag: "a40-459ec1860e5c0" Accept-Ranges: bytes Content-Length: 2624 Cache-Control: max-age=345600 Expires: Fri, 07 Nov 2008 18:17:55 GMT Keep-Alive: timeout=10, max=196 Connection: Keep-Alive Content-Type: application/x-javascript Loading... js [HTTP headers] http://newsimg.bbc.co.uk/js/app/av/emp/properties/en.js?... 11/7/2008 277 0.3K "14e-459ec18702800" ParamsHeadersPost Response Headers Date: Mon, 03 Nov 2008 18:17:55 GMT Server: Apache Last-Modified: Thu, 23 Oct 2008 14:01:04 GMT Etag: "14e-459ec18702800" Accept-Ranges: bytes Content-Length: 334 Cache-Control: max-age=345600 Expires: Fri, 07 Nov 2008 18:17:55 GMT Keep-Alive: timeout=10, max=105 Connection: Keep-Alive Content-Type: application/x-javascript Loading... js [HTTP headers] http://newsimg.bbc.co.uk/js/app/av/emp/emp_fmtj.js?... 11/7/2008 79 10.4K "28c4-459ec1860e5c0" ParamsHeadersPost Response Headers Date: Mon, 03 Nov 2008 18:17:55 GMT Server: Apache Last-Modified: Thu, 23 Oct 2008 14:01:03 GMT Etag: "28c4-459ec1860e5c0" Accept-Ranges: bytes Content-Length: 10436 Cache-Control: max-age=345600 Expires: Fri, 07 Nov 2008 18:17:55 GMT Keep-Alive: timeout=10, max=183 Connection: Keep-Alive Content-Type: application/x-javascript Loading... js [HTTP headers] http://news.bbc.co.uk/js/app/customisation/r2_0_3/main.js 11/7/2008 94 0.1K "8b-44c8b96158340" ParamsHeadersPost Response Headers Date: Mon, 03 Nov 2008 18:17:56 GMT Server: Apache Last-Modified: Tue, 06 May 2008 08:25:09 GMT Etag: "8b-44c8b96158340" Accept-Ranges: bytes Content-Length: 139 Cache-Control: max-age=345600 Expires: Fri, 07 Nov 2008 18:17:56 GMT Keep-Alive: timeout=10, max=94 Connection: Keep-Alive Content-Type: application/x-javascript Loading... js [HTTP headers] http://news.bbc.co.uk/js/app/customisation/r2_0_3/customisation.js?... 11/7/2008 46 40.4K "9e29-455d49b5f89c0" ParamsHeadersPost Response Headers Date: Mon, 03 Nov 2008 18:17:56 GMT Server: Apache Last-Modified: Mon, 01 Sep 2008 12:18:55 GMT Etag: "9e29-455d49b5f89c0" Accept-Ranges: bytes Content-Length: 40489 Cache-Control: max-age=345600 Expires: Fri, 07 Nov 2008 18:17:56 GMT Keep-Alive: timeout=10, max=84 Connection: Keep-Alive Content-Type: application/x-javascript Loading... js [HTTP headers] http://news.bbc.co.uk/js/app/customisation/capabilities/data/json.js 11/7/2008 98 0.03K "25-41bad417f5a40" ParamsHeadersPost Response Headers Date: Mon, 03 Nov 2008 18:17:56 GMT Server: Apache Last-Modified: Wed, 23 Aug 2006 11:00:49 GMT Etag: "25-41bad417f5a40" Accept-Ranges: bytes Content-Length: 37 Cache-Control: max-age=345600 Expires: Fri, 07 Nov 2008 18:17:56 GMT Keep-Alive: timeout=10, max=102 Connection: Keep-Alive Content-Type: application/x-javascript Loading... js [HTTP headers] http://newsimg.bbc.co.uk/js/app/customisation/r2_0_3/init.js 11/7/2008 140 0.2K "ef-44c8b95f6fec0" ParamsHeadersPost Response Headers Date: Mon, 03 Nov 2008 18:17:56 GMT Server: Apache Last-Modified: Tue, 06 May 2008 08:25:07 GMT Etag: "ef-44c8b95f6fec0" Accept-Ranges: bytes Content-Length: 239 Cache-Control: max-age=345600 Expires: Fri, 07 Nov 2008 18:17:56 GMT Keep-Alive: timeout=10, max=130 Connection: Keep-Alive Content-Type: application/x-javascript Loading... js [HTTP headers] http://news.bbc.co.uk/js/app/customisationstats/customisationstats.js 11/7/2008 113 1.5K "60e-451f9c1dc7600" ParamsHeadersPost Response Headers Date: Mon, 03 Nov 2008 18:17:56 GMT Server: Apache Last-Modified: Mon, 14 Jul 2008 10:57:28 GMT Etag: "60e-451f9c1dc7600" Accept-Ranges: bytes Content-Length: 1550 Cache-Control: max-age=345600 Expires: Fri, 07 Nov 2008 18:17:56 GMT Keep-Alive: timeout=10, max=110 Connection: Keep-Alive Content-Type: application/x-javascript Loading... css [HTTP headers] http://news.bbc.co.uk/css/screen/nol/v4/index.css?... 11/7/2008 9249 8.5K "2184-458d11b0ba600" ParamsHeadersPost Response Headers Date: Mon, 03 Nov 2008 18:17:41 GMT Server: Apache Last-Modified: Thu, 09 Oct 2008 12:23:52 GMT Etag: "2184-458d11b0ba600" Accept-Ranges: bytes Content-Length: 8580 Cache-Control: max-age=345600 Expires: Fri, 07 Nov 2008 18:17:41 GMT Keep-Alive: timeout=10, max=194 Connection: Keep-Alive Content-Type: text/css Loading... css [HTTP headers] http://news.bbc.co.uk/nol/ukfs_news/bsp/hi/customisation/css/r2_0_3/styles.css?... 11/7/2008 51 5.2K "14a4-44c8b98a5a400" ParamsHeadersPost Response Headers Date: Mon, 03 Nov 2008 18:17:55 GMT Server: Apache Last-Modified: Tue, 06 May 2008 08:25:52 GMT Etag: "14a4-44c8b98a5a400" Accept-Ranges: bytes Content-Length: 5284 Cache-Control: max-age=345600 Expires: Fri, 07 Nov 2008 18:17:55 GMT Keep-Alive: timeout=10, max=145 Connection: Keep-Alive Content-Type: text/css Loading... css [HTTP headers] http://news.bbc.co.uk/nol/shared/css/news.css 11/7/2008 139 0.3K "171-44f61a5ec6e40" ParamsHeadersPost Response Headers Date: Mon, 03 Nov 2008 18:17:56 GMT Server: Apache Last-Modified: Wed, 11 Jun 2008 10:38:41 GMT Etag: "171-44f61a5ec6e40" Accept-Ranges: bytes Content-Length: 369 Cache-Control: max-age=345600 Expires: Fri, 07 Nov 2008 18:17:56 GMT Keep-Alive: timeout=10, max=152 Connection: Keep-Alive Content-Type: text/css Loading... css [HTTP headers] http://news.bbc.co.uk/css/screen/shared/v4/mastheadfooter.css?... 11/7/2008 203 6.5K "19c4-45ac6ab7d9080" ParamsHeadersPost Response Headers Date: Mon, 03 Nov 2008 18:17:41 GMT Server: Apache Last-Modified: Mon, 03 Nov 2008 10:47:14 GMT Etag: "19c4-45ac6ab7d9080" Accept-Ranges: bytes Content-Length: 6596 Cache-Control: max-age=345600 Expires: Fri, 07 Nov 2008 18:17:41 GMT Keep-Alive: timeout=10, max=54 Connection: Keep-Alive Content-Type: text/css Loading... css [HTTP headers] http://news.bbc.co.uk/css/screen/shared/v4/styles.css?... 11/7/2008 205 11.6K "2d91-45ac6002fce00" ParamsHeadersPost Response Headers Date: Mon, 03 Nov 2008 18:17:41 GMT Server: Apache Last-Modified: Mon, 03 Nov 2008 09:59:20 GMT Etag: "2d91-45ac6002fce00" Accept-Ranges: bytes Content-Length: 11665 Cache-Control: max-age=345600 Expires: Fri, 07 Nov 2008 18:17:41 GMT Keep-Alive: timeout=10, max=164 Connection: Keep-Alive Content-Type: text/css Loading... css [HTTP headers] http://news.bbc.co.uk/css/screen/shared/emp.css?... 11/7/2008 205 8.8K "2298-4556c0fc15500" ParamsHeadersPost Response Headers Date: Mon, 03 Nov 2008 18:17:41 GMT Server: Apache Last-Modified: Wed, 27 Aug 2008 07:35:16 GMT Etag: "2298-4556c0fc15500" Accept-Ranges: bytes Content-Length: 8856 Cache-Control: max-age=345600 Expires: Fri, 07 Nov 2008 18:17:41 GMT Keep-Alive: timeout=10, max=195 Connection: Keep-Alive Content-Type: text/css Loading... css [HTTP headers] http://news.bbc.co.uk/css/screen/shared/v4/sitewidealert.css?... 11/7/2008 164 1.3K "553-45ac99e52de80" ParamsHeadersPost Response Headers Date: Mon, 03 Nov 2008 18:17:41 GMT Server: Apache Last-Modified: Mon, 03 Nov 2008 14:18:18 GMT Etag: "553-45ac99e52de80" Accept-Ranges: bytes Content-Length: 1363 Cache-Control: max-age=345600 Expires: Fri, 07 Nov 2008 18:17:41 GMT Keep-Alive: timeout=10, max=152 Connection: Keep-Alive Content-Type: text/css Loading... css [HTTP headers] http://news.bbc.co.uk/css/screen/nol/v4/uselection08.css?... 11/7/2008 202 3.6K "e14-45a8e47d77100" ParamsHeadersPost Response Headers Date: Mon, 03 Nov 2008 18:17:41 GMT Server: Apache Last-Modified: Fri, 31 Oct 2008 15:30:44 GMT Etag: "e14-45a8e47d77100" Accept-Ranges: bytes Content-Length: 3604 Cache-Control: max-age=345600 Expires: Fri, 07 Nov 2008 18:17:41 GMT Keep-Alive: timeout=10, max=162 Connection: Keep-Alive Content-Type: text/css Loading... css [HTTP headers] http://news.bbc.co.uk/css/screen/nol/v4/styles.css?... 11/7/2008 223 11.8K "2e69-45a627325e200" ParamsHeadersPost Response Headers Date: Mon, 03 Nov 2008 18:17:41 GMT Server: Apache Last-Modified: Wed, 29 Oct 2008 11:13:12 GMT Etag: "2e69-45a627325e200" Accept-Ranges: bytes Content-Length: 11881 Cache-Control: max-age=345600 Expires: Fri, 07 Nov 2008 18:17:41 GMT Keep-Alive: timeout=10, max=120 Connection: Keep-Alive Content-Type: text/css Loading... css [HTTP headers] http://news.bbc.co.uk/css/screen/nol/v4/business.css?... 11/7/2008 241 3.4K "d82-459af796a4880" ParamsHeadersPost Response Headers Date: Mon, 03 Nov 2008 18:17:42 GMT Server: Apache Last-Modified: Mon, 20 Oct 2008 13:41:38 GMT Etag: "d82-459af796a4880" Accept-Ranges: bytes Content-Length: 3458 Cache-Control: max-age=345600 Expires: Fri, 07 Nov 2008 18:17:42 GMT Keep-Alive: timeout=10, max=17 Connection: Keep-Alive Content-Type: text/css Loading... css [HTTP headers] http://news.bbc.co.uk/css/screen/nol/v4/furniture.css?... 11/7/2008 265 12.1K "2f66-457a22f7ecc00" |
Any external resources referenced in the <head> which are required to load before rendering begins have a similar delaying effect to redirects. Lots of resources in <head> is a massive performance lose, as is having a chain of redirects before reaching the correct page.
Adding a couple of redirects beforehand will make bad performing websites (such as those which take 16 seconds for page completion) seem a bit worse. The effect is more noticeable for good performing websites, such as those with 1 or 2 external resources in <head>, some carefully compressed graphics and lightweight markup.
Whichever way you cut it, those redirects aren't making the user experience faster. I'd expect "UI evolution" to at least achieve better performance!
Adding a couple of redirects beforehand will make bad performing websites (such as those which take 16 seconds for page completion) seem a bit worse. The effect is more noticeable for good performing websites, such as those with 1 or 2 external resources in <head>, some carefully compressed graphics and lightweight markup.
Whichever way you cut it, those redirects aren't making the user experience faster. I'd expect "UI evolution" to at least achieve better performance!



