All posts by Andy Favell

dna46t_bbc_pagespeedtest.png

How JavaScript impacts page loading speed on mobile

The effect of JavaScript on mobile web performance is twofold.

One, it is the second largest contributor to webpage weight, behind images, thereby increasing download time; and two, once downloaded, the browser then needs to run the script, which can delay the downloading/rendering of other (perhaps more important) assets on the page.

JavaScript (aka scripts or JS) is one of the triumvirate of technologies that make web pages (and web apps) work. The HTML (Hypertext Markup Language) controls the structure and content of the webpage; CSS (Cascade Styling Sheets) controls how the site looks on different devices; and JavaScript makes the page more interactive and dynamic.

Scripts perform numerous functions on webpages such as loading ads, A/B testing, tag management (personalizing the page) or displaying an inline video player.

Over the last five years, the total weight of pages sent to mobile devices has quadrupled to 2.2MB. Size matters because, in general, the more data that is sent over a mobile, or fixed, network the longer a page will take to load. More data, more seconds staring at an empty mobile screen.

This suggests that images – which tend to take up more of the total kilobytes (KB) or megabytes (MB) of each page – are the main culprit. But this is not always the case.

JavaScript could potentially have more of an impact on page performance than images. As Patrick Meenan, founder of the web performance testing site WebPageTest and software engineer at Google, explains:

“Scripts are usually a (bigger) issue because of the time it takes to actually execute the script in addition to the download size, while images really only matter because of the download size. With mobile devices for example, it can take several seconds to run a script even after it has been downloaded.” 

It’s not necessarily JavaScript, per se, that is the problem, but how it is implemented: scripts can monopolize browser activity, blocking the download and rendering (displaying) of other content.

“The problems are often compounded where the script is referenced in the page. The content after a ‘blocking’ script (as opposed to an async script) doesn’t exist, as far as the browser is concerned, until after the script has been downloaded and executed. When, as is commonly the case, scripts are put at the beginning of the page this means that the page will be completely blank until the scripts have downloaded and executed.”

We will discuss below the difference between blocking, inline, synchronous (sync), asynchronous (async) and deferred scripts and how to fix JavaScript problems, but first we’ll look at how to spot issues.

Testing for blocking JavaScript

If you have tested your webpages using Google PageSpeed Insights (N.B. you should regularly test your mobile webpages using tools such as WebPageTest and PageSpeed Insights), chances are you have seen the following warning:

! Should Fix:

Eliminate render-blocking JavaScript and CSS in above-the-fold content

Your page has 8 blocking script resources and 7 blocking CSS resources. This causes a delay in rendering your page.

None of the above-the-fold content on your page could be rendered without waiting for the following resources to load. Try to defer or asynchronously load blocking resources, or inline the critical portions of those resources directly in the HTML.

The text and image above is from a Mobile PageSpeed Insights test on BBC.com conducted in February 2017.

Note “above the fold” refers only to the part of the webpage which is visible on a mobile device, without scrolling, Google is not analyzing scripts on the rest of the page.

The BBC is the world’s most popular English language news website, according to Alexa, so to put it in context we should also test the others in the top four. The results suggests two more publishers have similar issues with JavaScript. (The test also highlights CSS issues, but this is not the focus of the article):

  1. BBC.com PageSpeed test (8 blocking scripts; 7 blocking CSS resources)
  2. NYTimes.com PageSpeed test (0 blocking scripts)
  3. ESPN.com PageSpeed test (2 blocking scripts; 3 blocking CSS resources)
  4. CNN.com PageSpeed test (6 blocking scripts; 2 blocking CSS resources)

4x growth in JavaScript use in five years

Over the last five years the amount of JavaScript used on the average mobile page has almost quadrupled from 101KB in February 2012 to 387KB in February 2017. The number of requests (a request is the number of times a browser is required to download an additional piece of content or code) for different JavaScript files has increased from 8 to 21.

This is clearly illustrated in the graph below from HTTP Archive. HTTP Archive tests the top 1 million sites several times every month using data from WebPageTest, and publishes trends and stats that are essential benchmarking for the performance of your site.

How JavaScript impacts page loading speed on mobileFor the top 1 million sites monitored by HTTP Archive, JavaScript accounts for 17.4% of page weight. JavaScript also accounts for 21 out of 93 total requests (22.6%).

For some sites, particularly in the news space, JavaScript has a considerably larger share of page weight than the norm.

The image below compares the breakdown by content type for the average site with BBC.com tested by HTTP Archive (15 February 2017):

  • The first thing to note is how impressively small the BBC page size is: 609KB v 2225KB.
  • The second thing to note is how small the combined size of the BBC images: 70KB v 1501KB.
  • The third thing to note is how proportionally large the scripts are: 458KB or 75.2% of total page size.
  • The fourth thing to note (not shown in the charts below) is that 39 (44.3%) of the BBC’s total 88 requests are scripts.

How JavaScript impacts page loading speed on mobile

When you compare the test results of the top four English language news websites, it is remarkable how much smaller the BBC is than its rivals. It is a one-third to a half of the size, with two to three times less JavaScript.

  1. BBC.com tested by HTTP Archive: Scripts 458KB (75.2%) of 609KB of total data; 39 JS requests (44.3%) of 167 88 total requests.
  2. NYTimes.com HTTP Archive test: Scripts 1511KB (51%) of 2953KB of total data; 73 JS requests (43.7%) of 167 total requests. (N.B. NY Times has a dedicated mobile site at mobile.nytimes.com, which is not listed by HTTP Archive, which may deliver different results.)
  3. ESPN.com HTTP Archive test: Scripts 1183KB (65.7%) of 1802KB of total data; 50 JS requests (47.2%) of 106 total requests.
  4. CNN.com HTTP Archive test: Scripts 1484KB (68%) of 2182KB of total data; 67 JS requests (31.9%) of 210 total requests.

What is the effect on mobile page speed?

So does it follow that the slim-line BBC site would load much faster than all its rivals?

Err, no. On 15 February 2017, HTTP Archive recorded the following load times:

  1. BBC.com: 18.3 seconds
  2. NYTimes.com: 27.4 seconds
  3. ESPN.com: 8.8 seconds
  4. CNN.com: 31.5 seconds

So, the BBC is faster loading on a mobile device than CNN and the New York Times, but considerably slower than the (larger) ESPN.

This is what the two sites look like on a mobile device. (The filmstrip is one of WebPageTest’s most visually compelling features, easily understood by any non-techie). Each frame represents 1 second. When the HTTP Archive test took place, for 9 seconds BBC.com mobile visitors saw nothing, while for 4 seconds ESPN visitors saw nothing.How JavaScript impacts page loading speed on mobile

There could be many reasons why one website might be faster than another, such as server response times, use of content delivery networks (CDN), the impact of ad networks, inclusion of third-party data (common on news sites), or the time and place of the test (in this case California, USA).

However, all other things being equal, it is possible that JavaScript could be a contributing factor. (Apologies for the hedging of bets). As noted above, BBC.com did receive more warnings for blocking scripts above the fold than the other news sites.

Reducing reliance on JavaScript

JavaScript is often used to perform tasks that cannot (easily) be done with HTML or CSS. As the W3C gradually add these features to the HTML or CSS standards and they are implemented by browsers, the JavaScript patch is no longer needed, as HTML/CSS is likely to be more efficient. A good example of this is responsive images.

Alex Painter, Web Performance Consultant at NCC Group:

“As a rule, it’s worth sticking to the principle of progressive enhancement – delivering a site that works without JavaScript and using scripts only for those extra features that can’t be done any other way.

“Using JavaScript to render content can be expensive – it takes time to load and execute. So, for example, if you can use HTML and CSS to achieve the same result, that’s generally going to be faster.

 “When it comes to responsive images, for example, you can use media queries in CSS and picture/srcset in the HTML to deliver the right image for the viewport without having rely on JavaScript.”

Choose asynchronous and deferred JavaScript over blocking and inline scripts

There are a number of ways that JavaScript can be implemented on a webpage, including:

  1. Blocking scripts are synchronous which means they have to be dealt with immediately and ahead of anything else. By default, all JavaScript is parser blocking. As the browser does not know what the script will do to the page, as soon as it meets a request (in the HTML file) to download a JavaScript file, it stops building the webpage, and does not continue until the file is downloaded and executed.
  1. Inline scripts also stop the page build, but as they are included in the HTML, they do not need to be individually downloaded. However too large or too many inline scripts will bloat and delay the initial download of HTML file.
  1. Asynchronous scripts allows the browser to continue parsing (analyzing the code and building the webpage), while the JavaScript file is downloaded. Including the async attribute in the HTML tells the browser that it doesn’t need to put everything on hold.
  1. Deferred JavaScript – tells the browser to leave the execution of the JS file until after it has finished building the webpage, this is signified with the defer attribute.

Are blocking scripts ever justified?

Patrick Meenan:

“If the site functionality relies on the code, then it needs to be run as a blocking script so that it is ready before the page needs it. A very common case for this is tag managers and A/B testing platforms where the code will change the page. In other cases blocking is used when it will be more work to load the functionality asynchronously.”

Reducing size of JavaScript files

How big is too big? How many requests is too many?

This will always be a balancing act.

Patrick Meenan:

“Since the browser will only load six requests at a time for each domain, if you have more than that it needs to request the rest after the first ones have completed, leading to longer times from the request/response delays.

 “Larger JavaScript files also take longer to parse and run (1ms for every 1KB of uncompressed JS is a reasonable estimate).  All else being equal, if you have the same amount of JS in a lot of files it will take much longer to load than if the same amount of JS was in a single file.”

Google recommends minification of JavaScript files using UglifyJS or Closure Compiler.

For more on how to optimize the speed of your mobile site, check out our previous three-part series:

Andy Favell is Search Engine Watch’s columnist on mobile. He is a London-based freelance mobile/digital consultant, journalist and web editor. Contact him via LinkedInor on Twitter at Andy_Favell.

dna45_image_formats_httparche_t.png

How to optimize images for mobile: Implementing light, responsive, correctly formatted images

The mobile web has a weight problem. Too many mobile sites are slow to load, and bloated with unnecessary bells and whistles, leading to a poor user experience.

Chief among the culprits is images, which as we have seen in part 1 of this series, How to optimize your mobile site speed, account for 68% of total page weight. Then, in part 2, we looked at how to reduce the impact of images on the speed of your mobile site, including how to make sure your images are as accessible as can be. This mostly focused on removing images which do not add value, and making the ones you do use work harder.

But how can you make sure that any images on your mobile site are light, device-responsive, and use the best format to combine speed and quality? This column focuses on optimizing images for mobile, including responsive images and other clever methods for stopping images ruining mobile user experience.

The balancing act of image optimization

The problem with image optimization is that there are no hard and fast rules. Image optimization is always going to be a careful balancing act between user experience, attractiveness and page performance.

Raluca Budiu, Director of Research at Nielsen Norman Group, explains:

“Because the screen is small on mobile, too small images may offer too little information, and too big images may slow down the page too much. We recommend that you start with a modest size image and allow people to zoom in (or download a larger picture of the image).

Most of the time huge images are not a good idea — their information density is low, and they require people to wait for the page to load and/or to scroll down for more content. This is a common problem with responsive one-column designs: because images are supposed to fill up the whole container width, we often end up with huge images that carry little information compared to their size.”

There is no set-in-stone rule for how small a mobile image should be – it’s a trade-off between quality and page size. But a good guideline is to benchmark against the 100 most popular sites. According to httpArchive, the average JPG is 29KB and the average PNG is 16KB.

Reducing the weight of an image is partly about saving the image at the appropriate size and resolution (number of pixels) and partly about compressing the image. Some creative tools, such as Photoshop, will afford some compression, but often not enough, especially with larger image types such as PNG.

There are a number of tools that will very effectively compress images individually or in batches of images. For example the homepages image above was compressed using TinyPNG resulting in a 79% reduction in weight.

For a comparison of the leading compression tools, see GitHub.

Should you use different sized images for mobile, tablet and desktop?

When designing separate websites for mobile, tablet and desktop, whether that is via dedicated URLs (site.com and m.site.com) or serving different sites via a single URL (adaptive web design), it is implicit that images ought to be appropriately sized for the largest device in that category.

The position is perhaps less clear with responsive web design (RWD). With RWD, the principle is to serve the same website to different devices, using CSS to format the content according to the device capabilities and screen size.

This doesn’t mean, though, that websites should necessarily adopt a one-size fits all approach to images, explains Alex Painter, Web Performance Consultant at NCC Group:

“Pages are often slow on mobile because of a failure to deliver images appropriately sized for the viewport. The popularity of responsive design may be partly to blame – the idea that the same content can be reflowed so the layout works in any viewport can mask the fact that imagery hasn’t been optimized for mobile.

Plenty of sites deliver the same images on desktop as they do on mobile – with mobile versions just scaled down to fit. This might not be immediately obvious to end users with high-end devices on fast, reliable networks. But it can make websites completely unusable for people with lower spec phones or with poor connectivity.

 There are two reasons why this is a big problem. The first is simple – it just takes longer to deliver an unnecessarily large image over the network. The second is often overlooked: the mobile device has to work hard to a) decode and b) scale down the image. This is expensive in terms of processing power and memory.”

But it doesn’t have to be this way. Helped in part by the advocacy of the Responsive Images Community Group, the HTML specification now makes it easier for developers to create a number of alternate images for different device types – to suit different screen sizes (viewport), resolutions (number of pixels) or device capability.

The webpage HTML tells the browser which of these images to select for screens up to a maximum width and if the image should take up all or just part of the screen width.

Previously, some developers would use JavaScript to specify the use of different images, but using the HTML <picture> element should be more efficient, reducing the extra code and requests that slow down page load times.

Alex Painter:

“Delivering the right image for the viewport is now reasonably straightforward. We’ve had CSS media queries for background images for some time, but until recently images referenced in the HTML was more of a problem.

Now, we have the responsive images specification: the <picture> element, with the srcset[set of alternative image sources] attribute and sizes attribute that make it possible to define which image should be delivered for which viewport width (or to allow the browser to make the most appropriate choice from a selection of images).

The spec is now very well supported by browsers, and developers should ideally be using it rather than using JavaScript to achieve the same end.”

How to optimize images for mobile: Implementing light, responsive, correctly formatted images

Who is using responsive images?

A peek at the source code of major websites such as Amazon, Facebook and the BBC confirms that none is yet using the <picture> element to serve responsive images.

Would they benefit from doing so? Serving different images to each platform potentially offers several advantages:

  • Allows the website to show a larger, higher resolution image on the desktop.
  • Reduces the picture sizes and total page weight and thus speeding up mobile load time.
  • Enables the mobile site to show a zoomed in image on mobile. (Note the cropped image of the dog above).
  • Retailers can display Mobile-Friendly Hero Images on mobile while sticking to traditional pack shots on larger displays.

Finding the best format for your images

The most common formats for images used in mobile/mobile-friendly sites are JPEG 46%, PNG 28%, GIF 23% and SVG 1% according to httpArchive.

How to optimize images for mobile: Implementing light, responsive, correctly formatted images

Using an inappropriate image format can increase file size and effect quality when images scale for different screen sizes.

There are two types of web image: raster and vector. The first is made up of dots (like a digital photograph), while the second is made up of lines and shapes. JPEG, PNG and GIF are raster. SVG is a vector. SVG is a newer format not as widely used (yet), but is recommended for responsive design sites by this course on Responsive Images from Google and Udacity.

There are pro and cons for each, and every web designer has a different opinion and favorite formats. You need to research your own company policy, but in general:

  • JPEG is most commonly used for web photographs
  • GIF is common for animations as well as simple graphs, icons and logos
  • PNG is common for higher quality graphs, logos, icons and other illustrations and photos with graphical effects
  • SVG is good for graphs and logos, page headers – things that are designed by an illustrator.

For more information on format types and sizes, see Google’s guide to optimizing images.

Alternatives to traditional images

Webpages are made up of many small images, such as icons and buttons. If these are made using individual GIF/PNG/JPEG images, it all adds to the page size and each one requires an individual browser request, which can slow down page load time.

Three methods that can help keep page size and image requests down are:

  • CSS sprites – combines a collection of smaller graphics into a single CSS file. N.B. Overloading sprites with too many or too large graphics will be counter-productive.
  • Icon fonts – is a library of icons sent as one single file.
  • CSS shapes – are shapes built using CSS, rather than as a traditional image

Mike D’Agruma Lead Front-End Web Developer, E-volve Creative Group:

“To save on file size, I generally stay away from loading larger, more popular icon libraries, and use Fontastic to create my own custom icon fonts. This method works extremely well on a variety of levels: 1) As I’m only using a small number of custom icons, the font file size is drastically smaller; 2) Icons are created with SVGs, which ensures they’ll be extremely crisp on devices; 3) You can’t beat this option for flexibility, as font icons are extremely customizable with CSS.

Another great way to safe on time, file-size and server requests is to use CSS to create shapes – you can create most shapes and add as many effects and transitions as you’d like with CSS.

 Take Summit County Metro Parks mobile site as an example, in the header section alone, I was able to use a combination of CSS shapes and font icons to create what could’ve been six different images. Activating the mobile menu shows an example of a CSS-shape animation (the hamburger menu morphing into an “X”), and the use of an additional icon on the right side of accordion triggers shows open and closed states.”

How to optimize images for mobile: Implementing light, responsive, correctly formatted images

Web design techniques for improving perceived load time

When you have trimmed the fat, removed the unnecessary images and optimized the remainder, but the page is still not loading fast enough – what do you do? Cheat.

Make sure the most important stuff loads first, says Raluca Budiu:

“When a page loads, make sure that the text loads first, so that people can start scanning the content. As images load, don’t shuffle the already loaded content around — it will cause readers to lose their place on the page, and sometimes they will even click on the wrong link because the right target unexpectedly moved.”

There is a difference between perceived load time and actual load time. All that matters to the user is that the content on they are looking at, or for, is available. They do not want to be staring at an empty screen while the browser fetches images they may never see.

There are three common techniques for delivering this. Robert Gaines, a Kansas, US-based, web and app developer explains:

 “1. Deferred loading, or delayed loading, uses JavaScript to stop images and other assets loading until after the main content of a webpage has finished loading. Deferred loading reduces the amount of time it takes for a webpage’s primary content to render, but reduces the need to cut images that would otherwise slow down a webpage.

2. Lazy Loading loads assets when and as they are needed. So content is loaded above the fold first, then below the fold as the user scrolls. With image galleries – such as product searches on retail sites – thumbnail images are used, larger images are only loaded when a corresponding thumbnail is clicked.

3. Progressive image loading first loads low quality images while a webpage is being rendered and then replaces them with high quality images after primary content has finished loading. Progressive image loading balances performance with visual appeal. Unlike deferred loading, it doesn’t leave users waiting for secondary images to load after primary content.”

Tools such as Photoshop allow images to be saved as progressive JPEGs, or interlaced PNG, which will load in the way described.

This course on Responsive Images from Google and Udacity is a good introduction to this subject; it is aimed at web developers, but everyone will benefit. You can skip the coding exercises.

 

This article is Part 3 of a three-part series on how to optimize your mobile site speed. Read the previous instalments in this series:

A version of this column was originally published on our sister site, ClickZ. It has been republished here for the enjoyment of our audience on SEW.

walmart-ice-cream.png

How to reduce the impact of images on your mobile site speed

Images are the main culprit for causing oversized web pages (average size 2.2MB) that can perform slowly on mobile devices.

Last week, we looked at how to optimize your mobile site speed and test for issues that might be slowing your site down. With Google placing more and more emphasis on mobile site speed and user experience in order to achieve a good ranking, discovering issues with your mobile site speed is critical. But how can you fix those issues once you’re there?

This column, the second of three, will discuss the different ways to reduce the impact of images on the performance of your mobile site.

 

You need to fix your mobile image problem. You are not alone. As detailed in my previous column, the average mobile webpage is now a ludicrous 2.2MB and this can severely impede how quickly the page loads on a mobile device.

At 68% of total page weight, images are the main culprit. This column will look at the different ways to reduce the impact of image on the performance of your website.

For those you like a step-by-step approach, here are ten steps to speedy mobile web pages.

  1. Speed test: how fast site loads on mobile device; causes of delay.
  2. Test image impact: do images improve or kill user experience.
  3. Image policy: review company policy on images; educate everyone.
  4. Image audit: evaluate number, format, size, situation, impact.
  5. Cut the fat: remove images that do not add value.
  6. Image impact: make images work harder.
  7. Balancing images with accessibility.
  8. Optimize images: right format, right size.
  9. Alternative techniques: for icons and buttons.
  10. Even more speed: web design techniques.

Steps 1-4 were mostly covered in Part 1. This column will concentrate on steps 5-7. Part 3 will concentrate on steps 8-10.

Cut the fat

The first and easiest step to improving page speed is to remove unnecessary images. If images do not add value and are taking up valuable real estate get rid of them. Crappy stock image just there to fill space? Be gone.

When you are auditing your existing pages or creating a new one, ask: does this image justify:

  1. The space it takes up on the mobile screen?
  2. Adding 30KB, 50KB, 100KB etc. to the page size?

Robert Gaines, a Kansas, US-based, web and app developer, advises:

“Before you add an image to a webpage, decide if you really need it; if it really adds value. Every image that you add slows the webpage down, impacting both user experience and search rankings. If you don’t need an image, cut the fat!

Slider images are a great example of images that can be cut from a webpage. Studies have shown that sliders do not have a significantly positive impact on either conversions or user experience – they are unnecessary bloat.”

Use heatmaps, user testing and A/B testing (covered in Part 1 of this series) to assess the impact your images are having on the users. Is it positive, negligible or negative?

Images that count

Once you have illuminated the images that don’t add value, concentrate on making the remaining images work harder for their pixels/KBs.

Raluca Budiu, Director of Research at Nielsen Norman Group, says:

“As web images can take longer to load on mobile devices, it is usually a good idea if they contain information, and are not purely decorative. Users rarely appreciate a pretty picture that is unrelated to an article. Ecommerce sites, in particular need good images — people can rarely make a buying decision if they cannot see the product well.”

Case study: Unilever mobile-ready hero images

One company that has really flung its weight behind making images more useful is Unilever.

Working with Cambridge University Inclusive Design team, the company has redesigned all product shots for all its brands to make them easier for web customers to instantly recognize and pick the right product, just using visual recognition, as they speed through any retailer’s catalogue of products “Vegas style” (i.e. spinning through results like the reels on a slot machine).

The idea is that by highlighting the essential details – brand, product type, size and quantity – on the image, shoppers don’t have to read the copy for every product.

In case you were wondering, a hero image is the term given to the fat clickable/tappable banner image, often on a carousel, at the top of homepages (particularly), featuring a new product, promotion etc. and a call to action. Mobile-Ready Hero Images are the smaller thumbnail images found on a page of product listings either in a category or following a search for e.g. men’s deodorant.

How to reduce the impact of images on your mobile site speed

Oliver Bradley, Global eCommerce Experience Design Director at Unilever, explains:

“Mobile-Ready Hero Images were created specifically for online retail to act as the primary image in search / favorites thumbnail results. They are designed to work well on all screen sizes that are typical for online retail (16mm on mobile, 23mm on tablet and 48mm on laptop / desktop).

They allow the online shopper to better recognize brand, format, variant and size as they are perform that fast vertical scroll which is typical behavior when scanning through long lists of products on a mobile or tablet.

The images can be zoomed and/or cropped to deliver better legibility & recognition of brand and variant esp. on portrait packs. If required brands can add the size of the product or number of contents in the bottom right-hand corner. If necessary, the type of product may be added as a stripe on the right-hand side (portrait packs), or as a stripe along the bottom (landscape packs). Makes better use of space than with a conventional packet shot.”

First introduced in 2014, Unilever has moved rapidly to convince retailers in 20 countries – including many of the retail giants e.g. Walmart, CVS, Walgreens, Tesco and Carrefour – to introduce the enhanced imagery to their e/m-commerce sites.

With some retailers, such as Asda.com (Walmart’s UK subsidiary), every Unilever product is now marketed with a Mobile-Ready Hero Image.

What’s more, Unilever, with the Cambridge team, have turned Mobile-Ready Hero Images into a standard: available open source and free for any competitor to pick up. And many of Unilever’s biggest competitors have done just that, says Bradley:

“We realized that we needed to create a versatile category solution with the same visual architecture and consistency across the board. Since doing this we’ve been pleased to see L’Oréal, GSK, P&G, Kellogg’s, Kimberly Clark and J&J follow our approach.”

The image below displays two screenshots. The first captures a deodorant search from Walmart.com, showing two Unilever brands with hero images with the product type and size alongside the product shot. With the two rival products, it is more difficult to establish the type of product or the size, without zooming in on the product.

As Walmart does not include these details in the blurb, this makes the hero images doubly useful.

The second image captures a shampoo search from Asda.com, showing a Unilever product (TreSemme), a P&G product (Herbal Essences), both using the hero image. The third product, also a P&G brand (Pantene) does not use a hero image. While the hero images are considerably more high-impact, Asda does include the product type and size in the blurb… assuming that the consumer reads it.

How to reduce the impact of images on your mobile site speed

So what’s the impact on UX?

At the start of the project, Unilever and the Cambridge team conducted quantitative research (i.e. interviews and surveys) with 3000 shoppers in and then verified their findings/work by conducted eye tracking tests with more than 100 shoppers, to watch how they interacted with the site and images using mobile devices on mobile to verify.

This user testing put Unilever in a good position to rebut any doubters from the retail business.

“Some retailers argue pack shots are necessary for e-commerce, because the text description next to the pack shot provides all the information that cannot be obtained from the photograph. But we know from eye tracking that 90% of the e-commerce page is ignored.

We know that the majority of shoppers don’t bother to check the product name, size or format on retailers’ websites or apps. That’s why nearly every shopper we interviewed had a story of accidentally buying a product online that turned out to be not as expected (especially on size). If a pack looks similar to the one their used to, they don’t bother to check the text to verify.

The point of online grocery is convenience and saving time. It’s about selecting a large number of products as quickly as they can. Because you don’t have to check the text with hero images, it makes shopping even faster.

We know this is true from the conversions the hero image have delivered. The A/B test results have been amazing: a 24% lift on Magnum, a 19% lift on Simple, and a 4% lift on Ben & Jerry’s.”

Accessibility

The biggest issue for any sort of image, but particularly an image that contains important textual data, is that that they are invisible to people with visual impairments. People who don’t see well or at all, use screen-readers to read the text on the site aloud.

There’s nothing wrong with using images, or hero images for that point, but it is essential that the content in the image should be either written in the web copy and/or in alt tags (these tags describe the image to a screen reader, but are invisible to the able-bodied reader).

Generally, accessibility experts frown on the use of text being placed within an images, because screen readers are blind to the data it contains. This is why, for example, it is preferable from an accessibility point of view to prepare tables of data as an html table, rather than simply uploading an image of the table – but this will always take additional time and usually won’t look as good.

Marco Zehe is an accessibility evangelist and QA engineer at Mozilla:

“Mobile images need alt text, just like for the desktop, of course. But it helps if the images are responsive, because people with low vision or elderly people will benefit from them zooming better.

“However screen readers do not do image recognition on the web, yet, so if there is text on the image, this is will be inaccessible. In principle, text on images should be avoided. But if the text helps clarify a photo, especially for people with low vision, and as long as it is only duplicating what is said in the copy and in the alt text, this is acceptable.”

So, if text genuinely adds value to an image, as is the case with Mobile-Ready Hero Images, then it is safe to assume this is acceptable, as long as it is duplicated in the copy and the alt tag.

So looking back to our Walmart and Asda examples pictured above:

  • The source code for the Dove deodorant on Walmart contains the alt text: “Dove Men+Care Extra Fresh Deodorant, 3 oz, Twin Pack”, which describes the product, size and quantity. The page copy describes the product, but does not include size or quantity.
  • The source code for the TRESemme Shampoo on Asda contains alt text: “TRESemme Moisture Rich Shampoo Rollback”, which describes the product, and offer, but not the size. The shopper needs to click through to discover this information.

 

This article is Part 2 of a three-part series on how to optimize your mobile site speed. Check back next week for Part 3, which looks at how to refine and reformat your mobile site images.

Or read the previous instalment: How to optimize your mobile site speed: Testing for issues.

This column was originally published on our sister site, ClickZ, and has been reproduced here for the enjoyment of our audience on SEW.

 

Andy Favell is Search Engine Watch’s columnist on mobile. He is a London-based freelance mobile/digital consultant, journalist and web editor. Contact him via LinkedIn or Twitter at Andy_Favell.

 

t_amp_trump_google.png

Accelerated Mobile Pages vs Facebook Instant Articles: Is Google winning the mobile war?

Articles published with Accelerated Mobile Pages (AMP) load four times faster than standard mobile pages with a 35% improvement in engagement time, according to new research from Chartbeat.

Facebook Instant Articles (FIA), a key competitor to Google’s AMP product, load faster than AMP. But publishers see three times as many AMP articles viewed per day than FIA articles.

This comes hot on the heels of a stream of encouraging news on AMP from the Google I/O keynotes, presented by VP product management Rahul Roy-Chowdhury and Malte Ubl, creator and tech lead of the AMP Project. These included:

  • There are now 2 billion AMP pages from over 900,000 domains, as of May 2017. A year ago there were 125 million AMP pages.
  • An average AMP page loads in less than a second and uses ten times less data than a normal mobile page.
  • AMP supporters and partners include Twitter, Tumblr, Qzone, Weibo, Pinterest, LinkedIn, Bing, Feedly, Nuzzle.
  • AliExpress reduced load times by 36% with AMP, helping to increase orders by 10.5% and conversion rates by 27%.

Meanwhile, in late May 2017, Facebook announced an extension to its Software Development Kit (SDK) so that articles produced for FIA will also be publishable as AMP articles, and soon also as Apple News. This is in response to publisher frustration at having to produce content in different formats for different platforms.

Facebook’s move could also be a reaction to a number of publishers reportedly dropping Facebook Instant Articles, and a recognition the FIA is losing ground to AMP.

A recap: What is AMP?

AMP is special type of slim-line mobile webpage, which is an open source project, led, or controlled (depending on your viewpoint), by Google. AMP web pages are faster because:

  • AMP is not part of the publisher’s main website (less baggage to download).
  • The content is static (less interactive baggage to stall download).
  • The articles are pre-cached on servers around the world, by Google or its AMP partners, so they are closer to the user (faster to download).

Any web page could be – and should be – speeded up in a similar way, by reducing page bloat, and using caching via a content delivery network. But the advantage of AMP is Google will only cache AMP pages and Google promotes AMP pages in mobile search above non-AMP pages.

As demonstrated by the following screenshots, of a Google search for “Trump” captured concurrently on a tablet and smartphone, using the tool mobilizer, AMP news stories dominate mobile search results for topical terms. Not just in the picture-led carousel of news, but throughout search results. AMP doesn’t feature at all in tablet results, which is baffling.

What the difference between AMP, Facebook Instant Articles, and Apple News articles?

Facebook Instant Articles and Apple News are news articles from third-party publishers that appear in the newsfeed on the Facebook app and within the Apple News app, respectively. They are tightly controlled by Facebook and Apple and only available to users of those apps. They are also not discoverable through web search or other third party sites or apps.

While these platforms present additional distribution channels for publishers, there is a double drawback to using them: the potential for losing out on direct traffic to their own sites and apps (where they potentially control all the ad revenue), and also the need to prepare articles in three additional formats.

The stats

Chartbeat’s research is particularly interesting as it provides an independent assessment of AMP and a comparison with FIA. There’s no inclusion of Apple News in the research, which is unfortunate as little is known about the platform except that it has 70 million users, according to Recode.

Chartbeat compared 360 sites that use both AMP and FIA, from its 50,000 media sites that use its analytics tools. So how did AMP stack up in the race against Facebook?

Speed and engagement

Let’s start with speed and engagement.

  • The research found the average mobile web article took 5.3 seconds to load, but AMP took 1.4 seconds. That’s not as quick as Google’s claim of under a second, but it is a four-fold improvement.
  • FIA loaded in a fraction of that time at 0.001 seconds, on most occasions too fast for Chartbeat to measure.
  • Comparing the read time of visitors coming from search, Chartbeat found readers engage with AMP articles for an average of 48 seconds v 36 seconds for normal mobile articles i.e. 35% longer.
  • There were no comparable engagement stats for FIA.

Accelerated Mobile Pages vs Facebook Instant Articles: Is Google winning the mobile war?

Considering AMP’s focus on speed, this comparison with FIA is embarrassing. However, Google is already working on speeding up AMP.

In his Google I/O keynote, Malte Ubl announced a plan to make AMP twice as fast to deliver “first contentful paint” – a technical term referring to the first ‘interesting bit’ of a webpage that the browser loads.

In practice, this will make it twice as quick to access the important part of a document, e.g. the text in an article, when clicked through from search.

Article volume

On a daily basis, publishers see three times as many AMP articles viewed as FIA articles, according to Chartbeat. The report authors concluded from these results that content has a longer lifespan on AMP, or receives traffic for more days from AMP, than from Facebook Instant Articles.

Accelerated Mobile Pages vs Facebook Instant Articles: Is Google winning the mobile war?

Article volume matters to publishers. Especially when they have to reproduce content for different platforms, as well as, and in competition with, their own sites and apps.

As noted above, Facebook has opened up its SDK so articles produced for FIA would also be AMP and Apple News ready.

Similarly, if AMP volume continues to plateau for these publishers as Chartbeat suggests it has since the beginning of the year, publishers could become restless.

AMP vs mobile web

The biggest competitor to AMP probably isn’t FIA or Apple News; it’s the plain old mobile web.

Chartbeat’s research shows that publishers that use AMP and FIA have seen them steadily make more of an impact on mobile traffic. But today AMP is 16% of all mobile traffic for AMP publishers, and FIA is 14.8% of all mobile traffic for FIA publishers. While this is still significant, the majority of mobile traffic is not made up of either.

Accelerated Mobile Pages vs Facebook Instant Articles: Is Google winning the mobile war?

Not everyone is happy with AMP

There has been a growing number of voices of dissent to AMP. A lot of this sentiment is summed up in this provocative Register article, calling on Google to “Kill AMP before it kills the web”.

It’s clear from the Google I/O keynote that AMP publishers have also raised issues. Elena Legeros highlighted and addressed four key challenges:

  1. All AMP pages look the same. Response: Google is releasing more templates through AMP start.
  2. It’s hard to measure/track visits to AMP pages. Response: Google Analytics is working with third party analytics companies to improve this.
  3. Not everyone likes AMP URLs in Google Search. Response: Google recognizes that it is frustrating. Will work with partners to display the original article URL.
  4. AMP pages do not monetize well through ads. Response: Google disagrees.

Andy Favell is Search Engine Watch’s columnist on mobile. He is a London-based freelance mobile/digital consultant, journalist and web editor. Contact him via LinkedIn or Twitter at Andy_Favell.

dna42_response_time_graph.png

How to optimize your mobile site speed: Testing for issues

The right picture is very useful on mobile and responsive websites. But images that are too large, too numerous and unnecessary simply slow down page load times and get in the way of the users reading and doing what they need to do.

The problem: the size of webpages sent to mobile phones has quadrupled in just five years. The main cause: images, which account for 68% of total page weight.

With mobile page speed a confirmed ranking factor in Google’s last mobile-friendly update, and Google’s mobile-first index looming large on the horizon, it’s in the interests of developers and SEOs to optimize their mobile site speed as much as possible. That means figuring out how to trim the fat from all those huge, cumbersome images.

This column will explore the issue and causes of delays in mobile page speed (i.e. how quickly pages load on a mobile device) and how to test webpages for problems with speed.

The next column will look at methods to reduce the impact of images on the performance of your mobile pages. This includes only using images that add value and making the images you do use work harder, with an excellent case study from Unilever.

This data was sourced from the incredibly useful httpArchive, which tests the top 1 million sites several times every month:

  • The average transfer size (i.e. bites sent from server to device) of a webpage is 4.2 times larger than it was five years ago, rising from 521 Kilobyte (KB) in December 2011 to 2197KB or 2.197 megabyte (MB) in December 2016. N.B.: this measures compressed rather than original file sizes.
  • Images are a massive amount of that bloat. Total size of images sent to mobile devices has increased 4.2 times from 352KB in 2011 to 1490KB in 2016.
  • Image requests have grown from 38 to 50. JPEGs are most common, accounting for 46% of image requests.
  • By comparison, the other major contributor to page bloat is JavaScript, which has risen from 98KB to 381KB with requests rising from 8 to 21 requests. That’s 17% of total page size compared to images’ 68%.
  • The one to watch is video, which was nonexistent in 2011 websites, but now averages 110KB or 5% of total page size and takes up a gigantic 542KB per request vs 43KB for a JPEG.

The most shocking discovery here is that the average size of a mobile webpage, 2197KB (2.2MB) is almost as large as the average desktop webpage at 2469 KB (2.5MB) in November 2016. We can only surmise why this might be:

  • Are responsive design websites… or to be more precise inefficiently built/implemented responsive design sites to blame (because the true responsive design website is one site reformatted for different devices)?
  • Has the adoption of lazy and deferred loading techniques encouraged companies to be less efficient with total page size?

Putting things right

A note before we begin:

Web/mobile images are an imprecise science. There are no hard and fast rules – different practitioners and scenarios dictate differing course of action.

There is no best format, size, content type, design, shape, placement or number of images, but there are best practices to help you make those decisions. The rule of thumb is as small, as few, as big an impact as necessary.

“Images” are not just illustrative pictures or graphs. They also include logos and icons – but these do not necessarily need to be traditional images, such as JPEGs.

Action plan:

  1. Review your policy on images, or create one, if you don’t have one. Issue guidelines for all web content creators as well as developers.
  2. Audit the images you are using on the site. Are they adding or taking away from user experience? Can they be improved, optimized, reduced in size (on page), pushed below the fold or removed?
  3. Test how effective your images are with the users. Research/test before you make any changes, test as you pilot changes and monitor results after changing.
  4. Work out how you will balance page speed with attractiveness, quality, impact, page speed, efficiency and accessibility.

The need for speed

Robert Gaines, a Kansas, US-based, web and app developer:

Graphics are attractive and allow users to quickly grasp concepts without reading large amounts of text, however they also slow load times. Excessive use of images or the use of especially large images will slow down webpages. Slow load times annoy both readers and search engines.

The need for graphics has to be balanced against page speed. When images are used, they should be compressed and scaled so that they load more quickly. In cases where compression and scaling aren’t enough, other advanced techniques may be needed.

There is no rule for perfect speeds that a page should download to a mobile device, how could there be – mobile connections vary massively. The rule of thumb is as fast as possible. Benchmark your performance against competitors and sector leaders.

Various studies and reports, see WPO Stats for examples, have shown that improving page speed improves conversions. For example, an FT.com study found that reducing page load by 3 second on mobile led to a 9% reduction in articles read over the month.

Google warns on its TestMySite tool that “Nearly half of all visitors will leave a mobile site if the pages don’t load within 3 seconds.” But the source of this stats is unclear.

Test, test, test

Testing is critical improving to website performance and usability.

1. Test how quickly pages download

Regularly test your mobile webpages (all new ones and all the main ones). Use different services and at different times, because tests results will differ… a lot.

WebPageTest is one of the better ones, it measures speed, page size and shows what proportion of the data and requests belong to images, JavaScript etc. Some of it is a bit techie, but the excellent filmstrip showing how the site loads second by second can be understood by everyone. WebPageTest used to offer remedies also, but sadly these have disappeared.

For something less techie, use Google’s PageSpeed Insights (also try the simplified version: TestMySite – it sometimes surprises by offering a different results to its brother). N.B. Google doesn’t actually test page speed, it estimates page speed based on key criteria, but it is excellent at pointing out problems with the page.

Top issues identified by Google include problems with image size and JavaScript codes, which we know from the httpArchive’s data are the two largest contributors to data bloat.

httpArchive is different. It tests the home pages of the top 1 million websites, at regular times each month. It is based on WebPageTest. It’s brilliant for showing the breakdown of content types e.g. images and shows historical trends. Even if you are not in the top 1 million you can use it to benchmark against the big boys: individuals, top 100, top 1000, top 1 million.

For this random test, let’s pretend we are the biggest retailer in the world, and compare against the biggest online retailer:

Mobile speed test performance test for Walmart.com:

  • httpArchive – mobile page speed (January 15, 2017): 20.6 seconds. Page weight: 1941KB. 95 requests. Images: 962KB. Image requests 53.
  • WebPageTest (tested on a US-based iPhone6, cable connection, (9.00 GMT, 29-01-17) – mobile page speed: 14.3 seconds; fully loaded 17.9 seconds.
  • PageSpeed Insights – mobile speed score: 45/100 (poor).
  • Google should fix list: Optimize images. Eliminate render-blocking JavaScript and CSS in above-the-fold content.

It is important to benchmark your performance against your competitors’ sites, so let’s try Amazon.com:

  • httpArchive – speed (January 15, 2017): 6.9 seconds. Weight: 554KB. 89 requests. Images: 259KB. Image requests 49.
  • WebPageTest – speed (9.00 GMT, 29-01-17): 2.4 seconds; fully loaded 4.8 seconds.
  • PageSpeed Insights – mobile speed score: 55/100 (poor).
  • Google should fix list: Eliminate render-blocking JavaScript and CSS in above-the-fold content.

Google PageSpeed, pictured in the image below, estimates that Walmart could save 478KB (almost 0.5MB) simply by compressing the images on the page. As can be seen from the httpActive chart, this could save as much as half the image weight or one quarter of total page size.

See Google’s Guidelines for optimizing images and fixing JavaScript issues.

How to optimize your mobile site speed: Testing for issues

2. Conduct user testing

As with all aspects of web development, user testing is critical to improving site performance and usability.

  • Conduct surveys and interviews with users to discover how they use your site and any pain points with the experience.
  • Test and watch users as they interact with the website. Use eye tracking to see what catches their attention and which images work.
  • Use heatmaps and web analytics to track how users interact with webpages and where they look.

3. A/B test webpages with different images, numbers, placement, formats and sizes of images

A/B testing shows two different versions of the webpage to different groups of visitors. Compare the results to see which types of image work best.

As we will see in the next column when we look at Unilever’s work with mobile images, user testing your mobile website is hugely important, and small changes to images can deliver big differences.

 

This article is Part 1 of a three-part series on how to optimize your mobile site speed. Check back next week for Part 2, which looks at reducing the impact of images on your website’s performance.

This column was originally published on our sister site, ClickZ, and has been reproduced here for the enjoyment of our audience on SEW.

 

Andy Favell is Search Engine Watch’s columnist on mobile. He is a London-based freelance mobile/digital consultant, journalist and web editor. Contact him via LinkedIn or Twitter at Andy_Favell.

t48_webpagetest_youtube.png

How video impacts mobile web performance and UX, part 3: detecting and remedying issues

Video has become an important tool in the marketers’ tool box. Video storytelling is a useful and increasingly popular way to engage customers.

But if your video doesn’t work properly or cripples your website or app performance it will become a major frustration to customers, marketers and techies alike.

In the previous two parts of this column on data and download speed and autoplay and audio we learned:

  • Video dominates mobile data traffic
  • When implemented correctly, mobile video should not impact the speed that pages load on a mobile device
  • Mobile users start to become impatient after waiting just two seconds for a video to load; by 10 seconds a fifth will have given up.

This column will explore how to detect, avoid and remedy issues with videos to give your viewers the best possible experience with your video content and keep them engaged and watching your videos.

Jump to:

How to detect problems with video
How to avoid problems with video
How to remedy problems with video

How to detect problems with video

Detecting issues with video, audio or any other web or app issue a) can be straightforward; b) should be everyone’s responsibility, from the CEO down; and c) helps to keep agencies, techies and marketers on their toes.

1. Use it

Blatantly obvious – but when was the last time you checked out your site and videos from a bus, train or bar? Incentivize employees to use the site/app (during beta testing and routinely after goes live) and report issues and suggest improvements.

Check for:

  • How quickly did the site/page load? (Count the seconds)
  • How long did you have to wait for the video to start?
  • How good is the quality?
  • Does it stall / (re) buffer during playback?
  • Was it worth watching/watching to the end?
  • How do you feel about these conclusions?

2. User test it

Recruit customers and monitor their behavior and reactions as they use your web site, using different devices, networks and locations. Score against the above checklist. If this cannot be conducted in person use a remote service such as UserTesting.com.

User testing should occur at each stage of the development process. For more on why user testing is so crucial, see my previous column for our sister site ClickZ on Why user testing should be at the forefront of mobile development.

3. Test it

There are different types of testing, including:

  • Page performance – tools such as WebPageTest (free) show how/if the video is impacting how fast the page loads. It shouldn’t. The image below shows the WebPageTest results for how quickly Sam Dutton’s mobile video explainer on YouTube loads on a mobile device. The page took 6.6 seconds to load 809kB.
  • A/B testing – tests alternative experiences with different groups of web (or app) visitors. For example, test hosting the video on the homepage versus on a dedicated page.
  • Video testing tools – AT&T’s Video Optimizer (formerly known as Application Resource Optimizer) is a free-to-download tool used by developers (requires technical knowledge) to detect issues such as delays with start-up and the frequency and duration of stalls and optimum segment size.

4. Monitor it

  • Web analytics tools, such as Google Analytics, track visitor engagement with video – e.g. number of views, who viewed, how long, and with the webpage itself, including dwell time and bounce rate. See this introduction to using GA to assess video engagement.
  • Heat map tools, such as Clicktale and Crazyegg provide a visual representation of how users interact, or attempt to interact, with webpages and video.

How to avoid problems with video

Following best practices while creating/producing the video or coding the page, website or app that will host it should help avoid many of the common issues – videos that won’t play, are slow to play, or have broken playback.

Industry guidelines on mobile video are thin on the ground, considering the increasing popularity of the format. What guidance is available tends to be a bit techie and thus a turn off for non-techies.

The following recommendations have been compiled with the help of:

1. Make it worth it

There are many costs involved with video/audio:

  • For the producer: the cost of production and distribution; impact on web performance
  • For the network: the impact of network congestion
  • For the viewer, in terms of data consumption, battery life and time it takes to consume.

This makes it imperative that the video is meeting a known user need, contains quality content, is the right length, optimized in terms of bitrate, segments and compression.

2. Be aware: video is greedy; HD greedier; 4K much greedier

When it comes to bandwidth, standard video is greedy, requiring 0.5 Megabits per second (Mbps); high definition (HD) is five times as greedy as SD; and 4K is 30 times as greedy.

Cisco’s Usha Andra explains:

“Mobile video and multimedia applications have higher bandwidth and lower latency requirements than non-video applications. The requirements can range from a low of 0.5Mbps for standard definition (SD) to 2.5Mbps for high definition (HD) and over 15Mbps for 4K/ultra-high definition (UHD) downloads and much higher for virtual reality (VR). Latency requirements can range from 100 milliseconds (ms) to 15ms for UHD VR video applications.”

3. Know the limitations of mobile networks in your target markets

Even among developed telecoms markets, the capability of mobile networks varies considerably. Check the Cisco GCI Global Cloud Readiness Tool for an averages of each country.

The stats suggest that download speeds in the US and UK are 40% lower than Norway and South Korea, and 25% lower than Canada:

  • South Korea – download: 31.0Mbps; upload: 14.3Mbps; latency: 68ms
  • Norway – download: 29.1Mbps; upload: 11.6Mbps; latency: 40ms
  • Canada – download: 24.2Mbps; upload: 9.0Mbps; latency: 51ms
  • UK – download: 18.2Mbps; upload: 8.0Mbps; latency: 55ms
  • US – download: 17.1Mbps; upload: 10.0Mbps; latency: 88ms.

Usha Andra adds:

“Please note that these are average speeds and latencies, which means many users experience higher or lower speeds compared to the average speeds. When the speeds and latencies are lower than what an application warrants, the end user experiences delay in video, garbled audio, etc.”

4. Home page or own page?

Few of the most popular sites, including those that have a strong video focus – YouTube, Vimeo, BBC and CNN – host videos on the homepage or category pages. These sites promote their videos on the homepage as image links (often with play button icon overlaid) and text links, which when clicked or tapped go to a page dedicated to that video.

Why? Keeping video off the homepage keeps it leaner and faster to load on mobile devices. See the Twitch example below.

5. Avoid autoplay

Forcing mobile web visitors to view video whether they want to or not, is:

  • Frustrating for the customer (especially when it happens in a quiet environment)
  • Prone to using up the customer’s bandwidth and battery life unnecessarily
  • Liable to slow down how quickly the page loads
  • Contrary to accessibility best practice (as it can interfere with the screen readers used by visually impaired people)
  • A common technique for artificially inflating video view stats.

There is a (vaguely plausible) argument that sites such as YouTube are an exception to the no autoplay rule. As the visitor is clicking through to the video on a dedicated page it is implicit that they intend to watch.

Consider Twitch, the surprisingly popular site where fans watch gamers playing video games live, captured in the image below. On the desktop homepage, Twitch.tv has a live game on autoplay, while on m.Twitch.tv, there are no videos hosted on the homepage.

Comparing the download size and page speed of Twitch homepage when downloaded to a mobile and desktop device on HTTP Archive (April 15 2017) delivers dramatic results:

  • Mobile homepage (with no video) took 5.8 seconds to load 354kB of data over 24 requests
  • Desktop homepage took 19.9 seconds to load 16,255kB of data over 275 requests. Of that, 11,827kB is video content.

How video impacts mobile web performance and UX, part 3: detecting and remedying issues

6. Viewer experience (VX) and choice

Make sure the video and host page is intuitive. Let the viewer take control. Make it easy to:

  • Choose video quality – low quality, HD or 4K
  • Select and exit full-screen view
  • Change device orientation change
  • View and operate. Ensure the video fits the device screen and that buttons are intuitive
  • Allow playback when the device is offline.

7. Make the video accessible

To make video/audio accessible for:

  • Visually impaired people, provide a written transcript of the audio.
  • People with hearing impairments, provide subtitles.

For more advice on making mobile content accessible to a wide audience, the BBC Mobile Accessibility Guidelines are an excellent resource.

8. Minimize video start-up delay

The delay to start-up is caused by two essential processes:

  1. The authentication process (including digital rights management).
  2. The downloading of the video. Video files are subdivided into segments. A sufficient number of segments need to be downloaded to the buffer (temporary store on the client device), before the video starts to play.

A delay is inevitable, but the video should be optimized to ensure delays are kept to a minimum.

As can be seen from the 2016 data from Conviva study below, videos tend to take longer to start on mobile devices, both on WIFI and Cellular, than Tablet or Desktop. It’s no coincidence that mobile has the highest proportion of exits per attempt.How video impacts mobile web performance and UX, part 3: detecting and remedying issues

9. Keep the user informed

While the authentication, downloading and (re) buffering occurs, tell the user what is happening and/or distract them. Watching a spinning wheel icon can be frustrating.

10. Minimize video stalls

Stalls occur when too few video segments stored in the buffer to allow playback to continue. The video will not continue until sufficient segments have been downloaded (called re-buffering).

The key is to find balance between slow start and stalling, says AT&T’s Doug Sillars:

“The 2 biggest metrics for video are:

  1. Startup delay (how long from click to stream).
  2. Stalls (video stops, maybe a spinner).

These are (of course) interrelated.  If you startup too quickly – there will not be enough video stored locally on the device… and you might get a stall.  Or you can take too much data at the start (long startup delay), but have no stalls later.

There is a magic “Goldilocks” point in the middle – not too hot, not too cold – that balances the two factors.” 

11. Optimize bitrate, compression and segment size

Optimize bitrate, compression and segment size for the device and network connection.

  • Re-buffering typically occurs where the video is played at a speed, measured in bitrates (bits per second), that is too fast for the download speed (bitrate) of the network connection, so the buffer is emptied quicker than it is being filled.
  • Digital videos are divided into files, called segments, of 2 to 10 seconds, which are downloaded to the buffer and then played in order. Segments of optimum size for the connection will download, buffer and play faster.
  • A Codec (coder/decoder) is a tool for compressing and decompressing audio and video files. There are a number of different compression formats, e.g. MPEG-4, each with pros and cons. Different video quality and the client device/connection will influence choice of format.

12. Use adaptive bitrates.

Adaptive bitrate streaming creates and stores digital video at a number of different quality/speeds/bitrates. The video player on the client device requests the most appropriate of these based on a) network speed, b) device capability, and c) capacity of the buffer.

There are two types of adaptive streaming, DASH and HLS, because one industry standard that worked on all devices would be just too easy (find out more here).

13. Use a content delivery network (CDN)

A content delivery network speeds up how quickly web media, including video loads and plays on a mobile device by reducing the that the video has to travel between the original web server – e.g. your webserver in California, USA and a viewer in Timbuktu in Mali – by replicating and storing the video on servers around the world.

According to BuiltWith, 53.8% of the top 10k websites use CDNs.

Akamai Edge, which was one of the original CDNs, founded in 1999, remains one of the most popular. According to BuiltWith, Akamai is used by 11.4% of the top 10,000 sites, followed by Amazon CloudFront at 4% and MaxCDN at 1.3%.

How video impacts mobile web performance and UX, part 3: detecting and remedying issues

14. Host or embed?

Hosting websites on a third party network, and embedding the file, removes several headaches, including video compression, adaptive bitrates and engaging a CDN. This helps to explain why 15.2% of top 10k websites embed YouTube videos and 3.6% Vimeo, according to BuiltWith.

How to remedy problems with video / audio

1. Page weight or load speed issues.

Regularly check the key pages using a testing tool such as WebPageTest (this is the tool used by HTTP Archive).

If this highlights issues of excessive page weight, slow download speed, and it appears that video is a contributing factor (rather than oversized images or inefficient use of JavaScript), the options are:

  • Kill autoplay
  • Ensure the video is not preventing the page loading correctly
  • Move the video to a dedicated page (with a prominent picture and text link)
  • Use A/B testing to verify if this solves the issue.

2. Video fails or is slow to start or stalls during play

If the video performance is an issue, here are some troubleshooting tips to try:

  • Try loading the video to a dedicated video service such as Vimeo or YouTube. Compare the performance of the video on the third-party site, embedded on your site and with the self-hosted version to highlight if problems lie with the video, as opposed to the website, webserver or CDN (or lack of CDN)
  • Test the video with a tool such as AT&T’s Video Optimizer (requires development skills) to detect issues with video segmentation, compression, buffering etc. and fix them
  • Have the video re-edited to make it more concise; and optimized to improve bitrate and compression
  • Use or replace the CDN.

If video performs better on some devices and over different connections e.g. PC on cable versus smartphone on 3G:

  • Prepare a number of versions of the video in different formats, with different quality, bitrates and compression to suit the most common scenarios of device and network type
  • Use device detection to discover the client device, its capabilities and the type of connection to serve the most appropriate version of the video
  • Use adaptive bitrates.

Resources (and sources)

These resources are aimed at developers, but are useful for all (if you ignore the techie bits):

 

This is Part 3 of a series looking at how video impacts mobile web performance and UX. Read the previous installments:

t_twitter_ola_pwa_native.png

Google I/O: What’s going on with Progressive Web Apps?

At Google’s developer jamboree, Google I/O, last week the search giant paraded a host of big name case studies and compelling stats to herald its success with two initiatives to make the mobile web better and faster: Progressive Web Apps (PWA) and Accelerated Mobile Pages (AMP).

Progressive Web Apps are a Google innovation designed to combine the best features of mobile apps and the mobile web: speed, app-like interaction, offline usage, and no need to download anything.

Google spotlighted this relatively new web product at last year’s Google I/O, where the Washington Post showed off a newly-built Progressive Web App to enhance its mobile experience.

Whether companies believe in or plan to adopt Progressive Web Apps, the initiative (along with AMP) has done a fantastic job of highlighting a) the importance of making websites and apps lean and mean so they perform better on mobile and b) how ridiculously bloated, slow and inefficient websites and apps have become.

PWA and AMP are not the only answers to mobile bloat, but being led and backed by Google, they bring the potential for 1) broad adoption, 2) lots of resources, and 3) favorable treatment from Android, Chrome and Google Search.

What’s so great about Progressive Web Apps?

PWAs bring native app-like functions and features to websites. They should (depending on the quality of the build) work on all smart devices, adapting the performance to the ability of the device, browser and connection.

The key features that get people excited about PWAs are:

  • The ability to send push notifications
  • Option to save to the device (home screen and – now – app launcher), so it loads even faster next time
  • Ability to work offline (when there is no internet connection)
  • Make payments. One of the most significant PWA announcements at Google I/O was that PWAs can now integrate with native/web payment apps, to allow one tap payment with the users preferred provider, including Android Pay, Samsung Pay, Alipay and PayPal
  • Closer integration with device functions and native apps.

The margin of what native apps can do compared with a web-based app (N.B. PWAs do not have a monopoly over mobile web apps) is disappearing rapidly.

The last year has seen a remarkable 215 new APIs, allowing web apps to access even more of the native phone features and apps, announced Rahul Roy-Chowdhury, VP, product management at Google, in his Mobile Web State of Union keynote.

He pointed out that you could even build a web-based virtual reality (VR) app (if you wanted to), citing Within and Sketchfab, which showcase creations from developers around the world.

Who ate all the pies?

But the most compelling thing about Progressive Web Apps is their download size, compared with iOS apps and Android apps. Check out the size comparisons in the image below for two case studies featured at Google I/O: Twitter Lite and Ola Cabs (the biggest cab service in India, delivering 1 million rides per day).

  • Size of Twitter’s Android app 23MB+; iOS app 100MB+; Twitter Lite PWA 0.6MB.
  • Size of OLA Cabs Android app 60MB; iOS app 100MB; PWA 0.2MB.

Why does size matter? Performance on the web is all about speed. The smaller the size the quicker the download. Think SUV versus Grand Prix motorbike in rush hour traffic.

Interestingly, Twitter markets the PWA as Twitter Lite particularly targeted at people in tier two markets where connections may be inferior, data more expensive and smartphones less advanced; while Ola Cabs markets the PWA at second or third tier cites where there are similar issues with connections and smartphones.

This (cleverly) helps to position the PWA as non-competitive to their native apps.

Which companies have launched Progressive Web Apps?

A growing number of big name brands (see image below) have launched PWAs. These include:

  • Travel companies: Expedia, Trivago, Tui, AirFrance, Wego
  • Publishers: Forbes, Infobae, Washington Post, FT, Guardian, Independent, Weather Company
  • E-commerce companies: Fandango, Rakuten, Alibaba, Lancôme, Flipkart
  • Formerly native app-only companies: Lyft, Ola Cabs.

Google I/O: What’s going on with Progressive Web Apps?

At I/O, Google trumpeted the achievements of a number of companies, inviting several to share their experiences with the audiences – only the good stuff, clearly.

1. Faster speeds; higher engagement

m.Forbes.com has seen user engagement double since launch of its PWA in March (according to Google).

For the inside track see this Forbes article. The publisher claims its pages load in 0.8 seconds on a mobile device. The publisher was aiming for a Snapchat or Instagram-like experience with streams of related content along with app-like features such as gesture-based navigation.

In this video case study, embedded below, created for I/O, Forbes claims to have achieved a 43% increase in sessions per user and 20% increase in ad viewability.

The Ola Cabs PWA takes 1-3 seconds to load on the first visit – depending on the network, “including low 3G” Dipika Kapadia, head of consumer web products at Ola, told I/O attendees. On subsequent visits it takes less than a second as it only needs to download the real-time information, including cab availability.

Ola achieves this partly due to its size: the app is just 0.5MB of which only 0.2MB is application data. As it downloads it prioritizes essential information, while other assets download in the background.

2. Consumers readily download PWAs to their home screens

When mobile visitors are using the mobile app, they receive a prompt to save it to the home screen, so it loads faster next time. It does this by caching all the static parts of the site, so next time it only needs to fetch what has changed.

Twitter Lite, as Patrick Traughber, product manager atTwitter, told the Google I/O crowd, sees 1 million daily visits from the homepage icon.

Since launch of the Progressive Web App, in April 2017, Twitter has seen a 65% increase in pages per session and 75% increase in tweets.

3. Notifications

The ability to send notifications to mobile users to encourage them back to the app, used to be one of the big advantages of native apps over mobile web. No longer.

Notifying users about recent activity is very important to Twitter, said Traughber. And Twitter is taking full advantage of this capability, sending 10 million push notifications each day.

For the inside track on Twitter’s PWA, see this article.

4. Winning back customers that have deleted your native app

App-only companies face the challenge that users only download and retain a limited number of apps on their smartphone and will uninstall those that aren’t used as regularly as others, thus once deleted, it’s over.

Thus it is an eye-opener that 20% of Ola PWA bookings come from users who have previously uninstalled the native app.

See Google’s case study on Ola’s PWA.

5. PWAs appeal to iOS users

Compared with other mobile browsers such as Chrome, Edge, Opera and Samsung, the default browser on Apple devices, Safari, can be slower when it comes to adopting advancements in mobile web. This means Safari users won’t experience some of the more advanced features of PWAs, yet.

Despite this, brands are seeing improved mobile engagement after launching a PWA. Lancôme Paris has seen session length improve by 53% among iOS users, according to this case study of the Lancôme PWA, cited at Google I/O.

6. Conversions

According to Wego’s video case study, embedded below, created for I/O, the Singapore-based travel service has combined both PWA and AMP to achieve a load time for new users is 1.6 seconds and 1 second for returning customers. This has helped to increase site visits by 26%, reduce bounce rates by 20% and increase conversions by 95%, since launch.

If you need more impressive stats to make the case for a web app, visit Cloud Four’s new PWA Stats.


For more articles on mobile web performance see:

How video impacts mobile web performance and UX, part 1: data and download speed
How video impacts mobile web performance and UX, part 2: autoplay and audio
How to fix your bloated mobile website: fewer, better, smaller images
Optimizing images for mobile: right format, right size, right place, right device
How JavaScript impacts how fast your page loads on a mobile device

Andy Favell is Search Engine Watch’s columnist on mobile. He is a London-based freelance mobile/digital consultant, journalist and web editor. Contact him via LinkedIn or Twitter at Andy_Favell.

t47_top_100_youtube_content_breakdown.png

How video impacts mobile web performance and UX, part 2: autoplay and audio

Mobile video is a major up-and-coming trend in content, with brands everywhere converging on the new and lucrative mobile video market.

Mark Zuckerberg said on a recent shareholder conference call that he sees video as “a megatrend on the same order as mobile” – which makes mobile video, the intersection between the two, the ultimate sweet spot of engaging content to draw in new consumer eyeballs.

But sadly, there are still some technical hurdles to overcome before the mobile video experience is as smooth as companies would like it to be. In our previous installment we looked at how video can be a massive mobile data hog, and why it shouldn’t (but still does) have an impact on download speed.

In this part we’ll look at the contentious subject of autoplaying videos and their impact on mobile webpage performance, as well as how audio can delay page speed, and what kind of conditions make for a poor viewer experience (VX).

Our third and final part will consider some solutions that webmasters can enact to counter the issues with mobile video.

Video autoplay and page performance

Comparing the data on HTTP Archive for average content for the top 100 most popular sites (according to Alexa) with the top 1 million (shown above) reveals some interesting stats.

On average, video content is just 17kB (rather than 128kB) which is 2.1% of total page size, which, is a (comparatively) slender 828kB.

There are three reasons why this might be:

  1. Top sites avoid using video. (Considering these include video specialist like YouTube, BBC and CNN, this is the least likely of the three reasons).
  2. Top sites avoid using video on the (mobile) homepage. (The homepage of YouTube, for example, is made up of image links to videos, rather than videos themselves. Each video has its own webpage).
  3. Top sites use video more efficiently (as Dutton suggests).

Querying this apparent anomaly of video usage between all sites and the top 100 with the web performance experts at HTTP Archive, we received the following answer from Rick Viscomi, a leader of the HTTP Archive project and Developer Advocate at Google:

“I think the answer is: efficiency. To be more specific, I think it comes down to autoplay. HTTP Archive just visits a page and records the page load without clicking around. Autoplay videos would be captured on those visits, while click-to-play would not.

“Autoplaying is wasteful for everyone involved because a page visit does not always demonstrate intent to watch. One notable exception is YouTube, where visiting a watch page is definitely intent to watch. Keep in mind that only home pages are crawled by HTTP Archive. So my theory is the top sites choose not to autoplay in order to keep bounce rates low and conversions high.”

Notably, autoplay video and audio is also frowned on from an accessibility perspective. See these BBC guidelines for example. The reason for this is that people with visual impairments rely on screen readers to read aloud a webpage. Clearly if audio or video media starts to play (including advertisements) it will interfere with the screen reader and will make tricky for the user to find out how to make it stop.

The impact of audio on page performance

One of the most useful features of HTTP Archive or WebPageTest (from where it is captured) is the filmstrip which shows how a website loads on a mobile device second by second.

The loading process for New York Times mobile site on May 1, 2017 is captured by HTTP Archive in the image below. The audio story The Daily is at the top of the mobile page, above the fold, allowing us to see clearly how audio may delay page speed.

The audio does not finish loading until 22 seconds, when the play button finally appears and the site is visibly complete.

How video impacts mobile web performance and UX, part 2: autoplay and audio

Poor viewer experience (VX)

Assuming there is no autoplay, a correctly coded website should not require the video to be downloaded until the user requests it by clicking on the play button.

However as soon as the mobile user clicks on that play button, the level of expectation changes…

There are three potential VX problems with video:

  1. The video is too slow to start.
  2. It fails to start.
  3. It stalls during play back – this is due to (re) buffering or a dropping connection, typically shown by the spinning wheel.
  4. Poor video quality – or quality that is less an optimal for the connection.

Research by Conviva and nScreenMedia (November 2016) illustrates the difference in VX quality when a viewer is indoors (WIFI) or outdoors (cellular) failures for videos to start increases from 1.5% to 2.9% and buffering issues rises from 7.9% to 14.3% of views.

This has a noticeable impact on user satisfaction out of home 11.8% exit before the video starts versus 9.0% in home.How video impacts mobile web performance and UX, part 2: autoplay and audio

Research carried out by University of Massachusetts and Akamai, of 6.7 million video viewers, in 2012, also shows a growing intolerance to slow, stalling video.

Ramesh Sitaraman, Professor of Computer Science, UMass, Amherst tells ClickZ:

“Mobile users are impatient and abandon videos that do not start up quickly. However, they are more patient than users who have high-speed Internet access (say, Fiber), since their expectations of speed are lower in comparison.

“Mobile users start to abandon a video after waiting for about 2 seconds. By the 10 second mark, if the video has not started, roughly a fifth have abandoned.”

And on stalling:

“We don’t have data split out just for mobile. But, we studied a cross-section of users that included mobile. Overall, people watch videos for a shorter period of time when the video stalls than they would have otherwise.

“Roughly, a 1% increase in stalls leads to 5% decrease in the minutes watched.”

 

This is Part 2 of a series looking at how video impacts mobile web performance and UX. Read the previous installment: How video impacts mobile web performance and UX, part 1: data and download speed.

Or read on to the next part: How video impacts mobile web performance and UX, part 3: detecting and remedying issues.

t47_cisco_mobile_data_breakdown.png

How video impacts mobile web performance and UX, part 1: data and download speed

Mobile video is great. When it works.

Implemented correctly, video or audio *should not* impact the speed that pages load on a mobile device and when the play button is pressed, it needs to start quickly and work well.

Video content is top of the agenda for many brands. It is proving a great way to engage customers and visitors, but when viewed on mobile devices, particularly those on cellular connection, video (and to a lesser extent audio) should come with a health warning.

Users are increasingly impatient with slow-to-load and stalling video and will start to abandon a video after waiting just two seconds, research from UMass and Akamai shows.

This column, the first of three parts, will take a close look at how and why video affects page performance. In the second part, we’ll look at the impact of video autoplay and audio on page performance, as well as what makes a poor viewer experience (VX).

Finally, we’ll explore how to detect, avoid and remedy issues to prevent users tuning out.

Video is a massive mobile data hog

The provision and consumption of video on mobile devices via web and apps is growing rapidly. Mobile video is already 60% of total mobile data traffic worldwide and is expected to be 78% by 2021 according to Cisco’s Visual Networking Index (VNI).

All other elements will grow over the next five years, but their proportion of overall traffic will be less. Audio will be 5% compared with 8% today and mobile web will be 14% compared with 30% of traffic today.

Video – and audio – used wrongly or inefficiently will impact mobile user experience (UX) – or should we say: “viewer experience” (VX) or “listener experience” (LX) – massively, but not necessarily in the same way as oversized images and poor or inefficient use of JavaScript.

Images and JavaScript, as seen in previous columns, are the biggest causes of slow loading mobile web pages. As discussed below, video can still contribute to page size and therefore contribute to page load delays, particularly (it seems) where autoplay is used, as we will discuss below.

But the biggest impact on VX comes after page load when the video is slow, or fails, to start or stalls.

The two charts below are from HTTP Archive, which twice monthly records the page size and download speed of the homepages of the top 1 million sites to desktop and mobile devices, using the excellent WebPageTest.

The first chart shows the breakdown of content types by bytes – images, JavaScript, video, stylesheets, HTML and fonts – as an average of all homepages recorded on April 15, 2017.

Video is 128kB or 5.5% of the total bytes loaded (2312 kB or 2.3MB). This might appear small, until you realize that 97% of pages monitored by HTTP Archive have no video content (we examine this surprising stat below).

Pages that do have video content will therefore show a higher proportion of video content.

The second chart (captured April 15, 2017) shows the content breakdown for the homepage of the US digital agency Huge. Here video content is 727kB or 14.5% of the total bytes. The total weight of the page is 5MB, which is a homepage worthy of the company name, and, when measured, took 25.8 seconds to load on a mobile device, according to HTTP Archive.

To be fair, many agencies (digital, media, advertising et al) have surprisingly slow loading, heavy weight sites (considering the importance of digital to their businesses), though Huge is exceptionally large. A trimmer example is Young and Rubicam. On the same date the Y&R homepage took three seconds to load 783kB on a mobile device (on other dates it took nine seconds) according to HTTP Archive.

How video impacts mobile web performance and UX, part 1: data and download speed

Video shouldn’t affect page load size or download speed

Implemented correctly, video (or audio) should not impact the size of the webpage or the speed that pages load on a mobile device, according to the experts.

Even when video is present on the page, to render the page, the browser only needs to load the video container, teaser image, start button etc. it doesn’t need to download the entire video (as the visitor may not want to watch it at all). Thus video and audio ought not to be a significant proportion of content recorded by HTTP Archive / WebPageTest – as we will see when we look at the most popular sites.

Sam Dutton is a Developer Advocate at Google who provides educational materials and workshops for techies in mobile video. He explains:

“Video is not a big issue for page loading, since in general video shouldn’t be part of the cost of loading a web page.

“HTTP Archive measures the bytes to load a web page, not the total bytes crossing the internet. When you load most web pages, you don’t load a video (but you do load images, HTML, CSS and JavaScript).

“Top sites are less likely than less popular sites to require video for page load since (hopefully) the top sites realize the detrimental effects on page weight and (therefore) bounce rates, etc.”

 

This is Part 1 of a series looking at how video impacts mobile web performance and UX. Read the next installment: How video impacts mobile web performance and UX, part 2: autoplay and audio.

dna39_brand_safety_1.jpg

Why brands should care about brand safety in mobile advertising

Easily spotted on the mobile web: holiday ad next to plane crash story; ?Muslim dating ad next to KKK story; beauty ad next to domestic violence story; car ad next to emissions scandal story…

[This post originally appeared on our sister site ClickZ.com, but we thought it was so useful we wanted to share it here as well]

Let?s admit it we?ve all had an occasional giggle when we spot an ad prominently displayed next to inappropriate content on the web. But for advertisers this is no laughing matter.

An ad that is not displayed in a contextually appropriate environment is not only a waste of marketing budget, but is a potential embarrassment (if shared on social media) or, at worst, damaging to the brand?s reputation.

Research by inMobi (via eMarketer), July 2016, highlighted in this column on mobile ad fraud ?reveals that 26% of advertisers state that concerns over brand safety is preventing the take up of programmatic purchasing (buying ads on the fly via an ad exchange) of mobile inventory.

While this is considerably less than the 48% concerned about fraud/viewability, this is surely a matter the industry needs to address.

The examples pictured in this column were easily found on the mobile web. Try it yourself by selecting potentially controversial stories and waiting to see what ad loads (often ads load slower than the content).

The sites we have featured are not implicitly ?toxic?, such as pornography or gambling, but prominent news outlets where some stories will deal with unpleasant matters from time to time.

No one would want these news stories to go unreported. But that doesn?t mean that a holiday company wants its ad next to a plane crash story; a baby food brand ad next to a child sex abuse story; a Muslim dating service ad next to a KKK story; a beauty ad next to a domestic violence story or a car ad next to a story on the emissions scandal.

The ad business calls this brand safety or content adjacency. The issue is a real one.

But preventing brand safety issues has become increasingly complicated because:

  • Direct relationships between advertiser and publisher have increasingly been replaced by a web of intermediaries including ad exchanges and ad networks companies.
  • Many sites are implicitly safe, but publish eclectic content that could any subject ? i.e. news sites or news stories/user generated content (UGC) on social media sites.
  • Keeping track of ads displayed on mobile sites and ? particularly ? mobile apps presents a unique set of challenges, compared with desktop web.

As Kurt Hawks,?SVP of cross device and video at digital ad targeting specialist Conversant, explains:

Mobile ad tech is still maturing and while the mobile web operates similarly to desktop display, the in-app environment is a very different and more complex tech ecosystem. A rise in the intermediaries needed to execute in-app has resulted in a more fragmented digital supply chain that is more difficult to monitor.

Text, image and video-based analysis have gotten more adept at assessing brand fit within webpages, but a lack of mobile standardization, particularly in the in-app environment, can hinder the effectiveness of these tools. For example, the VPAID?(Video Player Ad-Serving Interface Definition) standard is still not universally supported within in-app environments yet.

This is the forth in our series of columns on mobile ad quality: see also:

  1. Mobile ad fraud?
  2. ?Combatting mobile ad fraud
  3. Mobile ad viewability

Brand safety issues easily found on the mobile web

Let?s take a look at some examples of what appears to be untargeted ads appearing next to stories on three mainstream news sites: Inquisitr, Washington Post and The Mirror; and/or via Google?s AMP (accelerated mobile pages) search results.

Please note that brand safety is subjective, we can only guess that the brand, the viewer and the publisher would deem these contexts inappropriate.

  1. It is hard to imagine many mainstream advertisers wishing to be associated with a story about a man being arrested for murder, a KKK march in favor of Donald Trump?s victory, or pictured above a picture of a KKK ceremony. There were plenty of examples spotted on various journals ? but this was the most controversial: a Muslim dating site alongside this INQUISITR story.
  1. Are stories of funerals or air crashes ever a good context for advertisers? But surely no travel brand would wish to be pushing overseas holidays against the backdrop of a funeral of the president of a football club wiped out in an air disaster as spotted alongside this Washington Post story.
  1. Child sex abuse is also a topic that most advertisers would consider toxic, but a brand, particularly one of the magnitude of Heinz is will be questioning how an ad for baby meals ended up topping this Daily Mirror story??about alleged child sex abuse at Chelsea Football Club.

Just to be certain, we checked the stories pictured in this column with Melody Gambino, director of marketing at brand safety expert, Grapeshot:

Every one of these examples is poignant. The key to brand safety is not only ensuring you don’t put your advertisement in front of bots or on spam sites, but also that the content surrounding your ad is not offensive. This can be in a broad sense (terrorism) or something specific to your brand (emissions testing for VW, for example).

But no one can say for certain what is considered brand safe or not except the advertiser, explains Melody Gambino

Brand safety means different things for every brand and every campaign, so clarity about what it means for you is imperative to ensure you are getting the most from your brand safety partners.?

Defining brand safety

In the useful New Rules of Brand Safety, ?Grapeshot gives the following definition for brand safety:

The term ?brand safety? is notionally understood. It represents an environment that is fundamentally not hostile, will not cause perceptions of uncomfortable association or, worse, spur unwelcome sharing or commenting.

The costs of an error in this arena can mount quickly, from the need to craft defensive counter-messaging to lost sales. Only after the fact does the degree of damage become clear.

Dirty dozen of toxic content categories:

There are 12 different content categories which, according to the report, tend to be considered toxic and are routinely excluded by agencies and brand safety tools. These are adult, arms, crime, death or injury, online privacy, hate speech, military conflict, obscenity, illegal drugs, spam or harmful site, terrorism and tobacco.

Why brands should care about brand safety in mobile advertising

CASE STUDY

Based on these criteria, the three stories pictured above ? the KKK organizer?s arrest, the Chapeco funeral and the Chelsea abuse allegations ? all appear to fail the toxic test.

Presumably a rape story, even when associated a classic film such as Last Tango in Paris, is deemed toxic content. But should it be considered universally inappropriate for all brands?

The following ads have no contextual relevance to the film or the news story, but is this an association that charities or luxury brands should avoid? N.B. if you perform a mobile or online search on this story, you will find plenty of other examples, these are not isolated cases:

Why brands should care about brand safety in mobile advertising

Targeted or untargeted?

Advertisers attempt to improve the impact of ads by targeting the ads at visitors based on the publisher, the visitor, their location, and contextual relevance of the story using keywords, images and metatags.

There is little evidence targeting in the Last Tango rape story, but the following three examples suggest contextual targeting at its most unfortunate.

Why brands should care about brand safety in mobile advertising

  1. The Volkswagen emissions story isn?t a universally toxic topic ? but it is one that auto manufacturers, such as VW, should and do seek to avoid. The ad targeting software appears to have picked up on the keyword ?Volkswagen? on this Chicago Tribune story to serve up ads for a VW leasing service. Unfortunately the ad targeting failed to pick out the word ?emissions?, so did not put the break on the ad.
  1. In the second example, the ad targeting seems to pick out the keywords ?makeup tutorial? in this Mediaite story?to serve up an ad for a Beauty app and a recruitment ad for models. To a computer this will look like a good opportunity, but no beauty brand will want to be associated with the use of makeup to hide domestic violence.
  1. It is unlikely that the CBC house ad ?Holiday like you mean it? is contextually targeted at?this story 3 about drug use by Hitler and Nazi Army, but a reader would be forgiven for thinking so.

How brand safety works

There are two key methods for avoiding brand safety issues:

  • Blocking websites/URLs that are known to contain contentious material.
  • Detecting context from keywords either a) pre-bid, preventing the ad space being purchased at the exchange) or, where not possible, b) post-bid, where the ad is blocked from appearing on the page.

The first approach relies on agencies maintaining vast blacklists (and whitelists) of websites. Ad technology then blocks the ads from displaying on these blacklisted sites. The problem with this method is that it assumes that all content on blacklisted sites is bad for business and all content on whitelisted sites is good for business ? which as we have seen above is not the case.

The second approach is more complicated. Ad quality/verification software, from vendors such as Integral Ad Science and Meetrics scan websites for possible issues for advertisers.

Jason Cooper, general manager, mobile at Integral Ad Science, tells how it works:

When web pages load they are requesting content from all across the Internet; text, copy, images, advertising content, tracking and analytics pixels among others. In each one of these requests, a little tout runs ahead declaring the page that is making the request; by intercepting that call, a verification vendor can decide whether that page meets the brand safety threshold of an advertiser before allowing the ad to serve.

However, apps don’t send URL’s, in fact identifying the app name requires a number of different strategies and is something that will be solved incrementally over time.

Issues with mobile (apps)

One advantage of native apps, is that they are scanned ? particularly with the Apple Store ? for malicious code and inappropriate content, before being admitted to the apps stores. However this does not take account of individual stories, user generated content or content pulled in from third party sites. Unfortunately, as native apps use proprietary code, rather than the web technologies, the web-based (JavaScript) scanning techniques used by the verification vendors is ineffective.

Felix Badura,?director product development at Meetrics, explains:

It is not possible to apply state-of-the-art brand safety technology to the in-app environment due to technical limitations with regard to the interplay of native code (e.g. Java, Swift) and web code (HTML, JavaScript) inside the webview container that actually displays the ad.

Due to the fact, that native apps and content loaded via a webview cannot exchange information, JavaScript based ad verification for instance cannot scan the content of the app on the fly.

Tips and common mistakes with brand safety

  • Don?t assume that because you are buying ad space on a known app it will be safe for your brand. Apps don’t need to be porn free to tick the box of ‘safe’. An article about performance enhancing drug scandals next to Reebok or Nike ads can be equally as damaging. ? Melody Gambino, Grapeshot.
  • Brands must be especially vigilant and engage vendors that have robust brand safety capabilities (semantic analysis of text; tags; imagery and tonality of web pages and apps; video-level data), but must also ensure these partners are capable of handling the nuances of brand safety in-app. ? Kurt Hawks,
  • Only serve ads via the big marketers like AdMob or MoPub and keeping the pressure high on insisting to have a third party measuring the data. ? Felix Badura,
  • While it is a good idea, to retrieve and analyse the Package names of the apps where an ad is running, one should be aware that even problematic apps might be uploaded using inconspicuous names to stay below the radar. ? Felix Badura, Meetrics.

This is Part 39 of the?ClickZ??DNA of mobile-friendly web? series.

Here are the recent ones:

 

Andy Favell is ClickZ columnist on mobile. He is a London-based freelance mobile/digital consultant, journalist and web editor.

Contact him via LinkedIn ?or Twitter @Andy_Favell.