A few weeks ago I tested (again) nearly 500 responsive websites in different resolutions. My test was focused on size differences between resolutions, but looked at the overall page size as a single unit.

In this blog post, I’d like to dig into the same data, but this time drill down into the specific types of resources on the page – Image, JavaScript, CSS and HTML files. Such a drill down can give us better insight into which optimizations are being applied today, and help guide us regarding where to focus our performance evangelism.
Read the rest of this entry »

Apple has always allowed only one browser rendering-engine on the iOS platform – the one included by default. Both the native browser (Mobile Safari) and the browser embedded into apps (UIWebView) use this engine. In addition, any alternate browser on iOS, most notably Chrome for iOS, must use UIWebView and not their own engines.

However, a browser is not just a rendering engine, and the iOS browsers still differ quite a bit. For example, Mobile Safari benefits from a JavaScript engine that is 3X faster than UIWebView. Chrome for iOS, in turn, uses a custom network layer designed to be as fast as the one used by Chrome for Android.

Still, because Chrome for iOS and Mobile Safari are both closed applications, we had no way of actually measuring their performance. We were limited to measuring using UIWebView within Mobitest, and had to assume the other browsers are faster. Fortunately, technology is always improving…

I’ve been working with Manish Lachwani, the CTO of a new startup called Appurify. He and his team have created a platform for automated testing and measurement of black-box apps, on real mobile devices. More specifically, the platform enables some probing into the internals of select apps, such as Mobile Safari and Chrome for iOS, and even lets one simulate network speeds and cellular conditions. Using this technology, we can finally compare the actual performance of these three browsers.
Read the rest of this entry »

For web pages today, images are a real challenge.

On one hand, images account for over 60% of the page weight. This means they play a major role in overall page load time, motivating dev teams to try and make images as small (byte-wise) as possible. On the other hand, new devices boast retina displays and higher resolutions, and designers are eager to leverage these screens and provide beautiful rich graphics. This trend, along with others, led to a 30% growth in the average number of image KB on a page in the last year alone.

This conflict is partly due to what I think of as “Situational Performance”. If you’re on a fiber connection – like most designers – the high quality images won’t slow you down much, and will give you a richer experience. If you’re on a cellular connection, you’ll likely prefer a lower quality image to a painfully slow page.

Fortunately, not all hope is lost.
A few months ago we created a new optimization called Low Quality Image Placeholders, or LQIP (pronounced el-kip) for short. This optimization proved useful in bridging the gap between fast and slow connections, and between designers and IT, so I figured it’s worth sharing.
Read the rest of this entry »

I’m writing this short post to update you on a significant change in Akamai IO’s data source. Since its inception, IO’s data was based on many websites, but most of those sites catered to a US audience. This means that the data set was biased – it included global traffic, but held a disproportionate amount of traffic from the US.

Starting February 16^th, we’ve started using a new data stream, based on traffic from most Akamai customers – meaning a much more global distribution, enough to take away the entire bias. The new data set is also bigger, including over a billion requests each day, and uses a newer version of our device characterization engine.
Read the rest of this entry »

About a year ago, I ran a test comparing the performance of websites using Responsive Web Design (RWD) across different screen resolutions. The test consisted of loading the same RWD sites in Chrome using 4 different screen resolutions, triggering different “views” of the site, and comparing bandwidth and load times in each.

The test results didn’t bode well. They showed that practically all RWD websites downloaded the full payload of the desktop website regardless of what was displayed. These websites would download hundreds of KB of unnecessary data to a small screen, only to hide or shrink them on the client, resulting in abysmal performance on mobile devices.

Over the past year, RWD performance has been discussed at length, with great posts from Jason Grigsby, Tim Kadlec and many others. New tools such as PictureFill and Adobe Shadow make optimization and testing easier, and some of the conversation even made it into the HTML5 draft.

So, with all this progress, I figured it’s time for a retest – are we faster yet?
Read the rest of this entry »

In case you didn’t hear, a new HTTP version is coming to town. There’s a lot of great information about it, including a recent post by Stephen Ludin and a recent presentation by Mark Nottingham.

HTTP 2.0 is in its infancy, but much of its charter is to implicitly get rid of various performance problems HTTP/1.1 presents. Techniques like header compression and request multiplexing try to make websites inherently faster, with no extra effort required of the website owners.

As a result, I often hear statements like “HTTP/2.0 would get rid of the need for FEO”, or even “HTTP/2.0 would make CDNs unnecessary”. I strongly disagree with these statements, and figured it’s worth writing a post about why.
Read the rest of this entry »

Update: updated title and reference to mdot site below, following feedback

I like Responsive Design. Heck, I LOVE Responsive Design. I think it’s a brilliant methodology, which address true challenges in a very good way. But no matter how fond you are of RWD, I think you have to face the music – RWD makes it very hard to write a fast website.

I’m not saying you can’t write a high performance responsive website. I’m not saying you shouldn’t use RWD (Responsive Web Design) – I would actually recommend it to most organizations. However, RWD makes pages inherently more complicated, and all in all would make the mobile web slower.
Read the rest of this entry »

Consolidation of JavaScript and CSS files is one of the simplest Front-End Optimization techniques. Its goal is to reduce the number of roundtrips to the server, and thus save time and resources. Implementation is simple – Take all the (textual) JS files linked on a page, paste them into one large file, and make your page point to that resource. Repeat for CSS, and e-voila, you have a faster page.

Unfortunately, nothing is really as simple as it sounds… While implementing consolidation is fairly easy, applying consolidation creates two new performance problems: Duplicate Downloads and Breaking Progressive Processing. This blog post explains these issues, and describes the techniques we use – and you can use – to address it in Akamai FEO.
Read the rest of this entry »

Just over a year ago I posted the results of my research about Mobile Browser cache sizes. At the time, there was general consensus mobile browser cache was small, but a lack of concrete numbers to support it. I created some cookie-based measurement tool, which helped confirm mobile browser cache sizes were indeed far smaller than desktop browsers.

A lot has changed since then. Google shipped Chrome for Android, which explicitly stated it addressed the small cache size. Android’s native browser has also improved dramatically, as did Apple’s Mobile Safari. In addition, Firefox released an Android browser, and both Google and Yahoo released hybrid browsers for iOS (Chrome for iOS and Yahoo Axis), which mix Apple’s UIWebView with some of their own software.

With all those changes, plus some probing from Steve Souders, I figured it’s about time to rerun my tests.
Read the rest of this entry »

Last week I posted the first part of reviewing the architecture aspects of Front-End Optimization, and their impact. The purpose of that post (and this one) is to give you better insight into how FEO tools work, so you can make a more informed decision when considering using one.

If you haven’t done so already, check out last week’s post to learn about inline vs. offline analysis, central vs. local analysis, and optimizing close to the client vs close to the server. In this post, I’ll discuss the remaining 4 items in the table below.
Read the rest of this entry »