PriMoThemes — now s2Member® (official notice)

This is now a very OLD forum system. It's in READ-ONLY mode.
All community interaction now occurs at WP Sharks™. See: new forums @ WP Sharks™

Cache expiration best practice

Quick Cache Plugin. Speeds up WordPress®.

Cache expiration best practice

Postby WhiskeyJim » December 1st, 2010, 11:05 am

Can someone help me think through cache expiration times?

The purported best practice is 1 hour. Elsewhere, the recommendation is 1 day. Given the incredible speed difference in delivering a cached page, 1 hour drastically increases the chance that an uncached page is delivered, not to mention unnecessarily working the servers in the case of auto-caching.

What is wrong with the following thinking?

First, if I change the theme or add a widget or otherwise make a site wide change, the entire cache is cleared. So none of those macro events have any bearing on cache expiration settings.

Second, if a page is changed via edit or comment, Quickcache will re-cache the page and the front page. Dandy.

So why would I not set the cache expiration for say, at least a week? Heck, why not 2 or 3 weeks, along with the auto-cache feature?

The issues remain at least two.
First, widgets like related posts that change their behavior based on new posts would not update on unaffected pages until expiration. That may or may not be of any real concern. Perhaps a happy medium of 1 week would be better, given that the front page is still refreshed.

Second, depending on theme design, pages with category sub-menus, etc. would not update. Large magazine sites or CMS's with whole pages dedicated to category links are good examples. For those sites, 2 or 3 weeks is too long. But remember, Quickcache can be told not to cache those pages; just tell it to avoid those URI patterns.

In the cases above, there are still options without resetting the whole cache of hundreds and hundreds of pages. One alternative would be to edit the affected menu page (assuming it does not have a unique URI template) triggering the cache to re-write that single page.

The other alternative Jason would need to help with. And that is to allow further entry of pages in the cache pruning section of the cache. Then users could decide which pages to re-cache when edits and additions are made to the site.

Now that I have found a great web host, the servers and Quickcache deliver pages in about 1.5 seconds. Wow that is fast. Remember that Quickcache begins delivering the page much sooner than that, appearing almost instantaneous. Uncached pages are serving up at about 3 seconds. That difference is huge to me, and I believe to many readers; one seems immediate, the other has a slight delay.

So I have set cache expiration for a week; IMHO belated widget updates are not as important as blinding speed. As in most things in life (cars, work), speed makes all the difference.
User avatar
WhiskeyJim
Registered User
Registered User
 
Posts: 4
Joined: November 30, 2010

Re: Cache expiration best practice

Postby dozarte » December 15th, 2010, 12:47 pm

For related posts menu: use a javascript widget connected to your rss feed; remember to disable feed caching.

For menus: I use iframes to load external files that shows the menus.
User avatar
dozarte
Registered User
Registered User
 
Posts: 33
Joined: July 24, 2010


Return to Quick Cache Plugin

Who is online

Users browsing this forum: No registered users and 1 guest

cron