Skip Navigation

[Resolved] View loads extremely slow on backend

This support ticket is created 3 years, 9 months ago. There's a good chance that you are reading advice that it now obsolete.

This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.

Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.

Sun Mon Tue Wed Thu Fri Sat
- 9:00 – 13:00 9:00 – 13:00 9:00 – 13:00 9:00 – 13:00 9:00 – 13:00 -
- 14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 -

Supporter timezone: Asia/Karachi (GMT+05:00)

This topic contains 7 replies, has 3 voices.

Last updated by matthewL-7 3 years, 9 months ago.

Assisted by: Waqar.

Author
Posts
#1940591

Hi

I have a Toolset view I have made that is incredibly slow on the backend. It works OK on the front end its a little slow but that's to be expected because there is 10k+ CPT's its loading through. Its adequate though.

However on the backend it for this page and its view in the block editor:
- its extremely slow when making changes (like 30 seconds before I can hit save)
- it doesn't always let me hit save when I make edits, not recognising some changes.

Any ideas why it would be so unresponsive? Maybe its constantly reloading the results? How can I avoid this just for this page/view?

It actually doesn't seem to be an issue on other pages that also load CPT's from the 10K+ database, its just specifically this view, but this view/page does have a lot of customisations.

I have a dev site with the same issue if you'd like to take a look?

#1940789

Nigel
Supporter

Languages: English (English ) Spanish (Español )

Timezone: Europe/London (GMT+00:00)

Hi Matt

Can we get access to the staging site to take a closer look?

I will mark your next reply as private to get log-in credentials from you—you may want to create a temporary admin user for us to use that you can later delete. And be sure to have a current backup of your site.

Where can we find the problematic View?

#1942057

Hi Matt,

Thank you for sharing the admin access.

I've performed some page loading tests on that page edit screen and it completes for me between 30-40 seconds. Considering the number of results and the complex nature of the content involved, this is not bad.

An important point to remember about the WordPress' new Gutenberg editor is that it comes with an active preview screen, which fetches the data using the REST API. As a result, it can feel a bit slow compared to the classic editor where no preview was involved.

Another thing is that the Gutenberg editor comes with an autosave feature that is running frequently in the background scanning for changes and saving them.
( during that processing the update button is also disabled )

A couple of things that you can do to improve this are:

1. You can increase the value of the autosave interval so that processing happens less often:
hidden link

2. Your website seems to be served through Cloudflare. It would be a good idea to exclude its features for the admin pages:
hidden link

I hope this helps.

regards,
Waqar

#1942347

Hi Waqar,

OK thanks for this I will implement these suggestions.

One thing I noticed was reducing the amount of results in the view really helps when editing, is there any way to reduce this just on the backend? Its pain to reduce the results then remember to undo this then save.

#1943679

A workaround/hack that you can use for this would involve setting a low number of limits for the results in the view's settings.

But, then override that for the front-end using the "wpv_filter_query" query filter:
https://toolset.com/documentation/programmer-reference/views-filters/#wpv_filter_query

Example:


add_filter( 'wpv_filter_query', 'wpv_filter_query_func', 1000 , 3 );
function wpv_filter_query_func( $query_args, $view_settings ) {
	// skip if blocks edit screen
	if ( defined( 'REST_REQUEST' ) && REST_REQUEST ) {
		return $query_args;
	}
	
	// process if specific view and front-end
	if ( !is_admin() && ( isset($view_settings['view_id']) && $view_settings['view_id'] == 1234) ) {
		$query_args['posts_per_page'] = -1;
		$query_args['wpv_original_limit'] = -1;
	}
	return $query_args;
}

Note: you'll replace "1234" with your target View's ID.

#1947507
Screenshot 2021-02-14 at 16.48.24.png

Hi Waqar

That is great, that seems to do the trick.

Another issue with this specific page/view is that the text and fields box seems to get squished up making it really hard to edit, see the screenshot attached.

Any ideas how to avoid this?

Thanks

#1948771

Thanks for the update and glad that it worked.

Unfortunately, the more the nested grid items a page will have, the less width would be available for editing the content inside them.

However, you can maximize the editor's available width by setting the "Adjust Editor Maximum Width" option available at the top right corner to "100%".
( screenshot: hidden link )

While editing, you can un-check the option for the Toolset and WordPress settings pane, to maximize the available width.
( screenshot: hidden link )

You're welcome to mark this ticket as resolved and start a new one for each new question or concern.

#1949227

Ah ok thanks, that helps a little! 🙂