Gutenberg is larger, slower and more resource intensive than the old editor

[steveangstrom]

Issue Overview

Gutenberg is slower and weightier on resource demands than the old editor, this seems odd.

Steps to Reproduce (for bugs)

on localhost, disable all plugins other than Gutenberg, create a new post in the standard editor, save the post. Check the requests, speed and data transfer in your favourite tool.
Now edit the same post in Gutenberg Check the requests, speed and data transfer.
I tested in Chrome 60.0.3112.113 and Firefox 55.02

Expected Behavior

The new editor should be faster and lighter than the old solution

Current Behavior

it's slower and heavier, a representative result from localhost.

Reloading the old editor: 28 requests, 917KB, 1.8 seconds
Reloading Gutenberg: 58 requests, 3.0MB, 2.55 seconds,

[youknowriad]

Gutenberg is slower and weightier on resource demands than the old editor, this seems odd

this doesn't seem odd to me, it's in contrary logical.

• Gutenberg embeds the old editor and moves several other stuff to the client, which causes the bundle size to be weightier

• Gutenberg is API based, which means, more API requests, we're working on prefetching some, this should improve over time

• Gutenberg is slower, probably due to the size.

---

I don't think it's fair to compare to the old editor because Gutenberg brings way more features to the client (the old editor is basically the classic block). That said, this is a good starting point to start optimizing and improving the bundle size and performance. We've been mainly focusing on adding features until now, there'll be a time for optimization. Thanks for the report.

[steveangstrom]

My apologies for the imprecise term. I meant odd in the sense that it's not a desirable trait or goal we'd design toward, yet increased resource use exists and seems currently unaddressed.

If we were to hypothetically spec a new editor we might define key goals as: " it ought to be powerful, flexible, simple to use, responsive and light on resources" , and in spec'ing an updated editor we'd likely aim for more powerful, faster, stronger lighter, etc.

Light resource use brings a snappy response and many other benefits. The old editor seemed resource heavy, but the new one is even heavier. That seem to imply speed and lightness wasn't set as an aim, or isn't being tracked for risk.
The reason risk management exists is the natural pull of creatives toward the sexy end of dev, the interactive UI, the new library's method we can now call, etc. So we set measurements to see how we are doing to meet goals.

I worry that the ability to build and integrate a myriad sexy assets has burdened the project down, it's heavy. Heavier than its predecessor. If this was my project thats a primary goal being missed (I'd have aimed for lower than the previous version). More worrying is that this is unaddressed as that potentially indicates a risk management problem.

I'm concerned that this racing boat is festooned with so much bunting that it sits too low in the water to win a race, and nobody appears to care.

[BE-Webdesign]

@steveangstrom

It is good that you are bringing the topic of performance to light. Although Gutenberg does have a heavier asset bundle currently than the previous editor, it is important to understand that this currently builds on top of the classic editor. One thing that could help a lot is deduping our CSS in the webpack build process, #1422. That could be a good place to start to help out.

Performance is also a nuanced topic. In my opinion, even though the build is heavier currently, Gutenberg outperforms the classic experience as it takes a different approach to the typical server request response cycle, by running as more of a client side app. This gives Gutenberg a perceived performance enhancement over the classic editor and cuts down on any repaint/reload times significantly.

[ellatrix]

See also #2768 to async load resources by block. This could prove useful in general if we can use a "light" TinyMCE version for basic blocks with an editable region, and async load full TinyMCE for the classic text block.

[mtias]

There has been several rounds of performance improvements, and there's still a few things to do (dequeuing scripts we don't need, async loading, etc). Closing this in favor of granular issues.