search

magento / pwa-studio

🛠Development tools to build, optimize and deploy Progressive Web Applications for Magento 2.
https://developer.adobe.com/commerce/pwa-studio/
Open Software License 3.0
1.07k stars 683 forks source link

[feature]: Add static, compiled SSR to Venia #1529

Closed zetlen closed 5 years ago

zetlen commented 5 years ago

Venia renders all pages dynamically and all requests through UPWARD. This is our current unified system for doing SEO and preload. We should change it. We should start delivering a fully statically served, client-rendered app to real users (mobile and desktop), as well as to fully rendering crawlers like Googlebot. We should only do SSR for the few relevant things (Link expanders for social media objects) that absolutely require it.

Why tho

SSR is not necessary for SEO according to the PWA standards team. Their preferred approach is a quick static render, then progressive load. Plus, they endorse rendering different pages based on different browser capabilities using https://github.com/Polymer/prpl-server. This is a big change from the conventional wisdom in eCommerce, and because SEO is so important to eCommerce, this will have to be a thoroughly proven approach before it reaches wide adoption. Therefore, we must adopt it as soon as possible!

What is wrong

Our SSR is very slow, which is partially the responsibility of the Magento 2.3 GraphQL API in its current state. But we are also not consuming that GraphQL API very efficiently. In Venia, we do partial server-side render in an attempt to send content to all browsers that works for all browsers. But in practice, the backend GQL requests take seconds before beginning to send an app shell, according to this WebPageTest performed by Alex Russell at Google. All we use this for is pre-checking the route. Not worth it.

Most of the upward.yml file in Venia concerns strategies for rendering various app shells. Since this logic is so generic and UPWARD must handle requests dynamically, this adds a lot of time and complexity for all users, when the vast majority of the users are not going to need SSR at all. Instead, if they can get the app downloaded and loaded faster, they can use client-side SSR and ServiceWorker caching to achieve the same experience.

Google's best-practices showcase site https://shop.polymer.org is fully client-side rendered, and beats almost all other storefronts.

Describe the solution you'd like

  1. Refactor Venia to deliver from a statically generated HTML file. Measure performance gaoins
  2. Add an HTML asset generator, like the standard and popular one, to Venia's Webpack build
  3. Generalize this HTMLWebpackPlugin into the Buildpack pipeline
  4. Add SSR back through extensions, to use only when requests come from a user agent known not to have client side rendering. [Outsource the tracking of those user agents.])https://github.com/Polymer/tools/tree/master/packages/browser-capabilities)

Describe alternatives you've considered Full React SSR render, which is non-portable (it essentially requires NodeJS at runtime), slower, and more brittle.

Please let us know what packages this feature is in regards to:

paales commented 4 years ago

Full React SSR render, which is non-portable (it essentially requires NodeJS at runtime), slower, and more brittle.

What I'm scared of, is that the forced compatibility with PHP is the whole reasoning behind this issue. It seems that because UpwardPHP isn't able to do SSR, we create rationalisations/reasons why SSR isn't required.

Please note that Polymer is using the same reasoning, because nobody can SSR webcomponents. Nothing has been invented or changed in the spec to allow this.. They are not doing CSR because its not necessary, but because they can't. SSR does offer advantages, they are just very much in denial. (our own website is build completely in webcomponents and we now have to experience all the issues with it).

Why SSR:

  1. Sending only HTML / CSS for the currently rendered page will always be less KB's than shipping the whole application for that page. the HTML/CSS is one slice of the state of the application, and the application, well is, all the states for that page.

    Parsing and rendering HTML/CSS is way less CPU intensive and therefor the First Contentfull Paint will be earlier.

  2. Sending the initial state will reduce roundtrips, because the GraphQL query state can be embedded with the HTML, everything can be send along the HTML document.

  3. The balance tips more in favor of HTML/CSS than JS when bundle sizes becomes bigger.

  4. Some bots require it, having a single render system is easier than having a browser path and a bot path.

PWA studio seems to be on track to be a great product, following industry standards like React, Apollo Client, etc. which is a great win for the community. For the build system and delivery I would hope PWA studio would in that same direction: Go with a more industry standard solution as well. There are great solutions available that fix all these issues.

Take a look at NextJS's examples: https://github.com/zeit/next.js/tree/canary/examples Stuff still needs to be assembled in a way thats best for Magento, but at least a lot of 'common' issues are solved for us in an industry standard way.

Please be aware of the Not Invented Here syndrome. You choose React because of it's ecosystem, would be nice if we'd be able to leverage that.