-
Notifications
You must be signed in to change notification settings - Fork 26
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Reuse JSDOM instances across targets
I've been investigating a performance problem we ran into at Airbnb the last couple of days. We have some components that end up with very very large dependency graphs, which makes the webpack bundle quite large. Looking at the CI output, it seems to take about 2 min to bundle, which isn't the most terrible thing. But, then I've noticed that the timings for the targets are pretty crazy. Look at these logs: ``` [2020-06-17T19:36:15Z] image_analytics was not bootstrapped [2020-06-17T19:36:37Z] - chrome-medium ✓ (22034.4ms) [2020-06-17T19:38:38Z] No examples found for target chrome-mediumPlus, skipping [2020-06-17T19:38:38Z] - chrome-mediumPlus ✓ (4.0ms) [2020-06-17T19:41:05Z] p3_defer_modals was not bootstrapped ``` Here chrome-medium had examples, so it took snapshots and that took a while which makes sense. mediumPlus didn't have examples, so it took no snapshots. Happo says that mediumPlus took 4ms, but if you look at the timestamps in the log lines, you can see that it actually took 2 minutes. I believe that the time spent on empty targets is in initializing the JSDOM and loading up the webpack bundle. Since we have 6 targets, this adds up to 12 minutes of overhead per job just for loading the bundle, and another 12 if we have to check out previous SHA. This is much too long. I think we can improve performance by reusing the JSDOM instance for all of the targets. In the example above, this should save us about 10 minutes on a run where the previous SHA report exists, and 20 minutes on a run where the previous SHA report does not exist. One potential issue that could arise from this is if there is any side-effecty code in the bundle that looks at the viewport size when it is first executed, that will no longer work quite right since we run the bundle and then resize the window later. In order to preserve backwards compatibility with other DomProvider plugins, like the puppeteer plugin, I left in the width/height in the initialization call, and included a guard around the resize call in case it does not exist yet. We should clean these up in the next breaking change.
- Loading branch information
Showing
4 changed files
with
53 additions
and
16 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters