Change Details

This task represents the work with investigating how the loading performance of the visual diffs differ can be improved. This work is most immediately relevant to the work we are doing on the Toolbar v2: T229030. And more specifically, whether the visual diffs differ can be made to load quickly and reliably enough to //potentially// be shown to contributors by default, in the course of the edit flow. ===Details=== @Dlynch outlined the following approaches to how we might go about doing this investigation: # Currently this is built client-side on the main thread, which can therefore lock the browser up while it works. We should find ways to make this more performant. # A cheap “fix” that might be worth investigating is seeing whether we can pack the entire thing into a Web Worker (what’s a web worker?), thus getting it off the main thread even if it doesn’t speed it up in any way. # Alternately, we could find ways to split up the building of the diff so we can have the work happen on the main thread but in smaller pieces so any locking is less noticeable. # If we can’t do either of these things, we have to work out what the edge cases are that are making it slow, and fix them.

This task represents the work with investigating how the loading performance of the visual diffs differ can be improved. This work is most immediately relevant to the work we are doing on the Toolbar v2: T229030. And more specifically, whether the visual diffs differ can be made to load quickly and reliably enough to //potentially// be shown to contributors by default, in the course of the edit flow. ===Open questions=== - [ ] Do we know how quickly and reliably the visual diff differ loads in its current state? ===Details=== @Dlynch outlined the following approaches to how we might go about doing this investigation: # Currently this is built client-side on the main thread, which can therefore lock the browser up while it works. We should find ways to make this more performant. # A cheap “fix” that might be worth investigating is seeing whether we can pack the entire thing into a Web Worker (what’s a web worker?), thus getting it off the main thread even if it doesn’t speed it up in any way. # Alternately, we could find ways to split up the building of the diff so we can have the work happen on the main thread but in smaller pieces so any locking is less noticeable. # If we can’t do either of these things, we have to work out what the edge cases are that are making it slow, and fix them.

This task represents the work with investigating how the loading performance of the visual diffs differ can be improved. This work is most immediately relevant to the work we are doing on the Toolbar v2: T229030. And more specifically, whether the visual diffs differ can be made to load quickly and reliably enough to //potentially// be shown to contributors by default, in the course of the edit flow. ===Open questions=== - [ ] Do we know how quickly and reliably the visual diff differ loads in its current state? ===Details=== @Dlynch outlined the following approaches to how we might go about doing this investigation: # Currently this is built client-side on the main thread, which can therefore lock the browser up while it works. We should find ways to make this more performant. # A cheap “fix” that might be worth investigating is seeing whether we can pack the entire thing into a Web Worker (what’s a web worker?), thus getting it off the main thread even if it doesn’t speed it up in any way. # Alternately, we could find ways to split up the building of the diff so we can have the work happen on the main thread but in smaller pieces so any locking is less noticeable. # If we can’t do either of these things, we have to work out what the edge cases are that are making it slow, and fix them.