Over the last few years there’s been a lot of talk among web professionals about the different techniques available to create beautiful web sites. The parallel conversation concerning generating revenue has in the main been absent.

On 7^th October 2015 Google attempted to rectify this in their introductory blog post relating to Accelerated Mobile Pages (AMP). They state “Every time a web page takes too long to load, they lose a reader—and the opportunity to earn revenue through advertising or subscriptions.”

This statement supported by the authoritative voices of the BBC, The Guardian, The Wall Street Journal, Adobe and the many other huge organizations who are involved in the project tells anyone who measures the web from a revenue perspective that something is broken. The fact AMP exists as a technology tells you something is wrong. This is especially true for those making extensive use of the technologies AMP excludes.

What is AMP?

AMP requires a web server to create multiple versions of a web page, one specifically targeting mobile devices focused on great performance. This mobile specific web page won’t be able to run JavaScript and has a number of other constraints designed to improve performance. Here’s a summary of the major ones.

1. A single embedded stylesheet is allowed.
2. All elements must be sized by the web server.
3. HTML’s <img> element isn’t allowed and is replaced by <amp-img>.
4. Many other standard HTML elements are replaced by alternatives.
5. <input> elements are not allowed.
6. HTML5 is needed for video and audio support.
7. No polyfills.

So AMP is a great way of improving performance but pretty restrictive and certainly not suited to web pages that capture data or are personalized. The syntax used to create the web page whilst based on HTML and CSS is different in its operation.

AMP for most is an impractical answer to the acknowledged problem of diminished web revenue from mobile.

Simplification

Responsive Web Design (RWD) advocates will state that AMP isn’t needed IF the components are implemented properly and sensible designs are used. However, such tools have become so complex that most web professionals don’t understand all the negative implications of their use.

A small elite may understand specific frameworks and charge high fees for their services. Others splash liberal helpings of JavaScript and associated frameworks such as Modernizer, JQuery, Angular, Bootstrap and the like into a web page and create something which works beautifully in the lab but rarely well in the wild. Relying on improving mobile device specifications and data network capacity doesn’t solve the problem.

Simplification has been embraced by other corners of the IT industry in recent years. Whether it’s SQL being replaced with No-SQL solutions or web servers running tightly integrated C and C++ translated executables such as Nginx the prevailing direction is removing complexity. AMP heralds the arrival of a similar philosophy for the web but ironically plasters over the root cause.

Root Cause

Jeremy Keith at past BDConf sessions on web design quoted Jon Postal.

“Be conservative in what you send, be liberal in what you accept”

As a web professional you can only control the web server. So when viewed from that perspective the web server should send as little as possible, and accept as much as possible. Sound advice.

AMP isn’t the only web server approach Google are advocating. The HTTP Working Group are currently considering the HTTP client hints proposal from Google’s Ilya Grigorik to improve image optimization. There are still many barriers to overcome.

There is now an increasing number of web technologists reverting to Jon Postal’s advice and advocating web servers generating different content for different devices to improve performance and optimize for revenue. Full stack developers know this.

Use the Web Server

A web server can generate different content for different devices very easily. In addition to improving performance; user interfaces and ultimately the entire user experience can be improved. Consider the following:

1. Rich mega menus work very well on pointer driven devices such as laptops and desktops. A navigation system optimised for such fluid and rapid navigation helps users find what they want quickly. Such a navigation approach would not work on touch screens.
2. Retailers who analyse basket value and content by device type understand that there is a mobile context. Personalising featured products based on a device type is an easy way to optimise revenue.
3. Smartphones have up to 10 square inches of screen real-estate. A typical tablet has 30, and a desktop or laptop maybe 100. These are big differences which can be exploited not just to improve performance but to improve revenue. Simply placing advertising in optimum positions has a big impact on click through rate and therefore revenue.

Such techniques are used by sophisticated web businesses alongside modern device detection solutions to increase revenue. They will always involve using a combination of RWD techniques AND server side optimisations.

Search Engine Implications

Separate URLs

When separate web pages are created for the same content the canonical and alternate links can be used to ensure search engines can relate multiple pages and direct search users to the most appropriate one based on their knowledge of the request.

The desktop/laptop version of the page would include the following.

<link rel="alternate" media="only screen and (max-width: 640px)"
  href="http://m.example.com/page-1">

The alternative mobile version would include the following.

<link rel="canonical" href="http://www.example.com/page-1">

https://developers.google.com/webmasters/mobile-sites/mobile-seo/separate-urls?hl=en

Dynamic URLs

However, for many purposes the same URL is desirable. The HTTP 1.1 standard supports this through the use of Vary header. Setting this to User-Agent (the HTTP header which typically identifies different devices) search engines and caching proxies understand that the content may vary by device type. The following is an example of such a HTTP header setting.

GET /page-1 HTTP/1.1
 Host: www.example.com
 (...rest of HTTP request headers...)
 
 HTTP/1.1 200 OK
 Content-Type: text/html
 Vary: User-Agent
 Content-Length: 5710
 (... rest of HTTP response headers...)

https://developers.google.com/webmasters/mobile-sites/mobile-seo/dynamic-serving

Device Detection Nightmare

In order to properly determine which version of a web page should be sent to a device the web server needs to understand what the device is. In the past decade regular expression based solutions were used resulting in poor experiences and were rightly dismissed by influential evangelists.

Consider the following User-Agent HTTP header generated from a Nexus 5 smartphone.

Mozilla/5.0 (Linux; Android 4.4.4; Nexus 5 Build/KTU84P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.114 Mobile Safari/537.36 

One could create a regular expression to find “Android”. Such an approach assumes all web browsers running Android are mobile devices. Such an assumption is not valid when the number of media players and TVs running Android are considered. It also does not help differentiate between devices by screen size.

Another approach would be to identify the mobile device by the presence of “Nexus 5”. Keeping up with the 1,000s of new web enabled devices released each year is impractical for most. In order to serve different content to different devices effectively a more robust solution is needed.

Professional Device Detection

A professional device detection solution should include the following:

1. Provide both high performance and accuracy. Be wary of solutions which only provide one.
2. Be supported by a team of people dedicated and trained in the art of accurate classification of different devices.
3. Use device data from vendors and not screen scrapes of public domain web sites such as GSM arena. What will happen to their product should GSM arena stop or change?
4. Use an algorithm that supports the near exponential growth of device combinations during 2015. Legacy solutions which use regular expressions are not going to manage this growth and represent a risk for the future.
5. Identify false positive results to allow implementation of default behavior.

Modern device detection solutions make their APIs available as open source and repository packages for popular programming environments. Cloud services are available for those that can accept the performance penalty.

51Degrees (my company) has a dedicated team of 20 people provide all these advantages helping AdTech, Finance, Retail, Publishing, Healthcare, Gaming, Brand, Agency, Charity and Technology business all increase revenue from the web.

Those who’d like to know more about the techniques used and the benefits available should watch the following video to find out more.

Video Link: https://channel9.msdn.com/Shows/Web-Hack-Wednesday/browserdetection

Or download the free open source code and device data.

[Download Code] https://github.com/51degrees

[Data Options] https://51degrees.com/compare-data-options