4 ms·

How well do web components work in the context of SEO and pagespeed scores?

claytongulick 5y ago
I think they're generally intended for use in SPA/PWAs. I doubt the shadow dom is particularly crawler friendly. Also, they aren't great at SSR though some frameworks try to fix that. It would also depend a lot on how you were using/designing them. If you were using slots and putting content inside of a custom tag, and just using that tag for display concerns, SEO would be just fine, though you may lose some semantic markup points.
- e111077 5y ago
  Shadow DOM is crawlable for a few years now
jjcm 5y ago
I’ve had mixed results. Page speed is excellent - I built out an SPA with ~60 or so components and my uncached first paint happens in about 400ms. Cached I get 250ms (this is on prod so it includes the server latency). SEO is more difficult. I’ve been using the npm package prerender to serve up the page properly for Google/Facebook/Discord bots and for crawlers, and since using that I’ve had successful parsing, but at the cost of perceived performance by the bots (the prerender step adds about 2s to the pageload, which only the bots experience).
- brailsafe 5y ago
  Why don't you cache the prerender and serve to everyone?
  - jjcm 5y ago
    I'm using a static html file for the full app. The client side selectively removes/adds html for each of the pages depending on the url. Upside to this approach is that static = fast. Downside is if I prerender then the routes don't have the initial context for navigation to other pages. The prerender shows only a subset of the full site. I'd have to re-architect the client side router I wrote to support it, and that's very low on my MVP list, especially with performance in the 200-400ms range as it is.
- mhoad 5y ago
  I’m pretty actively following a lot of the web components community so I thought I would jump in here with some hopefully helpful information. Depending on what you mean by SEO it’s worth noting that for a while now Google and I believe Bing and a few others haven’t had any kind of requirement to pre-render content. You can just serve standard web components or any kind of SPA style front end and it will get indexed just fine, no penalties and no real issues unless you’re doing something particularly strange. However, one of the more exciting projects in the web components space (lit.dev) now also supports proper SSR as well which is a very new thing in the world of web components. They are trying to build it in such a way that any other library can take advantage of through a common interface. In fact there are some kind of early stage talks happening over here https://github.com/webcomponents/community-protocols https://github.com/webcomponents/community-protocols where a bunch of companies like Google, Adobe, ING and others are trying to develop some open protocols on a whole bunch of topics to improve interoperability between various libraries so that no one has to buy in 100% to any one setup.

I think they're generally intended for use in SPA/PWAs. I doubt the shadow dom is particularly crawler friendly. Also, they aren't great at SSR though some frameworks try to fix that. It would also depend a lot on how you were using/designing them. If you were using slots and putting content inside of a custom tag, and just using that tag for display concerns, SEO would be just fine, though you may lose some semantic markup points.

e111077 5y ago
Shadow DOM is crawlable for a few years now

jjcm 5y ago

I’ve had mixed results. Page speed is excellent - I built out an SPA with ~60 or so components and my uncached first paint happens in about 400ms. Cached I get 250ms (this is on prod so it includes the server latency). SEO is more difficult. I’ve been using the npm package prerender to serve up the page properly for Google/Facebook/Discord bots and for crawlers, and since using that I’ve had successful parsing, but at the cost of perceived performance by the bots (the prerender step adds about 2s to the pageload, which only the bots experience).

brailsafe 5y ago
Why don't you cache the prerender and serve to everyone?
- jjcm 5y ago
  I'm using a static html file for the full app. The client side selectively removes/adds html for each of the pages depending on the url. Upside to this approach is that static = fast. Downside is if I prerender then the routes don't have the initial context for navigation to other pages. The prerender shows only a subset of the full site. I'd have to re-architect the client side router I wrote to support it, and that's very low on my MVP list, especially with performance in the 200-400ms range as it is.
mhoad 5y ago
I’m pretty actively following a lot of the web components community so I thought I would jump in here with some hopefully helpful information. Depending on what you mean by SEO it’s worth noting that for a while now Google and I believe Bing and a few others haven’t had any kind of requirement to pre-render content. You can just serve standard web components or any kind of SPA style front end and it will get indexed just fine, no penalties and no real issues unless you’re doing something particularly strange. However, one of the more exciting projects in the web components space (lit.dev) now also supports proper SSR as well which is a very new thing in the world of web components. They are trying to build it in such a way that any other library can take advantage of through a common interface. In fact there are some kind of early stage talks happening over here https://github.com/webcomponents/community-protocols https://github.com/webcomponents/community-protocols where a bunch of companies like Google, Adobe, ING and others are trying to develop some open protocols on a whole bunch of topics to improve interoperability between various libraries so that no one has to buy in 100% to any one setup.