3PHealth Blog

The Complete Solution to making the Web go Faster.

Tuesday, August 9th, 2011

Yesterday I wrote a blog about why web optimization is NOT the complete solution to making the Web go faster.

I promised that in my next post I would talk about the complete solution to making the Web go faster.

So here goes.

Let’s start with a couple of assumptions (I know, always dangerous but bear with me):

You have the MOST optimized Web site on the planet. It passes every known test out there
Your goal is to make it so that content gets to the device 30% faster with more relevance

There’s ONLY ONE way to get content there 30% faster, and that’s to send “less content”. And there’s ONLY ONE way to send less content and that’s to have MORE CONTEXT about the connecting device. There I’ve said it. You have to reduce the size of your content, and at the same time make it more relevant to the context of the person that is connecting to your service.

So all that remains is the HOW do I do that? Well you need to improve the functionality of the browser. (Whilst preserving the customers privacy which we’ll get to a little later). So how can you improve the browser (and remain true to existing Web standards)?

Step one is to use a plugin, also known as a browser extension. This is the “approved” approach by all OEM browser manufacturers (except Google’s Android smartphone) to extending the functionality of the browser.

Step two – you need more context so you can drive relevance. How do you do that? We can just use an app for this portion. We can create a secure database (wallet) that stores the customers personal information, their devices capabilities and their current location. Each item is stored as a “field” and can be turned on or off with a simple checkbox. This is so the user remains in control of their privacy.

Ok – we now have two industry standard components – a way to interact with the browser, and a way to interact with the device. You join those two together and you have real time context. Only one last problem to solve – how do I get the data to the server using approved standards?

Fortunately the W3C has already thought of that. They have something called an X header – it’s a “standard” way to send “non-standard” data to the server. Great we can use that. We’ll encrypt the headers (approved by the W3C) and send the data to the server. All we need to do then is decrypt it using a simple script and we have everything we need.

Now we’re in great shape. For the first time we have a way to augment the HTTP protocol and add some very powerful information that can be used to help manage performance (among other things).

So instead of having to rely on the Web server to send down a bunch of JavaScript to figure out where the device is, or what the device is capable of, or what the user would like to see an Advertisement about, we now get that information BEFORE we have to send the Web page.

So what does all this look like schematically?

Using the X header approach we use one transmission up and one down – total 2
Using the current approach we use 8
That’s a 75% improvement (and we’re only looking for 30%)

Summary…

We’ve optimized our Web server/service
We’ve now used STANDARDS to improve the browser
What we can now do is optimize the “relevancy” of the content to make it more personal
Finally we have a complete end to end client server solution that uses all approved standards

What does all of this achieve? You’ve cut down on the number of requests a Web server has to process, you’ve reduced the content size to EXACTLY conform to the devices capabilities AND you’ve personalized the CONTENT so the customer finds it compelling. And if you’ve delivered a personalized advertisement, there’s now a much bigger likelihood that the customer will click on it. Which in turn increases the amount of revenue for your Web service. And of course it’s much, much faster.

Optimizing a Web site WITHOUT optimizing for the browsers (user, device and location) is like driving a Ferrari with VW engine. No matter what you do, it’s never going to get there quickly.

Why Web optimization is NOT the complete solution to making the Web go faster!

Monday, August 8th, 2011

Everyday now we hear about someone offering to “speed” up the Web. They tout all manner of “measurement tools”. They say “if you measure it, you can manage it”. And if you can manage it then you can make things go faster.

Nonsense!

Let’s take this hypothetical case. You’ve called in all the worlds foremost experts in Web optimization and they’ve spent millions of your dollars measuring your infrastructure and then helping you install the very latest hardware to speed things up. They’ve also optimized every Web page that you transmit to be the very best it can be. They then pronounce that the job is done and that you now have the fastest Web site with the best optimized content on the planet.

Imagine then your shock when you get a call from a customer complaining about how slow your Web site is. How can that be? You’ve spent millions, you’ve hired the best and your Web pages are perfect.

Well you forgot one tiny little item. The Internet is a CLIENT – SERVER environment. You’ve only optimized 50% of the equation. (Think of it as two cans and a piece of string, the game you played back in the day before mobile phones).

Until you optimize the other 50% your destined to never improve the speed of the Web. (Ignore the piece in the middle (the string) no one is going to pay to optimize that.

Next blog post – The complete solution to making the Web go faster.

Measuring Mobile Web Performance: 101

Monday, August 8th, 2011

Short version:

From the end users perspective on a real device, connected to a Carrier network, anywhere in the world.

Long version:

Well here things get a little more complicated. There are always two different ways to measure User-Agent (the device) performance, whether it’s on the desktop or Over the Air (OTA)/On the device. This translates into two different “categories” of performance testing.

Over the wire:

The first is simply testing to see what happens with any particular application “on the wire”. This includes all the simple “packet capture” style tools that are out there. These kind of test, historically, may or may not help you solve performance problems being seen with any particular User Agent (the device). Just watching some downloads take place doesn’t really tell the “whole story”… especially when it comes to analyzing something as complex as a modern HTTP protocol exchange.

Presentation/Application layer:

The second is testing the presentation/application layer itself. Whilst it’s important to know how efficiently the transport layer is functioning… in terms of sheer PERFORMANCE… it is just as important to know how quickly the resources are actually becoming available for use to the application itself, or what JavaScript errors might be taking place during the page loading, or a host of application level “conditions” that contribute to overall (User Perceived) performance

Before you can measure anything on mobile you have to understand the fundamental differences between two categories.

Finally – Any testing MUST include testing the actual Carrier performance on a real device which a user would hold in his or her hands. There’s lots of “back end” fake Mobile sites around – sorry these don’t count as the real user experience. Carrier network performance is NOT the same as a copper connection to the Internet at your desktop. It’s something entirely different.

Finally one more critical item to consider – the devices real time location. Just as the Carrier network effects performance so does the location of the actual device.

Ignoring any of these conditions means that you’re not measuring Mobile performance.

View “Page Source”for Mobile

Friday, August 5th, 2011

One of the requests we’ve had is to be able to “view the page source” during a performance test. Here’s an example of what you can see in the upcoming release of our software

Website: www.dell.com – click on “For Home”

Screenshot of what the web page looks like: