Support

Account

Home Forums Backend Issues (wp-admin) Slow backend v.2.5.7

Solved

Slow backend v.2.5.7

  • Hey ACF,

    My backend loading is extremly slow when i enter a page where i have made alot of flexible contents + repeaters.

    It takes like 30-60s to load. I have checked both host + other plugins and the issue comes from ACF Pro that the javascript is loading slow.

    God a solution for this or is there coming a update on this soon?

    – Ivan

  • Hi @ivan

    Unfortunately you’re experiencing this because you have so many flexible/repeater fields which probably also contain a lot of fields. This is more of a server-issue or possibly architectural issue.

    Are you using the ACF-JSON feature? That should help speed things up since you wont need to do so many DB calls.

    Other than that you’ll either have to up the specs on your server or rethink the way you’re using flexible/repeater fields. I see many people use a repeater with a google map field for example and complain when it’s loading slow and they have 30-40+ maps rendering on one page (madness). I always tell them to stop using repeaters and use a CPT instead. Problem solved. πŸ™‚

  • Hey Jonathan,

    No to ACF-JSON, how do I use this? CPT? Custom post type?

    – Ivan

  • Hi,

    It’s very simple. Just create a acf-json folder in your active theme and resave all your fieldgroups. more here: http://www.advancedcustomfields.com/resources/local-json/

    CPT is custom post type yes. Sometimes people tend to not think their content structure through before adding way to much content to a single page/post. I often consider a CPT whenever I know there’s going to be a lot of content and it can be defined like “person” or “car” etc.

  • unfortunately it didnt help πŸ™
    So there isnt coming any update that may help the loadtime?
    The advanced of using ACF instead of CPT is that its more dynamic on every page/post.

    – Ivan

  • HI @ivan

    No there’s no update since there’s really not much to do. You’re simply trying to cram in too much content on a single edit screen.

    My suggestion is that you look into better hosting. Better specs on the server will give you shorter load times.

  • Okay, what do you recommend of hosting in Denmark for this?

  • I don’t know any hosting companies in Denmark apart from one.com (I’m Swedish).

    However I’m sure you can find good threads about that here and there on forums πŸ™‚
    Also, it’s more about what kind of “package” you get on your web host than which web host you choose. Look into what options you have for upgrading your current account first. Maybe they have a good deal for you! You should be able to talk to your web host provider about this and they could recommend a package.

    Good luck!

  • Hi there,

    I am having a very similar issue. But mine happens on relationship fields. I never had any issues until we upgraded to 5.0 pro.

    We have a very powerful dedicated server. I think it’s something to do with the Javascript or AJAX. It’s unusable for me now and I can’t even work on it from my phone because it crashes the browser tab.

    I do also have a couple repeater fields.

    Finally, and likely part of the issue is that we have about 38k posts in the database and about 10 million entries in the post meta table.

    Maybe an option to disable the AJAX would fix it. Not sure.

    Not sure what to do but it’s somewhat urgent so if you’re able to do anything to help that would be amazing!

    Thank you for the exellent software!

    Ryan

  • Hmm If you find a solution let me know! I tried JSON and server so on. Nothing helps here.

  • Hi @rivage

    What kind of fields do you have in your repeaters? The post_object field etc. all use AJAX for this exact reason. To not try to load in all the posts in one go as a setup with your magnitude would be rendered useless! πŸ™‚

  • Indeed. Well like I said, it seems to be caused by the relationship fields. But oh well. Back home now and works fine in my desktop browser, even if it is a little slow. Thanks.

  • Okay. Well the AJAX in itself doesnt try to fetch that many posts.. perhaps it’s more of an DB query issue. That the querying of posts in general take some performance and time..

    Do you have any active settings for the relationship field like filtering specific posttype/category etc?

  • Yep, it filters by a post type which contains from 35-40k posts. The “Filter by Post Type” field has a single entry. The Filters field has Search checked. Return Format is Post ID. The rest should be defaults.

    I know the number of posts is the reason as I’ve run into countless other performance issues I’ve managed to work around or resolve. It didn’t have this issue before the AJAX was implemented therefore maybe an option to not use the AJAX or somehow automatically disabling AJAX if there are more than a certain number of posts for that particular post type could prevent the slowness and crashing.

    I’m personally fine with it the way it is now that I’m home and can work from my desktop but I imagine people with less powerful servers and clients would have much more of an issue with even many less posts than I have.

    Extra testing results: On my desktop in Opera the page takes about 8-10 seconds to load. On a Galaxy Note 4 in the Android Internet app it crashed. In Android Chrome it loaded eventually but very slowly. Additionally, hovering over the field when editing the field group is a bit slow as well as opening the field to edit it.

  • Thank you for the extended testing!

    I can’t really wrap my head around why it would be slower running AJAX than not. If we wouldn’t run AJAX all the posts would be loaded in on page load which basically should make the server hit the memory limit and crash (I would think). Of course I’ll have to take your word for it since I’m afraid the best site I have to test it on still only have about 15k posts (It works decently there).

    Perhaps there’s some AJAX tweaking that could be done to the relationship field and post object field to accommodate for huge quantities of posts.

    I’ll ask @elliot to chime in πŸ™‚

  • Actually now that you mention it I think maybe the memory limit could have been hit before but I have it set to 512M now and that seemed to work before upgrading and didn’t crash that Android Internet browser. Only after implementing AJAX/upgrading to ACF 5.0 Pro were these more noticeable delays when hovering or clicking the field and crashing that app present.

  • Maybe this is helpful to someone. In order to increase memory on the admin screens I put this in my themes functions.php file.

    function theme_increase_mem_limit($wp_max_mem_limit) {
    	return "512M";
    }
    add_filter('admin_memory_limit', 'theme_increase_mem_limit',10,3);
    
  • Thanks for that little snippet @rivage. I think one can also increase the memory limit overall on the site using different methods such as a constant in wp-config, changing the values in php.ini etc.. It all really depends on the servers configuration and what the server allows or not (many shared hosting solutions doesn’t allow any changes at all).

  • Yes but it seems that WP has it hardcoded in to set it to 256MB for admin screens for some reason and that wasn’t enough for this many posts.

  • Really? That’s new to me and frankly a bit strange.. I read up on it a bit now. According to this trac: https://core.trac.wordpress.org/ticket/13847

    It should now be possible to just set a constant WP_MAX_MEMORY_LIMIT and all places in wp-admin would also use this.

Viewing 21 posts - 1 through 21 (of 21 total)

You must be logged in to reply to this topic.