How has mobile marketing changed in the past year and how should your business react to best prepare for 2017 and beyond? Emily will discuss the what future holds for mobile optimization and how to rise above the rest of the pack in a mobile-first world.
2. #SearchLove @goutaste
If your plans don’t
include mobile, your
plans are not finished.
Wendy Clark, Coca-Cola
Meet your customers
in the environment
of their choice, not
where it's convenient
for you.
Cyndie Shaffstall
Mobile is becoming not only the
new digital hub but also the bridge
to the physical world.
Thomas Husson, Forrester
Mobile is the enabling
centerpiece of digital
convergence.
Tomi T Ahonen
More Google
searches take place
on mobile devices
than on computers.
Google
If you’re not using
mobile…don’t worry -
your competitors are
already using it and are
getting those customers
instead.
Jamie Turner,
60SecondMarketer
The adoption rate of mobile is twice
that of the internet.
Emma Crowe, Somo
The smartphone is
the key marketing
battleground of
2016.
Andrew Smith,
Director at Escherman
11. #SearchLove @goutaste
Old Model of
Thinking:
“Web VS. Apps”
OLD: Web vs. Apps
@paul_kinlan paul.kinlan.me/the-headless-web/
“Should I build
an app or a
website?”
12. #SearchLove @goutaste
OLD: Web vs. Apps
Engaging,ImmersiveExperiences
Potential Reach
APPS
WEB
Native Features Made Apps More Engaging
Web Features Made Sites More Discoverable
13. #SearchLove @goutaste
A Web of Apps – App Indexing
NEW: Web of Apps & App-Like WebOLD: Web vs. Apps
firebase.google.com/docs/app-indexing/ *App Icons Only on Android
14. #SearchLove @goutaste
NEW: Web of Apps & App-Like WebOLD: Web vs. Apps
http://www.cc.com/shows/the-daily-
show-with-trevor-noah
comedy-central://example-deep-link-to-
daily-show
Example deep links:
A Web of Apps – Deep Linking
15. #SearchLove @goutaste
NEW: Web of Apps & App-Like WebOLD: Web vs. Apps
A Web of Apps – ‘Instant Apps’
developer.android.com/topic/instant-apps/index.html
16. #SearchLove @goutaste
New: A Web of Apps & App-Like Websites
NEW: Web of Apps & App-Like WebOLD: Web vs. Apps
Engaging,ImmersiveExperiences
Potential Reach
APPS Deep
Links
WEB
23. #SearchLove @goutaste
The App-Like Web: What is a ‘PWA’?
NEW: Web of Apps & App-Like WebOLD: Web vs. Apps
@suzzicks
HTTPS Mobile
Friendly
Website
Service
Worker
Web App
Manifest
=+
Progressive Web
App
bit.ly/cindy-mozcon-2016
24. #SearchLove @goutaste
“Service Workers can give
users the best of both [app &
web] worlds:
A middle ground letting you
choose how and when the site
should be integrated deeper into
the device.”
NEW: Web of Apps & App-Like WebOLD: Web vs. Apps
@paul_kinlan paul.kinlan.me/slice-the-web/
25. #SearchLove @goutaste
The App-Like Web – Service Workers
NEW: Web of Apps & App-Like WebOLD: Web vs. Apps
Service Workers are so powerful, that browsers wont let you use it without encryption
HTTPS REQUIRED
26. #SearchLove @goutaste
New: A Web of Apps & App-Like Websites
NEW: Web of Apps & App-Like WebOLD: Web vs. Apps
@paul_kinlan paul.kinlan.me/the-headless-web/
27. #SearchLove @goutaste
New: A Web of Apps & App-Like Websites
NEW: Web of Apps & App-Like WebOLD: Web vs. Apps
Engaging,ImmersiveExperiences
Potential Reach
APPS Deep
Links
WEB
PWA
28. #SearchLove @goutaste
“Prepare for a time when no
one ever visits your website.
Awareness, research, and
conversion will all happen in
the search results…”
-- David Mihm
FUTURE: UI-Agnostic ContentNEW: Web of Apps & App-Like WebOLD: Web vs. Apps
bit.ly/david-mihm-2017
32. #SearchLove @goutaste
Get Better at Being a Data Source:
Structured Data (Schema)
FUTURE: UI-Agnostic ContentNEW: Web of Apps & App-Like WebOLD: Web vs. Apps
33. #SearchLove @goutaste
Get Better at Being a Data Source:
Structured Data Formatting
FUTURE: UI-Agnostic ContentNEW: Web of Apps & App-Like WebOLD: Web vs. Apps
moz.com/blog/json-ld-for-beginners
34. #SearchLove @goutaste
Structured Data Immediate SEO Benefits
FUTURE: UI-Agnostic ContentNEW: Web of Apps & App-Like WebOLD: Web vs. Apps
developers.google.com/search/docs/data-types/books
35. #SearchLove @goutaste
Get Better at Being a Data Source:
APIs
FUTURE: UI-Agnostic ContentNEW: Web of Apps & App-Like WebOLD: Web vs. Apps
42. #SearchLove @goutaste
Check Your Loading Optimization
OLD: Loading Optimization
testmysite.thinkwithgoogle.com
These are
the basics
we all still
get wrong
45. #SearchLove @goutaste
OLD: Loading Optimization
bit.ly/mobile-speed2 from
We Want Faster Sites, But We’re Also
Shipping More JS Than Ever
@samccone bit.ly/rel-preload-demo
48. #SearchLove @goutaste
OLD: Loading Optimization
Tools That Help With Critical Path Rendering
@ipullrank moz.com/blog/the-technical-seo-renaissance
Chrome Dev Tools
51. #SearchLove @goutaste
NEW: Progressive EnhancementOLD: Loading Optimization
An escalator can never break, it
can only become stairs. There
would never be an ‘escalator
temporarily out of order’ sign, only
an ‘escalator temporarily stairs.
Sorry for the convenience.’-- Mitch Hedberg
52. #SearchLove @goutaste
How Service Workers Can Help Optimize Repeat Visits
NEW: Progressive EnhancementOLD: Loading Optimization
medium.com/@addyosmani/progressive-web-apps-with-react-js-part-3-offline-
support-and-network-resilience-c84db889162c#.jtl0ooqu2
54. #SearchLove @goutaste
Service Workers Wont Help Everywhere… But
Remember They’re Enhancements
NEW: Progressive EnhancementOLD: Loading Optimization
‘Progressive Web App
Temporarily Functional Website
on Safari.
Sorry for the convenience.’
56. #SearchLove @goutaste
NEW: Progressive EnhancementOLD: Loading Optimization
ipullrank.com/how-i-sped-up-my-site-68-percent-with-one-line-of-code/
Be 99% sure! Prerender will load ALL of
the assets for the page. If you are
wrong, this can waste battery and
bandwidth from your mobile users.
Good use cases (near certainty on click):
• Next page in paginated article
• “Logged in” page from Login Page
Browser Assists
<link rel="prerender" href="http://example.com/page">
<link rel=”prerender prefetch” href=”http://www.example.com/page”>
57. #SearchLove @goutaste@benedictevans
FUTURE: Network OptimizationNEW: Progressive EnhancementOLD: Loading Optimization
We’re Halfway to Connecting Everyone
5.5bn people over 14 years old, close to 5bn with mobile phones, ~2.5bn smartphones
Future: Network Optimization &
Offline Functionality
58. #SearchLove @goutaste
The average mobile user is not on a $600+ phone & over
half of active Android users have 1 GB or less in Ram
FUTURE: Network OptimizationNEW: Progressive EnhancementOLD: Loading Optimization
Future: Network Optimization &
Offline Functionality
WATCH: bit.ly/progressive-performance
59. #SearchLove @goutaste
FUTURE: Network OptimizationNEW: Progressive EnhancementOLD: Loading Optimization
Image: kinsta.com/learn/what-is-http2/#goal_of_creating_http2
WE ARE HERE
YOUR AUDIENCE
MAY BE HERE
Understanding Network Connection Variability
Treat the Network as an Enhancement
60. #SearchLove @goutaste
Understand Network Connection Variability
FUTURE: Network OptimizationNEW: Progressive EnhancementOLD: Loading Optimization
Read: bit.ly/http2-intro
Image: kinsta.com/learn/what-is-http2/#goal_of_creating_http2
HTTP/2 enables full request & response multiplexing
HTTP/2 will be critical in connecting the next billion
61. #SearchLove @goutaste
• Prefetch & Prerender speed up your next navigation
• Preload speeds up the current one
FUTURE: Network OptimizationNEW: Progressive EnhancementOLD: Loading Optimization
• Pre-load can specify the download “as” =
• "script",
• "style",
• "image",
• "media",
• "document”
bit.ly/what-is-rel-preload
Optimize Network Requests
HTTP/2 + PreLoad = Moves the ‘start download’ time of a critical asset closer to initial request
64. #SearchLove @goutaste
Understand Network Connection Variability
Service Workers Help Optimize for Network Connectivity
FUTURE: Network OptimizationNEW: Progressive EnhancementOLD: Loading Optimization
@pierrefar deliberatedigital.com/mobile-seo
65. #SearchLove @goutaste
Service Workers
Can Even Give
Websites Offline
Functionality
FUTURE: Network OptimizationNEW: Progressive EnhancementOLD: Loading Optimization
66. #SearchLove @goutaste
Service Workers Can Even Give
Websites Offline Functionality
FUTURE: Network OptimizationNEW: Progressive EnhancementOLD: Loading Optimization
69. #SearchLove @goutaste
OLD: Mobile-specific Data
Google
Analytics -
Default
Google
Analytics -
Devices
Google
Analytics -
Browsers
Usually
social app
browsers
“How Are We
Serving Our Mobile
Users When They
Land Here?”
73. #SearchLove @goutaste
Which of These Devices Are ‘Mobile’?
OLD: Mobile-specific Data
All of these have a big screen, keyboard, and roughly the same performance – What is
the difference between them?
Lumia
Screen +
Keyboard
iPad Pro
Surface
Pro
MacBook
@benedictevans
77. #SearchLove @goutaste
NEW: Recovering Dark DataOLD: Mobile-specific Data
Cross-Browser Attribution is Getting
More Realistic…
arstechnica.com/security/2017/02/now-sites-can-fingerprint-you-online-even-when-
you-use-multiple-browsers/
“Now sites can
fingerprint you
online even
when you use
multiple
browsers”
78. #SearchLove @goutaste
NEW: Recovering Dark DataOLD: Mobile-specific Data
…But Cross-Device Attribution is Still Crazy
Hard (Especially Between Native Apps & Web)
Signed-In Users are usually our best shot at accurate attribution here
79. #SearchLove @goutaste
NEW: Recovering Dark DataOLD: Mobile-specific Data
Rankings Tracking on Mobile Today Is Near Pointless
@ipullrank moz.com/blog/the-technical-seo-renaissance
80. #SearchLove @goutaste
FUTURE: Beyond the BrowserNEW: Recovering Dark DataOLD: Mobile-specific Data
How Do You Record Offline “Traffic”?
bit.ly/track-offline
81. #SearchLove @goutaste
FUTURE: Beyond the BrowserNEW: Recovering Dark DataOLD: Mobile-specific Data
What About Push Notification Behaviors?
bit.ly/GA-push-tracking
82. #SearchLove @goutaste
Track your mobile
segments…
Yes, still do the
basics…
pass the Mobile
Friendly Test
Compress and
minify your
resources
(images, JS…)
83. #SearchLove @goutaste
Pay attention to
Service Workers
and new
performance
techniques
…but also start to build
the foundations for
what’s coming next.
HTTPS is tables stakes
for a lot of the future
Build out your
platform &
prepare to be
UI-Agnostic
Track your mobile
segments…
Yes, still do the
basics…
pass the Mobile
Friendly Test
Compress and
minify your
resources
(images, JS…)
Figure out how we’re going to track
it all outside a traditional browser
84. #SearchLove @goutaste
Pay attention to
Service Workers
and new
performance
techniques
…but also start to build
the foundations for
what’s coming next.
HTTPS is tables stakes
for a lot of the future
Build out your
platform &
prepare to be
UI-Agnostic
Be less REactive – be more PROactive
& let’s make the mobile world a better
place!
Track your mobile
segments…
Yes, still do the
basics…
pass the Mobile
Friendly Test
Compress and
minify your
resources
(images, JS…)
Figure out how we’re going to track
it all outside a traditional browser
Most mobile sessions start with a bunch ot stats and quotes like this – quotes to convince you that movile is growing.
But I’m calling shenannigans on this. Mobile has already won.
In fact, it’s old new that it’s won. Can anyone guess when Eric Schmidt said this? It was 2014. That was 3 years ago!
So let’s stop thinking of mobile as something you need to be sold on, and start thinking about what this actually means.
It helps to look at mobile in the context of an S-curve, starting from new innovation and moving up in this snake-like pattern until it levels out more around maturity
To take mobile seriously is to know that we’re already in the 2nd half of this S-curve.
We’ve actually moved past PCs and are heading to 5 billion users, which means we’re beyond the creation state – we’re moving into deployment.
So the issues that matter in mobile marketing are changing. The issues that matter in mobile marketing are changing.
Today, instead of just listing off tactics and google guidelines, I want to show you how these issues are changing, so that we can develop more pro-active strategies for the changing tide.
And I’ve brough 3 issues with me today:
Mobile platform
Mobile Performance
Mobile Analytics
For each one we’re going to talk about effective strategies for the old context, the new context, and for the future
Let’s start with mobile platform
When mobile was in its infancy, the classic platform question was: “should I build a mobile app or a mobile website.” and you can see why in this chart. The features, the capabilities of each platform were almost entirely different.
Where one struggled, the other excelled. Native apps lent themselves to engaging experiences, but you had to download them, and even after you downloaded them, you’d have to start from the home screen, so they struggled with reach.
Conversely, websites were great at reaching people but couldn’t integrate more deeply with the mobile device
But over the last few years, this has changed. Google introduced app indexing, which allows people to access content inside installed apps from Google Search – they can click a search result and land on that content in the app without them having to navigate from the home screen
This was made possible by a process called deep linking – which allowed app developers to assign specific URLs that could open specific app screens. So even without google search, native apps were finally capable of content sharing in ways that were previously only available to websites.
Google has even previewed the potential of where this could lead with the launch of “instant apps” – which would expand the functionality of deep links beyond just apps that are installed, so people can access un-installed app content, just like they would on the web.
So this has been rightfully exciting – and I’ve spent a large chunk of the last two years helping companies do this. It isn’t entirely easy by any means, but for businesses who had already invested in making their native apps their best digital experience, it was worth it.
But at the same time, the mobile web was also changing.
Watch this.
Who knew you could have push notifications for your website? How about this?
But meanwhile, the web was growing, too…
So apps got linking. But the mobile web got push notifications, installing, launching from the home screen, and browserless interfaces.
What makes all of that new functionality possible? A new-ish platform called “progressive web apps” – they’re similar to mobile friendly websites but they add two important supporting technologies – an app manifest that holds information about your website, and something called a service worker.
Now the “Service Worker” is really a critically powerful piece of tech. It is what enables the website to transition from a stand alone in-the-browser state to an app that is fully integrated with the device, more like something native.
Here’s how it works. When your website supports a registered service worker, it can act as an intermediary between the website and the server, so it can fetch resources fro the server.
A service worker is a script that stands between your website and the network, giving you, among other things, the ability to intercept network requests and respond to them in different ways.
enables parts of our JavaScript to act as a proxy between the browser and the server, intercepting and managing requests and responses, and storing or retreiving files from cache.
https://developers.google.com/web/fundamentals/getting-started/primers/service-workers
Things to note about a service worker:
It's a JavaScript Worker, so it can't access the DOM directly. Instead, a service worker can communicate with the pages it controls by responding to messages sent via the postMessage interface, and those pages can manipulate the DOM if needed.
Service worker is a programmable network proxy, allowing you to control how network requests from your page are handled.
It's terminated when not in use, and restarted when it's next needed, so you cannot rely on global state within a service worker's onfetch and onmessage handlers. If there is information that you need to persist and reuse across restarts, service workers do have access to the IndexedDB API.
Service workers make extensive use of promises, so if you're new to promises, then you should stop reading this and check out Promises, an introduction.
We can use service workers:
To make sites work faster and/or offline using network intercepting
As a basis for other ‘background’ features such as push messaging and background synchronization
So thanks to service workers as well as other new development in the mobile web, we ended 2016 in a place where websites and apps converged in capabilities that once used to function differently.
So the question of 2017 is not, should I build an app or a mobile website, but rather, do I invest in making a native app better at reach, or making my website more deeply engaging?
And the answer is YES.
As we look to the future, a lot of these questions obscure even further.
I love this David Mihm quote.
[read]
And with all my respect to David Mihm, this prediction is kind of cheating. Because for some verticals…
http://tidings.com/vault/predictions-2017-part-one.html
We’re already there. Look at this experience. You can book a table on open table without ever hitting open table’s specific website or app.
Which means that opentable could give 2 shits about their traffic growth. They don’t need taffic to make money.
Success can also look like this. So how do you prepare to optimize for a world where your UI might be irrelevant?
An easy way to get started while leveraging your current web platform is through structured data. Structured data allows you to add markup to your website so that your data can be easily ingested by another database.
There are a few ways to format your structured data, but JSON-LD is often the easiest and it’s recommended by Google.
And again, depending on your industry, there may already be special SERP treatment for companies that make their data more easily accessible through schema like this.
https://developers.google.com/search/docs/data-types/tv-movies
https://developers.google.com/search/docs/data-types/recipes
https://developers.google.com/search/docs/data-types/books
Is lyft a native app? A PWA? Could it be a chat bot? Sure! Lyft doesn’t give a shit what the new hot UI looks like because it’s actually an API. The new platform of the future could be slack, or starbucks, and Lyft would still have a business.
Moving on to mobile performance.
Performance matters, and mobile performance matters more. Half of mobile users abandon a site that takes more than 3 seconds to load, and when surveyed, they say they expect the site to take 2.
https://storage.googleapis.com/doubleclick-prod/documents/The_Need_for_Mobile_Speed_-_FINAL.pdf
So it’s no coincidence that the part of Google’s performance framework that gets a mobile icon is “load”.
https://developers.google.com/web/fundamentals/performance/rail
Load times have always been a critical part of performance, even more critical for mobile – it’s not surprise that this is an area that we’ve always tried to optimize, even from the early days
#goals should be:
100 ms response
8ms animate
50ms idle work
1000ms to interactive
And most people start assessing their site performance here – with PageSpeed Insights
https://developers.google.com/speed/pagespeed/insights/
Or the new TestMySite tool. And this is still a very good place to start, because
https://testmysite.thinkwithgoogle.com
We still fuck this shit up. A lot can be done HERE. And many many websites still miss out on these basics. All of this stuff in the box is saying “load less” – “load smaller code files, load smaller image files.”
And you have to be especially if you’re buying a wordpress theme. Some of the prettiest themes are the least performant.
https://themeforest.net/item/skrollex-creative-one-page-parallax/14699984 >> 23 JavaScript libraries and 20 CSS stylesheets
This is wise sage advice – anything that says multi-purpose is likely bloated with stuff you don’t use, but is going to load with your site anyway. IT DOESN’T MATTER IF IT SAYS RESPONSIVE. SLOW IS NOT MOBILE FRIENDLY.
https://themeforest.net/item/skrollex-creative-one-page-parallax/14699984 >> 23 JavaScript libraries and 20 CSS stylesheets
Okay but it’s 2017, we know we have to be fast, but we also want to load our fancy javascript. Apparently a lot of javascript. So after we’ve removed code we don’t need how do we ensure that everything we want to load doesn’t stop our page from loading.
---
At the same time as we are trying to minimize and compress our images for faster loading, we’re also trying to build richer and richer experiences. And that means we’re loading more javascript. The problem is that our phones – but especially older phones – have struggled to handle all the JS we want to ship.
So we need to load less code, but we also need to load more code. How do we do this? We optimize for this by loading the right code, at the right time.
we need to load it at the right time, and let the browser do more work for us whenever possible.
So newer performance frameworks still prioritize a fast loading experience, but the also explain how to – eventually – deliver the best possible experience to users who’s devices can handle it.
If you’re seeing this in your audits, it’s time to look at your waterfalls and move the critical JS and CSS code that you need into the critical rendering path.
https://testmysite.thinkwithgoogle.com
Tools like webpage test can help you see which resources are being required when.
http://www.freeperformancesoftware.com/product/webpagetest-org/
And Chrome Dev Tools can also help.
Timeline section of Chrome DevTools
https://moz.com/blog/the-technical-seo-renaissance
But let’s take this concept of critical path rendering one step further, and you get this newer concept of progressive enhancement.
I don’t mean these progressives
The idea of progressive enhancement is that your website should start with the minimum that it needs to function, and then add functionality as more advanced features are available to it, so that those features don’t hurt its performance. The perfect analogy is an escalator.
So our good friends service workers are also a progressive enhancement for performance – when the service worker isn’t installed, the website should still work. But when it is working, boy can it speed things up.
https://developers.google.com/web/updates/2015/11/app-shell
http://caniuse.com/#feat=serviceworkers
http://caniuse.com/#feat=serviceworkers
Okay so we load less code, we load it at the right time, and now we’re going to lean on the browsers for support when they can help us. This is a technique that Mike King has talked about.
https://moz.com/blog/the-technical-seo-renaissance
https://moz.com/blog/the-technical-seo-renaissance
Pre-fetch = OK to guess. Pre-render = better be sure.
Connecting the next billion
The average mobile user is not on a $600+ phone
Over ½ of active Android users have 1 GB or less in Ram
This has REAL performance implications
Don’t just test on a mobile phone – test on a mobile network
The NETWORK is the “enhancement”
Connecting the next billion
The average mobile user is not on a $600+ phone
Over ½ of active Android users have 1 GB or less in Ram
This has REAL performance implications
Don’t just test on a mobile phone – test on a mobile network
The NETWORK is the “enhancement”
Connecting the next billion
The average mobile user is not on a $600+ phone
Over ½ of active Android users have 1 GB or less in Ram
This has REAL performance implications
Don’t just test on a mobile phone – test on a mobile network
The NETWORK is the “enhancement”
Inconsistent network speeds - Understand network connection variability
if you care about those users, you should be treating the network as an enhancement.
Network connection optimization with “pre-load” on http2 for all the dependencies
Inconsistent network speeds - Understand network connection variability
if you care about those users, you should be treating the network as an enhancement.
Network connection optimization with “pre-load” on http2 for all the dependencies
There is now a school of “offline first” development
Intermittent connections don’t need to be a problem
Google Analytics (and Search Console) have gotten a lot better at segmenting mobile.
But you still have to be careful if you use other tools.
And when tools DO segment, you still have to know how they are segmenting. Which devices are ‘mobile’? ‘Tablet’? What counts as a ‘session’?
Defining what is ‘mobile’ keeps getting increasingly hard when everything looks more & more ‘mobile’…
The truth is that segmenting these devices is not always realistic – many people are multi-device, but our data limitations and our insistence on segmenting mobile users can sometimes obscure this