Recently we received a call for help. The client had produced a new website that was great to look at, packed with fresh content and ready to launch. There was just one problem, performance.
Some pages, in particular those driven by Views that were returning a large amount of data, were taking way too long to load. Interestingly the client had found that enabling page caching was not helping, yet enabling Views caching did help, a lot.
This observation led us to believe that something was telling Drupal that it should not cache pages. So over an IRC session we asked the client to search their module directory, usually found at sites/all/modules, for this: drupal_page_is_cacheable
Our rationale was that this function allows code to tell Drupal that a page should not be cached, our guess was that there was either a contrib module or a custom module that was calling this code. If we could find that module then we can find some way of re-configuring their Drupal install so that page caching would work again.
Note: It is also worth searching for this, which does the same thing: $GLOBALS['conf']['cache'] = 0;
Low and behold, we got a hit. The Honeypot module was installed to protect their contact forms against spam. The Honeypot module comes with a function that can embed a timestamp into a form in order to detect whether a form has been submitted quicker than we might expect a human to complete a form, in which case it is treated as a spam submission. Clearly, in order to embed a fresh timestamp the page can not be cached, so the module disables page caching while altering a form that will use Honeypot's timestamp protection.
The timestamp protection is a neat idea, but clearly is not suited to every use case. The Honeypot module authors foresaw this issue and so they have made it a configurable setting so that the website owner can turn it off in order to preserve page caching.
Getting back to our client, on the footer of every page there was a button to show the contact form in an overlay. Their Honeypot configuration was using the timestamp approach so every page was being marked as being non-cacheable.
The solutions here were actually quite straight forward once the problem had been identified:
- Alter the Honeypot configuration so that timestamp checks are not made
- Move the contact form so it launches in a new tab rather than in an overlay
- Keep the contact in an overlay but load it dynamically, for example using an iframe or AJAX
On this occasion the solution that was chosen was to disable timestamp protection on the Honeypot module config page: admin/config/content/honeypot
Now this client has launched their website and it is great to look at, packed with fresh content and loads lightning quick.
If you have got any pages that load really slowly, why not let us take a look at them?
- Log in to post comments