Don’t be fooled by lipstick and mascara, what really lies behind the door of your site?

I’m always amazed by the lack of attention companies pay to the performance of their website.  Do we want aesthetically pleasing and feature rich functionality to be the welcome mat to our site? Yes!  But once that door opens, customers expect error free execution and fast loading pages, the acceptable response time tolerance level for an e-commerce site is only two seconds.  Page speed performance is critical to e-commerce success and at the core of the user-experience is the server, revving, responding to their every click; in an instant they accelerate towards their goal, destination checkout!

A great looking site with complementary User Interface (UI) design enhances the User Experience (UX) but even fantastic product imagery and well written descriptive content can be easily crushed by poor site performance and server errors, don’t be fooled by lipstick and mascara.  In order to get you headed in the right direction Google Developers has a page listing of their best practices for increasing page speed, entitled PageSpeed Insights Rules.  Once you’ve had a stab at modifying the server’s configuration settings (Apache Performance Tuning), reviewed external resources and optimized your site code including images, head on over to GTmetrix.  It’s a free tool that analyzes your page’s speed performance using PageSpeed and YSlow, GTmetrix generates scores for your pages and offers actionable recommendations on how to fix them.  There are a number of other free tools out there like the Pingdom Website Speed Test to help you better understand your site’s overall page speed performance.

As I stated, it’s a shame to see so many highly creative, beautiful sites performing so poorly.  It often makes me wonder if they are aware of just how bad their performance is, when the total page size is almost 5MB and there are almost 200 requests, it’s no wonder a site can take almost 10 seconds to fully load, thankfully HTTP/2 is here…

…BTW, that was a segue and again thankfully things are evolving on the web and HTTP/2 is both the present and future now.








What is HTTP/2?
HTTP/2 is a replacement for how HTTP is expressed “on the wire.”  It is not a ground-up rewrite of the protocol; HTTP methods, status codes and semantics are the same, and it should be possible to use the same APIs as HTTP/1.x (possibly with some small additions) to represent the protocol.

The focus of the protocol is on performance; specifically, end-user perceived latency, network and server resource usage. One major goal is to allow the use of a single connection from browsers to a Web site.

Why revise HTTP?
HTTP/1.1 has served the Web well for more than fifteen years, but its age is starting to show.

Loading a Web page is more resource intensive than ever (see the HTTP Archive’s page size statistics), and loading all of those assets efficiently is difficult, because HTTP practically only allows one outstanding request per TCP connection.

In the past, browsers have used multiple TCP connections to issue parallel requests.  However, there are limits to this; if too many connections are used, it’s both counter-productive (TCP congestion control is effectively negated, leading to congestion events that hurt performance and the network), and it’s fundamentally unfair (because browsers are taking more than their share of network resources).

At the same time, the large number of requests means a lot of duplicated data “on the wire”.

Both of these factors means that HTTP/1.1 requests have a lot of overhead associated with them; if too many requests are made, it hurts performance.

This has led the industry to a place where it’s considered Best Practice to do things like spriting, data: inlining, domain sharding and concatenation.  These hacks are indications of underlying problems in the protocol itself, and cause a number of problems on their own when used.

Check the link to see a demo of HTTP/2’s impact

Check the link for more information on the HTTP/2 protocol at

HTTP/2 in Apache httpd
– Be aware that most browsers will speak HTTP/2 only on https: URLs, so you need a server with SSL support.
– But not only that, you will need a SSL library that supports the ALPN extension.
– If OpenSSL is the library you use, you need at least version 1.0.2.

In short HTTP/2 renders some of the old HTTP/1.1 optimization techniques unnecessary.




“You must unlearn what you have learned.”






David Moores

Advanced knowledge of web server deployment, database management systems, and server-side scripting languages. Strengths lie in digital analytics, metric components and the implementation of data tracking methods for mining interpretation. The body of my work has been a balance of problem solving and technical know-how. I love a problem and love solving them even more!

Leave a Reply