Web performance is business.
We can’t stress this enough, but having a site that “lags” will drive your users or potential customers away. Loading speed shouldn’t be just another “feature”, it should be the one everyone puts first. You can have the 3rd generation social network or the killer offer, but if you have to wait 3 seconds on each page, we’ll zap you!
Quitesimply, web performance has an impact on your business. At Fasterize, our first tests with an online tour operator showed a 20% increase in conversion rates over 2 months. More recently, we’ve seen a 10% increase in the transfo rate of a private sales site. Makes you think, doesn’t it? Who would miss out on even a 2, 5 or 10% increase in conversion rate without touching their site?
Web performance is all about organization.
Making a site fast isn’t just a matter of technique. Making a site fast is a matter of technique, keeping a site fast is a matter of organization.
In my previous experience as CTO at RueDuCommerce.com, we constantly worked to make the site as fast as possible. But as soon as we set up “commando” operations, 6 months later, we had to start all over again.
Why was this?
Because concatenating 3 files by hand and deploying them is easy. Setting up a system that concatenates the CSS of all in-house CMS templates according to a given page is more complicated.
Because minifying is easy on the command line. Doing it manually before each production run is boring.
Asking your graphic designer/webmaster/integrator to compress your images better is easy. Setting up a system to compress them before sending them to production is more complicated.
Because when you decide to make a sprite once, you feel like you’re on top of things, and that’s easy. Maintaining one sprite is complicated, let alone several. How many times have I seen sprites2.png, sprites2_new.png cohabiting with the good old sprite.png …
It’s human nature, if it’s not automated, no one wants to repeat a tedious operation over and over again.
And that goes for devs, operators and sysadmins alike. Configuring an Apache so that it has the right cache headers and Gzip configuration is easy.
Replicating this on 10 servers can be long and tedious.
Propagating these configurations during migrations, idem, can be a source of errors.
Because it’s easy to reduce loading time by 10, 20 or 30% at a given moment.
Tracking the results over time, right away, requires more investment…
Organization = automation = dev factory
In short, as you can see, webperf is all about automation. Automation takes time to set up.
At Fasterize, automation is one of our core values. And we often think that we’re not just another technical solution, a cache, a Varnish, etc. …. No, we’re a webperf automation solution. We’re one of the components of your future dev factory!
How about you? How are you organized to produce webperf? Have you automated your CSS creation, image compression and sprites? How many steps does your production require? If you have any examples to illustrate this, we’d love to hear from you!
