extremely slow page loads when Events Calendar Pro is in use

Home Forums Calendar Products Events Calendar PRO extremely slow page loads when Events Calendar Pro is in use

Viewing 12 posts - 1 through 12 (of 12 total)
  • Author
    Posts
  • #1569050
    vladtheinhaler
    Participant

    I’m using The Events Calendar for the first time and like many things about it, but I’m finding that it’s absolutely destroying my page load times. I’ve read through all the docs I can find, including the knowledge base, and although there are a lot of great suggestions there, none of them help my dev site.

    Background: I’m using a widely-used theme (Total) that I’ve used many dozens of times on other sites, and on the server I’m using (SiteGround) would expect a Home page with the features I’m using to load in about 2.5-3.5 seconds. With The Events Calendar in use, the actual loading time is a gruesome 6.5-8.5 seconds. Ouch!! When I disable Events Calendar and Events Calendar Pro, the page immediately loads in about what I’d expect: 3.25-3.5 seconds in repeated tests. The only action I need to take to get this 50% savings in load time is disabling the Events Calendar.

    I know there are a ton of things that can affect performance, so here’s a description of the server environment, WP config, and the things I’ve tried to fix this element:

    – PHP version is 7.1.8, which I know is not the recommended 7.2 but is pretty close
    – WP_MEMORY_LIMIT is 256M
    – there’s some level of caching and CSS/JS minification happening via the free tier of Cloudflare
    – I’ve installed and run WP-Optimize to eliminate database clutter
    – I’ve enabled the Month View Cache (under Events > Settings > Display tab)
    – I’ve set the Events Calendar to only show two events when clicking a date. not sure if that matters, but trying to keep the query light.
    – the current month view (July 2018) only has a couple of events, so it’s not as if there are dozens and dozens of event listings in the query for the active view
    – there are a few recurring events in the database, with probably approx 100 total instances (including single and recurring events). all events are pretty light in content, just a sentence or two of description and very few images or anything else beyond the basic commonly used fields.
    – I’m using the Events Calendar Category Colors plugin, which doesn’t seem like it should be a resource hog, but I mention it just to leave no known stone unturned
    – SiteGround offers its own server-side caching, and I’ve set that up and configured it properly BUT it’s not yet active because I’m running the site off a temporary dev URL and not the “real” URL that it will be running from post-launch. SG support says the SuperCacher is domain-specific, so I guess there’s a chance some server caching benefits might kick in after launch, but I’m sure not willing to bet on that and would love to have a solution before go-live, for obvious reasons.

    Sorry for the long post, but I know if I didn’t lay out all the above, people would (correctly) suggest a lot of stuff I’ve already tried. I’d be extremely grateful for any insights on this so-far intractable problem. . .

    #1569074
    vladtheinhaler
    Participant

    Two things to add:

    – this is a cross-post with the free WordPress community forum. . . didn’t realize that my purchase of two premium add-ons entitled me to Premium, so I posted there first, but was relieved to find out I could post here as well. Okay to close or delete the post in the other forum, or whatever you want, once it’s resolved here!

    – this project is close to go-live, so I’m in a hurry (of course) so if this convo goes on for more than a round or two (with 24-48 hours between rounds) the client will be distressed. anything you can suggest to cut to the chase and/or condense rounds of tests/questions into fewer messages would be greatly appreciated.

    #1571621
    Jennifer
    Keymaster

    Hello,

    I’m sorry that you’re running into this issue with the load times, and you are correct that there are several things that can impact performance. It sounds like you have already taken many of the steps that we typically start with! One thing you can do to try to pinpoint the source of the issue is to install the free Query Monitor plugin, which should help identify any particular queries that are  causing such high load times. If you do see anything events-related, please copy/paste those messages here.

    Are the load times this much higher only on pages with events content, or is having the plugin active causing everything on your site to slow down? For instance on your home page, if you remove the events widget, does that significantly improve the load time?

    #1571853
    vladtheinhaler
    Participant

    Yes, if I remove the Events widget on my site’s home page, the page loading time drops from about 6.5-7.5 seconds to 3-3.5 seconds. The 3-3.5 second range is about what I’ve seen on *many* sites using the same WordPress config (core, theme, plugins) but without The Events Calendar, so if I remove the calendar widget from the sidebar and make no other changes whatsoever, the page loads about as fast as I’d expect.

    I have to run at the moment so can’t install Query Monitor right now, but I’ll try that tomorrow and see if it provides any insights.

    #1572456
    Jennifer
    Keymaster

    Thanks for clarifying that! It does seem strange that the widget by itself would make such a drastic difference in the load time. Please let me know what you find with Query Monitor, and I’ll be happy to see if we can make any recommendations!

    #1573668
    vladtheinhaler
    Participant

    I finally had a chance to install QM and see that it gives me a vast amount of output, so I’m not clear exactly what diagnostics you’d find useful. A good place to start: QM does identify one Slow Query, which it associates with Events Calendar, and here’s a dump of all the output about that, below. I’ve also attached a screen grab of the Slow Query info summary itself, just to make sure I’m looking in the right place. If I’m understanding this correctly, the slow query is only adding 0.0919 seconds, which would hardly explain the 3-4 second page load difference I’m observing with EC active, but it’s the only info I see that seems relevant.

    And now, the log:

    Query Monitor
    Settings
    Pin Panel Open
    Close Panel
    Overview
    Slow Queries (1)
    Queries
    Queries by Caller
    Queries by Component
    Duplicate Queries (95)
    Request
    Template
    Scripts
    Styles
    Hooks & Actions
    Languages
    HTTP API Calls (1)
    Transient Updates
    Capability Checks
    Environment
    Conditionals
    Query Caller Component Rows Time
    SELECT option_name, option_value
    FROM wp_wrightoptions
    WHERE autoload = ‘yes’

    wpex_get_template_part()
    wp-content/themes/Total/framework/template-parts.php:121
    get_template_part(‘partials/page-single-layout’,”)
    wp-includes/general-template.php:155
    locate_template()
    wp-includes/template.php:647
    load_template(‘wp-content/themes/Total/partials/page-single-layout.php’)
    wp-includes/template.php:690
    get_template_part(‘partials/page-single-content’)
    wp-includes/general-template.php:155
    locate_template()
    wp-includes/template.php:647
    load_template(‘wp-content/themes/Total/partials/page-single-content.php’)
    wp-includes/template.php:690
    the_content()
    wp-includes/post-template.php:240
    apply_filters(‘the_content’)
    wp-includes/plugin.php:203
    do_shortcode()
    wp-includes/shortcodes.php:197
    preg_replace_callback()
    wp-includes/shortcodes.php:319
    do_shortcode_tag()
    wp-includes/shortcodes.php:319
    vc_do_shortcode()
    wp-content/plugins/js_composer/include/helpers/helpers.php:1311
    WPBakeryShortCode->output()
    wp-content/plugins/js_composer/include/classes/shortcodes/shortcodes.php:570
    WPBakeryShortCode_VC_Row->content()
    wp-content/plugins/js_composer/include/classes/shortcodes/vc-row.php:35
    WPBakeryShortCode->loadTemplate()
    wp-content/plugins/js_composer/include/classes/shortcodes/shortcodes.php:478
    wpb_js_remove_wpautop()
    wp-content/plugins/js_composer/include/helpers/helpers.php:236
    do_shortcode()
    wp-includes/shortcodes.php:197
    preg_replace_callback()
    wp-includes/shortcodes.php:319
    do_shortcode_tag()
    wp-includes/shortcodes.php:319
    vc_do_shortcode()
    wp-content/plugins/js_composer/include/helpers/helpers.php:1311
    WPBakeryShortCode->output()
    wp-content/plugins/js_composer/include/classes/shortcodes/shortcodes.php:570
    WPBakeryShortCode->content()
    wp-content/plugins/js_composer/include/classes/shortcodes/shortcodes.php:458
    WPBakeryShortCode->loadTemplate()
    wp-content/plugins/js_composer/include/classes/shortcodes/shortcodes.php:478
    wpb_js_remove_wpautop()
    wp-content/plugins/js_composer/include/helpers/helpers.php:236
    do_shortcode()
    wp-includes/shortcodes.php:197
    preg_replace_callback()
    wp-includes/shortcodes.php:319
    do_shortcode_tag()
    wp-includes/shortcodes.php:319
    vc_do_shortcode()
    wp-content/plugins/js_composer/include/helpers/helpers.php:1311
    WPBakeryShortCode->output()
    wp-content/plugins/js_composer/include/classes/shortcodes/shortcodes.php:570
    WPBakeryShortCode->content()
    wp-content/plugins/js_composer/include/classes/shortcodes/shortcodes.php:458
    WPBakeryShortCode->loadTemplate()
    wp-content/plugins/js_composer/include/classes/shortcodes/shortcodes.php:478
    dynamic_sidebar(‘pages_sidebar’)
    wp-includes/widgets.php:743
    WP_Widget->display_callback()
    wp-includes/class-wp-widget.php:372
    Tribe__Events__Pro__Mini_Calendar_Widget->widget()
    wp-content/plugins/events-calendar-pro/src/Tribe/Mini_Calendar_Widget.php:47
    Tribe__Events__Pro__Mini_Calendar->do_calendar()
    wp-content/plugins/events-calendar-pro/src/Tribe/Mini_Calendar.php:194
    tribe_get_template_part()
    wp-content/plugins/the-events-calendar/src/functions/template-tags/general.php:151
    tribe_show_month()
    wp-content/plugins/the-events-calendar/src/functions/template-tags/month.php:42
    Tribe__Events__Template__Month->setup_view()
    wp-content/plugins/the-events-calendar/src/Tribe/Template/Month.php:891
    Tribe__Events__Template__Month->get_daily_events()
    wp-content/plugins/the-events-calendar/src/Tribe/Template/Month.php:827
    Tribe__Events__Template__Month->get_cutoff_details()
    wp-content/plugins/the-events-calendar/src/Tribe/Template/Month.php:690
    tribe_end_of_day()
    wp-content/plugins/the-events-calendar/common/src/functions/template-tags/date.php:113
    tribe_get_option()
    wp-content/plugins/the-events-calendar/common/src/functions/template-tags/general.php:29
    Tribe__Settings_Manager::get_option()
    wp-content/plugins/the-events-calendar/common/src/Tribe/Settings_Manager.php:86
    Tribe__Settings_Manager::get_options()
    wp-content/plugins/the-events-calendar/common/src/Tribe/Settings_Manager.php:66
    get_option()
    wp-includes/option.php:90
    wp_load_alloptions()
    wp-includes/option.php:197
    Plugin: the-events-calendar 427 0.0919

    #1574896
    Jennifer
    Keymaster

    Thanks for sending that info! I will run this by the team and see if there is anything that we can recommend. In the meantime, we did just put out some maintenance releases, so can you upgrade to the current versions:

    The Events Calendar 4.6.20.1

    Events Calendar Pro 4.4.29.2

    After updating, you’ll want to clear out any caching that you are doing (via plugins or on your server – this will also mean temporarily disabling the month view cache under Events > Settings).

    Let me know if this makes any difference!

    Thanks,

    Jennifer

    #1574987
    vladtheinhaler
    Participant

    Hi, I just:

    1. updated both plugins
    2. cleared the SG Optimzer (server level cache) and Cloudflare cache
    3. unchecked the Month View cache for EC, saved, rechecked, resaved

    Home page now loads in 7.5 seconds, slightly slower than when I did the above :/

    #1575246
    vladtheinhaler
    Participant

    Just had two thoughts that seemed worth adding to the mix:

    1. I remembered Query Monitor was running, and once I turned it off, the site was back to its normal 6.5 second loading time from when I first opened the ticket. The extra time seems to have been due to QM, so no new worries there.

    2. I slightly misstated one possibly important thing in an earlier post: I get a 3-3.5 second Home page load when the EC/EC Pro plugins are entirely deactivated, not just by removing the widget from the Home page. If I just remove the widget, times are still long, but not quite as long as if the element is present, maybe a 1 second savings or so.

    Don’t know if either of these nuances is important, but just trying to make sure you have all available information.

    #1575256
    vladtheinhaler
    Participant

    STOP THE PRESSES, this issue is solved. The site was running on a preview URL (since it’s a redesign of a site that’s already up and running) so it wasn’t using any of SiteGround’s server-side caching and other speed-boosting goodies. Early this morning when traffic would be low, I did a test go-live using Cloudflare DNS so I could switch back and forth with minimal propagation delays. Turns out, just switching to the “real” domain so I could take advantage of server-side caching made the load times drop from 6.5 seconds to < 2 seconds!

    I’ve never seen so much improvemment between a dev site and a live site at the real domain on SG before, but this has really made me a believer in their SuperCacher. Anyway, thanks for your suggestions above, and sorry for the needless posts on this issue. . . case closed.

    #1576383
    Jennifer
    Keymaster

    I’m so glad to hear that everything is working well now! Caching can definitely make a difference in site performance, and I’m glad that it was able to solve this issue for you.

    If you run into any other issues, please feel free to open up a new thread!

    Thanks,

    Jennifer

    #1592086
    Support Droid
    Keymaster

    Hey there! This thread has been pretty quiet for the last three weeks, so we’re going to go ahead and close it to avoid confusion with other topics. If you’re still looking for help with this, please do open a new thread, reference this one and we’d be more than happy to continue the conversation over there.

    Thanks so much!
    The Events Calendar Support Team

Viewing 12 posts - 1 through 12 (of 12 total)
  • The topic ‘extremely slow page loads when Events Calendar Pro is in use’ is closed to new replies.