- This topic has 5 replies, 3 voices, and was last updated 9 years, 6 months ago by
.
-
Posts
-
Hello guys!
We are team who work with Denty on behalf of ITT. An we see one issue with events page with big amount of events. For example we using month view and around 3K events in month. total events count more then 16K.
example pages:
calendar view
http://dev.choosehealthier.1pls1.com/events/category/physical-activity/
https://gyazo.com/9a899432d8fbde663c3e118be3d7c2d0 – 22,7 seconds load
http://dev.choosehealthier.1pls1.com/events/category/food-nutrition/
https://gyazo.com/3416c0e79dbf0986bb37edeb08ba23c3 – 10 seconds load
list view
http://dev.choosehealthier.1pls1.com/events/category/physical-activity/2016-09-28/
https://gyazo.com/1b6a42da2b6f49cfd34fd4e0409b18bc – 8 seconds loadIs it any way for decrease time to load page? Maybe any solution for decrease number of SQL queries for display this events amount (we checked queries count for get info from database for “physical-activity” we get more then 9K queries).
Looking for your responce.
Thank you!Howdy cmchwp,
I would love to help you with this.
That is a very fair question. The answer is yes, there is more we can do. We do periodic performance audits, usually after big feature releases. I just finished one a little while back, and logged the takeaways for us to address. The performance improvements are not ready yet, but when they are they will be released as an update to the plugin.
In the mean time there are two things you can do to improve performance now:
- Enable Month View Cache in WP-Admin > Events > Settings > Display. No matter what we do, if our plugin continues to follow WordPress “best practice” Month view will still need to do a sizable number of queries when you have 3k events it’s trying to display. This is the unfortunate nature of the WP API here. However if we cache the HTML on this page, it will only have to do all of those queries once when an event is added/updated, rather than each page load.
- The biggest performance improvement we have coming down the pipes is caching JSON LD alongside the rest of month view. Unfortunately when we added that feature in 4.1 none of our code reviewers thought to cache it, since it appears in the header of the page. This means that enabling Month View Cache right now is effectively useless, all the queries it usually saves the calendar from doing are done anyways, just for a different purpose. If you pop the following snippet into your site, either into a plugin or a functions.php file, it will disable JSON LD in Month view. With that in place you should notice page load speeds drop dramatically after the page is cached.
https://gist.github.com/elimn/9ce1c3e64d060b758e22627b815455ae
Does that all make sense? Do you have any more questions?
Cheers!
– Brook
I just realized after posting that you are on an older version of our plugins, from before JSON LD was introduced. The second step would not apply to you unless you updated.
I totally understand the desire to stay on a version of the plugins you have tested thoroughly. But it does inhibit the amount of support we can provide.
Like many large pieces of software performance is a seesaw battle. You add new features, performance goes down. You optimize, it goes back up. Rinse and repeat. This means the latest version of our plugins is not always the fastest, though on average it trend towards getting more optimized. 3.10 introduced some nice performance improvements in a few views. If memory serves 3.11 had a negative impact on some of those, and they were subsequently addressed in 4.0. We’re stretching my memory a bit here.
If I were in your shoes I would test out the latest version of our plugins with JSON LD disabled, per the above. I would not be surprised if it is our fastest version to date with the prescribed configuration. And keep an eye on the release notes of future versions. We have been reexamining the intricate details of WP’ builtin query caching to make the most of it. One thing we have noticed is that a few of our post meta queries could hit the cache instead, if we do a get_post() request for that ID early in the page load and query by the ID again. This will involve a huge restructuring of our code, but that is something we already have a working prototype of. Once that prototype is ready for primetime both our Month view and especially our Minical widget will see a lovely performance boost. For month view this will speed up the page load, or if you have cache enabled it will speed up the rebuild. For the minical it will just drastically cut back on the number of queries it makes.
Cheers!
– Brook
- The topic ‘Decreasing loading time for big amount of events’ is closed to new replies.