The Complete Solution to making the Web go Faster.
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 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%)
- 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.