Guy's Pod

Responsive Web Design Adoption, 2014

Tue, 11 Nov 2014 13:06:43 +0000

Responsive Web Design is hot. Practically every company I speak to, around the globe, is either going responsive, has gone responsive, or – at the very least – giving it serious consideration. So, with all this buzz, how many websites are actually responsive?

To answer this question, I ran a test on the top 10,000 websites (per Alexa), and checked if they are responsive. This test was a repeat of a test I ran last year, and relies primarily on the presence of a horizontal scrollbar when loading the page on a small screen. If the scrollbar is there, it indicates the website didn’t adjust its styling to the display, and thus is not responsive. You can find the full test methodology in last year’s post.

I had the pleasure of presenting this data at the awesome Web Directions South 2014 (slides here), and in this post summarized the highlights. So, let’s get to the results!

RWD More Popular In The Long Tail

The chart and graphic below show the percentage of responsive websites amongst the top 100, 1,000 and 10,000 websites. As you can see, the adoption rate is quite substantial, reaching 18.7% adoption rate in the entire data set.

The adoption rate is noticeably lower in the very top sites. This may be due to costs, as the top sites can more easily pay for multiple separate websites. However, I believe the reason is more the higher agility of the lower tier sites. These sites often have less legacy code or internal politics than the ones at the very top, making the adoption of RWD easier.

	Top 100	Top 1,000	Top 10,000
RWD	11.8%	18.3%	18.7%
Non RWD	88.2%	81.7%	81.3%

RWD Adoption Growing Fast

The next chart shows the difference between this year’s results and the test I ran last year. As you can see, adoption has grown substantially in the top 1,000 websites and above. Amongst the top 10,000 websites, almost 8% of websites went responsive within the span of a single year – an incredible growth!

It’s worth noting that this test used the same URLs used in last year’s test, and so this adoption represents actual changes on the same websites. It’ll also be interesting to explore the percentage of RWD sites amongst the 2014 top sites vs. the 2013 top sites, but this test did not capture that case.

RWD Sites Use Large Resources

Comparing RWD sites to other websites on desktop shows responsive websites use fewer requests, with a median of 74 requests per page compared to 95 on non-responsive ones. However, the median page weight was practically the same, (roughly 1.1MB) for both types of sites.

This apparent discrepancy is due to the fact responsive websites use larger resources. As the chart below shows, the average size of a JS or CSS file is more than 20% larger on an RWD site. This increase may be due to the higher complexity of the page, as it can support multiple viewport at once.

Images are roughly 27% larger on a responsive site, and JPEG images are a staggering 50% heavier! Once again, various reasons may lead to this delta, one of which is the more frequent use of high resolution (“Retina”) images on responsive sites. Mobile displays have a high pixel ratio more often than desktop ones, driving more interest in HD images, which are often (wastefully) used for all clients.

RWD Sites Still Over Download

So far we’ve compared RWD sites to non-RWD sites. Another interesting view is the difference in page composition when loading an RWD sites on a small vs. a big screen. For most responsive sites, a smaller screen will present users with less content or functionality, for instance hiding some images or social sharing buttons, or shrinking down some images.

That difference, however, is not reflected in page size. The chart below shows the number of requests and bytes used when loading a web page on a small and big screen. In both of those cases, the User-Agent was that of a desktop browser (Chrome), while the third column shows data for loads on a small screen as well as a Mobile User-Agent.

As you can see, the delta is not big. RWD pages used a mere 7% fewer requests or bytes on a small screen, despite substantial differences in the amount of content displayed. Using a Mobile User Agent led to a bit more savings, combining for ~13% savings in bytes and requests. This may indicate that some responsive websites employ RESS, tuning the content served to the client if it’s a mobile device.

RWD Sites almost as popular as Mobile Websites

Another way to look at adoption is to compare it to the alternate mobile strategy – a dedicated mobile (“mdot”) site. To do so, I looked at the intersection of websites that appeared in both my set and in HTTP Archive Mobile, which – after some filtering of errors – left me with roughly 2,800 websites, all within the Alexa top 5,000. Not quite 10,000, but still a sizeable sample.

Amongst those sites, we can see that 17.2% of websites used RWD, 20.5% redirected to a mobile website, and the remaining 62.3% did neither. This is a limited perspective, as some of the “Neither” sites use Adaptive Delivery (using the same URL, but returning a different HTML to mobile clients). In addition, many of the mobile specific sites use RWD, responding to client fragmentation within the “mobile” group. Still, it’s interesting to see RWD is already almost as popular as a Mobile only site.

RWD Sites Are Heavier Than Mobile Sites

Now that we have a set of mobile sites and a set of responsive one, we can compare some performance characteristics of these two ways to handle the mobile web. As the next chart shows, mobile websites are substantially smaller than responsive sites. A median mobile site used less than half the bytes and roughly 30% fewer requests than its responsive peer.

Note that the absolute numbers are different than those we saw in the previous charts, for two reasons. The first is the smaller data set, and the second is the loading of these sites on real mobile devices. In the previous test, we simulated mobile, but now that we had a smaller test, I actually loaded the pages (both the Mobile and RWD ones) on a real mobile device (Moto G).

Processing RWD Sites on Mobile Is Expensive

One oft-discounted part of page load time is processing time, despite the fact it is a significant contributor to page speed. In this test, I used Chrome Dev Tools to capture the amount of processing time used with every page. This includes steps such as parsing JavaScript, rendering layout, painting on the screen, etc.

Once again, I compared processing time for RWD sites to that of Mobile sites, guessing that the higher complexity of responsive websites would require more compute. And indeed, as the chart below shows, that guess proved true. The two charts show the processing time in absolute CPU seconds and as a percentage of overall page load time. In both cases, a responsive website required the device (Moto-G, a $200 Android device) to spend much more time running the program that is the site, therefore slowing it down.

Summary

Responsive Web Design adoption is growing rapidly, and is already nearing the adoption levels of a dedicated mobile site. Unfortunately, this fast adoption of RWD is moving faster than the attention to its performance. Current RWD sites perform better than desktop sites in various aspects, but are substantially heavier and more complex on mobile, compared to the alternative – a dedicated mobile site.

In my opinion, this does not mean you should stick to dedicated mobile websites as your strategy. In today’s web (and tomorrow’s web), arbitrarily separating “mobile” from not is doomed to fail, and approaches like RWD are required if we’re to properly serve the fast pace and fragmented device landscape. However, mobile websites gave us some freebies when it comes to performance, and when using RWD, and the more complex pages it requires, we lose those discounts. We have to own our performance.

As an industry, we should keep encouraging the use of RWD, but at the same time we have to double our efforts in building knowledge and tooling for making responsive websites fast. So pick up an RWD Performance book (free copy!), attend an RWD Perf workshop near you, and start making responsive websites fast!

RWD Ratio in Top 100,000 websites - refined

Thu, 09 Jan 2014 13:56:04 +0000

A few weeks ago I posted the results of a research testing the top 10,000 websites for responsive indicators. The test showed roughly 12% of these sites were responsive, a ratio that was fairly consistent across the top 100, 1,000 and 10,000 sites.

Following twitter feedback, I reran the test on the top 100,000 (!!!) websites as well, and dug deeper into the websites flagged as responsive – this post shares the results.

What qualifies as a Responsive site?

The previous test results triggered a fair bit of conversation about what qualifies as a responsive website. Posts by Brad Frost, Jason Grigsby and Tim Kadlec discuss this in depth, so I won’t spend too much time on it. For the purposes of this blog, I consider websites using Fluid Design to be responsive (using the test described in the last post). Since fluidity is a minimum requirement for responsiveness, these results are an upper bound on the number of responsive websites out there.

In addition, I noticed a disproportionate chunk of error responses was flagged as responsive. Logically these responses are indeed fluid, as they adapt to the display size, but I wouldn’t really count them as valid pages. To mitigate this issue, I filtered out any website that had less than two “200 OK” responses. This filter eliminated some responsive error pages, but for the most part seemed to clean the results.

Lastly, note that while I’m saying “Responsive Sites”, I actually mean “Responsive Home Page”. I’m only testing the home page of each domain, and am assuming the rest of the site is equally responsive or not.

Ratios Hold: 11-12% of sites are Responsive

Let’s get to the numbers.

At a high level, the results I’ve observed in the top 10,000 websites held in the top 100,000 as well. The following table & chart shows the ratio of RWD sites in different website tiers.

# RWD Sites, by Tier	Responsive	Non-Responsive	RWD Ratio
Top 100	10	85	10.5%
Top 1,000	115	842	12.0%
Top 10,000	1,048	8,414	11.1%
Top 100,000	10,510	82,326	11.3%

As you can see, the ratio holds quite well across the different tiers, although it’s a bit stronger in the top 1,000 websites. Roughly every 9^th site is marked as responsive, both on the hotetst sites and the long tail of the web.

Hmm… 85+10 = 100?!

The math geeks amongst you may have noticed a few of the numbers don’t add up. The Responsive & Non-Responsive counts sum up to less than the “Top X” number – for example in the top 100, we only account for 95 sites. In addition, the ratios are a bit different (by roughly 1%) than the results I shared last month.

Both of those deltas are due to the filtering of broken pages I mentioned above. In the top 100 sites, 5 sites were filtered. In the top 100,000, over 7,000 sites were filtered. If you’ve ever tested a bulk list of URLs, you’d know that’s a pretty common error rate. Since many error pages were marked as responsive, the RWD ratio actually dropped by roughly 1% once the data was cleaned up.

What does this mean?

This test implies Responsive Web Design is no more prevalent on the long tail than it is in the top sites. This may surprise some, since RWD is touted as – amongst other things – a lower cost way to tackle mobile, and so the adoption in the long tail could have been bigger.

In addition, it means there are over 10,000 responsive websites out there. Some people may think that’s slow progress for a 3.5-year-old concept, but I think it’s actually a pretty impressive reach. We don’t know how quickly we got to this point, but at least we can track its adoption going forward.

Roughly 1 in 8 websites is Responsive

Wed, 18 Dec 2013 13:29:58 +0000

I’ve been on a bit of a quest to find out how many responsive websites are out there. In a recent post, I describe a decent way to track the adoption rate of the “One Web” concept, but that technique doesn’t work well for tracking responsive design.

Now, I think I found the trick for automatically identifying a responsive site.

The trick: A Horizontal Scrollbar on a Small Screen

That’s it. A simple test, and in fact – as a designer friend of mine pointed out – a technique used for implementing responsiveness before media queries and the term RWD existed.

My proposition is that if you take a non-responsive website and load it in a small browser window, a horizontal scrollbar will show up. However, if the website is responsive, it will magically adjust to the display size, and a scrollbar will not be needed.

I tested this out on a bunch of sites manually, and my theory seemed to hold true. I opened my Chrome window, resized it to be 320pixels wide, and started loading known responsive websites, such as Boston Globe, Starbucks, and the recently responsive Bloomberg. No scroll bar appeared. I tried out various non-responsive websites (plenty of those around), and a scrollbar was always there.

And so, I went ahead and automated a test.

Testing The Test

I wrote a small piece of JavaScript that compares the window.innerWidth value to the scrollWidth of the top elements on the page. If scrollWidth was bigger– the site was marked as not responsive.

I then used WebPageTest’s exec script command to load up a bunch of sites and run this test on them. I used the websites tested by the HTTP Archive as my sample set, as it lists websites in order of popularity across the web.

As a test run, I loaded the top 200 websites on a 480px wide Chrome window and manually vetted the results (I also tried 320px, which produced similar results – more on that in a future post). The results weren’t perfect, but were quite good.

Out of 23 identified RWD sites, only myspace.com, which has an unusual horizontal design, was incorrectly marked as responsive (although reddit has a not very usable panel too). Even more impressive was the fact only one of the 176 sites marked as non-responsive was wrong (tumblr was the exception).

You can check out the screenshots yourself (warning: some sites produced very explicit and NSFW shots)– responsive here and non-responsive here.

The Full Test – 10,000 Websites

For the full test, I ran the same setup on the top 10,000 websites, loading them again in a 480px wide Chrome window. As is common, a portion of the tests failed (due to temporary errors or invalid URLs in the list), making the total number less than 10,000, but close enough.

The following table and chart show the number and ratio of responsive websites for the full list, as well as the top 100 and top 1,000 websites.

# RWD Sites, by Tier	Responsive	Non-Responsive	RWD Ratio
Top 100	11	89	11%
Top 1,000	126	874	12.6%
Top 10,000	1,129	8,102	12.2%

As you can see, the results are fairly consistent, ranging from 11% to 12.6% across the different tiers. Almost 8% of sites failed to load, which is not uncommon when using generic lists.

While I could manually verify 200 URLs, doing the same for 10,000 was a bit much… In addition to assuming the results would be as accurate as the first 200, I came up with one external way to vet my results.

Secondary Verification: Mobile Redirects

In the mentioned recent post, I identified all the Mobile HTTP Archive websites that redirected to a mobile site. Since responsive websites usually replace a mobile site, I would expect to see practically no overlap between the list of RWD sites and the list of sites that redirect to mobile.

Comparing the two lists, I indeed only found 25 websites that were marked as both redirecting to a mobile site and responsive. This is quite small – only 2% of all marked responsive sites sites. It’s also substantially smaller than the 20% portion of all websites that redirect to mobile. Therefore, I see this as another affirmation of the test results.

After manually reviewing the 25 sites, I found a few sites that were mistakenly marked, as well as a few sites that indeed were both responsive and redirected iPhones to mobile, like Scribd, or that had an iPhone specific redirect but not a mobile website, like Opera.

Summary

I’m pretty excited about this new find – both the technique and the data.

Regarding the technique, I feel it’ll be a good (even if not perfect) way to track Responsive Design adoption over time. The data I have so far suggest 95% or more of the sites marked as responsive are indeed responsive, making it accurate enough to use. Beyond tracking adoption, now that we’ve found these sites we can analyze them and find recurring patterns, test performance methodologies and much more – I already have quite a few additional tests on the go…

Regarding the data, I’m actually quite impressed. I was well aware RWD is gaining adoption, but frankly did not expect almost every 8^th site to be responsive! I am truly happy it’s getting such broad adoption, and a little freaked out at the performance implications of it, since very few responsive websites make the effort to be fast.

I’d love to get feedback on both data & technique, along with ideas for what to look into next with these new data sets. Please share your thoughts in the comments field or ping me on Twitter.

RWD and “One Web” Adoption Rates

Wed, 04 Dec 2013 21:48:50 +0000

Responsive Web Design has been discussed for about 3 years now, and this year really felt like the tipping point for it. Pretty much any organization I talked to is doing something about it, with progress ranging from a launched site, through a budgeted plan, to at least having some executive support.

And so, I wanted to find out how far we’ve come – how many websites have gone responsive?

Determining whether a website is responsive or not isn’t simple. Responsiveness is a property of a website, and so identifying a responsive website is not as simple as looking for a media query in its CSS. However, truly switching to responsive design implies adopting the “One Web” concept – meaning having a single website for both mobile and non-mobile devices. And that, luckily, is a much more measureable number.

Our Data Sources

Many of you know of the HTTP Archive (HA), which crawls the home pages of the top 250,000 websites on the web every 2 weeks, and inventories the results. This information is great in inspecting trends on the web, even if it’s a limited view of it.

What you may not know, is that the HTTP Archive has a baby sister –HTTP Archive Mobile (HAM). HAM runs a similar type of test, powered by the same HTTP Archive & WebPageTest software, but the tests are run from real iPhones, using the Mobitest agent code. Since it’s harder to scale these devices, HAM only crawls 5,000 home pages every 2 weeks.

Lastly, all of these results are stored on Google BigQuery, thanks to Ilya Grigorik. By using some Google docs / BigQuery integration, we can correlate data between the desktop results and the mobile results, and run those tests over time.

Test #1: Redirects on First Request

Each URL test in HA/HAM keeps track, amongst others, of which request was the first request on the page. This is almost always the request to the “/” path on the domain, and so the request isn’t interesting, but its response is.

For every first request, we can see if its response was a redirect. The following chart shows the percentage of sites that redirected the first request, for both mobile and desktop.

The chart clearly shows two things:

Many websites use redirects. Even on desktop that rate is 27%.
Practically half of websites redirect first requests on Mobile. A lot.

While informative, this chart is still missing data. Clearly websites redirect for more reasons than just mobile, so this view still doesn’t tell us how many redirects happen because of mobile. Which brings us to Test #2.

Test #2: Redirects on Mobile ONLY

Using HTTP Archive, we can correlate the HAM & HA results and see which URLs were redirected only on mobile. This means the website did not redirect first requests from Chrome, but did redirect first iPhone requests.

Here’s a pretty chart showing % of sites that redirect only on Mobile across all 5K HAM websites and only the top 100:

As you can see, indeed practically the full 20% gap we saw before is explained by mobile redirects. It appears that 19% of websites redirect to a mobile website while 81% do not. Looking at the top 100 websites, which are often more sophisticated, a grander 34% redirect on mobile only.

It’s worth noting that very few websites redirect only on desktop – less than 2%. And in fact, 90% of those sites were Google domains, redirecting Chrome to HTTPS (with SPDY) while letting iOS Safari remain on http.

So now we know that 81% of websites serve the same URL to desktop and mobile. However, that’s a far cry from saying 81% are responsive. Since, as mentioned above, it’s hard to tell which ones are responsive, we need to resort to other techniques.

Test #3: Mobile only redirects, over time

Since Responsive design is only 3 years old, one way to determine its adoption is to look at the rate of mobile only redirects across time. This approach assumes very few websites were responsive 2.5 years ago, when HAM started measuring, and so we should expect fewer redirects over time.

Here’s a chart showing the % of mobile-only redirects between September 1^st, 2012 and November 1^st, 2013, for the top 5,000 websites, measured by HAM:

As you can see the % of mobile redirect has barely changed over this year and a bit. It does go from 20% to 19%, but that seems to be within the regular variability of the data.

This is pretty disappointing. It hints to me that no substantial number of websites has dropped their mobile-only websites in favor of a one-web site. As mentioned before, it’s not a clear-cut statement about going responsive, but I see it as a decent indicator.

You may have noticed this data is only for 14 months, while HAM is actually tracking sites for almost 2.5 years. The challenge is that the number of websites HAM is tracking has changed, going from 1,000 sites in June of 2011, to 2,000 sites in November that same year, to the current 5,000 websites in September of 2012.

Here’s the chart showing the % of mobile redirects across that entire time period, along with a layover of the number of sites tested:

As you can see, the percentage of mobile-only redirects slightly decreases with each increase of the number of URLs. This matches what we’ve seen in test #2, where that number was far higher on the top 100 websites than across all 5,000. In addition, the % of redirects remains similar across each period of time with the same number of URLs.

Summary

It’s a bit hard to tell whether to be happy or sad about the 20% number. There are definitely some responsive website amongst the remaining 80%, and one can hope it’s a big number…

However, the lack of change over the last 14 months tells me that the so-called “Responsive Revolution” is not upon us yet. Not even close. In fact, it doesn’t look like there has been any real progress in mobile readiness over the last 14 months, with the % of mobile redirects neither increasing nor decreasing.

I pointed out multiple times during the post that this isn’t a perfect view on the adoption of responsive design. Some websites choose to make their dedicated mobile website responsive, while others may switch from having no mobile website to responsive. In addition, it’s possible that the number of websites going from mdot to responsive is roughly the same as those moving from no mobile website to having a mobile site.

Still, I find this metric to be an interesting one, and it does represent the adoption of the “One Web” concept. I plan to track it over time, and see how it evolves.

Top 5 Tips for Making Fast RWD Sites

Tue, 26 Nov 2013 15:30:22 +0000

I was recently asked to provide a list of 5 tips for making Responsive websites fast. I’m usually not a fan of such “top 5” lists, feeling they over-simplify concepts that are quite complex (I definitely spend a good chunk of my time talking about this topic). However, as I wrote the tips it actually felt like 5 was the perfect number for the tips I had in mind, and that they did manage to paint a complete picture.

And so, I figured it’s worthwhile sharing these tips on this blog as well. The tips are roughly in order of priority, based on my assessment of their criticality, except for the last one, which is really a wildcard.

Without further ado, here are the top 5 tips for making your RWD (Responsive Web Design) site FAST:

Avoid downloading hidden images by using a JavaScript-based or CSS-based image loading technique. Responsive websites primarily use style rules to hide images that don’t fit on the screen, by setting their style to “display:none”. However, hiding an image in this fashion does not prevent the browser from downloading it, resulting in a wasteful download of an image that won’t be shown. Since most responsive websites show significantly fewer images on smaller screens, this issue is the primary reason for the excessive page weight of responsive websites on mobile.
Download images appropriately sized to the relevant screen, a technique known as “Responsive Images“. Responsive websites usually display the same image file across all display sizes (assuming the image is not hidden). The display size of the image, however, is defined using a percentage, and thus smoothly adapts to the size of the screen. This technique, known as “Fluid Images“, is great visually, but once again creates waste in the amount of downloaded data.

A better solution is to create several versions of each image, resized on the server to the appropriate size, and download the one closest to the current display’s capabilities. Doing so will again require using a smarter image loader, like the one discussed in tip #1. Resizing the image on the server means the payload sent to the small screen is lighter, and thus the page is faster. Note that an alternate approach is to only store the “best” image on the server, but use services like Akamai’s Image Converter to resize it (on the Edge) in real-time.
Conditionally load JavaScript, and especially 3rd party JavaScript. Responsive websites often include JavaScript components that are not actually used on a small screen. Examples include Twitter streams, location maps, live agent widgets and many more. Like the image examples above, hiding the output of those images using styles does not prevent the browser from downloading and executing the scripts. While smaller in payload, scripts have a much bigger byte-for-byte impact on page load time, and 3rd party scripts can each be a single point of failure on a page.

Therefore, it’s best to wrap those scripts with a small, inline script that checks the device properties and only adds the scripts to the page if they will actually be needed, thus avoiding the unnecessary slow down and reliability risks. It’s important to do so with care, to avoid slowing down the large screen version of the site. For instance, where possible prefer dynamically adding elements to the Document Object Model (DOM) over using the “document.write()” function. Note that Conditional Loading can be applied to CSS as well, though doing so in a performant manner is harder to do.
Use RESS – REsponsive + Server Side – to optimize your site for known clients. Responsive design is a great tool for supporting many types of clients without even being aware of its existence, but – as demonstrated in the previous tips – it often leads to bloat and excessive downloads. Some of this bloat can be handled using smart loading, but other types – like excessive HTML – are much harder to deal with on the client.

For such issues, the only real solution is to introduce a server side component that identifies known and popular clients, and tunes the HTML accordingly for those clients alone. Other clients will get the responsive website, which should still work, even if it is not as fast. A good example of this is to trim the biggest “large screen only” portions of your HTML when identifying that a client is a known smartphone, often eliminating in the same stroke references to JavaScript and CSS files that won’t be needed.
Introduce performance testing into your QA or build process. At the end of the day, you can’t optimize what you can’t measure. If you want to become fast and stay fast, it’s important to introduce a performance test into your regular testing and quality assurance processes, and to do so as early as possible in the flow. Tools such as WebPageTest and many others make it very easy to add a simple performance test of key pages on your application, and run those tests from browsers resized to different viewport sizes and simulating different device pixel ratio (“Retina”) properties.

One simple starting point is to measure the performance of a given page on your site today 20 or 30 times, mark the median page load time as a baseline, and note the standard deviation. Now introduce the same performance measurement into your build process, and if the new median page load time in more than one standard deviation higher than the baseline, mark the build as broken. This will help you prevent your performance from degrading over time, and will now let you focus on making that baseline smaller.

That’s it. Clearly there’s a lot more to elaborate on for each one of these bullets, but hopefully these tips can help you put a strategy in place for making sure going responsive doesn’t mean going slow.

Walking on the Edge(s)

Thu, 19 Sep 2013 16:32:28 +0000

In the next 3 weeks, I’ll have the luxury of attending four awesome web conferences, two of which – somewhat unfortunately – are named Edge… I would highly recommend attending both conferences, but if you can’t make it, the Edge conferences are also streamed online for free!

EdgeConf

The first one is EdgeConf, taking place on September 23^rd (this coming Monday) in NYC. It’s real name is just Edge, but I’ll call it EdgeConf to disambiguate… This will be the second EdgeConf ever, and the first one in the US.

EdgeConf is an expert’s conference, organized by Andrew Betts from FTLabs. It’s made up completely from panels, each focused on one of the hottest topic in today’s web, and discussing the hardest – and often unsolved – problems they surface.

The audience is just as much a part of the conversation as the panelists, both before and during the session, and we want your help in getting the best questions. If you have a question you want discussed, please add it to our Google Moderator site. You can (and should!) also browse around the current questions and vote for the ones you care about the most.

The entire conference will be streamed live on http://edgeconf.com/ when it goes live.

Akamai Edge

The second Edge is Akamai Edge, which takes place on October 9-11 in Washington DC. This is the annual Akamai conference, and as such includes a lot of great content related to Akamai products and technology, as well as some great sharing from Akamai customers (often the top sites in the world).

This year, we’ve also added two subject matter tracks – The Developer Track and Security Symposium. The Developer Track takes place on Wednesday, October 9^th, starting at 1:30 Eastern Time, you can see the full agenda here.

We have four awesome presentations in the Developer Track:

1:30-2:10: Gene Kim will talk about DevOps and how it can help your business
2:20-3:00: Jason Grigsby will explain Responsive Web Design and its performance implications
3:30-4:10: Josh Clark will take us into the future, going beyond Mobile (he’s also taking us on two 5k runs during the conference…)
4:20-5:00: Geoff Moore would show how to shape our organization to tap into all of these opportunities.

The entire Developer Track is streamed live online from http://akamai.com/edge/. You can also tune in earlier (11:40 AM) to see Tom Leighton, Akamai’s Co-Founder and CEO, give a series of demos of recent Akamai tech – that session is always a crowd favorite.

The Security Symposium is made up of various panels with some great security experts, including Bruce Schneier. It will not be streamed live, but it is being recorded and will made available online shortly after.

If you’re in the DC area, and want to attend in person, you can buy a one-day pass for the conference. Use the code “Veloc2013” to get a 50% (!!!) discount.

And don’t forget Velocity NYC!

Although it’s not called Edge, I’d be remiss not to mention the first ever Velocity NYC conference, taking place the week after Akamai Edge – October 14-16.

We have an absolutely amazing lineup of speakers and topics, such as Lyza Gardner, Jason Grigsby, Ilya Grigorik, Tim Kadlec, Brian LeRoux and many, many more. We even got Steve Souders to give a full talk this time!

Beyond the “regular” web performance and mobile talks, we have some great talks from nearby realms, like having Will Law talk about Responsive Video and Dan Kaminsky talk about Security in a performance and operations world.

And if all of that’s not enough, the day after Velocity we will have another great WebPerfDays unconference, organized by Sergey Chernyshev. A great place to learn even more, and – more importantly – discuss and digest what’s going on in the web performance world today.

If you haven’t registered yet, you can use the code COMM20 to get a bit of extra discount.

That’s it – for this month…

Definitely an exciting month ahead, with two Edges, Velocity & Web Perf Days.

I hope to see you in at least one of those. If you can’t be there, I’d encourage you to tune in online to Akamai Edge, submit your questions to EdgeConf, and come join the conversation in WebPerfDays after Velocity.

Responsive Images Meetup – A Subjective Summary

Fri, 13 Sep 2013 19:03:57 +0000

Earlier this week I was at a W3C Responsive Images Community Group (RICG) meetup in Paris. It was a great opportunity to connect with smart folks, some of which I’ve never met before, and I had some great conversations, both as part of the agenda and over drinks.

For those who weren’t able to enjoy the Parisian views, this blog post holds my (not at all official) summary of what took place, plus my opinions of it. Flo also wrote a blog post with his summary, which I highly recommend. I suspect there will be more detailed and accurate reports coming from the W3C RICG.

A bit of background

If you haven’t been following the conversation, let’s start with a quick background on where things stand. This is a short (and again, subjective) summary, you can find the full details on the RICG website,.

The need for Responsive Images can be broken down into three use-cases:

DPR Switching: Serving higher res images only to devices with higher Device Pixel Ratio (aka Retina devices)
Viewport Switching: Serving smaller images to smaller or lower-resolution screens
Art Direction: Serving a different (often cropped) version of an image to a smaller screen, highlighting the important parts of a picture instead of just shrinking it.

Today, responsive images can only be achieved using JavaScript, CSS or server-side detection, which are harder to implement and have performance implications compared to regular img tags. The current efforts by the RICG aim to enhance HTML (or HTTP) to support responsive images without requiring such workarounds. However, there’s more than way to skin this cat…

Here are the primary not-mutually-exclusive alternatives on the table:

Picture: an HTML element similar to HTML5’s <video> tag, which uses media-queries to determine which image to load and is uber flexible.
srcset: An <img> tag attribute specifying different URLs to load for a given DPR and possibly resolution.
Client Hints: HTTP header(s) the browser would send, indicating the client’s DPR (and more), allowing the server to serve the correct image.

There are a few other proposals (like Yoav Weiss’s “Magical Image Format”) which have their own merits, but are not as far along.

Current Status

The first part of the meetup included presentations about real world usage of responsive images today, given by Mat Marquis (Filament Group), Mark McDonnell (BBC News) and myself (Akamai). While interesting, they reviewed the past and present and not the future, so I won’t discuss them further here. The next part of the meetup was dedicated to current status of each of the standardization proposals.

Right now, no browser supports any of these proposals, but there has been some progress in their implementation. There are JavaScript polyfills for picture and srcset, and code patches for Chrome & Firefox were written or are underway. Client Hints is a bit behind, but also has a Chrome Extension to simulate it and a Chrome “intent to implement”.

However, srcset has been getting more love than that. Both WebKit & Firefox implementations of srcset for DPR only (no viewport) are “almost ready”. The Apple rep there couldn’t confirm (or deny), but I got a strong sense that this feature will show up in Safari soon enough.

We also briefly discussed the Resource Priorities proposal, discussed in the W3C Web Perf working group, which suggests new “postpone” and “lazyload” attributes on various elements. Resource Priorities includes a way to avoid downloading hidden images, making it very complementary to srcset (which offers no such method). Note that Resource Priorities is only in draft mode, and has no implementations I’m aware of.

The Jaded “Implementer”

Amongst those who showed up for the meetup were members of the Chrome, Firefox, IE and iOS/WebKit teams, and I found it especially interesting to hear their perspective. Ted O’Connor & David Baron, from Apple and Firefox respectively, were particularly blunt in voicing a somewhat jaded perspective on anything that was proposed… Which was sometimes depressing but still good to have. Below are three concrete cases where such feedback was given.

The picture element was practically sneered at by the implementers. It was seen as a “kitchen sink” proposal, which tries to address every possible use-case for this specific need. This may sound appealing, but some needs are actually broader than responsive images, and should be addressed in a platform wide approach (like Resource Priorities). Other use-cases may be doable in other ways, and others still are simply not important enough to modify HTML for.

When discussing the use of media queries for determining which resource to load, whether as part of the picture element or not, there was… some unease from the browser folks. Media queries are more complex to evaluate, and thus would require more CPU; they can’t always be evaluated by the preprocessor (think about viewport width in an iframe); and they may be enhanced in the future in ways that would be even harder to process. Unlike picture, though, I didn’t feel like using media queries was entirely dismissed. If there’s enough push and value, I think browsers may agree to take this path.

Lastly, on Client-hints, there was push back against adding headers. One explicit statement was that “while we (browser implementers) aren’t saying we’ll never add new headers, we’re only one step away from that”. They pointed out that while some header-based content negotiation techniques worked in the past (e.g. Accept-Encoding), many failed (e.g. Accept-Language, Accept-Charset), leaving a sense that this is a wrong approach. Personally, I don’t think past failures are a reason not to try again, and feel like an opt-in mechanism for Client Hints would mitigate much of the concern.

Srcset – the most likely path

As open as the discussion was, at the end of the day these decisions are at the mercy of the browser implementers. And the implementers like srcset, and have actually been implementing it (as implementers often do). And so, it seems pretty clear that srcset will happen.

DPR support in srcset is likely to start showing up very soon. However, the extended srcset spec, which includes viewport sizes, is not a foregone conclusion. The main problem lies with the hard-to-parse micro-syntax used in srcset, used to describe permutations of viewport dimensions and DPRs. For example, consider this img tag:

<img src=”a.jpg”
     srcset="b.jpg 400w 2x, b.jpg 800w 1x, c.jpg 600h 2x">

This small example demonstrates multiple problems:

The format isn’t easily readable. You need to know, for instance, that the specified dimensions indicate the “max” dimensions (e.g. a screen 400px wide or less, with a DPR of 2x or less), and not a “min” dimension.
There is no way to modify the definition to be a “min” dimension, which conflicts with how “mobile first” media queries are written.
The format requires repetition of URLs. In this case, b.jpg was created for screens that are 800px wide. This includes both a 400w/2x screen and an 800w/1x screen. Long URLs and multiple permutations can really make the attribute long.
The mix of height and width create ambiguity. For instance, if a 2x device was 400×600, should it load b.jpg or c.jpg? The algorithm dictates what to do, but it’s not at all intuitive.
The resolution is always specified in pixels (implied), not supporting large font sizes or zoomed in views.

This conversation was, in my opinion, the most productive one in the meetup, and came up with a few conclusions that most people agreed with:

For #1, we’ll just deal with it through education. It’s not brain surgery.
For #2, again, we’ll just deal with it. You can still describe the same conditions, albeit by using funky numbers like 3.99.
For #3, we discussed supporting OR conditions, but eventually dropped it. We don’t want to over complicate the format, and gzip compresses repetitions very well anyway. We also discussed using media queries, but – as mentioned above – that didn’t go over well.
For #4, everybody agreed we should drop “h”, but keep “w”. This makes the ambiguity go away, and nobody could figure out a strong need for “h” anyway.
For #5, we could support other resolution units, but there wasn’t much discussion about it.

One important clarification is that srcset is a recommendation, not a rule. This means a browser can choose to download a 1x image despite being on a 2x display. It may do so to preserve battery life, reduce bandwidth, accelerate the page, and may do so automatically or based on user preferences. This is different than media queries, which the browser must obey.

This flexibility means all images in a srcset should hold the same image, differing in quality only, since you can’t be certain which one the browser would load. This, in turn, means srcset cannot be used for Art Direction – which gets me to the next topic…

Not heading in the Art Direction

Some of the conversation was around priorities. Pretty much everybody agreed that the top priority was addressing high DPR (Retina) displays, and most agreed that handling smaller viewports was a close second. However, there was a strong lack of conviction about the Art Direction use-case.

The most common use-case for Art Direction is cropping – only showing a portion of an image on a smaller screen. Cropping can be achieved by serving a different image, but it can also be achieved with CSS overlays, showing only a portion of the downloaded image. This approach means you’ve downloaded wasted bytes, but if the image is already adjusted to the client’s resolution, it’s unclear just how much you’d save with server-side cropping.

For the use-case of showing different images in different viewports, you would need to stick to JavaScript or CSS. The sense in the room was that this is not a strong enough use-case to justify modifying HTML for it.

At some point I suggested adding an optional marker (in a separate attribute or in the micro-syntax) that forces the browser to respect srcset – let’s call it the strict marker for now. The strict marker would allow us to serve different images to different devices, including art direction needs. The image we serve would need to cover all the viewports in this device (e.g. landscape & portrait), but that’s still smaller than the full image in many cases. We debated this a bit, but didn’t reach any final conclusion.

Personal Perspective

While the conversation was very interesting, we didn’t really change the direction much… Browsers will stay on course implementing DPR for srcset (likely to show up soon), and my expectation is that they’ll add support for viewport width shortly after.

Personally, I arrived at the meetup favoring picture, but left it favoring srcset… assuming we add viewport and the strict marker, and that we implement Resource Priorities. With that combination, I believe we tackle the main performance needs: serve low res images to low res devices (srcset); avoid excessive client-side cropping (strict); and avoid downloading hidden images (Resource Priorities). I think it’ll be nice if we also added support for non-pixel viewport definitions.

I still think there’s room for Client Hints, especially if you want your images optimized through an automated tool, like Akamai’s FEO or Pagespeed. In addition, Client Hints is useful for more than just responsive images, and we need to judge it based on its complete value, not a specific hint.

All in all, I found the meetup very educational, and – while they were somewhat antagonistic – I saw a fair bit of merit in the implementer remarks. Hopefully you find this summary useful as well.

What are Responsive Websites made of?

Mon, 29 Apr 2013 18:28:58 +0000

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.

RWD Page Size

The average size of an RWD site ranged from 1,187 KB on the largest screen to 1,093 KB on the smallest one. The next chart shows those page sizes split into the four primary content types mentioned above, plus an “other” category to capture the rest.

As you can see, the overall size doesn’t change much, which was the point I made in the previous post, so I won’t fret over it too much now. However, the chart captures some new interesting tidbits, which I’ll go over in the next few sections.

It’s worth noting that while I’m only digging into 2013 data here, most of the observations seem to hold true for the data I collected in 2012.

Images make up the vast majority of bytes

As expected, and matching the trend we see across all websites, images make up the bulk of the bytes. Images account for about 6x the average weight of JavaScript files, and 9x that of CSS.

Images are also consistently the biggest component on a page, regardless of screen size. This implies optimizations like Responsive Images, which deliver smaller images to smaller screens, are not being applied.

Only images are optimized to screen size

Across resolutions, the only resource type that truly changes in size across resolutions is image. CSS, HTML, JavaScript and the (tiny amount of) HTML all stay the same across resolutions.

I see this as an obvious sign of inefficiency. Consider the complexity of the “mobile” view (on most RWD sites) compared to that of their “desktop” view. In many cases, the number of interactions or widgets on the page is much smaller, and yet the same amount of HTML, JS & CSS is delivered (and processed) to all screen sizes.

Clearly images are not optimized well enough either, as mentioned in the previous section, and given their size images are probably still the first thing to optimize. However, compared to other resource types, images are miles ahead.

RWD sites are “lighter” than regular desktop websites

Even on the largest resolution, the average page weight in this test suite is ~1.2 MB. This is quite small compared to the overall ~1.4MB average page size, and almost on par with the average home page size of the top 100 websites.

Given the performance issues on the smaller screen, I wouldn’t claim RWD developers are more performance aware than average. However, RWD does force you to think about what’s really needed on your page, which can lead to less clutter on the page – and thus fewer bytes.

And of course there is the possibility the sites inventoried by http://mediaqueri.es/ are not representative enough to compare to the bigger list of websites HTTP Archive tracks. Until we have more known RWD sites we don’t have much we can do about this concern, except take some of the comparisons with a grain of salt.

RWD sites use less JS and more CSS than average

Somewhat surprisingly, only ~10.5% of page bytes (on average) came from JS files, compared to ~15% on websites in general. The gap sounds even bigger in absolute numbers – an average RWD site uses ~120KB of JS instead of the overall average of ~220KB. This may again be attributed to the more minimalist design, or perhaps the need to make these sites work across more old mobile browsers – thus relying less on JavaScript.

However, RWD sites compensate for that with CSS weight, which accounted for 7.5% of RWD site page bytes, compared to 2.5% or less on websites overall. Despite being smaller overall, the average RWD site packs 85KB compared to the 36KB an average website uses – roughly 2.5x more. This part is not surprising at all, as much of RWD relies on CSS, and browser compatibility often requires duplicating CSS content, but it seems to be an area to improve in.

Comparing Requests

Since performance is made up of more than just byte download, this second chart outlines the average number of requests per resolution, again split by content type.

This chart mostly reinforces the insights I mentioned above:

Total number of requests doesn’t change much across resolutions
Images make up the majority of requests, by a large margin (though not quite as large as the gap in bytes)
Average total number of requests – roughly 41 – is quite low compared to the overall average of 91.
Total number of JS requests is almost half the average number

Unlike what we’ve seen with bytes, even the number of CSS requests is lower than the overall average of 5, though higher than the top 100 average of 2.7. In other words, RWD sites seem to have bigger CSS files, not more of them.

Seeing that the average RWD site uses only 41 requests is encouraging, though it could also imply complex websites don’t feel like RWD is a valid option for them. Another explanation could be that current RWD implementers are – on average – better developers & designers. RWD is still a new trend, and talented teams are more likely to be early adopters, making today’s numbers better than what they’ll be in the future.

Image Optimization – Requests vs. Bytes

RWD image optimization focuses on two main areas:

Not downloading hidden images
Downloading smaller images on smaller screens

I was curious to see if websites implement one of these more than the other. To check if that’s the case, I plotted the number of image bytes and image requests side by side, across the different window sizes.

You’d notice the two lines are quite cleanly aligned. This indicates (though it’s hardly scientific proof) that both optimization aspects are equally popular – though calling either popular is a stretch, as most websites don’t apply either.

I would suspect most RWD sites either optimize images or not, but if they do – they optimize both aspects. Helping this theory is the fact most responsive images tools, like PictureFill, also implicitly avoid handling hidden images.

Summary

This data gives us some good further insight into the state of RWD websites today. We can now say that:

The push for using responsive images is reaping some fruit. There’s still plenty of work to do before we’re in a good spot, but we’re making progress.
**Pretty much all other aspects of RWD websites, are not optimized **to screen size. We should further evangelize serving just the right amount of HTML, JS and CSS to clients, and build supporting tools.
It’s possible that RWD naturally helps reduce clutter and thus make web pages leaner. While not a factual statement, the data we currently have points

Remember that these conclusions, and for that fact all of these data, refer to the state of RWD today. It doesn’t mean responsive websites always behave this way, it just indicates what is actually happening in implementations today. I’ll keep tracking them, to help point out how we’re doing, and where we should focus our attention next.

iOS Browsers Speed Bakeoff

Wed, 17 Apr 2013 13:12:05 +0000

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.

TL; DR;

Here’s a quick summary of the bottom line results.

Overall, Mobile Safari showed to be 18% faster than UIWebView on average. This is a respectable difference, but nowhere near the 3x difference in JavaScript benchmark results. The networking improvements included in Chrome for iOS narrowed this gap, making Chrome only 7% slower than Mobile Safari on average. Despite the small gap, Mobile Safari was consistently faster. It beat UIWebView on 88% of websites and Chrome on 72% of websites – though often by a small margin.

Network conditions significantly impacted the results. On a fast 4G connection, Mobile Safari’s lead grew to 33% faster than UIWebView and 18% faster than Chrome. A similar difference would probably be seen on a good WiFi connection. On the other hand, on a 2-bar 3G connection Mobile Safari was only 2% faster than UIWebView, and it was 2% slower than Chrome. On the average network tier (3G, 5 bars), Chrome beat Safari on 58% of websites, by an average of 5%.

A few key takeaways from these results are:

There is a real, quantifiable difference between Mobile Safari and UIWebView-based browsers.
However, in real world cellular network conditions, the difference between the browsers on iOS is not huge.
The networking layer in Chrome makes a real difference, especially in less than ideal network conditions.
The small delta implies using UIWebView-based tools, such as Adobe Shadow, Mobitest, and MIHTool, maintains a decent approximation for the performance Mobile Safari would show, especially under average or poor network conditions.

Short history lesson

About 2 years ago, as part of iOS 4.3, Apple introduced some major improvements to its native browser, Mobile Safari. The most well known improvement was Nitro, an improved JavaScript engine that performs Just-In-Time compilation, making JS dramatically faster.

Unfortunately, apps did not benefit from these improvements. Apple did not include Nitro (and other optimizations) in its embedded browser, UIWebView. Apple stated this was due to security concerns, while others voiced conspiracy theories about Apple crippling HTML5 apps.

Whatever the reason, the embedded and native browsers were not equals, and are still not equal today. When Blaze, my previous company, compared browser performance between iOS and Android, Apple even explicitly stated that the embedded browser does not represent the native browser, due to these missing optimizations.

What the Benchmarks said

Based on benchmarks, the impact is dramatic. JavaScript Benchmark such as SunSpider are 3x faster on MobileSafari compared to UIWebView, implying that browsing a page inside your Twitter or Yelp app would be painfully slow.

Real websites, however, are not benchmarks. We already know that hardware improvements impact benchmarks more than page load times, and can expect the same to be true in this case. In addition, cellular performance isn’t all that great, and if the network is the bottleneck, browser differences may have less of an impact.

Luckily, we’re now able to test these expectations using Appurify, and compare actual load times of real web pages on the different browsers. Let’s get to the results.

Comparing Averages

On average, Mobile Safari was just a little bit faster. When averaging all network speeds, it was 18% faster than UIWebView and 7% faster than Chrome for iOS.

When comparing MobileSafari with UIWebView, there was a clear trend – the slower the network, the smaller the gap. Safari’s lead went from 33% to 12% to 2% as network speeds decreased. This makes sense to me – as the network gets slower, the bottleneck becomes mostly moving bits up and down, and optimizations like a faster JavaScript engine don’t help as much.

The comparison with Chrome for iOS was a bit murkier. Mobile Safari was 18% faster on the 4G network, but it was 5% slower under the 3G 5 bars conditions. The most likely explanation is that Chrome’s touted network layer shines under such conditions. When looking at the poor network conditions case, the delta shrunk, but Chrome was still 2% faster than Mobile Safari.

How did Mobile Safari compare to other browsers?

Mobile Safari vs…	4G Speed	3G, 5 Bars	3G, 2 Bars
UIWebView	33% Faster	12% Faster	2% Faster
Chrome for iOS	18% Faster	5% Slower	2% Slower

Safari Consistently Faster

Mobile Safari also outdid the other browsers in the vast majority of tested URLs. Compared to UIWebView, mobile safari was faster in roughly 4 out of 5 sites in the top two speeds, and 3 out of five in the poor network test.

On the top network speed, Mobile Safari also beat Chrome in 80% of cases. However, repeating what we’ve seen in the averages, Chrome did better under worse conditions, and was faster on 58% of websites in both the middle and bottom network speeds, even if the win was usually by a very small margin.

On how many websites was Mobile Safari faster?

Mobile Safari vs.	4G Speed	3G, 5 Bars	3G, 2 Bars
UIWebView	86%	79%	58%
Chrome for iOS	80%	42%	42%

How often did it really matter?

Realistically, a 1-2% difference matters very little. If Safari was consistently 2% faster than Chrome, few would call it a faster browser. So, I took a look at how often was the gap between the browsers significant, defined as a 10% or bigger load time delta.

Compared to UIWebView, Safari was much faster when the network was good. An impressive 70% of websites loaded significantly faster on Safari, usually by a gap of 20% or more. Safari was often much faster on a good 3G connection too, but on a bad connection the delta was harder to notice.

When comparing to Chrome, the results repeated the previous pattern. On a good connection, Safari was significantly faster on 60% of websites. That stat dropped to 10% on average conditions, and climbed back to 23% on poor network speeds.

On how many websites was Mobile Safari significantly (10%+) faster?

Mobile Safari vs	4G Speed	3G, 5 Bars	3G, 2 Bars
UIWebView	70%	39%	17%
Chrome for iOS	60%	10%	23%

On the flip side, Chrome also beat Safari by a large margin in a decent number of cases – 29% under poor conditions, and 16% under average conditions. Under good conditions, only 10% of websites loaded much faster on Chrome.

UIWebView beat Safari by a significant difference in less than 10% of tested sites, less affected by network speed.

On how many websites was Mobile Safari significantly (10%+) slower?

Mobile Safari vs	4G Speed	3G, 5 Bars	3G, 2 Bars
UIWebView	8%	7%	9%
Chrome for iOS	10%	16%	29%

Conclusions

My first conclusion is that the delta between UIWebView and Safari is smaller than I thought. Especially under less ideal network conditions, which is when users feel the most pain, UIWebView and Mobile Safari don’t differ much.

Being a big advocate for speed, though, my second takeaway is that this difference is still real and interesting. Especially under good conditions, Mobile Safari is truly faster. This means I still wish Apple would put Nitro and the other optimizations into UIWebView, and believe users would appreciate that.

My third takeaway, and the one I was most surprised to see, is how big of an impact the Chrome networking layer made. Chrome for iOS, despite being built around UIWebView, managed to significantly shrink the gap with Safari – and even beat it often enough. While I can’t say Chrome for iOS is faster than Safari, these numbers make it hard to say it’s slower. This is doubly impressive when you consider this test doesn’t capture some of the predictive optimizations Chrome employs when repeatedly used by real users.

My last conclusion is that the difference is small enough to feel comfortable using UIWebView based tooling. The world of Mobile painfully needs more tools for debugging and testing websites, and these tools only have UIWebView available to them.

Given the results of this study, I believe the browser performance in tools like Adobe Shadow, Mobitest, MIHTool and others is a close enough approximation of Mobile Safari to safely use. This is especially true in poor network conditions, and mostly true in average scenarios, which are the cases where performance matters the most.

Before signing off, I’d like to give another shout out to Appurify, for providing the technology needed to run these tests. They look like a very promising startup, and their platform makes previously complex test cases very feasible. I’d strongly encourage anyone dealing with Mobile to give them a try.

Appendix: Detailed Testing Methodology

As always, I try to be completely open about how I ran my tests. There is no such thing as a perfect test, but by sharing the details you can see any possible bias and use your own judgment on whether you should trust the results or not.

Using Appurify, I measured the page load times of the top 500 websites in the US (per Alexa) with each of three main iOS browsers (Mobile Safari, UIWebView and Chrome for iOS) under three different simulated cellular network speeds (3G 2-bars, 3G 5-bars, 4G LTE). All tests were run using an iPhone 5 running iOS 6.1.2, and were run in portrait mode from San Francisco.

The test flow was as follows:

For each network speed - For each URL - For each browser - Load the browser with an initial test URL (to avoid capturing app load time)
Load the URL being tested (start the timer)
Poll the browser every ~30ms to see if it completed loading
Once the page is loaded, stop the timer and log the time.
Navigate to the test URL again, clean all caches, cookies, history, etc
Exit the browser

For each browser, each URL was loaded 7 times, and I used the median load time of those for subsequent calculations. Note that the 30ms interval isn’t always perfect, as timers may invoke a few milliseconds later than planned.

Once I had the per browser data, it seemed obvious that sometimes the browsers did not load the same page. The most common reason was that the page was broken on one or both of the non-safari browsers. Page Size was a pretty good indicator of whether the same page was loaded on multiple browsers, so I only used the URLs where the page size was similar (within a 10%) across all browsers.

The odd broken tests and these filters reduced the dataset to 318 URLs. Furthermore, all the averages mentioned above are calculated while ignoring outliers – the top 5% of tests. Without ignoring outliers, a handful of timeouts and extreme cases threw off the numbers. After ignoring the outliers, the median and averages were very close to each other, and could almost be used interchangeably.

Note that when I compared sites across network conditions, I used the average page load time on each browser (across network speeds), and compared them to each other. This means if a site was much faster under a certain network speed, and a bit slower in other two, it may still be marked as faster overall. This approach isn’t more or less accurate than another, but it’s still worth clarifying.

The last detail to share is the exact network speeds used in this study. I throttled network speeds down to maintain a consistent speed for benchmarking, and used the network speeds that Appurify classifies as Verizon’s averages in different conditions (for San Francisco). Here are the technical details about those speeds:

3G, 2 Bars: 193/100 Kbps down/up, 331ms latency
3G, 5 Bars: 902/712 Kbps down/up, 150ms latency
4G, 5 Bars: 6.8/4.9 Mbps down/up, 29ms latency

If you’re interested in the raw data (they’re slightly complex), you can download it here.

Introducing LQIP – Low Quality Image Placeholders

Tue, 02 Apr 2013 21:18:52 +0000

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.

Core Concept

LQIP’s logic is simple. In a sense, this is like loading progressive JPEGs, except it’s page wide. There are more implementation details below, but it boils down to two main steps:

Initially load the page with low quality images
Once the page loaded (e.g. in the onload event), replace them with the full quality images

LQIP gives us the best of both worlds. On a slow connection, the user will load a fully usable page much faster, giving them a significantly better user experience. On a fast connection, the extra download of the low quality images – or the delay of the high quality ones – does not lead to a substantial delay. In fact, even on the fast connection the user will get a usable page faster, and they’ll get the full rich visuals a moment later.

Real World Example

Here’s an example of the Etsy homepage loaded with and without LQIP. Note that Etsy isn’t actually applying this optimization – I made a static copy of their homepage and applied the optimization to it using Akamai FEO.

On a DSL connection speed, LQIP boosted the page visual by about 500ms (~20%), while on FIOS it was only 100ms faster (10%). This acceleration came from the fact the overall page weight dropped from ~480KB to ~400KB thanks to the lower quality images. All in all, not bad numbers for a single optimization – especially on a highly optimized web page like Etsy’s home page.

DSL Connection, Without LQIP (above) vs. With LQIP (below)

FIOS Connection, Without LQIP (above) vs. With LQIP (below)

The faster visual isn’t the whole story, though. The LQIP page you see actually uses lower quality images than the other. While the LQIP page weighs 80KB less before onload, it weighs 40KB more by the time the full quality images were downloaded. However, the page is definitely usable with the low quality images, keeping the user from idly waiting for the bigger download. You can see an example of a regular and low quality image in the table below – I didn’t turn quality down too far.

Image Before LQIP (15.6 KB)	Image After LQIP (5.2 KB)

It’s just intelligent delivery

LQIP also helps on the political front, by bridging the gap between IT/Dev and the designers.

The designers are happy because their full-quality images are showed to the user, unmodified. Sure, the images are a bit delayed, but the end result will usually show up within a few seconds, and their handiwork would remain unharmed.

IT is happy because they deliver a fast page to their users, even on slow connections. The low quality images may just be placeholders, but (assuming quality wasn’t too drastically reduced) the page is fully usable long before the full images arrive.

Implementation Tips

LQIP implementation includes three parts:

Prepare the low quality images (server-side)
Load the low quality images (client-side)
Load the high quality images (client-side)

Step #1 varies greatly by your system. You can create the images in your CMS systems, duplicate them in your build system, or adjust quality in real-time using tools like Akamai Edge Image Manipulation.

Step #2 is simple – just load the images. You can do so with simple img tags, CSS, or using your favorite scripted image loader. If you use small enough images, you can even inline images (matches Ilya’s recommendations). In Akamai, we use LQIP in combination with loading images on-demand, reducing the number of requests as well.

Step #3 is where a new script probably comes in. A simple flow would be:

Create a JS function that iterates the IMG tags on the page, and for each: 1. Determines the full quality image URL (using a naming convention or an extra attribute on the IMG tag)
Modifies the SRC attribute to point to this full URL (will reload the image)
Call your JS function in the onload event

If you want to get fancy, you can load the high quality image in a hidden IMG tag, and then swap the low quality image with it at the onload event. This will prevent the low quality image from disappearing before the full quality image is fully downloaded, which can hinder the user experience.

Lastly, if you use CSS to load your images, you can also swap the low quality images for higher quality images by loading/applying a new CSS.

Summary

I’m pretty excited about LQIP.

It helps bridge the gap between two conflicting and growing needs, would work on old and new browsers alike, and is (relatively) easy to implement. It’s a “perceived performance” optimization, which is how we should all be thinking – and I believe it’s an optimization everybody should apply.