Support

Account

Register Login

Home › Forums › Backend Issues (wp-admin) › JS performance issues

Solving

JS performance issues

  • Hey @elliot

    Any chance we can get an update on this. I am about to start a project with the client whose site is experiencing issues due to this. I’d rather use the budget to work on new functionality rather than implementing a rewrite to work around this issue. I’d hate to spend their money just to find out that a fix was coming shortly.

  • Same here. I’ve some problems saving a Flexible Layout group containing 5 layouts / 24 fields. The site feels very slow (JS) an needs about 10 seconds to save in Chrome – in IE it seems a bit faster. Is there a fix for this?

  • No solution here, just some thoughts.

    There are really 2 issues discussed in this thread. On of them is a slow admin page due to the performance of JavaScript, the other is a slow saving issue. While it may appear to many that these are the same issue, they are in fact to separate issues as far as code and what’s going on.

    The JS issue will cause the admin page to be sluggish do to the way that ACF4 tests conditional logic. ACF5 has improved this…. but if you have a highly complex field groups setup with a lot of conditional logic, you’re still probably going to see problems and a slow down.

    The second issue, slow saving. This is an issue with the way that WP updates meta values. Every update query for every field in ACF produces at least 4 DB queries. First WP checks to see if there is already a value for a field and then it updates the value for the field. Sometimes it then does a new query to get the new value and populate the cache… why it needs to do this 3rd one, HTH knows. This is done twice for each field because ACF also needs to update the field key reference for the field. This is a limitation of WP because when updating it deals with one meta field at a time. It may be possible to improve this by adding an acf/save_post filter that gets all the post meta for a post before doing an update… but I have not tested this theory. At any rate, given enough fields on a single update it is possible that the update will time out in the browser before it completes. Fixing this problem I suspect is beyond the scope of what ACF is meant to do. Now, if someone could come up with a way to bypass this one at a time field update…. I’ve thought about it but I simple don’t have the time.

    On top of both of these issues is the fact that validation of field values is done on the server using AJAX. Part of the reason for this is to allow us, the developers, to create custom validation filters. This is an extra step that means the a post is actually sent to the server twice before it’s updated.

    My solution is to consider the limitations and plan my development around those limitations. What is logically possible and what is possible in practice are not the always the same thing. If I give a user a repeater field to add images and content with I expect them to be practical and not add 10,000 images to the repeater, although I wouldn’t be surprised if they tried.

  • I’ve run into a similar issue specifically with JS performance and multiple TinyMCE elements. I’ve been working on a fix that I’d love some help testing.

    Like many of you I end up with sites that have a TinyMCE field in a repeater or flexible content widget. If the client ends up adding more rows than expected the performance degrades quickly.

    So I built an add-on field that lazy loads the TinyMCE editor when someone wants to edit the content of the field. That way only one TinyMCE instance is active at a given time and performance improves significantly.

    I’ve used it in a few places and it currently supports both ACF4 and ACF5, but I’d love to get more people using it to see if I’ve missed anything.

    You can download and try it out here https://github.com/3pointross/ACF-Lite-WYSIWYG

    Any feedback would be great.

  • My biggest issue is during the image upload process. My current implementation is as follows:

    Flexible Field
    – Layout
    — Flexible Field
    — WYSIWYG
    — Image Upload
    — Plain Text

    The Layouts are 1,2,3,4 columns etc… so each column could use WYSIWYG, image or plain text options.

    Right now I have ACF PRO 5.4.8, am using @hube2 Reusable Field Groups plugin along with some others that I’ve included in the below zip.

    So far I’ve switched WYSIWYG to text tab default (trying @3pointross plugin :), switched from using image object to ID, use no conditionals in the front end. Around image number 5 being added to a column row, I get exceptional page lag.

    I completely understand limiting the complexity of flex content fields, but really want ACF to work as it’s a great plugin @elliot

    UPDATE Have to abandon ACF on a current client site. They experience timeouts when creating rows. I’d love a concrete solution here, but Beaver Builder is going to have to replace for this project.

    acf-test-fil....zip

  • Hi ppl

    I have a 18 fields ACF module, full of tabs for making step configurations & gather options per group.

    Also i added some conditional logic for displaying blocs options.

    All that mixed, i get the same problems…

    I noticed that all performances issues i get, comes from AJAX requests that timeout & behaviors associated on the client side.

    Here is AN IDEA on how you could handle that for making BETTER performance with your ACF module :

    On load, parse arrays of modules & instanciate them like this :

    > Module is in a Tab ?
    1. Yes : Is it the default TAB ?
    1.1. Yes : conditionalLoad()
    1.2. No : wait the tab has focus for conditionalLoad()
    2. No : conditionalLoad()

    THEN, conditionalLoad() check if the field is activated by the conditional logic
    You can also add another layer of performance optimisation : load a module WHEN it is also in viewport (tabLoad() > conditionalLoad() > inViewportLoad())

    I use flexible but also repeater fields with rows or blocs that have each SELECT field 😉 so imagine what i have…

    actually i get 100+ async requests on load… from that !!

  • Hey people. I was reading through the latest changelogs and it seems a fix has been release to alleviate this issue. Not sure if it would fix it (I can’t validate right now on the website that was causing the issue for me). Maybe validate? https://www.advancedcustomfields.com/blog/acf-pro-5-5-0-update/ (WYSIWYG delay option)

  • Same issue here, just with flexible and multiple layouts in it. Admin stuck for 1.5 minutes.

    WP 4.7.2
    ACF PRO 5.5

    However, it seems more of a regression to me as it was working much better a couple of releases ago. Unfortunately, I am not able to know which update to look at.

  • I just did a quick test and at 100 wysiwig fields on the page I get a popup that says

    A script on this page may be busy, or it may have stopped responding. You can stop the script now, open the script in the debugger, or let the script continue.

    2 to 3 times before the page finishes loading with the delay setting turned off.

    The page is much faster and I get no warnings about the script with the delay turned on.

    Also, when scrolling the page with this number of fields there is a noticeable lag in page scrolling. With the delay turned on this lag vanishes until you’ve clicked in many of the editors to activate them.

    It seems to have solved a lot of the issues that I was seeing.

  • Hi John,

    Do you have a rough idea on how long the page is taking to load for you with the delay setting enabled?

    I must say that the load times are not significantly different in my case (using about 10 flexi layouts and conditional logic in most of them) – maybe the issues are unrelated? I have a feeling that the release candidate 5.5.X version was working better for me than the latest stable release?

    Cheers, Scott.

  • I’m not on the fastest internet connection here, currently. My upload speeds suck, so it will effect page load times.

    When I click update, with 100 wysiwyg fields all containing 5 paragraphs from http://lipsum.com/

    First there is the “validation request” (spinning icon next to update). This takes about 15 seconds

    Then there is the actual submission (I can tell when the page is done submitting in firefox and the browser starts to get data back because in the browser tab changes direction and changes color) This takes about another 15 seconds.

    After the page starts loading it is done working after another 10 seconds.

    so the total page load time is about 40 seconds.

    Adding conditional logic on top of this will add additional time, especially if you have a lot of it. Repeaters and flex fields add their own overhead to page’s rendering time. This time may also be effected by the speed of the computer you’re using and how much memory you have available. Where I have a problem with my current internet connection, my computer can make up for it because it brand new and is exceptionally fast and I’ve got RAM to burn.

    Overall, I personally would not consider a 1 minute load time on a page with 100 wysiwyg editors to be slow. It’s not blazing fast, but if someone’s going to add that much information then they should expect it to be a bit slow.

  • Sh*t that is quite long. Longest loads I’m getting is about 15-25s on page with 10-15 flexible content rows each with a WYSIWYG, Image, Link, Repeaters etc – which shows I am impatient more than anything!

    Most of the time savings I was able to achieve by posting the field group changes via AJAX instead of refreshing the whole page (and having to wait for the field groups and other DOM elements to be redrawn every time). Saving request take about 5-10s on average, so after loading the page for the first time, it’s a no-brainer.

    I do agree with you though, you can’t be all things to all clients. If they want the flexibility of creating custom layouts and rows with lots of complex conditional logic happening, then the wait for a minute is more than a reasonable cross to bear for a fool-proof, fully formatted page on the front end.

    Thanks for sharing your insights, it is always helpful to be able to benchmark along the way.

  • I’m limited to DSL speeds where I am now. If I was at work I’d expect the upload/response times to be less than half of what I’m seeing. You also have to remember that I come from a time before the internet (https://www.youtube.com/watch?v=d85p7JZXNy8) and everything is fast today compared to a 14.4 phone modem and a computer that took 20 minutes to boot up 🙂 It’s just a matter of perspective.

  • ^_^ so true!

    ROFL at that vid – “…I come from a time way back …. when computers were used for 2 things. You either go to the moon – or play pong. Nothing in between.”

    Thanks for the lols at the end of my work day John, cheers!

  • Trying to debug the issue, I deleted my problematic Filed Group, the only with a terrific delay which sometimes is even able to crash Chrome.

    After deleting, I started recreating the fields group.

    1. First I set a Post Object field.
    2. Second a Flexible field.
    3. Inside the Flexible, in the first Layout, I placed a Relationship field.

    That was already enough to start experiencing a serious delay with page freeze.

    All of my other 29 fields groups still show no issues at all so I guess there should be something closely related to this kind of grouping.

  • For what I can see so far, it is closely related to the filters part of the field settings (Filter by Post Types, Filter by Taxonomy, Filters) which specifically hangs for a couple of seconds before loading, even if just a relationship field is present inside the Group.

    A specific characteristic of the website I am working on, is the high number of Categories, 309 at the moment. Could this be the real cause of the issue?

    Every kind of field that loads those filters seems to add delay up till making the page totally unstable. Two relationships and 4 Post Object are enough to trigger the Chrome script warning.

    I really need to find at least a temporary workaround as the site is in production and changing data structure is clearly out of question. It is possible to edit the fields with JS disabled or it MUST be on?

  • @yumyo I don’t think you are experiencing a JS problem. With that many categories on the site try unchecking Taxonomy in the filters. In order to use this filter ACF loads and sorts all of the taxonomy/terms for the site.

  • Hi @hube2, thanks so much for replying.

    I got no issue on data insertion, eg. on page home. The issue only arises when I access the field groups in the “Edit Field Group” page. Also, if I disable javascript there’s almost no delay and taxonomies are all listed as expected.

  • Ok, disabled all plugins, switched to Twenty Seventeen, no issue. So, I now need to find the conflicting bit. I should have done it first, sorry for wasting your time guys.

  • I managed to isolate the offending fellow beyond any doubt.

    Unexpectedly, it is Shortcake (Shortcode UI) 🙁 I am very happy is not ACF though.

  • I’ve been looking into a good shortcode plugin and I did see several issues on github and the support forum on WP about that plugin having compatibility issues with several other plugins. I guess it makes WooCommerce completely useless.

  • I’ve opened an issue in the Shortcake Github repo

    https://github.com/wp-shortcake/shortcake/issues/696

    The idea behind Shortcake is very nice but like you said, it easily conflicts with some of the best WP plugins.

Viewing 22 posts - 76 through 97 (of 97 total)
1 2 3 4

The topic ‘JS performance issues’ is closed to new replies.