Thank you to @aristath @youknowriad and @priethor who helped with this post.
In case you missed the first post on post/page performance, I’d recommend checking it out first before digging into this post, as it helps give greater context into the breadth of work around performance improvements. This post builds on the discussion by talking specifically about the approach Core Contributors Core contributors are those who have worked on a release of WordPress, by creating the functions or finding and patching bugs. These contributions are done through Trac. https://core.trac.wordpress.org. take to managing the performance of the Core Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Editor itself!
Think of Core Editor Performance as impacting the user experience when creating content. It’s the difference between a jarring experience, with the editor barely keeping up as you type, and a creative one — where adding dynamic content is a breeze with performance hardly being noticeable.
With each release of Gutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/, a performance benchmark is run against the last few releases that compares different response times for a large post (~36,000 words, ~1,000 blocks). You can find this benchmark at the bottom of each “What’s New in Gutenberg” post. While this approach doesn’t cover every scenario, and absolute numbers are not intrinsically meaningful, it has helped identify variations in performance for different releases. Generally speaking, while the loading time of the editor is important, pay special attention to typing speed (also known as KeyPress Event speed). This is a far more important measure when it comes to user experience as this is what allows for the smooth experience when working in the editor.
Beyond an overview of neat numbers, what does focusing on Core Editor Performance entail? Pulling from the documentation, the following overall metrics are tracked:
- Loading Time: The time it takes to load an editor page.
- Typing Time: The time it takes for the browser to respond while typing on the editor.
- Block Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. Selection Time: The time it takes for the browser to respond after a user selects a block. (Inserting a block is also equivalent to selecting a block. Monitoring the selection is sufficient to cover both metrics).
Specifically, this work includes everything from improving how performance benchmarks are measured for PRs to smoothing out the experience of using the Block Inserter to continually tweaking block interactions to improving consistency in performance benchmarks. At the end of the day, Core developers take a comprehensive approach when working to meet or exceed these performance benchmarks while improving the user experience for all WordPress users. You can read more about the journey towards a performant web editor in this very informative post from WordPress Contributor, @youknowriad.
The work on performance is never done though (just check this PR out) so, if you’re interested in helping in this area, make sure to join #core-editor, check out the current focuses, and attend the Core Editor weekly meeting Wednesday @ 14:00 UTC.
#core-editor, #core-editor-improvement, #gutenberg, #performance
