Smush or Autoptimizer delaying Elementor counter and progress bars

That’s likely autoptimize (I’m it’s developer) indeed g4125 ; it tries to make all JS non-render-blocking by loading it a late as possible, but that indeed impacts UI elements rendered by it.

You could:
* untick “aggregate JS”
* keep “aggregate JS” on but exclude Elementor’s JS from JS optimization

hope this helps,
frank

Thanks for that very prompt response Frank.

Unticking ‘aggregate JS’ doesn’t appear to have made any difference.

What do I need to add to the current exclusions of:
wp-includes/js/dist/, wp-includes/js/tinymce/, js/jquery/jquery.js
to exclude the counter and progress bars?

Sorry, I’m a WYSIWYG designer and the behind the scenes stuff is a little like a foreign language.

if unticking “aggregate JS” doesn’t make a difference, then excluding won’t help either; when “aggregate JS” is off the JS isn’t deferred (loaded as late as possible) any more.

maybe take a step back; then loading the page with ?ao_noptimize=1 appended to the URL (to disable AO), do those UI elements load normally?

Does that totally disable Autoptimizer?

They don’t load as fast as they did originally, but they ‘may’ be faster than they were before appending the address. It’s difficult to tell because you have to scroll down to the bottom of the page past the UI elements, and then back up again for them to animate, where they used to animate as soon as they appeared as I scrolled down.

Would that imply that Smush is causing the problem then?

Essentially I’m trying to get a graphics-heavy page to load as fast as I can, but if the UI elements don’t animate almost instantly, they end up giving the wrong information which will be worse than the page loading slowly.

I’ve just done a test.

Normally whilst scrolling down, as soon as the counter or progress bar appears at the bottom of the screen – it animates.

Now what appears to be happening is the reverse. If I sit and wait for the animation to happen in front of me – nothing happens. But if I scroll to the bottom of the page, then back up, they have animated.

You should be able to test this yourself by using the same method you’ve told me to do.

Thanks for your help BTW

well, you could try temporarily disabling Smush, but I would be kind of surprised that that would have that impact?

Since I use autoptimize, but not smush, and have animations, I thought to check out what happens on my site. There is indeed a delay of about 1 sec. before the first animation, but it never bothered me. However, to make a long story short, in my case the presence or absence of autoptimize, whether via plugin disabling or URL argument, seems to have no effect whatsoever on the delay in the animation. What does make a big difference is the local caching of the page in the browser. Server side caching does not seem to impact the issue. I don’t use a CDN.

The browser, too, makes a difference. Apparently, Chrome either caches better than Firefox (relative to Elementor animation, at least) or it draws the page from the local cache more quickly than does Firefox.

I am not asking for any support about this, but thought that sharing my own case might help in the diagnosis. If it just confuses things, ignore this.

I’ve disabled Smush and it does indeed make a difference – the animations are now back to normal.

I’m still testing it, but I think the way forward is to use Smush to smush the images then disable it and use Autoptimize to make the site faster to load.