Page Speed and Fast Paths

I would be pretty safe saying all e-Commerce folks grasp the concept that slow page loading is the kiss of death to website sales and revenues.

There are some excellent articles written on how to accelerate site performance, accelerate content delivery, reduce web page resource requirements, compress images, reduce time-to-first-byte and help gain some speed or the perception of speed.

What? You’ve done all of that? But it just isn’t enough?

Read on.

According to a recent study published by Radware, instead of reducing content, the median e-commerce web page contains 99 resources (images, CSS, scripts, etc..), making them bigger than ever.

These resources create latency. Funny thing about latency… you can’t fix latency with bandwidth but you CAN fix bandwidth with latency. You can tweet that.

Cisco, Riverbed and others have gotten very good at reducing the packet size of data being transmitted, reducing the need for retransmission, and reducing the intelligent conversation needed between routers in order to reduce transmission time and latency. Market prices for bandwidth have plummeted and clients have built networks using multiple carriers.

But here’s the thing.

Once it leaves your router and enters that glorious world wide web, it is ruled by an old, static set of tables fondly known as Border Gate Protocol or BGP.

BGP is the Google Maps of the Internet. It is the ultimate address matrix that uses a predefined route matrix to determine the shortest routing data should take between any two points (and then the next two points, etc.). Which is fine except that BGP was never designed to address performance nor does it attempt to.

So what happens – and it happens a lot – is that BGP takes all that wonderfully accelerated website data and sends it down the wrong path. Well, maybe not the wrong path but certainly not the best performing path with the lowest latency.