Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Javascript & SEO 2019
Similar to Javascript & SEO 2019 (20)
More from Edd Wilson
Recently uploaded
Recently uploaded (20)
Javascript & SEO 2019
- 1. hello@impression.co.uk The Javascript & SEO Landscape
- 3. hello@impression.co.uk Impression Founded in November 2012, Impression has grown to be one of the UK’s premier agencies, working with brands across the globe to drive higher returns on their digital marketing investments. ● 50 strong UK team ● Specialisms across SEO, PPC, PR, Analytics ● Work with startups, SMBs & Corporates ● Won a nice selection of awards, too
- 4. hello@impression.co.uk Edd Wilson Senior Technical SEO Specialist ● 10 years in SEO ● Agency & In House experience ● 5 years at Impression
- 6. @impressiontalk Websites using Javascript in 2019 @impressiontalk
- 8. @impressiontalk What SEOs need to do @impressiontalk
- 9. @impressiontalk hello@impression.co.uk 2014 “..sometimes things don't go perfectly during rendering, which may negatively impact search results for your site.”
- 13. @impressiontalk Hulu saw a 4 million organic visitor drop off
- 14. @impressiontalk How does Javascript impact organic search?
- 15. @impressiontalk The two aspects of JavaScript SEO Although they’re inherently intertwined, there are two aspects of JavaScript SEO specialists want to learn: JavaScript SEO for Rendering Performance JavaScript SEO for Loading Performance
- 16. @impressiontalk “53% of mobile users abandon sites that take longer than 3 seconds to load” - SOASTA / Akamai
- 17. @impressiontalk “Speed is now used as a ranking factor for mobile searches” - Google (July 2018) Need another reason?
- 18. @impressiontalk The problem the modern web has
- 19. @impressiontalk
- 20. @impressiontalk
- 21. @impressiontalk hello@impression.co.uk How does this impact SEO / Googlebot? ● Ranking factor in mobile search - (Googlebot Smartphone) ● Crawl efficiency - if a page is slow, Googlebot can notice its crawlers are slowing down your website and decide to decrease the crawl rate. ● Google could have issues related to rendering your content.
- 22. @impressiontalk hello@impression.co.uk Optimisations you can make ● Fix render blocking resources ○ De-prioritise render-blocking JavaScript to the footer (not <head>) ○ Use “async” or “defer” tags ● “Chunk” JavaScript ○ Only load required modules per page ● Remove unused CSS and “scope” CSS
- 23. @impressiontalk hello@impression.co.uk JavaScript Async vs Defer https://flaviocopes.com/javascript-async-defer/#performance-comparison & https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/lo Only time- critical, like Analytics Everything else Load in footer where possible, too!
- 24. @impressiontalk hello@impression.co.uk Optimisations you can make ● Load appropriate image sizes ○ JavaScript lazy loading should never be used on all images ○ “Deferring loading of non-critical or non-visible content, also commonly known as "lazy loading", is a common performance and UX best practice … if not implemented correctly, this technique can inadvertently hide content from Google...” ● Inline critical CSS and/or JS ○ Include critical JS in <script> in the <head> and de-prioritize/remove the rest
- 25. @impressiontalk hello@impression.co.uk Optimisations you can make ● HTML, JS and CSS file compression ○ Whitespace and GZIP ● Reduce code library usage (jQuery) ○ http://youmightnotneedjquery.com/#toggle_class
- 26. @impressiontalk hello@impression.co.uk How to identify JS performance issues ● View Source ○ Investigate included scripts ○ Check positioning ○ Check for defer/async ● Use waterfall load tools (Chrome, Pingdom) ○ Load order ○ Server response time ○ CDN for all static resources (lower TTFB) ● Lighthouse / Chrome Audit ● Pagespeed Insights
- 28. @impressiontalk hello@impression.co.uk How’s this different? “Loading Performance” ● The JavaScript that loads and executes AFTER the initial page source has loaded ● Can affect any website using any amount of JavaScript
- 29. @impressiontalk hello@impression.co.uk How’s this different? “Rendering Performance” ● Affects websites which build or heavily modify content through JavaScript ● These websites don’t work on their own without JavaScript enabled
- 30. @impressiontalk hello@impression.co.uk JS rendered content & the web ● Google has had a long relationship with JavaScript crawl schemes [1] ● This summer the evergreen GoogleBot launched ● For other popular international search engines/apps without WRS ○ Indexing and ranking content is difficult/impossible ○ If present, home /popular linked pages often appear poorly in results pages ○ This is an inherent issue: JavaScript is traditionally rendered Client Side ○ Bing currently recommends Dynamic Rendering for best results ● Google has had a long relationship with JavaScript crawl schemes [1] ● This summer the evergreen GoogleBot launched ● For other popular international search engines/apps without WRS ○ Indexing and ranking content is difficult/impossible ○ If present, home /popular linked pages often appear poorly in results pages ○ This is an inherent issue: JavaScript is traditionally rendered Client Side ○ Bing currently recommends Dynamic Rendering for best results
- 31. @impressiontalk hello@impression.co.uk 2018: Google’s WRS and second wave indexing Chrome v41 (March 2015)
- 32. @impressiontalk hello@impression.co.uk 2019: Evergreen GoogleBot “Second wave” now used for most websites Latest Chrome (Since May 2019)
- 33. @impressiontalk hello@impression.co.uk 2019: Evergreen GoogleBot ● Lots of new features (1000+) ○ New APIs for lazy loading ○ Support for Web Components ○ JavaScript ES6 ….meaning better understanding of existing problematic JavaScript (just for GoogleBot)
- 34. @impressiontalk hello@impression.co.uk However... “I wouldn't say that two waves of indexing are dead, it's definitely not. I expect eventually rendering crawling and indexing will come closer together. We're not there yet [...]” - John Mueller, 28 August 2019
- 36. @impressiontalk @impressiontalk So can we do better? ● Not serving empty HTML to bots ● Not asking users to wait for initial content downloads ● Delivering consistent content for all search engines ● Ensuring we’re rendering Open Graph tags for the social web The goal is to serve all users populated & complete HTML on the first load
- 37. @impressiontalk Server Side Rendering Server Side Rendering “SSR” is a blanket term: ● Pre-rendering / Static rendering ● Static site generation ● Dynamic rendering ● Hybrid rendering ● Isomorphic JavaScript / Universal Rendering
- 38. @impressiontalk @impressiontalk Pre-rendering ● Serve bots full page HTML snapshots of all pages ○ Store snapshots in a temporary cache ○ Serve static HTML to all bots/crawlers ○ Refresh periodically (~7 days to keep cache fresh) ○ If pages update in the meantime, queue for new HTML snapshot ● Best for ○ Mostly static websites ○ Blogs, brochure & lead gen websites
- 39. @impressiontalk Pre-rendering ● DIY Open Source options ○ Puppeteer & Rendertron ○ Try for yourself: https://render- tron.appspot.com/render/https://www.brightonseo.com/ ○ Relatively simple to get set up ● Commercial options ○ Prerender.io (250 pages free; no endorsement) ○ Very easy to get set up ○ Nice extra: prerender.io strips all <script> tags in HTML for bots (smaller files)
- 40. @impressiontalk https://developers.google.com/web/updates/2019/02/rendering-on-the-web Static site generation ● Technically something slightly different to other rendering options ● HTML files are generated: ○ For every possible URL ○ Generated as a build step and then only on specific triggers ○ Not refreshed based on cache time-outs ○ Not refreshed at regular intervals ● Suitable for sites of all sizes, where content isn’t overly dynamic
- 41. @impressiontalk Hybrid rendering ● A combination of server-rendered and client-side rendered pages ● First static page loads rendered server side ● Users and Bots get HTML and for users the JS then executes ● Then browser renders subsequent content following this https://developers.google.com/web/updates/2019/02/rendering-on-the-web & https://seopressor.com/blog/seo-javascript-google-io-18-summary/
- 42. @impressiontalk Dynamic rendering ● For content that changes rapidly, or non-supported JS features ● A variation on pre-rendering/hybrid as HTML is rendered in real-time https://developers.google.com/search/docs/guides/dynamic-rendering
- 43. @impressiontalk Dynamic rendering ● A workaround for crawlers, but not seen as cloaking by Google ○ Google will diff rendered DOM vs server HTML for major content differences ● If appropriate then a temporary cache for rendered pages is fine ● Site dynamically detects whether it’s a search engine or not and serves appropriate content ● Can use similar pre-rendering solutions (Rendertron etc) for this ● To test: Verify with Google’s Mobile Friendly Test/URL Inspection https://developers.google.com/search/docs/guides/dynamic-rendering
- 45. @impressiontalk Recap: Benefits of SSR* *From any of the SSR options ➔ Serve users & bots populated HTML (no wait) ➔ Able to serve content from cache, CDN or static file (fast) ➔ JavaScript can be stripped out for bots (smaller files) ➔ Can rehydrate into an app once DOM ready (keeps functionality)
- 46. @impressiontalk So today’s take away will be: Serve all of your users - humans and bots - fully rendered HTML on first page load ...and then load in some nicely optimised JavaScript enhancements
- 47. × Detecting and debugging JavaScript SEO sites 47
- 48. @impressiontalk @impressiontalk Navigating the site as a user Probably the easiest and least technical! ● Navigate from page to page as a user ● If the browser URL changes but the page doesn’t visibly reload … then it’s likely using at least some JavaScript features to do so
- 49. @impressiontalk @impressiontalk Request as GoogleBot Change Network Conditions to change User Agent to “GoogleBot” ● See if for GoogleBot the website returns full HTML ● Also, look for differences in the code to the rendered DOM
- 50. @impressiontalk @impressiontalk What is Diff checking? As close as possible, a perfect match between ● client side rendered HTML and ● what it’s fed from the server Resource: https://www.diffchecker.com/ Chrome plugin: “View Rendered Source”
- 51. @impressiontalk @impressiontalk Debugging and testing ● Google: Lighthouse Audit (Loading Performance) ○ Test real-world data on your machine or simulate & throttle RUN IN PRIVATE ● Google: Pagespeed Insights(Loading Performance) ○ Test “field data” (Lighthouse) vs “lab data” (the CrUX report) [1] ● Google: Mobile friendly test & URL inspection tool(Rendering Performance) ○ Test how GoogleBot sees your URL and ensure content is being displayed ● Bing Webmaster Tools & Yandex Webmaster Tools (Rendering Performance)
- 52. @impressiontalk @impressiontalk Using search operators site: search operators pick up indexed content from pages, just in case you’re unsure if your content is being seen (Note the title!)
- 53. @impressiontalk @impressiontalk Case studies All SPA situations are typically unique, but see what impact these changes had will show the value of properly considered SSR solutions.
- 54. @impressiontalk @impressiontalk UK Tool Supplier ● No prerender and then incorrect prerender ● Uncrawlable internal links ● Links rendering to homepage ● Crawl depth suffered & indexed pages dropped
- 55. @impressiontalk @impressiontalk Venue finder website ● New React website with no SEO consideration ● JavaScript redirects only partially understood ● Metadata only rendering defaults ● All canonicals linking to homepage The results 133% Increase in organic impressions 98% Increase in weekly organic traffic 93% Increase in enquiries
- 56. @impressiontalk @impressiontalk Beware what your marketing team is adding! 56 (Front end API translation)
- 57. @impressiontalk @eddjtw What we didn’t cover ● Personalisation and its effect on API-driven content ● Progressive Web Applications
- 58. @impressiontalk @eddjtw Takeaways ● JavaScript SEO best practice is always changing ● There’s been 2+ major changes over the summer already ● Personalisation will continue to keep this interesting ● Frameworks will continue to improve (for SEOs!) Serve all of your users - humans and bots - fully rendered HTML on first page load