Performance issues in the backend (wp-admin)

• startupguys

• January 7, 2014 at 3:25 am

Whilst developing a new theme we’re experiencing really bad page responsiveness in wp-admin when using our ACF setup for pages, it makes Google Chrome, Safari and Firefox latest versions really lag on our computers, which are normally pretty speedy iMacs.

Is anyone aware of performance issues when using the repeater, flexible content and gravity forms ACF addons on the same page in the backend? We’re using some conditional logic and argue-ably I’ve got quite a few fields on the repeater and FC but the JavaScript lag is killing my browser 🙁 I can provide login details via Private Message if the developer(s) would like to check it out for themselves?

Any tips would be much appreciated, as it’s too low for us/clients to use on a production website currently.

• Elliot

• January 7, 2014 at 1:34 pm

Hi @startupguys

Just to confirm, this is JS lag, not PHP load time?

Have you checked your console log for any errors reported?
The latest version of ACF feature some minimal and efficient JS, so perhaps there is something else going on here. Does the issue completely go away when ACF is deactivated?

Can you deactivate all other plugins and leave ACF, does this help the issue?

Thanks
E

• Will

• January 7, 2014 at 1:46 pm

I’ve run into issues before with having too many post revisions stored in the database. Cleaning them out helped. You can run this query to see where you’re at.

SELECT COUNT(*) FROM wp_posts WHERE post_type = "revision"

if you have wp cli installed it’s as easy as

/path/to/wordpress/ $ wp db query 'SELECT COUNT(*) FROM wp_posts WHERE post_type = "revision"'

If that number seems high (I can’t really say what high is, depends on how many posts you have) you could make a backup of your db (!), delete all the revisions and see if that speeds things up.

/path/to/wordpress/ $ wb db export /path/to/your/backup/home/mysite.snapshot.sql

/path/to/wordpress/ $ wp db query 'DELETE FROM wp_posts WHERE post_type = "revision"'

There are plugins to make deleting a little more nuanced. Say, delete all but the last 2 revisions or whatever.

If that turns out to be the problem, you can permanently cap the revisions count in your wp-config with this line:

define( 'WP_POST_REVISIONS', 3 );

More info here: http://codex.wordpress.org/Editing_wp-config.php#Specify_the_Number_of_Post_Revisions

• startupguys

• January 7, 2014 at 9:11 pm

Hi @elliot and @willthemoor,

Thanks for the help so far, I had 14 post revisions with 2 posts on the dev site. I backed up the database, deleted those 14 revisions but alas still the same performance issue I’m afraid.

I’m running the latest stable version of ACF 4.3.4 and the plugins for it.

No console JS errors showing, PHP is pretty rapid on the second only a second or 2 max, I think having multiple tinymce’s on the page might be killing it JS wise, only with condition logic – as it visually takes a few seconds to hide the condition logic hidden fields.

I’m trying to use ACF to be a page / content builder, so using flexible content and repeater it adds rows, and columns, then the content type I require e.g. form, textarea, wyswig. It works really well on the frontend, and backend apart from the lag.

Any further ideas to debug, I can provide login access if you wish to check it out yourselves (it’s not a live site, just a theme dev). Let me know how I can send these privately if so.

Many thanks for your help with this.

• startupguys

• January 7, 2014 at 9:15 pm

Also @elliot, just to add I’ve tried disabling all plugins (apart from Gravity Forms, otherwise it doesn’t load due to ACF GF add-on). And issue remains the same, so I’ve isolated it to ACF for you.

• Elliot

• January 8, 2014 at 9:00 am

Hi @startupguys

Yes please. You can provide some login details in a comment, and mark it as private.

Cheers
E

• startupguys

• January 8, 2014 at 10:02 pm

This reply has been marked as private.

• Elliot

• January 9, 2014 at 10:01 am

Hi @startupguys

Thanks for the login details.
I am quite sure that the performance issues are coming from your server, not from ACF.

When I edited the fiedl group (which only contains 5 fields), the page took quite some time to load and appears to load in broken sections.

The reason why the ‘sample page’ is so laggy, is because the page also loads slowly in broken sections, and then only once it has fully loaded, can the JS run.

The lag is not from JS, but from PHP.
I would consider upgrading your server, or developing on a local host for now.

Thanks
E

• startupguys

• January 13, 2014 at 11:06 pm

Hi @elliot,

Thanks for looking into this for us, we’ve upgraded our server this weekend, and the server load is consistently low now with lots of capacity and performance to hand. It’s a dedicated server (with no other accounts on), running quad core with 4GB RAM, so it should be pretty quick :S

I’ve rechecked the plugin in the backend, and it’s still grinding when editing that sample page. Although all the other pages are still quick and working fine, the browser actually crashes Chrome for 5 seconds or so, whilst the ACF fields are loaded in with my end – which points to the JS my end.

I would be grateful if you could recheck the loading times to confirm it’s still PHP, and pin point me the correct way to check the performance so I can remove this bottleneck and utilise your plugin in a speedy manner going forwards.

Love the plugin, it’s really awesome stuff – just can’t deal with this lag as I’m sure you can understand 🙂

Thanks @elliot

Kind Regards,
Matt

• Elliot

• January 14, 2014 at 9:06 am

Hi @startupguys

Thanks for the follow up. Yes, your PHP load speeds have much improved and the page is apearing as it should, all at once.

But you are quite right in regards to the lag, it is still there.
I wonder if the lag is caused by lots of conditional logic rules being run each time you change an input.

Are there lots of conditional logic rules applied to these layouts?

I have mad a recent update on github which includes some improvements to the conditional logic JS. This may help to speed up the page by running less JS when you change an input.

Perhaps you can download the latest code from github and replace the input.js and input.min.js files into your current ACF?

Thanks
E

• startupguys

• January 17, 2014 at 3:57 am

Hi @elliot,

I’ve just added your updated input.js and input.min.js files to the plugin and refreshed my cache, I believe there’s a minor improvement but still very laggy in the JS rendering on the page – still not good enough for us to use in production.

The worst is in the page initial render, the browser freezes and can’t scroll or click for the first 5 seconds or so on my iMac running latest stable Chrome.

We do have quite a bit of conditional logic, as well as using nearly all of your ACF plugins at the same time, so it’s probably JS overload for poor Chrome 😉

It’s a bit quicker when selecting new content types for flexible content, but if the new flexible content has a few options (e.g. 8 – plus conditional logic), it grinds quite a bit. Take a look at the CTA box, by adding content onto the Sample Page. Notice the lag when changing Hover Options from None to Image or Color. This is the same for Accent Border dropdown we’ve got.

Do you have any ideas on how we could improve it’s performance? Your efforts are really appreciated on this – thanks again 🙂

Kind Regards,
Matt

• Elliot

• January 19, 2014 at 6:30 pm

Hi @startupguys

I would export your field group to XML so you have a backup, then trash it in WP.
Edit the page and see if the JS lag has dissapeared.

If so, then yes, the issue comes from ACF.

Now, untrash your field group and edit it. Lets remove all conditional logic from it and again, check the edit post JS lag. Is there any improvement?

Add back in the conditional logic starting with any sub fields. These will most likely cause more JS processing.

Let me know what you find.

Thanks
E

• startupguys

• January 20, 2014 at 10:12 pm

Hi @elliot,

Many thanks for your response, I’ve put the custom fields group into the trash, and the page now loads instantly, the browser no longer freezes etc.

So we can narrow it down to the ACF plugin(s), so now I’ve removed the conditional logic from the fields and everything loads instantly! 🙂

Looks like the performance issue lies within having multiple conditional logic within a repeater and flexible content fields, it kills it browser and creates a large processing overhead on the client side.

So I’ve set this up – so you can review the performance difference in the pages. Under Pages – Sample Page contains no conditional logic, and Josh Boxed Layout this contains 4 conditional logic queries (3 of which within the FC repeater).

Kind Regards,
Matt

• Elliot

• January 21, 2014 at 5:40 pm

Hi @startupguys

Thanks mate. Will do.

Cheers
E

• Phil Kurth

• January 25, 2014 at 8:20 am

Just thought I would add to this as I have experienced the same issue.

I use the flexi field for a similar functionality and have a lot of sub fields with conditional logic. The lag became quite high after a few fields had been added to the page and I found that the main culprit was a post link field inside repeater rows. I disabled that and the conditional logic and everything was smooth again. This was developing locally as well.