I’m going off the deep end today a bit to talk load speed. Site speed is extremely important because it directly effects conversion. No matter what combination of marketing tactics you employ from SEO, Social, SEM and so on, a slow loading page will effectively be the mountain in your path to a successful campaign.
As a conversion lever, if you consider the impact from a few studies, front end engineering as a discipline has HUGE implications for conversion and overall web experience. Referencing the NYT article above, if you’re site is 250 milliseconds worse than your next nearest competitor, your site will lose traction over the long term as visitors will defect and prefer the higher performing experience.
Just a few things to do:
1. Minimize HTTP Requests: set guard rails around the number of objects per page and be aware of how they are called and in what order. Reduce the chance of any bottlenecking.
2. Use a CDN Content Delivery Network: Use a content delivery network such as Akamai, Amazon Edge, Edge Cast, Level3 or other to distribute your content across multiple servers.
4. GZIP compression: reduces the size of the HTTP response thus making the site load faster. Most internet browsers support GZIP and it can reduce response size by as much as 70%.
5. Governance around Pixels/Beacons: Implement governance around how beacons are used so that you are reducing the number of beacons used while still being able to integrate with Omniture, Google Analytics or conduct a/b testing and qualitative surveys.
6. Optimize Images: reduce the file size of all images as much as possible and test and come to a consensus on what quality to size ratio works best for each image type.
Front end speed optimization is a never ending process because the benchmark is constantly shifting as new technologies are adopted.
My main focus here is the importance of Front End Engineering but I’ll say a few words about back end engineering as well. On the backend we should move away from computationally expensive implementations like MySQL, PostGres, Oracle and so an and move towards using a more distributed database layer (Redis, Mongo, Cassandra, Hyperdex, etc.) because the key is the ease of which these can be replicated and syndicated across multiple servers.