We’re often told that the web is increasingly mobile, and that it is imperative for businesses to adapt their marketing strategies to be ‘mobile-first’ in order to capitalize on this shift in internet behavior.

But just how mobile is the web in 2017, and what does this mean for search?

Leading SEO and content performance platform BrightEdge today released a new report which sheds light on this question, and on the steadily widening gap between mobile and desktop search.

I spoke to Erik Newton, VP of Customer Marketing and Head of SEO at BrightEdge, about the report’s findings, Google’s mobile-first index tests, and how SEOs can adapt their strategy to account for the increasing divergence between desktop and mobile.

Majority mobile: 57% of web traffic is now mobile & tablet devices

In one of the key findings of the research, BrightEdge reports that 57% of web traffic now originates from mobile and tablet devices – meaning that close to 6 out of every 10 consumers are using a mobile device. Businesses who still aren’t optimizing for mobile, therefore, are ignoring a decisive majority of potential customers.

Even more noteworthy is the finding that the same query on the same search engine generates a different rank on mobile and desktop 79% of the time.

Among the top 20 ranked results, the gap is less pronounced, with 47% of queries differing between devices – but this still means that close to half of rankings differ.

And 35% – more than a third – of the time, the first page that ranked for any given domain was different between mobile and desktop SERPs.

In a press release about the research, BrightEdge commented that these figures indicate a “significant shift to a new mobile-first index”. I asked Erik Newton whether this means that BrightEdge believes Google’s mobile-first index is already being rolled out. Most SEOs believe we are still awaiting the official launch of the new index, but is BrightEdge seeing otherwise?

“We are seeing a divergence of rank and content between the two devices, and we have seen the data move in both directions over the last few months,” says Newton. “We believe that Google is testing and calibrating, as they have with other major shifts, to prepare for the separate mobile index.”

This fits with Google’s usual M.O. around big algorithm updates, but it also means that whatever strategies SEOs are planning to deploy when the mobile-first index finally rolls around, now might be the time to start testing them.

And for those who are still biding their time, they may already be losing out.

How are businesses really doing on mobile?

In the marketing industry, we’ve been talking for what feels like years, with increasing urgency, about the need for our campaigns and our web presences to be mobile-friendly. Or mobile-responsive. Or mobile-first.

But how are businesses really doing with this? Are marketers doing enough, even in 2017, to optimize for mobile?

“For most of the businesses that grew up on desktop, we see them using a desktop frame of reference,” observes Erik Newton. “We see evidence of this tendency in web design, page performance, analytics, and keyword tracking.

“We believe that Google gives the market signals to move forward and toward mobile faster. This is one of those times to push harder on mobile.

“Some of the newer companies, however, are mobile-first and even mobile-only. They are more likely to be app-based, and have always had majority mobile share.”

As we’ve seen from the figures cited in the previous section, using desktop as a frame of reference is increasingly short-sighted given the widening gap between desktop and mobile rankings. But how, then, should marketers plan their search strategy to cater to an increasing disparity between the two?

Should they go so far as to split their SEO efforts and cater to each separately? Or is there a way to kill two birds with one stone?

“The research report has some specific recommendations,” says Newton.

“One – Identify and differentiate mobile versus desktop demand.

“Two, design and optimize websites for speed and mobile-friendliness. Three, use a responsive site unless your business is app-based and large enough to build traffic through app distribution.

“The first challenge is to be even equally attentive to both mobile and desktop. We find that many brands are not acutely aware of the basic stat of mobile share of traffic.

“Additionally, brands can analyze the mobile share among new visitors, or non-customers, to see what kind of a different role it can play for people at different stages of the customer journey. For example, my mobile traffic is 32% higher among new visitors than overall visitors, and my mobile-blog-non-customer is 58% higher. That’s a place I should be leaning in on mobile when communicating to non-customers.

“Brands do not need to split their SEO efforts, but they do need to decide that some content efforts be mobile-first to be competitive.”

It can be difficult for brands who have traditionally catered to desktop users and who are still seeing success from a desktop-focused strategy to break away from this mindset and take a gamble on mobile. However, the figures are convincing.

What’s most evident is that it isn’t enough for SEOs and marketers to wait around for the launch of Google’s mobile-first index: it’s already being tested, and when combined with the growing proportion of mobile web traffic, brands who wait to develop a mobile-first strategy are increasingly likely to miss out.

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.

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?

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

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.

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.

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:

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

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.

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:

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.

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?

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.

Work out how you will balance page speed with attractiveness, quality, impact, page speed, efficiency and accessibility.

The need for speed

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:

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.

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.

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

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:

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.

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.

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.

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

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.

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

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.