Google is offering a mobile web developer certification for the low-low price of just 99 dollars!
The post Google is Offering a Mobile Web Developer Certification for $99 by @MattGSouthern appeared first on Search Engine Journal.
Google is offering a mobile web developer certification for the low-low price of just 99 dollars!
The post Google is Offering a Mobile Web Developer Certification for $99 by @MattGSouthern appeared first on Search Engine Journal.
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.
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.
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.
“Four, understand different online consumer intent signals across desktop and mobile devices. Five, produce separate mobile and desktop content that resonates on multiple device types.
“Six: focus on optimizing mobile content and mobile pages to improve conversions. Seven: track, compare, and report mobile and desktop share of traffic continuously.
“Eight, measure and optimize the page load speed of the mobile and desktop sites separately. And nine, track your organic search rank for mobile and desktop separately.
“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.
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.
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.
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.
Twitter Lite is a faster, data friendly way for people to use Twitter to see what’s happening in the world.
— Twitter (@Twitter) April 6, 2017
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?
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.
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.
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?
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?
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.
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.
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 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:
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.
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.
Testing is critical improving to website performance and usability.
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.
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.
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.
As with all aspects of web development, user testing is critical to improving site performance and usability.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
“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 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 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.
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:
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 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.
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.
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.
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 is also affected by a site’s speed and even a one-second delay can reduce conversions by 7%.
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.