Improving performance

[AliceR]

Improving performance

I just watched a recent talk on Common Mistakes that degrade frontend performance https://www.twitch.tv/videos/994452019
This is a summary of my learnings I am planning to apply on this project:

JS Bundle analysis

1. gatsby-plugin-webpack-bundle-analyser-v2
   wrapper around webpack-bundle-analyser, high level overview of all the bundles on the site. Which bundle is big?
   Great place to start

2. gatsby-plugin-perf-budgets
   Same plugin, but it applies page by page. Better insight into hashed bundles.
   Which javascript is loaded, app level vs. template level.

These are the sections:

• App bundle, good chance for optimization (global bundle)
• web pack runtime - no control
• Framework, react and react dom - no control
• Commons, libraries used on every Gatsby page
• Component, for each page component and the components it uses
• Shared, libraries used by more than one page
• Styles, css modules
• Library, libs larger than 160kb
• Dynamic imports, when using import() syntax

3. Dev Tools performance tab
   Profile the page, look for javascript that runs long time. Bundle analysis gives kilobytes, performance tab helps see if javascript loops and gets expensive when executed.

This analysis gives clues on where to apply the next section hints:

Component Level Code Splitting

Out of the box, gatsby does page/template level code splitting. Sometimes you might want component level code splitting.

• flexible layouts (e.g. headless CMS)
• conditional rendering of expensive components
• when the page imports all the components, they end up in the bundle even when not needed
• we need to maintain SSR: gatsby-plugin-loadable-components-ssr
use @loadable/component to import components conditionally

Global State Management

(not relevant for this project, but adding for completeness and possibly future reference)

• problem: components on app level that are not app level.
• state management can introduce a lot more expensive javascript
• data on every page that does not need to be on every page
• wrapping the whole app in a redux store should ring some alarms 🚨
• Gatsby will place all the helper functions and dependencies in the app bundle, this can grow very large very quickly
• ask first:
  • can this be local state? lets keep as local as possible
  • are slices of store page specific? only wrap that page
  • are there slices of the store that are interaction dependent?
• check github.com/graysonhicks/gatsby-redux-code-splitting-example for how to do combine gatsby with redux

(Too) Lazy Images

First and largest contentful paints account for half of the Lighthouse score (LCP).

• Target some images to behave differently.
• The only image I can see at first is the big banner. This can slow down the contentful paint.
• Above the fold: loading=“eager” (prop in image component) <- Quick win! 🍎
• Below the fold: loading=“lazy” (default anyways)

---

PS: Gatsby offers a paid service to help improve performance: https://www.gatsbyjs.com/products/concierge/performance

Other resources

https://www.gatsbyjs.com/docs/how-to/performance/improving-site-performance/

[AliceR]

😱 Running a lighthouse audit

[AliceR]

Now, this just happened

It is getting to a point where I wonder if these issues might be related to our recent upgrade to Gatsby v3. But maybe its also just me, adding a platform and instrument image on every platform card, where I should really look into pagination...

Seems like we need to prioritize and tackle this issue earlier than I initially thought.

[necoline]

wow, thanks for diving in to this! It looks like we have our work cut out for us. My guess is that images on all the cards was certainly a big part of this ☝️ . I think v3 only helped with some of our performance issues

[AliceR]

Skipping the card images did make the deploy pass: #282
I'll open a separate issue for the card images and keep this one focussed on the remaining performance issues.

[AliceR]

Current lighthouse reports for three important pages:

• Home

• Explore platforms

• Campaign page