A feature I remember back from the days of the UBB 5 system was that it would create static html pages and re-direct you to them when necessary for topics and forums. This made the forum very fast as it only had to put a topic together once until some changes were made.

The down side is that it would take up more space on the web server - which shouldn't be too much.

With the right algorithms for this, done the right way, it could really make a difference in speed on large, popular sites.

Either way, would be worth experimenting, eh?

For sure, we know about that :) Static HTML in any way is faster that any database, because HTML server was created to display these pages. If we talk about miniBB... I guess, we will *ignore* this feature for this time. There could be a way to generate static HTML of course, and catch cached pages on the fly... For sure, worth of thinking, but later...

I had a idea that html pages could use a serial number similar to dns zone files.
The reason for this is that when someone visits a page there browser could store the page in a cache with the serial number.
If the page is visited again whilst the page is still cached and the serial number has not changed the page could be loaded from the cache instead of downloading it again to save time.
Does anyone have any suggestions or comments regarding this.

Thanks Kirk

?

I don't understand why DNS in general matters here.

Cache operations done by most browsers automatically (or, for example, you can force storing in cache via meta tag, <META NAME="Document-state" CONTENT="Static">, or via another tag).

FOR SURE, you CAN NOT handle browser cache operations using HTML, or JavaScript and specially server side script.

Sorry to bump such an old thread but I really think such a feature will be very useful for busy boards.

It all should be build on the server side. There are many technologies for servers which will make caching like this, and if you are running big projects, you can't run them on the shared hosting for sure. It must be your own dedicated, configured to your own needs server. It's not the question related to miniBB at all, and we will not invent the bicycle with PHP/mySQL scripting in this area. It has no sense.

Wordpress has a Cache plugin and so does vBulletin. I believe you are talking of more serious stuff like PHP Accelerator or memcache.

From a flowchart perspective, here's how it might work:

1. Create a cache (html pages) of all the forum pages in a directory say "cache".

2. Whenever a thread is updated, update it's cache in "cache" directory.

3. While accessing a page, check if cache exists. If it exists, serve it, else load dynamic page, create a cache.

I don't know what kind of "cache" plugins these software companies have, but I'm sure it's more for their public relations, not a real perspective. The real thing is behind a physical server only.

What you suggest would work only for guests anyway, and only if you don't have a lot of dynamic stuff on forums. But All PHP scripts are dynamic. miniBB itself is a very dynamic script. And if we talk about vBulletin... they even parse all BB-codes on-the-fly. Of course, some way they would need the script which "caches" themselves. But miniBB is very well cached itself in that case. Everything we could store static way, is already stored.

Some of the elements can't be stored at all.

Let's take Who's online module - it changes all the time, you can't store it in cache. That means, any page it is displayed on, can't be contently cached.

When you are logged in, on forum there appear different links ("Edit", "Move"), some new options (reply/new topic forms) and so on. They all depends on WHO is logged in - administrator, or moderator, or a regular user, or if nobody is logged in at all. If you use Signatures add-on, and if the user changes a Signature, that means, all older cached won't work anymore.

I know very well how Caching works and what it means from the perspective of PHP scripts. So... once again, we don't need this for miniBB. What we can optimize, is already optimized. If your Pentium IV server on CentOS works slowly with 400 visitors per second, not a wonder. Upgrade the hardware of the server. Upgrade the software on the server. Optimize the server itself. Purchase dedicated server. Rent a Cloud at least. Cache won't help you in that case.

OK Paul I get it.