Slow performance on large code blocks #2063

New Issue

OVERLORD · 2026-02-05T02:46:44+03:00

OVERLORD commented

2026-02-05 02:46:44 +03:00

Originally created by @modem7 on GitHub (Jan 30, 2021).

Describe the bug
On large code blocks (1000+ line), editing performance is quite slow, and takes a while to edit it.

Can take around a minute to be able to start editing.

CPU spikes to 18% when opening (not surprising) for about 1-2 seconds, and no RAM usage change (currently only using around 120MB).

Steps To Reproduce
Steps to reproduce the behavior:

Create code block
Paste large amounts of data
Save
Re-open page, and edit code block

Expected behavior
Potentially faster/better optimised code block editing (if possible?)

Screenshots
https://omegawiki.modem7.com/books/docker/page/current-docker-compose

Your Configuration (please complete the following information):

Exact BookStack Version (Found in settings): v0.31.4
PHP Version: Whatever is in the LinuxIO image
Hosting Method (Nginx/Apache/Docker): Docker
Browser: Vivaldi (Chrome based)

Additional context
This may be an unusual edge case, so absolutely understandable if it's not high up on the priority list to investigate.

Originally created by @modem7 on GitHub (Jan 30, 2021). **Describe the bug** On large code blocks (1000+ line), editing performance is quite slow, and takes a while to edit it. Can take around a minute to be able to start editing. CPU spikes to 18% when opening (not surprising) for about 1-2 seconds, and no RAM usage change (currently only using around 120MB). **Steps To Reproduce** Steps to reproduce the behavior: 1. Create code block 2. Paste large amounts of data 3. Save 4. Re-open page, and edit code block **Expected behavior** Potentially faster/better optimised code block editing (if possible?) **Screenshots** https://omegawiki.modem7.com/books/docker/page/current-docker-compose **Your Configuration (please complete the following information):** - Exact BookStack Version (Found in settings): v0.31.4 - PHP Version: Whatever is in the LinuxIO image - Hosting Method (Nginx/Apache/Docker): Docker - Browser: Vivaldi (Chrome based) **Additional context** This may be an unusual edge case, so absolutely understandable if it's not high up on the priority list to investigate.

OVERLORD added the 🛠️ Enhancement 📝 WYSIWYG Editor 💻 Front-End labels 2026-02-05 02:46:44 +03:00

OVERLORD closed this issue

2026-02-05 02:46:46 +03:00

OVERLORD commented

2026-02-05 02:46:51 +03:00

@ssddanbrown commented on GitHub (Jan 30, 2021):

Hi @modem7,

Could you confirm what editor you're using? The Default WYSIWYG editor or the markdown editor?

Additionally, Could you confirm the exact editing step that you find troubling slow? Opening the code block for edit? Making the change? Saving the change?

@ssddanbrown commented on GitHub (Jan 30, 2021): Hi @modem7, Could you confirm what editor you're using? The Default WYSIWYG editor or the markdown editor? Additionally, Could you confirm the exact editing step that you find troubling slow? Opening the code block for edit? Making the change? Saving the change?

OVERLORD commented

2026-02-05 02:46:58 +03:00

@modem7 commented on GitHub (Jan 30, 2021):

Heya,

WYSISYG editor in this case.

And to better explain I made a screenshare video:

https://user-images.githubusercontent.com/4349962/106382603-8d425900-63b8-11eb-8d57-89d0d09581d0.mp4

Edited to embed video rather than dropbox.

This is another page with a smaller code block to give a performance difference:

https://user-images.githubusercontent.com/4349962/106382667-06da4700-63b9-11eb-99d7-e8f9cbf6a9cd.mp4

Custom HTML header:

<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/codemirror/5.29.0/theme/rubyblue.min.css"/>
<script>window.codeTheme='rubyblue';</script>

Removing the custom HTML header does not change the loading times.

@modem7 commented on GitHub (Jan 30, 2021): Heya, WYSISYG editor in this case. And to better explain I made a screenshare video: https://user-images.githubusercontent.com/4349962/106382603-8d425900-63b8-11eb-8d57-89d0d09581d0.mp4 Edited to embed video rather than dropbox. This is another page with a smaller code block to give a performance difference: https://user-images.githubusercontent.com/4349962/106382667-06da4700-63b9-11eb-99d7-e8f9cbf6a9cd.mp4 Custom HTML header: ``` <link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/codemirror/5.29.0/theme/rubyblue.min.css"/> <script>window.codeTheme='rubyblue';</script> ``` Removing the custom HTML header does not change the loading times.

OVERLORD commented

2026-02-05 02:47:00 +03:00

@ssddanbrown commented on GitHub (Jan 31, 2021):

Thanks for confirming @modem7. Looks like the code editor popup window performs okay, but the main editor is super slow.

Initial Findings

Chrome performance chart, Page editor load, 4x CPU slowdown:

Green parts are CodeMirror which represents most of the code execution time, Can see two major events which consume a lot fo time.

Sequence of events appears as follows:

TinyMCE loaded.
TinyMCE content set.
- During TinyMCE initial set content, CodeMirror loaded for each code section.
  - CodeMirror renders out code sections, Potential duplicate work three very similar long-running patchDisplay calls.
  - CodeMirror updateHeightsInViewport call runs causing massive style/layout shift. Very Heavy
TinyMCE adds page styles, Causes massive style/layout calculation
TinyMCE finishes up (Note, Mulitple editor change events fired in this process causing slowdown in calls to getContent for saving.)
cm.refresh() call from BookStack WYSIWYG code function runs after timeout, causing re-run of all rendering and layout calculations. Very Heavy Again

Current page load timings of that test of about 10-11 seconds.

There's duplication in CodeMirror block rendering here. Both before and after editor styles loaded. Should probably render codemirror on set content, as we're doing, but defer visibility and display of CodeMirror content until after styles loaded. Potentially test with CodeMirror in its own forced rendering layer, if not already, to see if that offers a performance boost.

@ssddanbrown commented on GitHub (Jan 31, 2021): Thanks for confirming @modem7. Looks like the code editor popup window performs okay, but the main editor is super slow. --- ### Initial Findings Chrome performance chart, Page editor load, 4x CPU slowdown: ![image](https://user-images.githubusercontent.com/8343178/106383415-b87b7700-63bd-11eb-917a-477e38ab9743.png) Green parts are CodeMirror which represents most of the code execution time, Can see two major events which consume a lot fo time. Sequence of events appears as follows: - TinyMCE loaded. - TinyMCE content set. - During TinyMCE initial set content, CodeMirror loaded for each code section. - CodeMirror renders out code sections, **_Potential duplicate work three very similar long-running patchDisplay calls_**. - CodeMirror `updateHeightsInViewport` call runs causing massive style/layout shift. **_Very Heavy_** - TinyMCE adds page styles, **_Causes massive style/layout calculation_** - TinyMCE finishes up _(Note, Mulitple editor change events fired in this process causing slowdown in calls to getContent for saving.)_ - `cm.refresh()` call from BookStack WYSIWYG code function runs after timeout, causing re-run of all rendering and layout calculations. **_Very Heavy Again_** Current page load timings of that test of about 10-11 seconds. There's duplication in CodeMirror block rendering here. Both before and after editor styles loaded. Should probably render codemirror on set content, as we're doing, but defer visibility and display of CodeMirror content until after styles loaded. Potentially test with CodeMirror in its own forced rendering layer, if not already, to see if that offers a performance boost.

OVERLORD commented

2026-02-05 02:47:05 +03:00

@ssddanbrown commented on GitHub (Jan 31, 2021):

Chart after improvements

Chrome performance chart, Page editor load, 4x CPU slowdown:

@ssddanbrown commented on GitHub (Jan 31, 2021): ### Chart after improvements Chrome performance chart, Page editor load, 4x CPU slowdown: ![image](https://user-images.githubusercontent.com/8343178/106390655-56346d80-63e1-11eb-8ab2-483cbf336d79.png)

OVERLORD commented

2026-02-05 02:47:07 +03:00

@ssddanbrown commented on GitHub (Jan 31, 2021):

Hi @modem7,

I've now had a dive into this and explored the situation, There's a couple of things at play:

Inefficient loading of code blocks into the editor causing duplicate browser work in processing styles and layout.
Code block performance is poor with long-content blocks due to needing to re-calculate height to show all content on the page.

For 1, I have patched the code in bc1e84325c, as detailed above, to reduce the inefficient duplicated work. This reduced loading down to 60% of the original time from my testing, which may vary depending on device and content.

For 2, there's not much I can do within the code based without altering how people's page content displays although you can apply a workaround on your own instance if desired. Limiting the height of code blocks brings massive performance benefits in these situations. You can do this by adding the following to your "Custom HTML Head Content" setting:

<style>
.CodeMirror, .CodeMirror-scroll {
  max-height: 900px;
}
</style>

That should improve both page viewing and editing performance dramatically.

The fixes for 1. above will be part of the next feature release. Since I've addressed the main BookStack inefficiency ready for next release, and provided a workaround for the remainder of the performance issues, I'll close this off but feel free to comment here still if required.

@ssddanbrown commented on GitHub (Jan 31, 2021): Hi @modem7, I've now had a dive into this and explored the situation, There's a couple of things at play: 1. Inefficient loading of code blocks into the editor causing duplicate browser work in processing styles and layout. 2. Code block performance is poor with long-content blocks due to needing to re-calculate height to show all content on the page. For 1, I have patched the code in bc1e84325c7edfb52b07c7e6bde881b09280c3ba, as detailed above, to reduce the inefficient duplicated work. This reduced loading down to 60% of the original time from my testing, which may vary depending on device and content. For 2, there's not much I can do within the code based without altering how people's page content displays although you can apply a workaround on your own instance if desired. Limiting the height of code blocks brings massive performance benefits in these situations. You can do this by adding the following to your "Custom HTML Head Content" setting: ```html <style> .CodeMirror, .CodeMirror-scroll { max-height: 900px; } </style> ``` That should improve both page viewing and editing performance dramatically. The fixes for 1. above will be part of the next feature release. Since I've addressed the main BookStack inefficiency ready for next release, and provided a workaround for the remainder of the performance issues, I'll close this off but feel free to comment here still if required.

OVERLORD commented

2026-02-05 02:47:14 +03:00

@modem7 commented on GitHub (Jan 31, 2021):

Thank you very much! I'll apply the workaround and wait for the rollout!

Appreciate the quick turnaround on this, thanks again!

@modem7 commented on GitHub (Jan 31, 2021): Thank you very much! I'll apply the workaround and wait for the rollout! Appreciate the quick turnaround on this, thanks again!

OVERLORD referenced this issue

2026-02-05 03:31:56 +03:00

Separate English into UK/US #2273

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/BookStack#2063