[HOLD for payment 2024-10-16] [$250] [Performance] Avoid including mapbox in initial web bundle

[janicduplessis]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

What performance issue do we need to solve?

Reduce the amount of JS needed to load the app by delaying loading of resources that are not needed initially until they are used. One good candidate for this is mapbox, which is only used when creating a distance expense. The map is already not available while offline so this is not a concern.

What is the impact of this on end-users?

This app will load faster initially on web.

List any benchmarks that show the severity of the issue

We can see that mapbox is about 1mb (300kb gzip) of JS by running bundle analyzer (npm run analyze-packages). We can also see that this bundle is loaded initially by using chrome devtools network panel.

Proposed solution (if any)

Delay loading the map code until the component is rendered by using React.lazy. Offline mode is not a concern here since the map doesn't work while offline.

List any benchmarks after implementing the changes to show impacts of the proposed solution (if any)

We can see that mapbox is now in its own bundle by running npm run analyze-packages. We can also verify that this bundle is not loaded initially and only when rendering a screen that displays the map.

Platforms:

Which of our officially supported platforms is this issue occurring on?

• Android: Native
• Android: mWeb Chrome
• iOS: Native
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Version Number: 9.0.25-1
Reproducible in staging?: Yes
Reproducible in production?: Yes
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
Expensify/Expensify Issue URL:
Issue reported by: @janicduplessis
Slack conversation:

View all open jobs on Upwork

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021832118031291081965
• Upwork Job ID: 1832118031291081965
• Last Price Increase: 2024-09-27

Issue Owner

Current Issue Owner: @

Issue Owner

Current Issue Owner: @slafortune

[melvin-bot]

Auto-assigning issues to engineers is no longer supported. If you think this issue should receive engineering attention, please raise it in #whatsnext.

[cristipaval]

@neil-marcellini I know you worked with Mapbox. Do you mind taking over this issue and managing it? There is already a PR for it, I guess we'll want a C+ to review first.

[melvin-bot]

Huh... This is 4 days overdue. Who can take care of this?

[janicduplessis]

Waiting for review!

[neil-marcellini]

@sobitneupane would you please review the PR as C+?

[neil-marcellini]

Hi @janicduplessis. Thanks for working on this. I want to make sure this is a problem worth solving, as is our standard practice. Would you please present some benchmarks of the load time for the app with the mapbox bundle included and separate? Or otherwise determine what percentage of the load time comes from Mapbox with a direct measure? Please detail your testing methodology as well. Was a problem and solution presented anywhere in Slack? Would you please write one in the issue description?

Once I have that info I'll feel confident about going forward with this or not.

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~021832118031291081965

[melvin-bot]

Current assignee @sobitneupane is eligible for the External assigner, not assigning anyone new.

[neil-marcellini]

Waiting for @janicduplessis to respond

[melvin-bot]

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

[janicduplessis]

@neil-marcellini Here's the network profile for production newdot with network throttling "Fast 4G":

We can see that the loading of JS happens in 2 steps, let's only consider the 2nd step which is when mapbox is loaded. The app loads 3 js bundles in parallel for a total of 6.6mb.

From looking at the bundle analyser result we can see that mapbox is included in chunk 62 and weights about 1mb.

I would assume that with limited bandwidth even if the 3 bundles are downloaded in parallel, reducing the size of one will cause the other 2 to download faster. So if we consider those 3 bundles as just one it should be a size reduction of about 15%, which can be about 1s download time reduction.

This might not be exactly accurate, but we can measure better on the PR with an adhoc build.

There was no official problem / solution presented in Slack, this stem out of the discussion in this thread to improve the website initial loading performance.

[neil-marcellini]

Thanks for writing that out @janicduplessis. I think a 1s/15% time savings on a slow connection is worth it, but just barely. Would you please follow this guide and post your problem solution in #expensify-open-source on Slack? Once we get a good amount of thumbs up we can move forward.

[melvin-bot]

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

[janicduplessis]

Working on this today

[janicduplessis]

Measured main and PR and here is the result (there was an issue with gzip compression last time I tested, so re-measured everything)

In chrome with "Fast 4G" connection. The screenshots show the part where we load the bundles in parallel. As I excepted reducing the size of some of the bundles also cause the bigger one to load faster even if its size didn't really change.

Current:

PR:

We go from 1.86s to 1.68s for the slowest bundle to load. We save 180ms, which is about 10%. On slower connection (3G) it seems to lead to slightly bigger savings, 37s -> 32s (14%). If we consider the whole loading sequence it is a pretty small improvement.

Will post a proposal in slack to see if we think this improvement is worth it.

[melvin-bot]

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

[janicduplessis]

Posted the proposal on slack.

[neil-marcellini]

Nice, I'm glad to have Rory's support and from others, so let's go ahead with it. 180ms isn't much for the fast 4g but 5s on 3G is big.

[neil-marcellini]

The PR is on staging. I'm assigning a BZ member to handle C+ payment.

[melvin-bot]

Triggered auto assignment to @slafortune (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[melvin-bot]

The solution for this issue has been 🚀 deployed to production 🚀 in version 9.0.46-5 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• Reduce bundle size by lazy loading map #41242

If no regressions arise, payment will be issued on 2024-10-16. 🎊

For reference, here are some details about the assignees on this issue:

• @janicduplessis does not require payment (Contractor)
• @sobitneupane requires payment through NewDot Manual Requests
• @janicduplessis does not require payment (Contractor)

[melvin-bot]

Payment Summary

Upwork Job

• Contributor: @janicduplessis is from an agency-contributor and not due payment
• Reviewer: @sobitneupane owed $250 via NewDot

BugZero Checklist (@slafortune)

• I have verified the correct assignees and roles are listed above and updated the neccesary manual offers
• I have verified that there are no duplicate or incorrect contracts on Upwork for this job (https://www.upwork.com/ab/applicants/1832118031291081965/hired)
• I have paid out the Upwork contracts or cancelled the ones that are incorrect
• I have verified the payment summary above is correct

[slafortune]

@janicduplessis does not require payment (Contractor)
@sobitneupane requires payment of $250 NewDot Manual Requests

[garrettmknight]

$250 approved for @sobitneupane