With the changes in the new version of Lighthouse, we saw our pages drastically dropped in score as compared to the last version (version 6 vs version 5)
This forced us to take a look again at how we are loading our pages and worked hard during the last couple of weeks to change the structure of our meteor pages.
Here are some learnings that might help other users of Meteor and React
- Server Side Rendering
- server render package: https://docs.meteor.com/packages/server-render.html
- @captainn meteor react-loadable: https://github.com/CaptainN/npdev-react-loadable
- Inline CSS
- @wildhart technique of inline css: Pre-rendered landing pages with Critical CSS
- react-router to identify and cache the inline-css of different routes (although the pages are dynamic, each route normally displays the same page structure (i.e. the same critical css); used staticContext for cases where a page structure changes depending on some variable)
- Async load CSS
- We have to fork
boilerplate-generator
package to achieve this: https://github.com/meteor/meteor/tree/devel/packages/boilerplate-generator - Defer css: https://www.filamentgroup.com/lab/load-css-simpler/
- Proper React hydration without re-rendering (for many, no white-screen flicker)
- react-router for the staticrouter context: https://reacttraining.com/react-router/web/example/static-router
- fast-render-like data handling: we did not use fast-render in this case but the idea is the same. When generating the SSR page, we attached the data from the static context to the generated HTML page. During react hydration, the data is being used to hydrate the page and not query from the server
Sample pages:
Feedback welcome so we can further improve our pages