Toolset has been very helpful in building the product until now. I have used all the amazing features your product has to offer to build my site. I have more than 10 custom post types which are in a range of relationships from great grandfather to grandchild O2O, O2M and M2M ones.
I have used views and types shortcode all across my site and I have combined the shortcodes with elementor post templates to build the product. There are a decent number of shortcodes used on the pages and the functionality works exactly the way I want. I have also written custom php in the toolset custom code section to trigger events that either update posts or store data in the database. I am using toolset forms, toolset custom fields, toolset access and many other features.
This site works but has become really slow. I am talking about TTFB of more than 10 seconds. The page that are really slow have lot of shortcodes which include many toolset shortcodes. My question to you is -
What are the limits of WordPress and Toolset? Am I am ever going to get decent speed if I use multiple shortcodes from Toolset?
What is my current setup -
1) I am on Siteground with their $100 plan
2) I have Siteground optimizer plugin enabled
3) I have WPRocket plugin enabled
But this does not help with dynamic content and dynamic pages. I have heard about Object caching - memcache or Redis. Siteground offers memcache but that does not seem to work on the site. What do people do when they have lot of dyanamic content on WordPress using Toolset? there has to be a way to speed up things. I was wondering if there is a way to store this data either in object cache or cookie cache so that DB does not get hit every single time but this needs to happen at user level and my current setup does not help a lot.
As I am using a lot of [WPV--] shortcodes, I would really appreciate some advice on how could I make the site fast? I have read a lot of stuff and it seems like I am on a decent plan and it just does not work.
Are Toolset and WordPress bound to slow down when you have 10+ post types and dynamic content? The worst part is I have not even launched and the thing is just slow. Any help appreciated.
I would like this ticket to be taken care of by a person in the US and preferably Christian.
Thank you.
What are the limits of WordPress and Toolset? Am I am ever going to get decent speed if I use multiple shortcodes from Toolset?
Are Toolset and WordPress bound to slow down when you have 10+ post types and dynamic content?
There's nothing inherently slow about using Toolset's shortcodes or having 10+ post types. Dynamic content is inherently slower than static content since it must be pulled from a database. Slowness usually comes from complexity, like Views nested multiple levels deep that loop over loops, images that use custom resizing in loops, complex queries that have multiple custom field or relationship filters, open ended queries that do not use pagination, huge numbers of posts/users/taxonomy terms, custom codes that perform calculations or operations based on dynamic query results without caching, etc.
What do people do when they have lot of dyanamic content on WordPress using Toolset?
A good caching plugin is usually worth investigating. As much as possible, a good caching plugin can generate static html versions of each page and serve them up very fast. This is usually appropriate for landing pages, archives, and individual posts. It does not really help with custom search results, since those use URL variables. It is not helpful if your content varies by User. You can optimize those caching plugins to update the cached version when specific posts or post types are updated to keep your content fresh. TTFB of 10+ seconds seems excessive, so I think you could have some improvement there.
Minimizing the number of nested loops will help minimize the number of database queries required to serve up a page.
Limiting the number of results in Views and archives by using pagination will help speed up pages that have open-ended queries.
Utilize Views caching as much as possible based on the documentation available here: https://toolset.com/documentation/legacy-features/views-plugin/how-to-use-views-parametric-search-on-large-sites/
Use a plugin like Query Monitor to check baseline performance with only Toolset plugins and a default theme like Twenty Twenty One active, and any custom code deactivated. If any single query runs longer than 0.05 seconds, our developers can investigate that as a performance issue.
Christian,
Thanks for the insight. Almost all the scenarios that slow down the site apply to me.
1) There are post loops and each loop template has a significant number of shortcodes to show dynamic content
2) There are nested views with cannot be cached until the very last view
3) The are custom fields, queries, and custom code that might not be fully restricted by pagination.
I am using WP Rocket as a caching plugin (with advanced conditions that only update the cache when there is a change in post content) and will try to apply Views caching to see if things change.
I have a follow on the caching mechanisms. Do you have insights on using Redis or Memcache for speeding up the site? What about cookie-level caching?
Do the caching plugins and Views caching already use object caching that stores frequent queries and avoid page load time?
Do you have insights on using Redis or Memcache for speeding up the site? What about cookie-level caching?
Hmm, no I don't have any documentation available about any of those specifically. Toolset does not offer any direct integration with Redis or Memcache as far as I'm aware. Views caching documentation does not deal with cookie-level caching, so I don't think there is anything specific available or that either.
Do the caching plugins and Views caching already use object caching that stores frequent queries and avoid page load time?
Each caching plugin works differently, so you would need to consult the documentation for any caching plugin you decide to implement to see exactly how it improves load time. Some use object caching, some use static HTML versions of the page, some use proprietary database tables, combinations of the above, etc., variable per plugin.
I understand Views' caching mechanism stores the entire View output in the wp_options table of the database using transients for fast retrieval, it does not utilize object caching like Redis or Memcache to cache queries and results.
Thank you for your help. My issue is resolved now. Thank you!
