6 ms·

Enhance WASM: Back End Agnostic SSR for Web Components

90 points by robin_reala 3y ago

burcs 3y ago
Does server side rendering still have better SEO than client side? I thought that was no longer the case, it's hard to find concrete evidence though. I'm also curious why rendering something in the browser would have poor performance or wouldn't be optimally accessible?
- josephg 3y ago
  > I'm also curious why rendering something in the browser would have poor performance or wouldn't be optimally accessible? To render something in the browser, you have to first send the browser javascript, which then needs to run. Server side rendering can usually be able to generate HTML faster than the javascript renderer can generate DOM. And the HTML itself is often smaller than the javascript needed to render the html. (And you can generate HTML from your server, not from your user's slow android phone via javascript). Server side rendering almost always gets you a faster time-to-first-paint. Which is good for blogs and news websites. But if you need client side rendering anyway (eg you're writing Figma), then its not as big a deal.
  - j45 3y ago
    Sending everything to the browser to crunch is a lot of downloading, and then available at the speed/mercy of the client computer, relative to the resources they have, and what they have acvailable (relative to other tabs). Server side caching is pretty good these days and a valid option in more cases. A lot of devs just started client side and the other side naturally seems bad or unknown. The time where this was an issue server side was when linux didn't network or perform so well with lots of traffic (and the cloud became popular). That's been largely solved.
- hobofan 3y ago
  > it's hard to find concrete evidence though It's hard to find concrete evidence for anything in SEO. However, from what I've seen (and is also shown by some big websites that index just fine) at least Google seems to do handle client side rendering just fine and has been doing so for ~5+ years.
  - gildas 3y ago
    For my part, I've had exactly the opposite experience. Without SSR or equivalent, you often have to wait weeks for your content to be indexed on Google, and the quality of the results varies. I'm talking about sites of at least several hundred/thousand pages.
    - j45 3y ago
      Same. Lots of concrete info out there the more time one spends in SEO openly seeing how non-tech people achieve SEO, and most of the time (not surprisingly) Wordpress is server side.
- mdhb 3y ago
  Google have run headless chromium for many years now, there are no extra bonus points for serving straight HTML to them. The only thing you might get pinged on is if you have crappy core web vitals scores as a result of the client side rendering.
  - gitgud 3y ago
    How does google decide to use the headless chromium? If there’s no metadata in the raw HTML?
  - afavour 3y ago
    > there are no extra bonus points for serving straight HTML to them. There is, in the sense that every site gets a CPU budget allocated for indexing. SSR means less of that budget gets used per page.
    - mdhb 3y ago
      I don’t think this CPU budget actually exists… it’s certainly never been publicly mentioned as far as I can tell. I think it’s another one of those half truths floating around the SEO world. Is there some concept of a budget regarding how many pages they should index on your website? Yes. Is it the same thing as CPU budget, no. Does it impact what position you rank in absolutely not.
  - j45 3y ago
    Most websites, especially templates are extremely heavy in their assets for first time load. The vitals bvetween the average client side compared to the average server side can be staggering. For example, if you take a website that is using client side, on a headless cms or something vs Wordpress, wordpress has many, many plugins that obsess on optimizing the assets and delivery of the file beyond most client side implementations. I love building myself a client side site, it feel so fast, until the need to communicate better or at scale increases and it is a reminder why the website should just be something that is good at being a website.
- adamddev1 3y ago
  I've also wondered this. I have single page client-rendered web apps that get crawled and indexed by Google just fine. The only problem I've run into is when sharing a link on something like WhatsApp, their crawlers don't get the OpenGraph metadata that gets rendered based on the page/link, so the share preview isn't as nice.
- danpalmer 3y ago
  As others have mentioned, Google does client side rendering. What I was told by SEO people in my previous role (unverified otherwise) is that there's essentially a CPU budget per site, and while you can client-side render, it takes more of that CPU budget. For a small site this may be fine, for a large site with many pages it may prevent frequent re-crawls of the site. That said, I gather the budget is not the same for all sites, but varies by other factors. As I said, unverified, but it makes sense and seems like a good way to do it.
  - PlutoIsAPlanet 3y ago
    > while you can client-side render, it takes more of that CPU budget I wonder how Reddit gets indexed given its client-side rendering is painfully slow.
    - buremba 3y ago
      I believe Google can override its CPU budget manually though.
      - j45 3y ago
        I would suspect there aren't an excess of people at Google to manually override.
    - h1fra 3y ago
      CPU Budget (and page budget) is dependent on website popularity. You can see it clearly when you start a new website, google will index 10 pages at most, and as your website grow in popularity it allows 100->1000->10K etc...
  - j45 3y ago
    The CPU budget, for sure, is used in google's ranking of websites because they know how long it will take a site to load, and that is a way to test the speed of a site. Server side is generally lower cpu hit for content that is more SEO specific.
- 63stack 3y ago
  Only tangentially related, but I wonder if "indexability" is even relevant anymore. Google is getting close to useless for searching, and I would bet that all of the big tech companies are racing to write better crawlers to make sure they can suck up all the sweet free content for their next AI model, the incentive for making your site crawlable is inverted in an ironic way. I feel it's much easier/better to concentrate on social media or sites like hn/reddit to increase your site's discoverability.
- scraplab 3y ago
  By using client side rendering you’re effectively playing SEO on hard mode. It’s all possible, but you’re making life very difficult for yourself. Google will crawl and render client side only sites, but the crawl budget will be reduced. The bigger factor is that Google cares a lot about long clicks - clicks on results which don’t immediately produce another search or a return to the results page. Client side rendered sites almost always perform worse from the POV of the user and therefore convert at a lower rate. And now Web Vitals includes things like Largest Contentful Paint and Interaction to Next Paint, you’re going to find it much harder to bring these metrics under the target thresholds. If you want to perform well in search, make things easy for yourself: use mostly SSR HTML and CSS and some sprinkles of JS on top.
  - graemep 3y ago
    "Client side rendered sites almost always perform worse from the POV of the user and therefore convert at a lower rate." I assume that people who create client side rendered sites disagree. Surely no one wants to make user performance worse, and I struggle to see advantages sufficient to offset that.
    - gryzzly 3y ago
      Generally very few people care, unless it’s "an impact metric" tied to that team. Or there is a "performance sprint" or something. "DX" has been more important than "UX" in the current mainstream JS community for a while. To give an example: babel, that enabled syntactic sugar, also caused many versions of runtime implementations of various ES6+ syntax to end up in bundles, or polyfills for browsers the clients aren’t actually using etc. You can read more about the things that are absolutely mainstream and are problems in very popular libraries in the "Speeding Up JavaScript" series from Marvin Hagemeister – like this one https://marvinh.dev/blog/speeding-up-javascript-ecosystem-part-6/ https://marvinh.dev/blog/speeding-up-javascript-ecosystem-pa... Also, most devs are testing on powerful devices, and there is a big disconnect between their experiences and that of their users – https://infrequently.org/2021/03/the-performance-inequality-gap/ https://infrequently.org/2021/03/the-performance-inequality-...
- _heimdall 3y ago
  > I'm also curious why rendering something in the browser would have poor performance or wouldn't be optimally accessible? That's really a tough one to answer since every site is different, but here's a few things to keep an eye on when doing CSR. You don't own the hardware rendering your site. Slow devices will render pages more slowly and there's really nothing you can do about it beyond optimizing the rendering logic itself. CSR will always add more network requests to the page. For a small site, or a user close to your servers this may not be an issue. Caching on CDNs will help for any static files too. Any API requests that are required for rendering will likely introduce waterfall network requests. If the APIs live on your servers, that could have been drastically reduced or removed all together if the HTML rendering was handled by server in the first place. For accessibility, I'm not aware of anything that can't be done accessibly with CSR, but there are things that can get tricky. Every accessibility tool is different. Making sure that content added and removed is updated properly, changes are notified to users when necessary, and that focus is handled properly are all up to you when you decide not to "use the platform" as they say.
- j45 3y ago
  Client side rendering is harder for SEO than server side. Server side has many advantages. If the key is delivering SEO information, client side dynamic UX might not be the core of that experience, and may not be the best application for that part of it.
- doctorpangloss 3y ago
  If you wanna play in someone's network you gotta follow their arbitrary rules. Google's? A bunch of random ass metrics. Facebook's? Well, I guess you're making a Business Page. Apple's? The list is so long. JavaScript frameworks masquerade as SDKs and whatever, when really something like Next.js is a middleware with the same eventual product development complexity as Unity. Web developers think they have 2 browsers (Mobile Safari and Chrome). It's really like 10+ game consoles: Meta Instagram, Meta Facebook, Meta WhatsApp, TikTok iOS, TikTok Android US, TikTok Android Worldwide, Google Search destination, App Store iPhone, App Store iPad...
strogonoff 3y ago
It’s a bit unfortunate that no SSR-supporting libraries and frameworks in JavaScript seem to allow the final website to be built in a pure standards-compliant ES runtime. You have to bring in the entire Node or Deno because everything tends to be hard-coded to depend on the filesystem and other non-standard APIs.
- ricardobeat 3y ago
  That used to be easy with Svelte 3, but later versions got node APIs more intertwined with the code, + a lot of useful features live in SvelteKit.
  - csjh 3y ago
    How do you mean? Svelte 4 and 5 don't use any node-specific APIs for SSR
- afavour 3y ago
  agreed. I once played around with the idea of a framework that rendered server-side then immediately registered a service worker that would perform all subsequent renders on-device. It did work but there were enough rough edges with compatibility that I never got anywhere concrete with it.
- throwitaway1123 3y ago
  The VC funded JS startups have no incentive to promote this, but you can still just call renderToString in any ES runtime to SSR your React components. There's definitely more boilerplate to deal with, but you could easily get away with doing SSR in a lightweight runtime like QuickJS.
  - strogonoff 3y ago
    That is technically correct. I guess I’m just being lazy.
- yencabulator 3y ago
  Not sure if you really meant "build" as in build time there or not. SvelteKit server-side runs happily on e.g. Cloudflare Workers which is just V8 + Web APIs, and definitely not Node or Deno. Generating the files to deploy to a Cloudflare Worker still needs NodeJS.
mike_hearn 3y ago
Interesting. I'm currently doing some work to enable React SSR in the Micronaut framework, which might be useful for some people working on the JVM. There's also https://elide.dev https://elide.dev which is a polyglot server framework that also supports SSR. I didn't fully understand what WASM is doing here though. Web components whether React or otherwise are written in Javascript or something that compiles to it, so you need a server side JS engine (Elide/my Micronaut work use GraalJS). Is WASM just being used here as an alternative to providing a .so/.dll file?
revskill 3y ago
Custom element is global ?
danielvaughn 3y ago
I find this confusing. My understanding of web components is that they exist to encapsulate fragments of the DOM and use JavaScript to extend the functionality of elements. I don't understand how SSR could possibly help here, other than taking the first rendering pass out of the loop and generating standard HTML...which would then mean it's not a web component and just typical SSR. What am I missing?
- CharlesW 3y ago
  > …which would then mean it's not a web component and just typical SSR. SSR doesn't mean that you can't use web component frameworks, just that the framework must be able to both (1) produce and manipulate DOM in the browser as output, and (2) render the same components into HTML strings on the server. I believe frameworks with this capability are categorized as "isomorphic" frameworks. Enhance WASM essentially makes Web Components an isomorphic component framework, with a bonus (for some) of not having to use a server-side JavaScript runtime.
  - danielvaughn 3y ago
    That makes sense, though the first paragraph of that page talks about how web components depend on client-side javascript. My confusion is that a web component by definition has to run client-side javascript. You're either (a) using javascript to port content from a template into your custom element, or (b) using javascript to attach a shadow dom to a custom element. I could be wrong about this, but I don't believe there's a way to send down a working web component from the server without accompanying client-side logic.
    - 1shooner 3y ago
      >I don't believe there's a way to send down a working web component from the server without accompanying client-side logic. Do you mean declarative shadow dom? That landed in FF 123, so I think it's now available on all major browsers.
      - 3y ago

90 points by robin_reala 3y ago

Does server side rendering still have better SEO than client side? I thought that was no longer the case, it's hard to find concrete evidence though. I'm also curious why rendering something in the browser would have poor performance or wouldn't be optimally accessible?

josephg 3y ago
> I'm also curious why rendering something in the browser would have poor performance or wouldn't be optimally accessible? To render something in the browser, you have to first send the browser javascript, which then needs to run. Server side rendering can usually be able to generate HTML faster than the javascript renderer can generate DOM. And the HTML itself is often smaller than the javascript needed to render the html. (And you can generate HTML from your server, not from your user's slow android phone via javascript). Server side rendering almost always gets you a faster time-to-first-paint. Which is good for blogs and news websites. But if you need client side rendering anyway (eg you're writing Figma), then its not as big a deal.
- j45 3y ago
  Sending everything to the browser to crunch is a lot of downloading, and then available at the speed/mercy of the client computer, relative to the resources they have, and what they have acvailable (relative to other tabs). Server side caching is pretty good these days and a valid option in more cases. A lot of devs just started client side and the other side naturally seems bad or unknown. The time where this was an issue server side was when linux didn't network or perform so well with lots of traffic (and the cloud became popular). That's been largely solved.
hobofan 3y ago
> it's hard to find concrete evidence though It's hard to find concrete evidence for anything in SEO. However, from what I've seen (and is also shown by some big websites that index just fine) at least Google seems to do handle client side rendering just fine and has been doing so for ~5+ years.
- gildas 3y ago
  For my part, I've had exactly the opposite experience. Without SSR or equivalent, you often have to wait weeks for your content to be indexed on Google, and the quality of the results varies. I'm talking about sites of at least several hundred/thousand pages.
  - j45 3y ago
    Same. Lots of concrete info out there the more time one spends in SEO openly seeing how non-tech people achieve SEO, and most of the time (not surprisingly) Wordpress is server side.
mdhb 3y ago
Google have run headless chromium for many years now, there are no extra bonus points for serving straight HTML to them. The only thing you might get pinged on is if you have crappy core web vitals scores as a result of the client side rendering.
- gitgud 3y ago
  How does google decide to use the headless chromium? If there’s no metadata in the raw HTML?
- afavour 3y ago
  > there are no extra bonus points for serving straight HTML to them. There is, in the sense that every site gets a CPU budget allocated for indexing. SSR means less of that budget gets used per page.
  - mdhb 3y ago
    I don’t think this CPU budget actually exists… it’s certainly never been publicly mentioned as far as I can tell. I think it’s another one of those half truths floating around the SEO world. Is there some concept of a budget regarding how many pages they should index on your website? Yes. Is it the same thing as CPU budget, no. Does it impact what position you rank in absolutely not.
- j45 3y ago
  Most websites, especially templates are extremely heavy in their assets for first time load. The vitals bvetween the average client side compared to the average server side can be staggering. For example, if you take a website that is using client side, on a headless cms or something vs Wordpress, wordpress has many, many plugins that obsess on optimizing the assets and delivery of the file beyond most client side implementations. I love building myself a client side site, it feel so fast, until the need to communicate better or at scale increases and it is a reminder why the website should just be something that is good at being a website.
adamddev1 3y ago
I've also wondered this. I have single page client-rendered web apps that get crawled and indexed by Google just fine. The only problem I've run into is when sharing a link on something like WhatsApp, their crawlers don't get the OpenGraph metadata that gets rendered based on the page/link, so the share preview isn't as nice.
danpalmer 3y ago
As others have mentioned, Google does client side rendering. What I was told by SEO people in my previous role (unverified otherwise) is that there's essentially a CPU budget per site, and while you can client-side render, it takes more of that CPU budget. For a small site this may be fine, for a large site with many pages it may prevent frequent re-crawls of the site. That said, I gather the budget is not the same for all sites, but varies by other factors. As I said, unverified, but it makes sense and seems like a good way to do it.
- PlutoIsAPlanet 3y ago
  > while you can client-side render, it takes more of that CPU budget I wonder how Reddit gets indexed given its client-side rendering is painfully slow.
  - buremba 3y ago
    I believe Google can override its CPU budget manually though.
    - j45 3y ago
      I would suspect there aren't an excess of people at Google to manually override.
  - h1fra 3y ago
    CPU Budget (and page budget) is dependent on website popularity. You can see it clearly when you start a new website, google will index 10 pages at most, and as your website grow in popularity it allows 100->1000->10K etc...
- j45 3y ago
  The CPU budget, for sure, is used in google's ranking of websites because they know how long it will take a site to load, and that is a way to test the speed of a site. Server side is generally lower cpu hit for content that is more SEO specific.
63stack 3y ago
Only tangentially related, but I wonder if "indexability" is even relevant anymore. Google is getting close to useless for searching, and I would bet that all of the big tech companies are racing to write better crawlers to make sure they can suck up all the sweet free content for their next AI model, the incentive for making your site crawlable is inverted in an ironic way. I feel it's much easier/better to concentrate on social media or sites like hn/reddit to increase your site's discoverability.
scraplab 3y ago
By using client side rendering you’re effectively playing SEO on hard mode. It’s all possible, but you’re making life very difficult for yourself. Google will crawl and render client side only sites, but the crawl budget will be reduced. The bigger factor is that Google cares a lot about long clicks - clicks on results which don’t immediately produce another search or a return to the results page. Client side rendered sites almost always perform worse from the POV of the user and therefore convert at a lower rate. And now Web Vitals includes things like Largest Contentful Paint and Interaction to Next Paint, you’re going to find it much harder to bring these metrics under the target thresholds. If you want to perform well in search, make things easy for yourself: use mostly SSR HTML and CSS and some sprinkles of JS on top.
- graemep 3y ago
  "Client side rendered sites almost always perform worse from the POV of the user and therefore convert at a lower rate." I assume that people who create client side rendered sites disagree. Surely no one wants to make user performance worse, and I struggle to see advantages sufficient to offset that.
  - gryzzly 3y ago
    Generally very few people care, unless it’s "an impact metric" tied to that team. Or there is a "performance sprint" or something. "DX" has been more important than "UX" in the current mainstream JS community for a while. To give an example: babel, that enabled syntactic sugar, also caused many versions of runtime implementations of various ES6+ syntax to end up in bundles, or polyfills for browsers the clients aren’t actually using etc. You can read more about the things that are absolutely mainstream and are problems in very popular libraries in the "Speeding Up JavaScript" series from Marvin Hagemeister – like this one https://marvinh.dev/blog/speeding-up-javascript-ecosystem-part-6/ https://marvinh.dev/blog/speeding-up-javascript-ecosystem-pa... Also, most devs are testing on powerful devices, and there is a big disconnect between their experiences and that of their users – https://infrequently.org/2021/03/the-performance-inequality-gap/ https://infrequently.org/2021/03/the-performance-inequality-...
_heimdall 3y ago
> I'm also curious why rendering something in the browser would have poor performance or wouldn't be optimally accessible? That's really a tough one to answer since every site is different, but here's a few things to keep an eye on when doing CSR. You don't own the hardware rendering your site. Slow devices will render pages more slowly and there's really nothing you can do about it beyond optimizing the rendering logic itself. CSR will always add more network requests to the page. For a small site, or a user close to your servers this may not be an issue. Caching on CDNs will help for any static files too. Any API requests that are required for rendering will likely introduce waterfall network requests. If the APIs live on your servers, that could have been drastically reduced or removed all together if the HTML rendering was handled by server in the first place. For accessibility, I'm not aware of anything that can't be done accessibly with CSR, but there are things that can get tricky. Every accessibility tool is different. Making sure that content added and removed is updated properly, changes are notified to users when necessary, and that focus is handled properly are all up to you when you decide not to "use the platform" as they say.
j45 3y ago
Client side rendering is harder for SEO than server side. Server side has many advantages. If the key is delivering SEO information, client side dynamic UX might not be the core of that experience, and may not be the best application for that part of it.
doctorpangloss 3y ago
If you wanna play in someone's network you gotta follow their arbitrary rules. Google's? A bunch of random ass metrics. Facebook's? Well, I guess you're making a Business Page. Apple's? The list is so long. JavaScript frameworks masquerade as SDKs and whatever, when really something like Next.js is a middleware with the same eventual product development complexity as Unity. Web developers think they have 2 browsers (Mobile Safari and Chrome). It's really like 10+ game consoles: Meta Instagram, Meta Facebook, Meta WhatsApp, TikTok iOS, TikTok Android US, TikTok Android Worldwide, Google Search destination, App Store iPhone, App Store iPad...

strogonoff 3y ago

It’s a bit unfortunate that no SSR-supporting libraries and frameworks in JavaScript seem to allow the final website to be built in a pure standards-compliant ES runtime. You have to bring in the entire Node or Deno because everything tends to be hard-coded to depend on the filesystem and other non-standard APIs.

ricardobeat 3y ago
That used to be easy with Svelte 3, but later versions got node APIs more intertwined with the code, + a lot of useful features live in SvelteKit.
- csjh 3y ago
  How do you mean? Svelte 4 and 5 don't use any node-specific APIs for SSR
afavour 3y ago
agreed. I once played around with the idea of a framework that rendered server-side then immediately registered a service worker that would perform all subsequent renders on-device. It did work but there were enough rough edges with compatibility that I never got anywhere concrete with it.
throwitaway1123 3y ago
The VC funded JS startups have no incentive to promote this, but you can still just call renderToString in any ES runtime to SSR your React components. There's definitely more boilerplate to deal with, but you could easily get away with doing SSR in a lightweight runtime like QuickJS.
- strogonoff 3y ago
  That is technically correct. I guess I’m just being lazy.
yencabulator 3y ago
Not sure if you really meant "build" as in build time there or not. SvelteKit server-side runs happily on e.g. Cloudflare Workers which is just V8 + Web APIs, and definitely not Node or Deno. Generating the files to deploy to a Cloudflare Worker still needs NodeJS.

mike_hearn 3y ago

Interesting. I'm currently doing some work to enable React SSR in the Micronaut framework, which might be useful for some people working on the JVM. There's also https://elide.dev https://elide.dev which is a polyglot server framework that also supports SSR. I didn't fully understand what WASM is doing here though. Web components whether React or otherwise are written in Javascript or something that compiles to it, so you need a server side JS engine (Elide/my Micronaut work use GraalJS). Is WASM just being used here as an alternative to providing a .so/.dll file?

revskill 3y ago

Custom element is global ?

danielvaughn 3y ago

I find this confusing. My understanding of web components is that they exist to encapsulate fragments of the DOM and use JavaScript to extend the functionality of elements. I don't understand how SSR could possibly help here, other than taking the first rendering pass out of the loop and generating standard HTML...which would then mean it's not a web component and just typical SSR. What am I missing?

CharlesW 3y ago
> …which would then mean it's not a web component and just typical SSR. SSR doesn't mean that you can't use web component frameworks, just that the framework must be able to both (1) produce and manipulate DOM in the browser as output, and (2) render the same components into HTML strings on the server. I believe frameworks with this capability are categorized as "isomorphic" frameworks. Enhance WASM essentially makes Web Components an isomorphic component framework, with a bonus (for some) of not having to use a server-side JavaScript runtime.
- danielvaughn 3y ago
  That makes sense, though the first paragraph of that page talks about how web components depend on client-side javascript. My confusion is that a web component by definition has to run client-side javascript. You're either (a) using javascript to port content from a template into your custom element, or (b) using javascript to attach a shadow dom to a custom element. I could be wrong about this, but I don't believe there's a way to send down a working web component from the server without accompanying client-side logic.
  - 1shooner 3y ago
    >I don't believe there's a way to send down a working web component from the server without accompanying client-side logic. Do you mean declarative shadow dom? That landed in FF 123, so I think it's now available on all major browsers.
    - 3y ago