The final edit-story.js bundle is getting bigger and bigger. It is almost 0.5MB already, which is quite high.
We need to analyze the current bundle (e.g. using webpack-bundle-analyzer) to better understand the root cause.
Then, we need to come up with a robust solution. This will involve tweaking some configs, removing some polyfills, splitting up the bundle into multiple chunks, serving less code to modern browsers, etc.
Same goes for the dashboard app.
_Do not alter or remove anything below. The following sections will be managed by moderators only._
Code splitting is fairly easy to do and we could rather smoothly find some components, that could be removed from initial load, as these will never be displayed on from the start:
It's very common to do code-splitting and natively supported by both webpack and react.
Some interesting findings here. 馃暤


Those two large SVGs are actually encoded PNGs 馃
Those two large SVGs are actually encoded PNGs 馃
We could probably get @samitron7 to convert these to proper vectors.
It's these icons here in the figma, which are made with images rather than vector shapes:

Specifically, it's the three small stars in the corner of both elements, that should be vector shapes rather than a 40kb image.
Related: #1348
@barklund any thoughts on how we could best ship slim bundles to modern browsers and polyfilled bundles for older ones?
@barklund any thoughts on how we could best ship slim bundles to modern browsers and polyfilled bundles for older ones?
On AMP side we use module-no-module approach. But figuring out which module browsers support which polyfills is also non-trivial.
@barklund you guys have the svg for those 2 icons already correct?
@samitron7 yes, that has been addressed
@swissspidy @pbakaus would you characterize this as a 1.0 Stable blocker? Considering whether this scope can move out to post the initial release.
Not really a blocker I think. Existing code can be fixed post-release, and new features can leverage this from the get-go.
+1, let's not block on this.
Most helpful comment
Code splitting is fairly easy to do and we could rather smoothly find some components, that could be removed from initial load, as these will never be displayed on from the start:
It's very common to do code-splitting and natively supported by both webpack and react.