SearchLove San Diego 2017 | Emily Grossman | The New Mobile

Editor's Notes

• #3: 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.
• #4: 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.
• #5: 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
• #6: To take mobile seriously is to know that we’re already in the 2nd half of this S-curve.
• #7: 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.
• #8: 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.
• #9: And I’ve brough 3 issues with me today: Mobile platform Mobile Performance Mobile Analytics
• #10: For each one we’re going to talk about effective strategies for the old context, the new context, and for the future
• #11: Let’s start with mobile platform
• #12: 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.
• #13: 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
• #14: 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
• #15: 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.
• #16: 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.
• #17: 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.
• #18: Watch this.
• #20: Who knew you could have push notifications for your website? How about this?
• #21: But meanwhile, the web was growing, too…
• #22: So apps got linking. But the mobile web got push notifications, installing, launching from the home screen, and browserless interfaces.
• #24: 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.
• #25: 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.
• #26: 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
• #27: 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.
• #28: 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.
• #29: 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
• #30: 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.
• #31: Which means that opentable could give 2 shits about their traffic growth. They don’t need taffic to make money.
• #32: Success can also look like this. So how do you prepare to optimize for a world where your UI might be irrelevant?
• #33: 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.
• #34: There are a few ways to format your structured data, but JSON-LD is often the easiest and it’s recommended by Google.
• #35: 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
• #36: https://www.programmableweb.com/news/what-are-benefits-apis/analysis/2015/12/03
• #37: 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.
• #38: Moving on to mobile performance.
• #39: 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
• #40: 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
• #41: And most people start assessing their site performance here – with PageSpeed Insights https://developers.google.com/speed/pagespeed/insights/
• #42: Or the new TestMySite tool. And this is still a very good place to start, because https://testmysite.thinkwithgoogle.com
• #43: 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.”
• #44: 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
• #45: 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
• #46: 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.
• #47: 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
• #48: Tools like webpage test can help you see which resources are being required when. http://www.freeperformancesoftware.com/product/webpagetest-org/
• #49: And Chrome Dev Tools can also help. Timeline section of Chrome DevTools https://moz.com/blog/the-technical-seo-renaissance
• #50: But let’s take this concept of critical path rendering one step further, and you get this newer concept of progressive enhancement.
• #51: I don’t mean these progressives
• #52: 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.
• #53: 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
• #54: http://caniuse.com/#feat=serviceworkers
• #55: http://caniuse.com/#feat=serviceworkers
• #56: 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
• #57: https://moz.com/blog/the-technical-seo-renaissance Pre-fetch = OK to guess. Pre-render = better be sure.
• #58: 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”
• #59: 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”
• #60: 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”
• #61: 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
• #62: https://www.smashingmagazine.com/2016/02/preload-what-is-it-good-for/
• #65: 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
• #66: There is now a school of “offline first” development
• #67: Intermittent connections don’t need to be a problem
• #71: 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.
• #72: http://www.aleydasolis.com/en/search-engine-optimization/keywords-research-tools-comparison/
• #73: http://www.aleydasolis.com/en/search-engine-optimization/keywords-research-tools-comparison/
• #74: 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
• #75: Social Sharing (IM, Email, Slack…) Search
• #76: Social Sharing (IM, Email, Slack…) Search
• #77: Social Sharing (IM, Email, Slack…) Search
• #78: https://arstechnica.com/security/2017/02/now-sites-can-fingerprint-you-online-even-when-you-use-multiple-browsers/
• #80: https://moz.com/blog/the-technical-seo-renaissance
• #83: So instead of a bunch of quotes about mobile being a big deal, I want to leave you with this.
• #84: So instead of a bunch of quotes about mobile being a big deal, I want to leave you with this.
• #85: So instead of a bunch of quotes about mobile being a big deal, I want to leave you with this.
• #91: 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
• #92: https://www.programmableweb.com/news/what-are-benefits-apis/analysis/2015/12/03
• #93: https://testmysite.thinkwithgoogle.com
• #94: Push critical resources for the initial URL route. Render initial route. Pre-cache remaining routes. Lazy-load and create remaining routes on demand.