I have a page that displays about 200 posts from a Types CPT. There is a nested view that displays a related CPT post for each of those posts in the loop. That second CPT has about 1800 entries, but only displays the most recent that matches the parent CPT, so it's pulling 200 from the 1800 or so.
Without the nested view of the related post type, it loads at a normal speed. But with the nested view it takes a significant time to load. Not so long that it times out, but long enough to suggest to the user that there is a problem.
Here are two links to the page in question, one with and one without the nested view, so you can see the difference.
With: hidden link
Without: hidden link
My question:
Are there any general troubleshooting issues you could suggest that might be causing the second view to slow page loading?
Is there something about the nested view that is causing this delay that could be dealt with by how the filter is constructed or some other aspect of the view (I assume you'll need access to the backend to assess that fully).
Is there something I could do to have the main view load first and have the second view (which is probably slowed by searching through more entries), load after the first view has loaded?
Hello and thank you for contacting the Toolset support.
Before going further on this, and assuming that the view does not use additional queries to the database I would say that:
- The view without nested views will generate one query to the database. Total queries: 1 query.
- The view with nested views will generate one query + a query per post. Total queries: 1+200=201 queries.
It is expected that the second one will take a much longer time than the first. If the queries search against custom fields, the underlying SQL queries will cost more than a query without custom fields.
Generally, enabling pagination on the view will reduce the time of the second page. If you display 20 posts, the total number of queries would be 21 queries instead of 201.
From my side, I loaded both pages in less than 10 seconds. Check this screenshot hidden link The second one was loaded faster than the first one. Maybe you have some server caching layer that has cached the results of the first query and used it on the second query.
So, generally, implementing cache will speedup these pages. If you are using custom fields, and those can be converted to taxonomies, that would speed up the query too. Search by taxonomy is less costly than using custom fields.
It is not really easy, and probably not possible, to load the first view first, then load the second one. I can't really say, without checking how the views are built. So, I am setting your next reply will be private to let you share credentials safely to check these views. ** Make a database backup before sharing credentials. **
Thanks. Good suggestions so far. If I were to consider implementing the suggestion about taxonomies over custom fields, would that require that each of the fields that currently make up the CPT be their own taxonomy (e.g. Field1 becomes a taxonomy, Field2 becomes a second taxonomy)? Or would the same cost savings be achieve with a custom taxonomy using Term Fields?
Term fields are as costly as Post fields. In general, using custom fields(for posts, terms, or users) adds cost to the database query. Database management systems such as MySQL do optimize these requests and are very efficient about querying data, but custom fields do add some cost depending on the database size. That can go from a few milliseconds to a few seconds depending on the database size and the server resources(CPU, and memory).
If you were using a select, radio, or checkboxes field in the view's query/search, I would suggest using a taxonomy for each field(Field1 becomes taxonomy1, Field2 becomes taxonomy2, etc.)
I checked both pages and their views do not use any custom fields for searching. They do use a custom field(wpcf-alphasort20192020) for sorting. The view(Current Bills 2) on the second page is not using any nested views inside of its loop.
I hope this helps. Let me know if you have any questions.
Thanks for taking a look at my site. Unless I'm not following your answer, I think my question may have gotten a little muddled in our prior exchanges.
The main thing I'm asking about is the first link. I know that the second link doesn't have a nested view. That's why I sent it to you; to illustrate a point. The second page is exactly the same as the first page, but with the nested view removed. My point in sending the second link was just to illustrate that without that nested view, the page loads so much faster (1-2 seconds vs. 8-9 seconds), that it seems the slow loading of the FIRST page must be related to the nested view.
So, I'm asking about page 1, which has a view called "Current Bills", which has a nested view called "One-History" which uses a filter to query the database for related posts based on a toolset relationship between two custom fields.
The question I was hoping to get an answer to is what is it about the nested view that makes the first page load so slowly, and is there something I could do to make that load faster?
Sorry for missing that and thinking that the second page holds the nested view.
As I explained earlier, the nested view will require a database query for every post in the parent's view loop. For example, the page's parent view returns 188 posts. This means that the parent and nested view generate 1+188 database queries(against posts table) to pull the posts. Then, there are other queries to pull custom field data(against postmeta table).
The only thing, I can think of currently, is to replace the nested view with a custom shortcode. This custom shortcode will play as a cache. If it found the cached data(the returned HTML for the nested view) it will return it, and if it does not, it will execute the nested view. To execute the view you can use do_shortcode or wpv_do_shortcode functions:
return do_shortcode('[wpv-view name="one-history"]');
// or
return wpv_do_shortcode('[wpv-view name="one-history"]');
Then, you can invalidate this cache, either by time, using the Transient API, or you can invalidate it when the relationship links happen:
- https://developer.wordpress.org/apis/handbook/transients/
- https://toolset.com/documentation/customizing-sites-using-php/post-relationships-api/#toolset_association_created
- https://toolset.com/documentation/customizing-sites-using-php/post-relationships-api/#toolset_before_association_delete
I hope this helps. Let me know if you have any questions.
Thanks these are helpful suggestions. I'll test some of them out. May be that pagination may be the best solution. We will see. My issue is resolved now. Thank you!
