How fast your web page loads has always been an important metric to consider. The methods, summed up as the term “page speed optimization”, and reasons that we use to speed up web pages have evolved considerably in the last ten years.
Harbinger of Change
The date was June 29th, 2007 — it would be a date that would impact the world in ways we couldn’t fortell. This was the day that the original iPhone launched.
How could we know, at the time, that there would be as many mobile devices as there are human beings in less than ten years. It wouldn’t take long for there to be a need to be a paradigm shift in how the web was formatted — no longer would we only be designing for desktop or laptop monitor resolutions in just a few short years.
“Flash” Back 10+ Years
Much of web development is a balance of form and function. It’s like much in life, simply existing to perform a function often does not set you apart from the masses. As human beings, we love beauty as much (and often more than) what a thing does. As web developers, we strive to invent different website designs to set the website owner apart from the other 1.1+ billion websites in existence right now.
In, what we here at i3dTHEMES refer to as the “Flash Golden Era”, the years between 2002-2009, those sites that had a rich user experience achieved it through a mix of HTML, CSS, and Flash objects.
Page Load Time
The areas that impacted “page load time” during this time was server speed, size of the HTML document and size of CSS/JS/Flash resources. We need to also remember, high speed internet was not as wide spread as it is today, so the same document that loads fast today (even for a mobile device) would, on average, load slower in 2005.
Even today, server speed is one of the easier aspects to look at — is your website running on a unit that is running dated hardware, or is at capacity? If it is, then you should consider having it moved to newer faster hardware.
The Main Focus of Page Load Time 10+ Years Ago
But what your web page loads, is one of those aspects that, as a webmaster, we had (and still do) the greatest control over. If all your web page was a plain-text document it would load near instantly.
But we all want a website that stands out from the billions of other websites, and is unique and user-friendly.
In order to make a website styled, we use Cascading Style Sheets (CSS), which in turn reference background graphics or images. We also use foreground images, and in 2007, the use of Adobe Flash animation was everywhere.
Flash files could be very large, and sometimes take 5-10 seconds to load. Often, Flash files would be optimize to ‘externally load’ other resources (other flash files, configuration files, and images) — and in doing so a ‘pre-loader’ animation would spin or indicate how much more time was needed to load the graphic.
We were all bench-marking for the three second load time — we knew that if you didn’t have something eye catching to keep your visitor on your site, within three seconds, your visitors would start “bouncing”. In other words, if you didn’t have either your pre-loader counting down (or up) or most of your website styled within three seconds, the likelihood of your visitors hitting the back-button on their web browser was pretty high.
So, if you had Flash in your page, and it was the majority of your top header, the rest of the page would render immediately while the Flash object was loaded — the initial page actually rendered faster in 2007.
In 2007, to optimize a page for “speed”, you’d need to optimize your background and foreground images, optimize the Flash movies, and make sure you were using a pre-loader if the movie would take longer than three seconds to load.
It took a few years for smart phones to really catch on after the iPhone launch of 2007 — the iPhones did not support Adobe Flash, so if you wanted to have a “flashy” site, you needed to have some mechanism to ‘degrade gracefully’ for those devices that didn’t support a non-mobile technology — we achieved that through an alternate slider that showed in place of the Flash object in the event that the device couldn’t show Flash. It was meant as a stop gap until Apple finally endorsed Flash.
2010 – A Declaration (of sorts) of War on Flash
And then, in April of 2010, Steve Jobs, CEO of Apple, published an open letter called “Thoughts on Flash”. In short, he declared that Apple would not allow Flash on the any device running what we now call iOS (iPhone, iPad, iPod touch).
As the Apple market-share grew, we all began to realize that if we wanted websites that operated the same on all devices and still be “flashy” that we would need to abandon the Adobe Flash animated objects that we’d spent the last 5-8 years developing, and move to a new “mobile friendly” way of adding engagement.
It wasn’t long before it was obvious that Apple would win the war and Adobe Flash would be considered a non-viable technology if you wanted to have your website mobile friendly.
A New Era in Design and Development
HTML5 was officially adopted in 2014, which allowed for more dynamic animations as well — it is now supported by all modern web browsers.
There would also be additional frameworks that helped to render pages for mobile, such as “Bootstrap”, “960 Grid System”, and “YAML”. This was a way of making sure a website rendered well for all devices, from smart phones, to tablets, to laptops and desktops.
However, to make this new era of engaging and mobile responsive websites happen, there was a trade off.
With Great Functionality comes Great Overhead
There was a major draw back to these new frameworks: there was a fair bit of overhead now to load a web page.
The difference between 2007 and 2017, with regard to the composition of web page resources is significant.
2007 Web Page Resources
- HTML (15KB)
- 1-4 Stylesheets (19KB)
- 1-10 background images (200KB)
- 1-15 foreground images (200KB)
- Flash objects (150KB)
2017 Web Page Resources
- HTML (75KB)
- 5-10 Stylesheets (more, due to frameworks) [380KB]
- 1-20 background images [900KB]
- 1-20 foreground images [300KB]
Render Blocking is Now Noticeable
This is why often you click on a link and have to wait 5-10 seconds for a the browser to respond — it isn’t necessarily the speed of the web server, but the fact that the render blocking resources must be loaded before a page is rendered.
In order to make pages load faster in 2017, we have to become familiar with some very technical optimization techniques to shave as many millisecond off the load time as possible.
Google provides a tool called PageSpeed Insights, which helps us to determine what is slowing down our web pages. These aspects of page speed optimization, that PageSpeed Insights covers, include “minification”, “image optimization”, “server side configuration” and “deferral of render blocking resources”.
Images must be optimized as much as possible. Transparent PNG files are often used — these files are larger than JPEG files, but can still be optimized using websites such as tinypng.com
Server Side Configurations
If available, we need to enable GZIP compression and web browser caching on the server. Often these feature are not enabled by default, but once turned on can make a dramatic impact on the load time of website resources.
Deferral of Render Blocking Resources
A side effect of deferring the loading CSS to after the page loads is something called the FOUT (Flash of Unstyled Text) — basically, your web page looks like a plain black-text-on-white-background until the CSS files load in.
The only way to resolve the FOUT is to determine what styles are required for the rendering any region “above the fold” (the area visible to the web browser on initial page load), and insert them into the HEAD region of your page so that the initial “above-the-fold” region is properly rendered immediately while the rest of the CSS resources gradually load in.
The Implications of a Mobile Web
With all of this focus on making sure the web is both beautiful and engaging, but also accessible to mobile devices, we’ve adopted a world where we need to spend more effort on making sure websites render as fast as possible.
Luckily, there is an option out there if you’re not up for implementing the technical recommendations of the PageSpeed Insights tool. In 2016, we developed a website plugin called Accelerator that automatically optimizes an entire website for page speed. If making sure your website is optimized for speed is important to you, but you don’t want to spend the time to learn how to manually optimize your pages, check it out.
Oh yes, there’s a next. We will be releasing information over the next month or so about where the web is going, so far as optimization is concerned. Hint: speed is everything. And if you’re not concerned about how fast your pages load now, just wait until you learn about how the web is changing. It really isn’t something you can dismiss any longer.
Web page resource composition was simple in 2007 compared to web pages of 2017. There are more render blocking resources within many pages now, which require special techniques in order to make web pages load as fast (or faster) as they appeared to load 10 years ago. However, there is a solution called Accelerator that automatically optimizes your site for you, if the technical specifications and recommendations of Google PageSpeed Insights are more than you’re up for.