Tag Archives: mobile web

PWA-1-1024x705.png

Progressive Web Apps versus Android Instant Apps: Which is better for marketers?

Much has been made of the fight between mobile apps and the mobile web, but the line between the two is no longer as clear-cut as it used to be.

Broadly speaking, a mobile-friendly or mobile-responsive website is less costly and time-consuming to develop than a native mobile app, and tends to attract a wider audience – it’s quick to access, with no downloading or storage required.

Native mobile apps, meanwhile, tend to offer a better user experience and see more engagement from a dedicated core of users who are loyal enough to download a company’s app and come back to it time and time again.

But in the last couple of years, two hot new contenders have been added to the mix which aim to combine some of the best features of the mobile web and the app world for a better all-round mobile experience. They are: Progressive Web Apps (PWAs), and Android Instant Apps.

Image via Google Developers

Both Progressive Web Apps and Android Instant Apps are Google initiatives that put a new spin on the traditional mobile app. Both aim to provide a faster-loading, slimmed-down mobile experience; so you can be forgiven for wondering what exactly the difference is between the two.

In this article I’ll sum up the key features of Progressive Web Apps and Instant Apps, look at the differences between the two, and examine which offers a better proposition for businesses who are considering investing in one or the other.

What are Progressive Web Apps?

Andy Favell recently wrote a great piece for Search Engine Watch about the latest developments with Progressive Web Apps in the wake of Google I/O. In it, he explained:

“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’s Developer page about Progressive Web Apps describes PWAs as “user experiences that have the reach of the web and are reliable, fast and engaging”. While at base PWAs are mobile webpages, they are designed to act and feel like apps, with fast loading and offline usage.

This immediately eliminates one of the biggest drawbacks of the mobile web: that mobile web pages depend on an often-shaky data connection that can lead to a poor experience and long, frustrating load times.

Progressive Web Apps versus Android Instant Apps: Which is better for marketers?

Image via Google Developers

Progressive Web Apps can also be saved to a user’s home screen, so that they can be launched with the tap of an icon just like a regular app can.

Google encourages developers to build Progressive Web Apps to an established standard, which when met, will cause Chrome to prompt the user to add the PWA to their home screen.

Brands who have already jumped on the PWA bandwagon include Twitter (whose PWA, Twitter Lite, sees 1 million daily visits from users’ homepage icons), Forbes, Expedia, Alibaba, the Washington Post, and even former native app-only companies like Lyft.

PWAs already offer many traits that we associate with native apps, including push notifications, geolocation, access to device features like the camera and microphone, and as mentioned above, offline working and icons on the home screen.

At the same time, they give organizations access to the benefits of the mobile web including easy discoverability and shareability (just send a link), universal access regardless of device (no need to release a separate iOS or Android app – although PWAs don’t quite have full functionality on iOS yet; more on that later), and the ability to bookmark individual links.

This sounds like a very compelling proposition for companies who aren’t sure whether to invest in a mobile site or a mobile app, or who want to significantly improve the experience of their mobile site for users.

So why did Google, after already having developed Progressive Web Apps, go on to launch Android Instant Apps in 2016? What is the difference between the two?

What are Android Instant Apps?

Android Instant Apps are fully-fledged native Android apps that are designed to work in a very specific way. Like Progressive Web Apps (or any mobile site, for that matter) they can be shared via a link, which when opened will give the recipient access to a stripped-down version of the app.

So, in the example that Google used at I/O in 2016, one user could send another a link to the recipe section of the Buzzfeed Video app, who would then be able to open it and access the part of the app that was linked to – in this case, recipe videos – without downloading it.

Progressive Web Apps versus Android Instant Apps: Which is better for marketers?

Screencap via Android Developers on YouTube

If they wanted to access the rest of the app, they would need to then download the full version, but this could be done easily without performing an additional search in the Play store.

Android Instant Apps are designed to be effectively the same as using a regular Android app, to the point where users may not even notice that they are using the feature. The only indicator that they are accessing an Instant App is a simplified app interface.

Apart from Buzzfeed, brands known to be using Instant Apps include The New York Times Crossword, Periscope, Viki (a video streaming service for Asian TV and film), football app Onefootball and video hosting service Vimeo.

Gif of Android Instant apps from various brands displayed on smartphone screens

Some of the brands currently using Android Instant Apps, including Onefootball, Vimeo and The New York Times. Image via Android Developers Blog

Android Instant Apps set out to tackle many of the same problems as Progressive Web Apps: they are designed to launch quickly, provide a user-friendly interface, and avoid cumbersome and data-costly downloads.

The feature is designed as an upgrade to existing Android apps, rather than being an additional app that companies need to develop. This is good news for organizations who already have an Android app, and for those who do, upgrading probably seems like a no-brainer.

But for those who might not have an app yet, do Instant Apps make a persuasive enough case by themselves for developing an Android app? Or might they be better off putting their time into developing a Progressive Web App?

Progressive Web Apps versus Android Instant Apps

On an individual feature basis, here is how Progressive Web Apps and Android Instant Apps compare to one another:

Progressive Web Apps Android Instant Apps
App-like interface App-like interface
Offline usage Offline usage
Fast loading Fast loading
No need to download an app/visit the app store No need to download an app/visit the app store

✘ Unless you want to access the full version of the app

Shareable via a link Shareable via a link
Icon on the home screen Icon on the home screen
✘ Lacks integration with some smartphone features (e.g. flashlight, contacts, Bluetooth, NFC) All the features of a native app
✘ Not yet supported by every OS (PWAs can be used on iOS/Safari and Windows/Microsoft Edge but have no offline functionality or push notifications) ✘ Android only
Can be crawled by search engines ✘ Not discoverable by search engines
No need to develop a fully-fledged app

✘ But you do still need to develop a web app that meets Google’s standards

✘ Need to develop a fully-fledged Android app

Unless you already have one, in which case you can just upgrade

In that list, you may have seen some features which especially appeal to you, some which might be deal-breakers and have put you off one option or the other, or some “cons” which aren’t enough of a deal-breaker to put you off.

Point-for-point, however, the two look about equal. So in the interests of settling the debate: which one is the better option for marketers?

Which is better for marketers: Progressive Web Apps or Android Instant Apps?

Well… Sorry to let you down after you’ve made it this far, but the issue isn’t quite as clear-cut as I’ve framed it to be.

As with the “mobile app versus mobile web” debate, no one option is inherently better than the other (although one can be cheaper or quicker to develop than the other), because it all depends on the needs of your brand and what you want your mobile experience to deliver.

What PWAs and AIAs have done is mitigate some of the biggest drawbacks of the mobile web and mobile apps, respectively, so that it’s possible to almost have the best of both worlds no matter what you decide.

If you’re trying to decide between building a regular mobile site (whether mobile-optimized, mobile-friendly or mobile-first) or a PWA, a Progressive Web App is a no-brainer. And if you already have an Android app (or were going to build one), upgrading to an Instant App would bring a lot of additional benefits.

Progressive Web Apps versus Android Instant Apps: Which is better for marketers?

Image via Android Developers

The lack of iOS support for both is an obvious drawback, although in this respect PWAs just edge out, as Safari is reported to be considering support for Service Workers, the feature that enables PWAs’ offline usage and push notifications. (Chrome, Firefox and Opera all currently support Service Workers, and Microsoft Edge is in the process of developing support).

Ultimately, the best solution might be a combination of several. Google Developer Advocate Dan Dascalescu points out in his article ‘Why Progressive Web Apps vs. native is the wrong question to ask’ that “if you already have a product, you already have an app, a web presence, or both, and you should improve both. If you don’t have a product, then if you have the resources to build native Android + native iOS + web apps, and keep them in sync, go for it.”

If you don’t need Android-specific native features, he reasons, then you can cover your bases with the combination of a PWA and a native iOS app. Though in some cases, building a PWA can lead to increased adoption even on iOS; AliExpress, Alibaba’s answer to eBay, saw an 82% increase in conversion rate on iOS after launching a Progressive Web App.

Progressive Web Apps have been around and available to organizations a little longer than Android Instant Apps, so there are a few more use cases and examples of why they work than there are for Instant Apps. Over the next year or so, I predict that we’ll see wider adoption of Instant Apps, but only from those brands who had already developed Android native apps anyway.

Ultimately, for those companies for whom developing a native Android app makes sense, nothing has really changed. Companies who were undecided between investing in mobile web versus a native app may have more reasons to plump for mobile web now that Progressive Web Apps have come along – especially once PWAs have full support in Safari and Microsoft Edge.

I can see PWAs becoming the more widespread choice for organizations once they work across all devices, as they truly do combine the best features of mobile web and apps, while also being universally accessible. But they’re not going to eliminate the need for apps entirely.

The upshot of it all is that whether organizations adopt Progressive Web Apps or Android Instant Apps, users will get a better experience – and that benefits everyone.

 

This article was originally published on our sister site, ClickZ, and has been reproduced here for the enjoyment of our audience on Search Engine Watch.

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.

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_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.

Google Search for Events Gets Overhauled by @MattGSouthern

Google has overhauled search results for events on its app and the mobile web.

The post Google Search for Events Gets Overhauled by @MattGSouthern appeared first on Search Engine Journal.

Google rolls out new event search feature on app & mobile web

Searches for events will now surface a list of activities that include location and date details. The post Google rolls out new event search feature on app & mobile web appeared first on Search Engine Land.

Please visit Search Engine Land for the full article.
5671380.gif

Now You Can Find ‘Style Ideas’ With Google Image Search by @MattGSouthern

Google has introduced a new feature called “style ideas” for image searches on the mobile web.

The post Now You Can Find ‘Style Ideas’ With Google Image Search by @MattGSouthern appeared first on Search Engine Journal.

Website-speed_Infographic_Skilled_Final.jpg

How speed affects your site’s performance [infographic]

Site speed is an important factor for SEO and conversion, but do we really understand its impact?

There is increased online competition and a decreased attention span that makes it hard for a site to convert visits into sales, or even to increase traffic.

Site speed can significantly affect a user’s decision on whether a visit to a page should be prolonged (or repeated) and this cannot be overlooked by any site owner.

In fact, a page’s load time affects several key areas:

Sales

It’s no surprise that 79% of customers are less likely to buy again from a site that lacks a speed optimised performance. As everything gets faster, you cannot afford to stay still.

Mobile experience

Mobile experience is highly linked with site speed as this is among the most important factors that affect the length of a visit. 64% of smartphone users expect a page to load in less than four seconds and if your page fails to do so, you might need to optimise it.

User experience (UX)

Customer experience and mobile experience are relevant to the user experience and what a visitor thinks of your site’s performance. A page that loads in 10 seconds has fewer chances to be visited again, comparing to a page that loads in just 2 seconds.

Revenue

If your site’s speed affects your page’s sales, then it also affects your revenue. It’s interesting to note that 40% of people will abandon your website if it loads in more than three seconds.

SEO

Page speed affects the traffic to your site and even a one-second delay in page load can result in 11% loss of page views. Moreover, the introduction of AMP is another proof of Google’s focus on site speed and although it’s still early to draw conclusions, users seem to enjoy the feature when it’s available in search results.

Conversion

Conversion is also affected by a site’s speed and even a one-second delay can reduce conversions by 7%.

Quick tips to improve your site’s speed

  • Test your current speed
  • Measure mobile performance
  • Monitor analytics for customer behaviour
  • Reduce heavy images and scripts
  • Remove unnecessary plugins
  • Avoid CSS files

Skilled.co created an infographic that provides an overview of 12 case studies which prove why site speed matters.

Here are some examples that may convince you to optimise your page’s load time.

 

tweet.jpeg

Three reasons you might not need Google AMP after all

Mobile devices currently account for more than half of all internet use on a global level, and yet, many websites are still not mobile-friendly.

Even those that are designed to look good on smaller screens still run the risk of loading slowly as a result of poor image optimization or heavy reliance on JavaScript and other large files.

Smartphones have less powerful hardware and network connections than desktop and laptop devices, and Google wants to be sure that the websites they refer people to meet user expectations.

The data shows that 40% of people abandon websites that take more than three seconds to load. AMP, which is short for Accelerated Mobile Pages, is Google’s answer.

How does AMP work?

AMP works by limiting the types of elements that web publishers can use, to ensure the pages can be downloaded and displayed quickly. Google’s servers then cache the web’s AMP-powered pages, and they pre-render in the background while people are still perusing their search results, to further help minimize page rendering times.

Using this protocol, pages cannot become too bloated with tracking scripts and ads. By controlling the amount of JavaScript and only allowing limited HTML and CSS, Google says they can load websites up to 85% faster.

Do you actually need AMP?

What Google won’t tell you, of course, is that you may not actually need AMP to maximize your site’s speed. The company has too much riding on the success of the AMP initiative to admit that it’s redundant – at best – in many situations.

In fact, if you’ve already been doing everything you can to improve your site’s mobile loading speed, then implementing AMP may involve more disadvantages for you than advantages.

Does your site have a lot of pages that aren’t articles? Do you depend on third-party tools for lead capture or audience tracking? Do you monetize your site using an ad engine that isn’t among the relatively few supported by AMP?

If you answered yes to any of the above questions, then when it comes to maximizing speed, you’re probably better off using your own knowhow and infrastructure, as opposed to Google’s. There are even mobile-oriented website building tools, such as Duda, that can do everything AMP does, but without many of the disadvantages.

Here are three situations in which AMP isn’t for you:

1) You’re already using a content delivery network (CDN)

When you use a CDN to host your image files and other content, your audience queries are routed to the networked server that’s physically closest to each site visitor.

Many CDNs also use smart file caching rules, sophisticated session routing optimization algorithms, purging of unused files and built-in image compression to minimize load times. This is extremely effective for speeding sites up, in many cases reducing latency by up to 50%.

Even if you don’t feel the need to invest in a CDN, though, there’s a lot you can do on your own to minimize the bandwidth demands of your images and code.

You can implement “lazy loading,” or deferred loading of images, so that your audience can begin reading your content before each image appears on the page. In addition, tools like CompressJPEG or CompressPNG can dramatically reduce your image file sizes.

With these solutions in place, you can feel good about sidestepping AMP.

2) You’ve already adjusted the code on the mobile version of your site

Mobile-friendliness is about much more than designing for smaller screens. One of the ways AMP minimizes page load times is by disabling plugins and other JavaScript assets. This ensures that there isn’t much code that needs to download to the visitor’s web browser before the page is viewable.

But you don’t need AMP to disable your most sluggish mobile-unfriendly plugins and other JavaScript-powered components.

If you’re working in WordPress, then this isn’t actually so hard to set up. All you need to do is adjust your theme’s functions.php file to include some “dequeue” commands by adding a code snippet along the lines of:

if(wp_is_mobile()){

wp_dequeue_script( ‘cufon_handle’ );

}

This particular function will determine if the visitor is on a mobile device, and if so, will disable the Cufon plugin, a useful font replacement tool.

Add additional versions of this code to account for all the plugins and scripts you want to disable. Keep in mind, though, that in order to dequeue a script, it must first be enqueued. If it is not, this solution will have no effect.

3) Your site’s mobile version only has a single CSS reference

Style sheets, as powered by CSS files, are generally relatively small, but if you have several of them, then your audience’s devices will need to query your servers for each one separately.

Often, it’s the query volume, rather than the weight of the files, that can slow down content loads.

The solution is to consolidate all of your style sheets into one master CSS resource. To get started with this, set your website code to reference an external CSS file called from your CDN, rather than placing the CSS in-line through all the pages on the website. Then, use a tool like CSS Minify to clean up your CSS file before hosting it on your CDN.

In this sense, CSS files are similar to images. They should be consolidated, compressed, minified and hosted via a CDN. With all this in place, you’ll kill code bloat and unlock faster load times, once again negating the need for AMP.

To AMP or Not to AMP?

If you’re already doing everything you can to reduce the number and sizes of resources required to load your content, then your pages might be as fast as they ever will be.

However, speed isn’t to be taken too lightly. As long ago as 2012 – before the dominance of the mobile web, mind you – Amazon estimated that each second of added load time per page costs the ecommerce giant some $1.6 billion in annual sales.

If you’re struggling to get your page load times down to within four or so seconds, which is where it should be for the optimal user experience, then you may want to consider using AMP.

At this time, Google doesn’t officially consider AMP implementations to be a ranking signal, although some websites have started to see lower click-through rates since AMP pages have started aggregating in mobile SERPs. Carefully consider the costs and benefits of using AMP for mobile speed before you dive in – you may be giving up more than you need to.

Publishers are struggling with AMP page monetization

Google’s Accelerated Mobile Pages (AMP) initiative has gained significant traction in the past 12 months, and high-profile publishers such as The New York Times, Wall Street Journal and Hearst are among the many companies that have adopted AMP.

According to a DoubleClick study conducted earlier this year that looked at various performance metrics of AMP pages across 150 publisher sites, the majority of publishers using AMP saw increased eCPMs.

But now, The Wall Street Journal is reporting that many publishers using AMP are seeing their AMP pages generate substantially less revenue than their non-AMP mobile pages. According to the Journal, “Multiple publishers said an AMP pageview currently generates around half as much revenue as a pageview on their full mobile websites.”

One of the reasons for the lower revenue is likely that while AMP supports around 75 different ad providers, including many of the largest, there are fewer types of ad units available.

“AMP pages rely heavily on standardized banner ad units, and don’t allow publishers to sell highly-customized ad units, sponsorships or pop-up ads as they might on their own properties,” The Wall Street Journal’s Jack Marshall explained.

Those ad units that AMP doesn’t support might make it easier for publishers to maximize their revenue, but some of them, particularly pop-ups, are the very ad units that degrade user experience.

For now, Google is satisfied with AMP’s ad capabilities and Richard Gingras, Google’s VP of news, suggests that some publishers are seeing lower ad revenue on their AMP pages because they’re not taking full advantage of AMP’s ad capabilities. That said, he acknowledged that AMP is in its early stages.

“We want to drive the ecosystem forward, but obviously these things don’t happen overnight,” Gringas stated. “The objective of AMP is to have it drive more revenue for publishers than non-AMP pages. We’re not there yet.”

AMP is probably the future, regardless of revenue considerations

Despite the fact that Google is aware that some publishers adopting AMP are generating less revenue as a result, it will likely have time to improve AMP’s capabilities. That’s because publishers by and large seem prepared to stick by AMP, even if it’s costing them money in the short term.

One reason for this is that AMP traffic is growing. According to CNN chief product officer Alex Wellen, 20% of CNN’s search traffic now goes to the news outlet’s AMP pages, and AMP traffic has increased by 80% in the past two months.

The other reason publishers are giving AMP the benefit of the doubt is that they strongly suspect Google will favor AMP pages in a big way going forward. As one publisher put it, “Publishers who are not using AMP will probably be penalized.”

Even if that doesn’t come to pass, the expectation that Google will increasingly favor AMP pages over non-AMP pages will probably remain a powerful motivator for publishers to adopt it regardless of revenue considerations.