WP version: 4.8.1 (latest)
Types version: 2.2.16 (latest)
Browser: Chrome 60.0.3112.113 on macOS Sierra
I've created a custom post type with many custom fields (of varying types --WYSIWYG, select, colorpicker, single line, etc.). When I add a new post or edit an existing one, the page is just soo slow when I scroll. I noticed that on every scroll there are multiple messages like:
[Violation] 'setTimeout' handler took 55ms
[Violation] Forced reflow while executing JavaScript took 53ms
wp-tinymce.php?c=1&ver=4603-20170530:3 [Violation] 'setTimeout' handler took 60ms
[Violation] Forced reflow while executing JavaScript took 58ms
wp-tinymce.php?c=1&ver=4603-20170530:3 [Violation] 'setTimeout' handler took 57ms
[Violation] Forced reflow while executing JavaScript took 56ms
wp-tinymce.php?c=1&ver=4603-20170530:3 [Violation] 'setTimeout' handler took 56ms
(screenshot also attached)
I'm using the latest WP version and Types plugin version. I've also tried on another localhost website (with the same latest versions of WP and Types) which uses a different theme, and I get the same messages and slowness on it too. Custom post types where fields are less show less number of messages since scrolling is not required. But when there are many fields, scrolling is terrible and those messages are generated on every scroll along with minor freezes and a very rough experience.
What's causing this and how do I fix it?
Thanks.
It looks like a you have several WYSIWYG editors shown on your editor page at the same time. WYSIWYG editors are fairly complex, and each additional editor on the page is going to add more and more complex scripting requirements that need to be considered. Eventually a browser will get overloaded and can't render fast enough to keep up with scrolling. It's called jank, and it's why things feel slow.
One way I recommend to approach this problem is to use multiple field groups, so that these WYSIWYG editors are separated into different field panels. Then you can toggle unused panels closed, and only open up a single necessary panel at any time. This will help a lot with scrolling problems related to these WYSIWYG editors. To give you more specific advice, I would need to see your admin area to make more targeted recommendations, but please be aware that there are some limitations that can't be avoided when many complex editors are placed on the same page.
Hi there,
We have exactly the same issue and I was about to open a separate thread.
I've discovered that if the Yoast plugin is deactivated, the problem goes away and the edit page becomes usable again.
Do you use Yoast and are you able to test this to confirm if the problem is indeed a conflict between the two plugins?
(As some background info, we use Types alongside WPML and have 10-15 custom field groups, each of which has a WYSIWYG editor, alongside some other controls. Using Text editing mode is fine, but switching to the Visual editor everything grinds to a halt. The problem has only become apparent since upgrading to WordPress 4.8).
James
@christian-c
Yes, I have 8 WYSIWYG editors. That makes sense as the default post types (posts/pages) are also throwing those messages albeit very few. Has it always been this way or is this specific to the latest/recent versions of WordPress/TinyMCE? I wonder if WP/TinyMCE devs are planning on fixing it. Can't find much on the web about it.
I would also imagine that anyone who's using Types/Views extensively must've faced this issue since its logical to use multiple WYSIWYG fields in custom post types.
I'll have a look at the alternatives you have suggested. Thanks.
@jamesa-2-2
Interesting that deactivating Yoast solves the issue for you. Do you get the same console messages in Chrome as I'm getting?
Yes, I use Yoast but it is deactivated on my localhost dev site. I even deleted it but it now to check but it had no effect; the problem still persists. It could be that you had another WYSIWYG editor because of Yoast and when that went away the page became faster for you?
@sgr2 - yes I'm seeing the same console messages in Chrome as you. I see the same messages when Yoast is deactivated, but less of them (and the edit page is at least usable). Activating Yoast seems to push it over the edge.
I've replicated this with all other plugins disabled, and with a reduced number of custom field groups activated. With 2 or 3 custom WYSIWYG fields, the edit experience is clunky. Anything beyond 6 or 7 and it becomes unusable (in Chrome, and on my MacBook Pro (Retina, 15-inch, Late 2013, 8GB RAM) at least). Unfortunately these multiple WYSIWYG fields are integral to our site layout.
I'm using Chrome 61.0.3163.79 on MacOS Sierra but the issue is the same in Chrome Canary (63.0.3213.0). Safari doesn't seem to show the same problem and the edit page is usable.
@christian-c - let me know if you need any more info. I can provide a development login if you would like to see the problem first hand, or would be happy to arrange a screencast or similar.
The problem will continue to grow as more and more complex features are added to the WYSIWYG. For example now the Bootstrap menu is included. If you toggle the Bootstrap menu closed on all WYSIWYG panels, performance will improve significantly.
Yoast is quite heavy as well, so including the Yoast panel in a wp-admin editor page along with multiple WYSIWYG editors is going to compound any slowness you already experience. For that reason, I recommend toggling that panel closed unless you are actively editing in it.
So to recap, my recommendations are:
- Place WYSIWYG fields in separate field groups, so that each field group can be toggled on or off as needed to show only a single WYSIWYG editor on the page at a time.
- Toggle extra feature menus off unless they are needed, like the Bootstrap button.
- Toggle the Yoast panel closed unless it is being used.
It's possible this is an issue that needs to be resolved by Chrome, or by tinymce, or by us, so it will take a bit of investigation. I will reach out to my developers and make sure they are aware that multiple WYSIWYG editors are causing significant usability issues in Chrome, and update you here with any information I receive.
Thanks @christian-c
If I can do anything to help with the investigation, just let me know. Happy to provide access to one of development sites if it would be useful.
@christian-c
Thanks. Hope the investigation goes well.
I’m a little surprised I can’t find more about this issue on the web. I thought there’d be many posts on WP/Chrome/TinyMCE issue boards.
@jamesa-2-2
Yes, Safari is fluid in comparison to Chrome. Firefox’s performance is between the two; almost usable . (I’m on a MacBook Pro 13-inch, mid-2014, 8 GB RAM)
I just tried it on Chrome on Windows 10 and even though the console messages were there, the experience was far better than on Chrome on macOS. Have you tried it on Windows?
After a bit of discussion, it appears that this issue is most likely a compatibility problem with specific browsers on the Mac platform that we won't be able to address. Our recommendation for now is to use one or more of the workarounds mentioned above, or to use Safari instead of the other browsers mentioned.
