Exclude pages with forms, carts and checkouts from page caching, or keep saved pages shorter-lived than the form's security token. After any caching change, send a test through every form, then again the next day.

Faster, and then quieter

Since Google's Speed Update arrived in July, plenty of small business sites have switched on caching, through a plugin or the host's server, and pages load noticeably faster.

A week later the contact form has gone quiet. There are no errors in the dashboard and nothing looks broken, only fewer enquiries than usual, then none.

Caching is one of the most effective fixes for a slow site, and one of the easiest ways to break the parts that should differ for every visitor.

What caching does

Without caching, a WordPress site builds every page from scratch for every visit: the server runs PHP, queries the database and assembles the page, which takes time.

Page caching saves the finished page the first time it is built and hands that saved copy to everyone who asks for it afterwards, until the copy expires or somebody clears it.

For a page that is the same for everybody, that is pure gain. For anything that should change from one visitor to the next, the saved copy is a copy of the wrong thing.

What a saved page can get wrong

The first is the one that fails silently. The form looks perfect, accepts every word typed into it, and then refuses the message when the visitor presses send.

The form token that expires

Some WordPress forms include a hidden security token, a code showing that the message came from the form on your page rather than from a program posting straight to the server.

The token is valid for a limited time, often between twelve hours and a day, which is fine when every visitor gets a freshly built page.

A cached page carries the token from the moment it was saved. Kept for a week, that copy hands most visitors a token that has already expired.

The visitor types a whole enquiry, presses send and gets a vague error or a note that the session has expired. Some try again and fail again; others leave, and the business never hears from them.

Carts and anything personal

Stores have more at stake. The small cart in a store's header shows what this visitor has added, and a saved copy can show it to the next visitor too.

Store software sets a cookie when somebody adds an item, and a properly configured cache then stops serving that visitor saved pages. Cart, checkout and account pages should never be cached at all.

A server cache switched on by a host that does not know the site is a store may ignore those signals, which is how one customer's cart can turn up on another customer's screen.

A worked example

An epoxy floor coating contractor in Prince George coats garage floors, workshops and commercial kitchens. Most of its work starts with a quote form asking for the floor's size and condition, with a few photographs.

In July, worried about the Speed Update, the owner installed a caching plugin and switched on every option it offered. The home page went from slow to quick.

Ten days later he noticed that quote requests had stopped. A customer who phoned instead mentioned that the form had shown an error twice.

Whoever maintained the site found two problems. The plugin kept saved pages for a week, so the form's security token had expired on most days. And its option to combine scripts had broken the photo uploader on phones.

The quote and contact pages were excluded from the cache, the form's scripts were left out of the combining, and saved pages now expire twice a day.

The form also stores every submission on the site, so a message survives even if its email goes astray, and somebody sends a test request every Monday morning.

What to leave out of the cache

Most caching tools keep a list of pages they never save. Put every page with a form on it: contact, quote, booking and newsletter sign-up.

Add the cart, checkout and account pages for a store, and any page that shows something personal to a logged-in visitor.

If a form appears on every page, in a sidebar or the footer, excluding pages is not practical.

Instead, make saved pages expire well within the token's lifetime, or have a developer make the form fetch a fresh token as it loads.

Combining and shrinking scripts

Many caching plugins also offer to combine a site's scripts into one file and strip out spaces to make them smaller. It sounds like free speed.

But scripts often depend on loading in a particular order, which combining can change. Form validation, uploads and spam checks are common casualties; the symptom is a send button that does nothing.

Switch these options on one at a time, test the forms after each, and leave out any script that breaks.

Several caches at once

Caching can happen in several places: a plugin, the host's server, a content delivery network sitting between visitors and the server, and the visitor's own browser.

Two or three layers, each keeping its own copy, make stale pages hard to trace: clearing one leaves the others serving the old version. Know which layers your site has and who controls each.

After changing hours or prices, clear every layer, then check the page on a phone over mobile data rather than from the office.

The counter-case

A brochure site with no forms, no store and no logins has little for caching to break, and can cache freely.

Some forms are built to cope, fetching a fresh token as the page loads, and survive any cache. Good hosting often handles the standard exclusions for common store software automatically.

None of this is a reason to avoid caching, which remains one of the best speed improvements available. Cache everything that is the same for everyone, exclude what is not, and test the forms.

After any caching change

  1. Write down every form the site uses.
  2. Exclude form pages from the page cache.
  3. Exclude the cart, checkout and account pages.
  4. Send a test through every form today.
  5. Send another tomorrow, from a phone.
  6. Store submissions on the site as well.
  7. Turn on script combining one option at a time.

Step five catches what step four cannot. A form tested an hour after the change works perfectly because its token is fresh; the failure only appears once the saved page is older than the token.

What cheaper hosting tends to leave out, including help with settings like these, is covered in free hosting bundled with a domain.


Frequently asked questions

Why does caching break contact forms?

Some forms include a hidden security token valid for twelve to twenty-four hours. A cached page keeps serving the old token after it expires, so messages are refused when sent.

Which pages should never be cached?

Pages with forms, the cart, checkout and account pages, and anything personal shown to a logged-in visitor. Everything that is the same for everyone can be cached.

What if my form is on every page?

Then excluding pages is impractical. Keep saved pages shorter-lived than the form's token, or have the form fetch a fresh token as the page loads.

Can caching show customers someone else's cart?

It can, if a server cache ignores the cookie a store sets when something is added. Cart, checkout and account pages should never be cached at all.

Why test the form again the next day?

Because a form tested straight after the change has a fresh token and works. The failure appears only once the saved page is older than the token.

Is combining scripts worth switching on?

Sometimes, but it can change the order scripts load in and break form validation or uploads. Turn options on one at a time, testing forms after each.

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.

Switched on caching this summer?

Ask us to check it. We will test every form, cart and booking page against your cache settings.

Start a Conversation