Javascript & SEO 2019

hello@impression.co.uk
The Javascript & SEO
Landscape

bit.ly/SEO-JS
My slides here ^

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

Edd Wilson
Senior Technical SEO Specialist
● 10 years in SEO
● Agency & In House experience
● 5 years at Impression

×
Clients and Awards
@impressiontalk

@impressiontalk
Websites using Javascript in 2019
@impressiontalk

@impressiontalk
What SEOs saw
@impressiontalk

@impressiontalk
What SEOs need to do
@impressiontalk

@impressiontalk
2014
“..sometimes things don't go perfectly
during rendering, which may
negatively impact search results for
your site.”

@impressiontalk
2016
@impressiontalk

@impressiontalk
Hulu saw a 4 million organic
visitor drop off

@impressiontalk
How does Javascript impact
organic search?

@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

@impressiontalk
“53% of mobile users abandon sites that take longer than 3
seconds to load”
- SOASTA / Akamai

@impressiontalk
“Speed is now used as a ranking factor for mobile searches”
- Google (July 2018)
Need another reason?

@impressiontalk
The problem the modern web has

@impressiontalk
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.

@impressiontalk
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

@impressiontalk
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!

@impressiontalk
● 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

@impressiontalk
● HTML, JS and CSS file compression
○ Whitespace and GZIP
● Reduce code library usage (jQuery)
○ http://youmightnotneedjquery.com/#toggle_class

@impressiontalk
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

@impressiontalk
JavaScript rendering
performance

@impressiontalk
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

@impressiontalk
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

@impressiontalk
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

@impressiontalk
2018: Google’s WRS and second wave indexing
Chrome v41
(March 2015)

@impressiontalk
2019: Evergreen GoogleBot
“Second wave”
now used for most websites
Latest Chrome
(Since May 2019)

@impressiontalk
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)

@impressiontalk
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

@impressiontalk
However...
https://www.onely.com/blog/how-much-content-not-indexed-google-2019/

@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

@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

@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

@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)

@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

@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/

@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

@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

@impressiontalk
https://developers.google.com/web/updates/2019/02/rendering-on-the-web

@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)

@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

×
Detecting and debugging JavaScript SEO sites
47

@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

@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

@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”

@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)

@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!)

@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.

@impressiontalk
@impressiontalk
UK Tool Supplier
● No prerender and then
incorrect prerender
● Uncrawlable internal links
● Links rendering to
homepage
● Crawl depth suffered &
indexed pages dropped

@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

@impressiontalk
@impressiontalk
Beware what your marketing team is adding!
56
(Front end API translation)

@impressiontalk
@eddjtw
What we didn’t cover
● Personalisation and its effect on API-driven content
● Progressive Web Applications

@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

Thank you!
@EddJTW
@impressiontalk
www.impression.co.uk
bit.ly/SEO-JS

Javascript & SEO 2019

More Related Content

What's hot

Similar to Javascript & SEO 2019

More from Edd Wilson

Recently uploaded

Javascript & SEO 2019