When you work in the web performance world, you’re constantly reading blog posts about new techniques or new hacks that are implemented or tried on new website / Single Page app / mobile website / CMS. You also meet a lot of people telling you that “yes we do some concatenation, minification, whatever … but mhhh … not for this because it’s outside the deployment process … “. Or you see people trying to speed up their websites without monitoring anything.
So instead of focusing on techniques, shouldn’t we watch the side aspects of web performance as being as important as techniques?
Web performance is business
It is not overstated : having a website which is slow scares your users and potential customers. The loading time shouldn’t be a feature like the others, this is the one that everyone should put first. You can have the most exciting third generation social network, if it takes 5 seconds to load each page, you zap! “If it is fast and ugly, users will use your website and grumble at it. If it is slow, they won’t use it.”
The web performance simply has an impact on your business. After months of A/B testing, lots of experimentations (and sometimes deceiving results), we managed to prove that. Not by making pages slower and measuring a decrease of some indicator or another. But by speeding up some websites and measuring this effect against the non optimized version.
And we discovered that :
- A/B testing is quite hard to get it right (sampling, confidence interval, etc …)
- definitely, the mean in not a good metric to look at. Percentiles are
much better and looking at distributions through CDF is way
more clearer - some websites are very sensitive to speed, others are less (competition, customer typology, product offer, etc …). It can go from a 22% conversion rate increase for an online travel website to a 7% increase for a private sale website (passing by a near 0% for an already quite well optimized motorcycle accessories website)
I think the most annoying thing when we talk about business impacts of the web performance is that we are mixing everything : devices, websites, customers. Each website has its own metrics! See this good article from Larry Haig.
So, please everybody, stop using the old Amazon figures. They are old, they are specific to Amazon, they are related to slowing websites and moreover from a pre-iphone world.
Web performance is organization
Making a fast website is not a matter of technique or I should say : making a fast website is a matter of technique, keeping a website fast is a matter of organization.
In my previous experience, as CTO of a major french eCommerce website, we were constantly working to make the website as fast as possible. But as soon as we put up SWAT web performance operations, we had to start over six months later. SWAT teams can do a good job but they are focused for a short period.
Velocity is not speed (it’s not SpeedConf, isn’t it?) and websites should be organized to produce web performance, to go fast and make things fast. We are in an ever changing world (browser, connections, devices) and we must constantly adapt our rules to it. Including for web performance.
Besides, this is not only the IT teams that should be focused on web performance, but every team in the company, like a customer oriented mind, websites should have a web performance oriented culture. IT should not have to fight against marketing about image sizes or third parties widgets. They should work hand in hand to find the best compromise on web performance.
So just look around you : if web performance is not discussed at a management committee level, it will be harder …
Web performance is automation
Why?
Because manually concatenating three files and deploy them is easy. Implementing the system that concatenates the CSS and JS in all templates that come from your home based CMS on a given page, is a little bit harder. (Hey that’s why in major CMS this feature is implemented, isn’t it?)
Because minifying CSS or JS with a command line is easy. Doing it manually each time before production deployment is boring and error prone.
Because asking his designer / webmaster / integrator to better compress the images (“save for the Web baby”), it’s easy. Developing the system that compresses each images before deploying to production is more complicated.
Because deciding to make a sprite once is trendy, it gives you the impression you are on top level and it’s (quite) easy. Maintaining a sprite is difficult, not to mention several sprites. How many times I have seen sprites2.png , sprites2new.png coexist with the old sprite.png … Instead of saving bytes, these sprites make the page heavier!
Yes, it’s only human : if it’s not automated, nobody wants to keep repeating a tedious operation. And making mistakes is human 😉
And that applies to both devs and sysops. Configuring an Apache web servers so that it has the right cache headers options and good gzip config, ok, easy. Manually replicate it on 10 servers, um, it can be long, tedious and error prone. Propagate these configs during migration, idem, it can lead to errors.
And even if all the rules were implemented / developed on your website / framework, how do you ensure that everything works as expected? Because measuring once a 10% decrease in load time is easy. Watching and measuring what happens in the long term for all users, all platforms, detecting issues, etc … requires more investment … If you don’t have a web performance monitoring tool, how can you decide what web performance development you must prioritize?
In short, you guessed it, web performance is first automation. Automation is mandatory if you’ve decided to follow a web performance strategy. And automation takes time to implement…
OK, Web performance is technique
Concatenation, minification, lazyloading, JS and CSS loaders are all well known practices. They are now implemented in popular CMS and frameworks.
But the fact is that we can fight against browsers when implementing these techniques : they now have predictive parsers (see Andy Davies article) and can beat your optimizations. So not only do you need to apply these techniques but you must go further and adapt them to the different kind of browsers/devices/connections (see “Situational Performance” post by Guy Podjarny)!
To go further, we’ll have to really get technical :
- manage pre rendering / prefetching (and more generally prebrowsing as Steve Souders defined it, http://www.stevesouders.com/blog/2013/11/07/prebrowsing/),
- make SPDY / HTTP2 compliant website (including server push)
- manage images precisely for each devices (inlining, pixel ratio, size, new formats like webP or JPG-XR)
- lazyload only “Under The Fold” images or inline minimal “Above The Fold” CSS and JS for the first view
And I think the last VelocityConf (specially in London where I attended) really woke up the community and introduced these new challenges about new browsers, new devices, new formats and so new techniques to play with.
To sum up, web performance is a major feature for every business websites, there is no more doubt about it. But even if practices are well known by the community, an efficient use of these practices should be based on automating them, specially because they are continuously evolving.
And because of that, we, tech guys, still have a lot of work for the next decade 😉
Stéphane Rios
CEO, Fasterize
Twitter @stefounet