Performance Improvements about frontend

[alextes]

Yes, I've been eyeing these metrics and wanting to improve them for a while 🙈 .

I'm glad someone popped up and started plucking some great low-hanging fruit, thank you 💛 .

I just spent some time refactoring things and have to get back to some features on the roadmap but I tend to pick these things up anyway along the way because they never get done otherwise. So both creating issues with great opportunities is helpful, as well as any PRs. I'll always make time to review those.

Ping me on Telegram https://t.me/smilingalex if you'd like my input on anything or I don't react to a PR!

[alextes]

Yea Lighthouse is great!

Well, I think that would depend on what you prioritize no? Downloading 30Mb of images is pretty terrible by any standard, don't get me wrong, but I think our audience is more interested in the time to first paint and interaction, and less interested in downloading a couple more megabytes. Nevertheless, I'm happy we improved it! Thanks for the help.

You'll also see Lighthouse mentions the same, reducing initial load with a smaller JS payload is nr3 on the list:

I vaguely recall the lib was also one of the bigger ones on the treemap in Lighthouse but not 100% sure now.

[alextes]

Another thing that came to mind, Lighthouse doesn't like our large DOM size. To some extent this is hard to overcome as the page is a dashboard and those tend to have a lot of nodes. However, we have a bunch of lists containing many items, which could wait with rendering those items. I think those might be the biggest DOM size savings available to us.

Then secondly we're exploring a design where each section lives in its page, that would help a lot.

[alextes]

Another idea: our SVGs are a mess. Looking at the network panel a lot of our requests are SVG, if we switch from:

<img href="/svg-icon.svg" />

To:

import svgIcon from "../assets/svgIcon.svg";
import Image from "next/image";
<Image href={svgIcon} />

Next will use clever caching techniques to skip the 304 check and majorly speed up the loading of the site, as about 50 requests can now be skipped.

If anyone wants to work on this, let me know, I'd propose we:

• move all SVG used by a single component into the associated component folder.
• all shared SVGs in a shared folder src/assets is fine for this, perhaps src/assets/svg-icon could be nice
• re-export all SVGs at 100px (this won't matter for the size, but it does matter for how NextJS scales them by default! ping me and I'll take care of it, I'm happy to give access to our Figma file but SVGs are a mess there too)

The speed up from this on first and subsequent loads should be pretty big!

/cc @dawsbot our performance superhero 🦸‍♂️

[alextes]

@dawsbot no worries haha. Anything that isn't risky to merge, doesn't add tons of complexity for little gain, and improves performance is getting merged 🚀 😄 .

With the lazy loading, all I want to confirm is that we actually improve FCP / LCP / TTI before we merge anything that deviates from how Next would handle things by default, which seems pretty good.

I appreciate you'll try to keep it low-effort / low-stress for me to merge 🙏 .

(PRs are in btw)

[dawsbot]

GTmetrix-report-ultrasound.money-20220817T073535-DZIUoUWL.pdf

[alextes]

Thinking about other potential improvements, we use a library to copy the 🦇🔊 to clipboard, and its a very silly 50kb or so. We should try to find a piece of code we expect will work cross-browser / on phones, and use that instead.

[dawsbot]

Thinking about other potential improvements, we use a library to copy the 🦇🔊 to clipboard, and its a very silly 50kb or so. We should try to find a piece of code we expect will work cross-browser / on phones, and use that instead.

Although that feels like an easy win, 50k is not actually a big issue at the moment. There are higher priority payoffs to fix first like the 4MB images ✅ I always try to do data-based improvements with tests like the GMetrix and lighthouse scores included above.

Thanks for being so responsive! 🙏

[alextes]

We settled on a first pass for breaking up our dashboard page into sections. This should result in major performance improvements.

If anyone wants to work on it, just let me know!

[dawsbot]

Excited to see progress on this! Would you like me to implement the MVP for the lazy loading @alextes ?

[alextes]

@dawsbot yea, if you like, can you maybe do a proof-of-concept with whatever piece would benefit the most from lazy loading? But no hurry from my side, feel free to do it post-merge too. It'll actually be tough to find time for this before the merge 😅 .

With a proof-of-concept in a branch we could also take a look and see how it impacts our timings in lighthouse 👌 .

[dawsbot]

Don't get cold feet on me now @alextes ! 😂

I understand, I'll make a minimal example that's stress-free to merge. Something that really improves this loading, so that at merge, folks have a lightning-fast experience ⚡️

[dawsbot]

I'll wait until these get merged because of the diff it'll create: https://github.com/ultrasoundmoney/frontend/pulls

LMK @alextes