To demonstrate (Ian rubs his hands together) I get to use quadrant diagrams.
For us mere mortals, here’s a fuller explanation:
UI enhancement changes the way the browser interacts with content rendered on the server. Examples include tabbed, drop down navigation, and (sigh) carousels.
Client vs. Server-Side
Every web page is an interaction between a client (a browser, like Chrome, or a bot, like Google) and a server.
Generating a web page involves three steps:
- Fetch the page template (the layout)
- Fetch the content
- Merge the content with the template
Server- and client-side rendering perform these three steps differently.
Server-side rendering does all three steps on the server, then sends the result to the client. The client has everything it needs, renders the full page, and goes on its merry way.
Here’s our quadrant diagram so far:
Static Content vs. Dynamic Interface
Some pages are just stuff: Words and pictures and links and buttons. Clicking those links and buttons send me to another page or display a form. They don’t profoundly modify the page itself. That’s static content, and it’s what you browse 90% of the time: Articles, product pages, blog posts, news, etc.
Other pages change a lot depending on my actions: A text editor, a multi-faceted search, or a page where content continually updates. A page like this is a dynamic interface. The Portent Title Generator, built by some incredible agency (cough) is an example:
Hopefully, your SEO strategy doesn’t hinge on dynamic content. If you’re going to succeed in SEO, you need to get your static content indexed and optimized.
Static vs. dynamic is the next part of the quadrant diagram:
That’s in Google’s own words at io2018. Check the video at 14:11.
- Google felt it necessary to point out that fact
If you’re doing SEO, you can’t afford to end up in the bottom-right box.
If you must use client-side rendering on static content, here are two ways to reduce the damage:
Prerendering and user-agent detection
Prerendering works like this:
- Render a server-side version of each page on your site
- Store that
- When a client visits, check the user agent
The logic is licking-your-own-eyeball-from-the-inside tortured: If you can deliver prerendered content, why not just do that from the start? But, if you must, try Puppeteer to do prerendering, or a service like prerender.io, which does all the work for you.
If you search for “hybrid rendering,” you’ll find seven million pages, each with a slightly different definition of “hybrid rendering.” For our purposes, assume it means “Deliver the most important content, then the other stuff.”
When To Use Which
For static content, use server-side rendering or, if you must, prerendering. If you want to optimize content that’s in a dynamic interface (like Coursera’s course list), use hybrid rendering.
ONE LAST QUADRANT DIAGRAM:
Why Mitigation Sucks
My rule: If Google gives you ways to mitigate a thing, don’t do that thing at all.
You know your doctor can set a bone. That doesn’t mean you go out of your way to break your leg for giggles.
If nothing else, remember that Google changes their mind.
That doesn’t include carousels and other stuff. That’s UI enhancement, not content delivery. Done right, it’s perfectly OK.
This will bunch up the undergarments of many SEOs, developers, search scientists, and engineers: Don’t test.
Tests make you feel better. They show you that Google can indeed render the content. Great! Hooray for you!
No. Boo for you! Because testing verifies indexing and rendering. It does not verify that you’re competitive.
Ask Yourself Why
There are two lessons here:
- There’s a difference between SEO and indexation
Then remember this handy quadrant diagram. I put a lot of time into this:
Is there a tool that can detect whether client-side or server-side is being used to deliver content? Or something I could look for in the source code?
If a site’s using client-side rendering, the page will be blank or missing big chunks of content.