ICS Calendar has been working well for most of its users, but one frequent problem I’ve encountered is caching. If users have a caching plugin installed on their site, especially LiteSpeed, it can be very difficult to get the calendar to update.
ICS Calendar has never used AJAX before now, deliberately. AJAX isn’t bad. After all, this post is all about how I’ve just added it to ICS Calendar! But I think sometimes it is seen as the way to do everything, and it’s not. I think it should only be used when necessary, and up to now, it has not been necessary for ICS Calendar.
AJAX requires frequent communication between the client (web browser) and server. That’s fine when the client has a fast Internet connection, the server isn’t overloaded with traffic, and the amount of data transferred in each AJAX request is small. But if any of those factors falls off, so does performance. In an ideal experience, the user should never see a “spinner,” a visual cue that something is happening behind the scenes.
Because ICS Calendar’s data is all text, the entire calendar is rarely a huge amount of data, even when it has a lot of events. That’s why we just load it all up front, and let the interactions — showing and hiding descriptions, switching between months, etc. — happen entirely in the browser, where there’s no lag.
OK, so that’s why ICS Calendar normally doesn’t use AJAX. What’s a reason why it would, and why am I adding it now?
That’s where caching comes in. Because ICS Calendar’s data is sent as regular old HTML, caching plugins sometimes mistakenly treat its output as static page content. When you update page content that’s actual text in the WordPress database, caching plugins know the page has been changed and will refresh the cache. But since ICS Calendar is retrieving external calendar data, caching plugins have no way of knowing that there’s been an update to the calendar; there’s no corresponding change in the WordPress database.
But caching plugins generally don’t cache anything that gets dynamically inserted into the page by JavaScript, including AJAX. So that’s how my new solution to the caching issue brings AJAX into the picture for ICS Calendar.
Now (as of version 10.3.0), when you add ajax="true" to your shortcode, ICS Calendar won’t insert the entire calendar contents into the page’s HTML. Instead, it just inserts a small placeholder <div&;gt; tag instead. Then, after the page is rendered, AJAX fires off, replacing that <div&;gt; with your calendar. Otherwise, the calendar will look and function just as before.
The benefit here is that the initial HTML output of the page never does change, so caching plugins will handle the page properly. And the AJAX call is outside of the purview of the caching plugin, so ICS Calendar will retrieve the calendar data as it normally would without any caching plugin at all. (ICS Calendar does include its own caching… by default, saving feed data for one hour.)
There’s another use case where the new ajax parameter will be helpful: sites with very large calendars, especially ones that contain a large number of recurring events. Because these calendars can sometimes take a while to parse, and since ICS Calendar normally sends its content as part of the initial response HTML, the page won’t start rendering for the user until parsing is complete. By using ajax="true" in these cases, the entire page can load, and then the calendar will pop into position once it’s ready. This provides a better user experience, and might help with page speed analytics and SEO as well.
Presently this feature is considered “beta,” as I am looking for feedback from users on its performance. It’s not built into ICS Calendar Pro’s Calendar Builder yet, although Pro users can add ajax="true" to their shortcodes, even id-based ones.
ajax Documentation
Support Request Form
—Scott