Tag Archives: MOBILE

Google-updated-homepage.png

What do we know so far about Google’s new homepage?

Google has released a new, feed-based mobile homepage in the US, with an international launch due in the next two weeks.

This is perhaps the most drastic and significant update of the Google.com homepage (the most visited URL globally) since Google’s launch in 1996.

The upgraded, dynamic entry point to the world’s biggest search engine will be available initially on mobile devices via both the Google website and its mobile apps, but will also be rolled out to desktop.

Let’s take a look at what’s changing and how, as well as what it might mean for marketers.

What’s different about the new homepage?

Google’s new homepage allows users to customize a news feed that updates based on their interests, location, and past search behaviors.

On the Google.com website (via a mobile device), there are now four icon-based options: Weather, Sports, Entertainment, and Food & Drink.

The ‘Weather’ and ‘Food & Drink’ options can be used straight away, as they take the user’s location data to provide targeted results. The ‘Sports’ and ‘Entertainment’ options require a little more customization before users can benefit from them fully. Without this, Google will just serve up popular and trending stories within each category.

In the example below, I tapped on the ‘Sports’ icon, then selected to follow a baseball team, the Boston Red Sox. Based on this preference, Google then knows to show me updates on this team on my homepage. The results varied in their media format, with everything from Tweets to GIFs and videos shown in my feed.

What do we know so far about Google’s new homepage?

This means that rather than encountering the iconic search bar, Google logo, and the unadorned white interface we have all become accustomed to, each user’s feed will be unique. As I start to layer on more of the topics I am interested in, Google gains more information with which to tailor my feed.

On the Google mobile app, based on my selection above, my homepage looks as follows:

What do we know so far about Google’s new homepage?

This is quite a big departure and is an experience we should expect the Google.com website to mirror soon. For now, the latter retains enough of the old aesthetic to be recognizable, but the app-based version is more overt in its positioning of suggested content.

The trusty search bar is still there, but users are encouraged to interact with their interests too. The interface is designed for tapping as well as typing.

Sashi Thakur, a Google engineer, has said of the launch,

“We want people to understand they’re consuming information from Google. It will just be without a query.”

It is essentially an extension of the functionality that has been available in Google’s Android app since December. Google will also continue to use push notifications to send updates on traffic, weather, and sports, based on the user’s set preferences.

Why is Google launching this product now?

Google has struggled to find a significant commercial hit to rival its hugely lucrative search advertising business. That business relies on search queries and user data, so anything that leads users to spend more time on Google will be of significant value.

The same motive has led to the increased presence of Google reservations, which now allow users to make appointments for a range of services from the search results page.

As Google stated in their official announcement, “The more you use Google, the better your feed will be.”

Users type a query when they have an idea of what they want to find; Google is pre-empting this by serving us content before we are even aware of what exactly we would like to know. By offering a service that will increase in accuracy in line with increased usage, Google hopes users will get hooked on a new mode of discovering information.

What do we know so far about Google’s new homepage?

This also allows Google to incorporate a number of other initiatives it has been working on, such as fact-checking and Google Posts.

You’d be forgiven for wondering whether Google is trying to find its way into social media again. After the demise of the short-lived Google+ platform, Google has seen Facebook grow as a credible threat in the battle for digital advertising dollars.

Facebook’s algorithmic news feed has been a significant factor in its rise in popularity, and with Google Posts incorporated into this news feed, there are certainly elements reminiscent of a certain social network in Google’s new homepage initiative. Readers may also recall the launch of iGoogle in 2005, a similar attempt to add some personalization to the homepage.

That said, it seems more likely that these changes have been rolled out in response to recent launches from Amazon than as a direct challenge to Facebook.

Amazon has made an almost dizzying amount of product announcements and acquisitions of late. As a pure-play ecommerce company, their rapid growth will have been cause for consternation at Google and there is a need to respond.

Of particular interest in relation to the new Google feed is the very recent launch of Amazon Spark, a shoppable feed of curated content for Amazon Prime members. It is only available via the iOS app for now, but it will be launched on Android soon too.

What do we know so far about Google’s new homepage?

Spark is a rival to Instagram in some ways, with its very visual feed and some early partnerships with social media influencers. It is also similar to Pinterest, as it encourages users to save their favorite images for later and clearly tries to tap into the ‘Discovery’ phase that Pinterest has made a play for recently.

Amazon has also launched its ‘Interesting Finds’ stream, which works in a noticeably Pinterest-esque fashion:

What do we know so far about Google’s new homepage?

Google has taken aim at Pinterest with its ‘Similar items’ feature and its revamped visual search technology, which feeds the new Google Lens.

In Google’s announcement of the new homepage, they make use of the verbs “discover” and “explore”. Both Amazon and Pinterest have tried to shape and monetize these phases of the search-based purchase journey; Google evidently thinks its homepage needs to take on a new life if it is to compete.

Will it open new opportunities for marketers?

Almost certainly. We should view this as a welcome addition to the elements of current search strategies, with a host of new opportunities to get in front of target audiences.

Google is not launching this product because of any existential threat to its core search product, which still dominates Western markets:

What do we know so far about Google’s new homepage?

Source: Moz/Jumpshot

The update should encourage a shift in user behavior. As people get used to the new experience, they will interact with Google in new ways and marketers need to be prepared for this.

From a paid perspective, we can expect to see new options open to advertisers, but not in the immediate future.

Amazon has two innate monetization mechanisms within Spark: users have to sign up to Prime (for an annual fee) to get access and, when they do, they are served a shoppable list of results. It comes as no surprise when we are on Amazon that we will be asked if we want to buy products.

That is not always the case on Google, where the initial purpose of the news feed is to gain traction with users and encourage them to spend more time within the site.

Options for sponsored content and (almost inevitably) paid ecommerce ads will come later, once a large and engaged user base has been established.

neural-image-search.png

Everything you need to know about visual search (so far)

Visual search is one of the most complex and fiercely competed sectors of our industry. Earlier this month, Bing announced their new visual search mode, hot on the heels of similar developments from Pinterest and Google.

Ours is a culture mediated by images, so it stands to reason that visual search has assumed such importance for the world’s largest technology companies. The pace of progress is certainly quickening; but there is no clear visual search ‘winner’ and nor will there be one soon.

The search industry has developed significantly over the past decade, through advances in personalization, natural language processing, and multimedia results. And yet, one could argue that the power of the image remains untapped.

This is not due to a lack of attention or investment. Quite the contrary, in fact. Cracking visual search will require a combination of technological nous, psychological insight, and neuroscientific know-how. This makes it a fascinating area of development, but also one that will not be mastered easily.

Therefore, in this article, we will begin with an outline of the visual search industry and the challenges it poses, before analyzing the recent progress made by Google, Microsoft and Pinterest.

What is visual search?

We all partake in visual search every day. Every time we need to locate our keys among a range of other items, for example, our brains are engaged in a visual search.

We learn to recognize certain targets and we can locate them within a busy landscape with increasing ease over time.

This is a trickier task for a computer, however.

Image search, in which a search engine takes a text-based query and tries to find the best visual match, is subtly distinct from modern visual search. Visual search can take an image as its ‘query’, rather than text. In order to perform an accurate visual search, search engines require much more sophisticated processes than they do for traditional image search.

Typically, as part of this process, deep neural networks are put through their paces in tests like the one below, with the hope that they will mimic the functioning of the human brain in identifying targets:

The decisions (or inherent ‘biases’, as they are known) that allow us to make sense of these patterns are more difficult to integrate into a machine. When processing an image, should a machine prioritize shape, color, or size? How does a person do this? Do we even know for sure, or do we only know the output?

As such, search engines still struggle to process images in the way we expect them to. We simply don’t understand our own biases well enough to be able to reproduce them in another system.

There has been a lot of progress in this field, nonetheless. Google image search has improved drastically in response to text queries and other options, like Tineye, also allow us to use reverse image search. This is a useful feature, but its limits are self-evident.

For years, Facebook has been able to identify individuals in photos, in the same way a person would immediately recognize a friend’s face. This example is a closer approximation of the holy grail for visual search; however, it still falls short. In this instance, Facebook has set up its networks to search for faces, giving them a clear target.

At its zenith, online visual search allows us to use an image as an input and receive another, related image as an output. This would mean that we could take a picture with a smartphone of a chair, for example, and have the technology return pictures of suitable rugs to accompany the style of the chair.

The typically ‘human’ process in the middle, where we would decipher the component parts of an image and decide what it is about, then conceptualize and categorize related items, is undertaken by deep neural networks. These networks are ‘unsupervised’, meaning that there is no human intervention as they alter their functioning based on feedback signals and work to deliver the desired output.

The result can be mesmerising, as in the below interpretations of an image of Georges Seurat’s ‘A Sunday Afternoon on the Island of La Grand Jatte’ by Google’s neural networks:

Everything you need to know about visual search (so far)

This is just one approach to answering a delicate question, however.

There are no right or wrong answers in this field as it stands; simply more or less effective ones in a given context.

We should therefore assess the progress of a few technology giants to observe the significant strides they have made thus far, but also the obstacles left to overcome before visual search is truly mastered.

Bing visual search

In early June at TechCrunch 50, Microsoft announced that it would now allow users to “search by picture.”

This is notable for a number of reasons. First of all, although Bing image search has been present for quite some time, Microsoft actually removed its original visual search product in 2012. People simply weren’t using it since its 2009 launch, as it wasn’t accurate enough.

Furthermore, it would be fair to say that Microsoft is running a little behind in this race. Rival search engines and social media platforms have provided visual search functions for some time now.

As a result, it seems reasonable to surmise that Microsoft must have something compelling if they have chosen to re-enter the fray with such a public announcement. While it is not quite revolutionary, the new Bing visual search is still a useful tool that builds significantly on their image search product.

Everything you need to know about visual search (so far)

A Bing search for “kitchen decor ideas” which showcases Bing’s new visual search capabilities

What sets Bing visual search apart is the ability to search within images and then expand this out to related objects that might complement the user’s selection.

Everything you need to know about visual search (so far)

 A user can select specific objects, hone in on them, and purchase similar items if they desire. The opportunities for retailers are both obvious and plentiful.

It’s worth mentioning that Pinterest’s visual search has been able to do this for some time. But the important difference between Pinterest’s capability and Bing’s in this regard is that Pinterest can only redirect users to Pins that businesses have made available on Pinterest – and not all of them might be shoppable. Bing, on the other hand, can index a retailer’s website and use visual search to direct the user to it, with no extra effort required on the part of either party.

Powered by Silverlight technology, this should lead to a much more refined approach to searching through images. Microsoft provided the following visualisation of how their query processing system works for this product:

Everything you need to know about visual search (so far)

Microsoft combines this system with the structured data it owns to provide a much richer, more informative search experience. Although restricted to a few search categories, such as homeware, travel, and sports, we should expect to see this rolled out to more areas through this year.

The next step will be to automate parts of this process, so that the user no longer needs to draw a box to select objects. It is still some distance from delivering on the promise of perfect, visual search, but these updates should at least see Microsoft eke out a few more sellable searches via Bing.

Google Lens

Google recently announced its Lens product at the 2017 I/O conference in May. The aim of Lens is really to turn your smartphone into a visual search engine.

Everything you need to know about visual search (so far)

Take a picture of anything out there and Google will tell you what the object is about, along with any related entities. Point your smartphone at a restaurant, for example, and Google will tell you its name, whether your friends have visited it before, and highlight reviews for the restaurant too.

This is supplemented by Google’s envious inventory of data, both from its own knowledge graph and the consumer data it holds.

All of this data can fuel and refine Google’s deep neural networks, which are central to the effective functioning of its Lens product.

Google-owned company DeepMind is at the forefront of visual search innovation. As such, DeepMind is also particularly familiar with just how challenging this technology is to master.

The challenge is no longer necessarily in just creating neural networks that can understand an image as effectively as a human. The bigger challenge (known as the ‘black box problem’ in this field) is that the processes involved in arriving at conclusions are so complex, obscured, and multi-faceted that even Google’s engineers struggle to keep track.

This points to a rather poignant paradox at the heart of visual search and, more broadly, the use of deep neural networks. The aim is to mimic the functioning of the human brain; however, we still don’t really understand how the human brain works.

As a result, DeepMind have started to explore new methods. In a fascinating blog post they summarized the findings from a recent paper, within which they applied the inductive reasoning evident in human perception of images.

Drawing on the rich history of cognitive psychology (rich, at least, in comparison with the nascent field of neural networks), scientists were able to apply within their technology the same biases we apply as people when we classify items.

DeepMind use the following prompt to illuminate their thinking:

“A field linguist has gone to visit a culture whose language is entirely different from our own. The linguist is trying to learn some words from a helpful native speaker, when a rabbit scurries by. The native speaker declares “gavagai”, and the linguist is left to infer the meaning of this new word. The linguist is faced with an abundance of possible inferences, including that “gavagai” refers to rabbits, animals, white things, that specific rabbit, or “undetached parts of rabbits”. There is an infinity of possible inferences to be made. How are people able to choose the correct one?”

Experiments in cognitive psychology have shown that we have a ‘shape bias’; that is to say, we give prominence to the fact that this is a rabbit, rather than focusing on its color or its broader classification as an animal. We are aware of all of these factors, but we choose shape as the most important criterion.

Everything you need to know about visual search (so far)

“Gavagai” Credit: Misha Shiyanov/Shutterstock

DeepMind is one of the most essential components of Google’s development into an ‘AI-first’ company, so we can expect findings like the above to be incorporated into visual search in the near future. When they do, we shouldn’t rule out the launch of Google Glass 2.0 or something similar.

Pinterest Lens

Pinterest aims to establish itself as the go-to search engine when you don’t have the words to describe what you are looking for.

The launch of its Lens product in March this year was a real statement of intent and Pinterest has made a number of senior hires from Google’s image search teams to fuel development.

In combination with its establishment of a paid search product and features like ‘Shop the Look’, there is a growing consensus that Pinterest could become a real marketing contender. Along with Amazon, it should benefit from advertisers’ thirst for more options beyond Google and Facebook.

Pinterest president Tim Kendall noted recently at TechCrunch Disrupt: “We’re starting to be able to segue into differentiation and build things that other people can’t. Or they could build it, but because of the nature of the products, this would make less sense.”

This drives at the heart of the matter. Pinterest users come to the site for something different, which allows Pinterest to build different products for them. While Google fights war on numerous fronts, Pinterest can focus on improving its visual search offering.

Admittedly, it remains a work in progress, but Pinterest Lens is the most advanced visual search tool available at the moment. Using a smartphone, a Pinner (as the site’s users are known) can take a picture within the app and have it processed with a high degree of accuracy by Pinterest’s technology.

The results are quite effective for items of clothing and homeware, although there is still a long way to go before we use Pinterest as our personal stylist. As a tantalising glimpse of the future, however, Pinterest Lens is a welcome and impressive development.

Everything you need to know about visual search (so far)

The next step is to monetize this, which is exactly what Pinterest plans to do. Visual search will become part of its paid advertising package, a fact that will no doubt appeal to retailers keen to move beyond keyword targeting and social media prospecting.

We may still be years from declaring a winner in the battle for visual search supremacy, but it is clear to see that the victor will claim significant spoils.

The ultimate law of mobile site design: Entertain users and drive conversion

Most consumers rely on their smartphones to make purchases and gain knowledge. In 2017, any business that lacks a mobile presence runs a serious risk of falling behind.

But it’s not just about having a site – it needs to provide a good experience. According to Google, 29% of smartphone users will immediately switch to another site if it doesn’t satisfy their needs.

Mobile users are goal-oriented, and they expect to find what they need from a responsive mobile instantly and easily. So punch up your conversion rates by designing your mobile site with the user’s intent and needs in focus.

1. Homepage and navigation

A homepage can serve as a promotional space and welcome page, but should provide users with the content they are searching for. A conversion focused homepage should tick off the following elements: concise CTAs, homepage shortcuts, minimal selling or promotions.

Navigating on a smaller screen, it is easy for users to miss key elements on your homepage. Therefore it is advisable to put your calls-to-action where users will see them easily, such as occupying the bottom half or above the fold.

Your call-to-action signifies the tipping point between conversion and bounce. To design calls-to-action that convert, optimize the copy and design, i.e. choice of words, color, size, fonts, etc.

We understand the travails of losing our way in the mall or a mart? The same happens on mobile sites, the lack of navigation menus or location bars can hurt conversion. Mobile users expect to get back to the homepage with a single tap either through tapping your logo or clicking the home navigation menu. For best practices, use your logo as the homepage shortcut.

Too often, ads and promotion beat the purpose of visiting a page and users get turned off. To entertain visitors and drive conversion, ads or promotional banners should be kept to the minimum and placed in a position which won’t affect the user experience.

To place ads on your homepage, think like a user. What is the user trying to accomplish? Where will their attention be focused? How do I keep the page clean and uncluttered?

By answering these questions, ad placement on your homepage will be a breeze and won’t need to negatively impact user experience.

2. Commerce and reviews

With an increased rate of digitization, users expect smooth mobile experiences when searching, reviewing and purchasing products. How can marketers and businesses increase their conversion rates while ensuring excellent mobile experiences for visitors?

The answer lies in allowing visitors/users to convert on their own terms.

For an ecommerce store, requesting that visitors sign up very early in the customer’s journey is a major turn off. Visitors will abandon a website demanding registration before they can continue, resulting in low conversion unless the site is an authoritative brand.

For better results, allow visitors explore your site before requesting for registration and enable visitors purchase products as a guest. For mobile commerce sites, easy and quick should be the watchword when designing the checkout process.

Best practices for mobile commerce include the availability of multiple payment options for commerce sites. Adding payments options such as Apple Pay, PayPal and Android Pay can boost conversion rates saving users the stress of inputting credit card information. For previous users, load and pre-fill their data fields for convenience in filling shipping information.

Statistics show that 92% of consumers read online reviews before purchasing a product or doing business with a company. Meaning reviews are an important part of the decision-making process for consumers, include reviews on your web pages then allow filters be applied to these reviews. Filters such as “most recent reviews”, “most positive reviews” and “lowest ratings”.

3. Site usability

When it comes to mobile site design, every little detail matters. Details such as zooming, expandable images, transparency about the use of visitors data will aid conversion.

According to studies, users found it easier to navigate a mobile-optimized website than desktop sites on smartphones. To ensure consistency, optimize every single page on your website for mobile devices, including forms, images, etc.

Your search bar should be placed near the top of your homepage for users to search for specific products and ensure the first search results are the best. Remember to include filters on search results to narrow down users intent or preferences on your mobile site.

Be careful not to label the link to your desktop site as full site. This might confuse visitors into thinking the mobile site is not fully featured causing them to opt for the full site, simply label the link to the desktop site as “Desktop Site” and link to the mobile site as “Mobile Site”.

When optimizing a mobile site, remember to disable pinch to zoom on your images as this might affect the general site experience, calls-to-action will be missed and messages will be covered. Basically, upload images that are sized properly and will render perfectly on any device.

Due to the nature of mobile devices, lengthy forms will hurt conversion when trying to gain leads. On surveys or multiple page forms, include a progress bar with upcoming sections at the top or bottom to guide users through the process.

To aid or satisfy customers, implement auto-fill on forms for name, phone and zip code fields. For date and time fields, include a visual calendar as users might not remember dates for the next weekend but the visual calendar will stop users from leaving your page to use the calendar app.

There are numerous resources on forms that include the use of calendars and other custom input fields, including Google forms, Xamarin Forms and FormHub.

4. Technicalities

While great design drives conversions, do not ignore the very foundation of your website. The following technicalities should be implemented and audited monthly.

  • Implement analytics and track conversion on mobile and desktop
  • Test your site as a visitor and load content in their intent
  • Optimize and test your mobile site on various devices and browsers to ensure optimum performance
  • Mobile ads should redirect to mobile sites, not desktop sites
  • Check your site speed using Google speed tool
  • Check for elements of Flash and remove them as they won’t render on iOS and slow on Android
  • Submit your mobile site pages XML sitemap submitted to Google.

Finally, run your website through Google’s Mobile-Friendly Test.

dna46t_bbc_pagespeedtest.png

How JavaScript impacts page loading speed on mobile

The effect of JavaScript on mobile web performance is twofold.

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

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

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

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

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

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

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

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

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

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

Testing for blocking JavaScript

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

! Should Fix:

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

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

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

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

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

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

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

4x growth in JavaScript use in five years

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

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

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

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

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

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

How JavaScript impacts page loading speed on mobile

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

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

What is the effect on mobile page speed?

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

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

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

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

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

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

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

Reducing reliance on JavaScript

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

Alex Painter, Web Performance Consultant at NCC Group:

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

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

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

Choose asynchronous and deferred JavaScript over blocking and inline scripts

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

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

Are blocking scripts ever justified?

Patrick Meenan:

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

Reducing size of JavaScript files

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

This will always be a balancing act.

Patrick Meenan:

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

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

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

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

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

dna45_image_formats_httparche_t.png

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

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

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

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

The balancing act of image optimization

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Alex Painter:

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

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

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

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

Who is using responsive images?

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

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

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

Finding the best format for your images

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

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

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

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

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

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

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

Alternatives to traditional images

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

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

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

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

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

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

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

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

Web design techniques for improving perceived load time

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

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

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

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

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

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

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

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

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

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

 

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

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

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.

The ultimate guide to mobile technical SEO

With smartphone users growing year-on-year while desktop users stagnate, it comes as no surprise that Google looks to put mobile at the very core of its search engine algorithm in 2017.

Mobile is destined to become the backbone of determining rankings on both the mobile and desktop version of your website – so it’s vital to look at technical SEO from a mobile perspective.

What is technical SEO?

Technical SEO provides Google and other search engines with the information they are requesting to understand the true purpose of your content.

Technical SEO looks at the coding and technical issues which impact search engines, many of which will be mentioned in this blog.

What mobile configuration should I be using for my mobile website?

There are currently three mobile configurations that Google recognizes: ‘responsive web design’, ‘dynamic serving’ and ‘separate URLs’. However, Google recommends using responsive web design, which is distinguishable from the other two configurations due to the URLs and HTML remaining the same for both mobile and desktop.

1. Responsive web design

A responsive web design uses CSS media queries to allow desktop webpages to be viewed in response to the size of the screen, which redesigns the content according to the device.

Benefits:

  • Singular URL is better for users and makes content easier to share and to click on
  • Google crawlers and other bots only need to crawl once, which will help in increasing crawl budget and indexing your pages efficiently
  • Redirects are not required to take them to the correct version of the page. This reduces errors that can be made when creating redirects on your site.

Weaknesses:

  • If the desktop version goes down, so does the mobile version
  • Can’t be used for feature phones or tablets like the other two.

2. Dynamic serving

Dynamic serving uses user agent detection to deliver alternate HTML and CSS according to the user agents that are requesting them.

Benefits:

  • Unique experience delivered per device
  • No redirection required.

Weakness:

  • User agent redirects are prone to mistakes
  • Bots need to crawl pages with different user agents, which uses up crawl budget and can lead to indexing inefficiency.

3. Separate URLs

For every desktop URL on your site there is an equivalent mobile URL with this mobile configuration. This allows you to serve mobile-dedicated content.

Much like dynamic serving, user agent detection is used to redirect mobile users landing on the desktop version.

Benefits:

  • Mobile-dedicated content
  • Implementation is easy.

Weakness:

  • User agent redirects are prone to mistakes
  • Waste of crawl resources.

3 focus areas of mobile technical SEO

These areas are fundamental for your mobile technical SEO:

1. Website speed

How can you improve your website load speed and make your user experience smooth? If you’re not already asking this question, then please do!

This is a crucial first stage of a user’s experience of your website – you want it to be epic and flawless! Here are four ways to speed up your pages:

Accelerated Mobile Pages (AMP)

Although AMPs are not signal ranking factors and mainly benefit the users, these pages are an area which may become important with mobile-first indexing in 2017.

AMP works using coding language AMP HTML which restricts code to increase page loading speed and reliability. This can help load a page in under three seconds if your page is not able to perform that otherwise.

If you have a WordPress site it’s very straightforward to implement AMP. Check out this article on how to implement Google AMP on your WordPress site.

Simple and minimalistic templates

It’s important to remember the No.1 rule when it comes to the design of your website; less is more, so ensure your templates are minimalistic.

Additional elements to your template layout such as plugins, widgets and tracking codes all require additional loading time which can start to accumulate and cause excessive page loading times to pages on your site.

A normal page loading time is roughly under three seconds. Anything that exceeds this is considered too long, so ensure only necessary elements are on the page template.

One easy but effective way to reduce page speed loading time is to ensure Gzip compression and lossless compression is applied to all images. Oversized images can be a big cause of slow page speed loading.

No redirect chains

Under no circumstances should you ever have redirect chains. These can increase page loading with every additional redirect in the chain. Therefore, it’s fundamental that all redirects are performed in one step instead of multiple steps.

In the circumstance of 404 pages you must crawl and export these pages and resolve them using 301 (one step) or ensure you’re using custom user-friendly 404 pages which humors the user and guarantees they can continue their journey on your website instead of bouncing from your site.

Browser caching

Every time a browser is opened to your website it must download the web files to display your page correctly – which includes HTML, CSS and JS.

Browser cache begins to accumulate website resources automatically (local computer) upon the users’ first time on your web page. This allows the browser to recall the first website version cached, which allows the site to be loaded quicker on your return to a particular page of your site – greatly benefiting your returning visitors to your website.

Making use of browser caching is very simple and can be done by editing your HTTP header to set expiry times for files. With most file types, you can choose how frequently they need to be updated.

2. Site architecture

The site structure is another very important element of mobile technical SEO – mobile users want to be able to navigate to the pages with ease and within less than three clicks. Here are some simple ways to make sure all pages are easily accessible and still relevant.

Following the breadcrumbs

Breadcrumbs present a clear website hierarchy and indicate where the user currently is, which will help reduce the number of clicks/actions required to get to previous pages or different sections.

Breadcrumbs should be used as secondary navigation in addition to your primary navigation. Breadcrumbs should be used by large sites and ecommerce sites where hierarchy and site structure may become very complex and confusing for users and bots.

Juicing internal links

Silo content helps search engine crawlers to correctly interpret your website and help increase keyword rankings for that page. Internal links within the content make it easier for users to find content targeting keyword relevant terms. This will improve the visibility of your older articles that are topically related to the newly published ones.

In addition, utilizing internal category links will help users flow between your related topic resources on your site and discover other related topics.

3. Structured data mark-up

Structured data helps inform Google as to how to interpret the type of resource the page is by looking at the content and on-page optimization.

Rich snippets provide additional structured data markup to provide extra information of what your site entails in SERPs. This allows users to determine if the page is worth clicking through to. Rich snippets provide opportunities to provide extra information such star rating and number of reviews.

Google has two tools for structured data markup – one for help with implementing structured data mark-up and the other for testing the structured data mark-up. For more help getting started, check out our beginner’s guide to Schema.org markup.

Summary

As you can see, this is a very extensive topic and I’ve focused on the areas that I expect technical SEO to place most importance on. There won’t be a particular change in current technical SEO tasks performed but it’s clear that if mobile is at the forefront of search engine algorithm updates in future then we should expect to see a change in priority of ranking signal factors.

When it comes to choosing your mobile configuration, it will come down to your budget and where your audience is viewing you. If you’re looking for simple and non-expensive, then having a responsive website design is the solution.

However, if you’ve got a little more to spend and want to ensure your audience have a great experience of your website, then the other mobile configurations are good options as well.

It’s also worth considering how you’re currently being viewed by your audience. Are they more desktop/laptop based? If so, then responsive web design is the best solution as they will have no issues with understanding the mobile layout.

If they are split, or mobile views are higher, you might be better off with the other options as the user may want to obtain information quickly.

If you have any technical SEO questions, feel free to comment below.

walmart-ice-cream.png

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

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

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

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

 

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

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

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

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

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

Cut the fat

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

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

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

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

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

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

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

Images that count

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

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

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

Case study: Unilever mobile-ready hero images

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

So what’s the impact on UX?

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

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

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

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

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

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

Accessibility

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

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

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

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

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

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

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

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

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

 

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

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

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

 

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

 

t_amp_trump_google.png

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

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

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

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

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

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

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

A recap: What is AMP?

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

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

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

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

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

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

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

The stats

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

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

Speed and engagement

Let’s start with speed and engagement.

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

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

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

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

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

Article volume

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

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

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

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

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

AMP vs mobile web

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

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

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

Not everyone is happy with AMP

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

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

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

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

dna42_response_time_graph.png

How to optimize your mobile site speed: Testing for issues

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

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

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

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

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

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

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

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

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

Putting things right

A note before we begin:

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

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

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

Action plan:

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

The need for speed

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

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

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

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

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

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

Test, test, test

Testing is critical improving to website performance and usability.

1. Test how quickly pages download

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

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

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

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

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

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

Mobile speed test performance test for Walmart.com:

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

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

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

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

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

How to optimize your mobile site speed: Testing for issues

2. Conduct user testing

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

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

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

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

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

 

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

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

 

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