|
|
Posted by Alan J. Flavell on 09/05/05 22:36
On Mon, 5 Sep 2005, Toby Inkster wrote:
> My general technique is that each page looks like this:
>
> <?php
> $title="My page";
> include "inc_top.php";
Have you thought about cacheability? ...
> The "inc_top.php" file opens a PHP session (if I'm using them), checks
> authorisation details associated with the session and page, does the HTTP
> header stuff,
.... then perhaps you have. Could you be a bit more explicit about the
HTTP bit, please?
As you might gather, cacheability is one of my pet topics, and I'm
concerned that all too many pages on the web appear to be dynamic (due to
the use of SSI, ASP, PHP or whatever) when in fact their components hardly
change from one month to the next. The result can be sluggish browser
response, with or without an intermediate web cache.
For anyone who cares to take an interest in this topic, I'd recommend my
favourite tutorial - admittedly it concentrates on shared web cache
servers, but the ideas that it promotes are good for browser cacheing too.
Mark Nottingham, http://www.mnot.net/cache_docs/
(And don't miss his cacheability engine - it showed up some significant
mistakes on our own official site, I can tell you.)
all the best
p.s as an alternative to these server-time dynamics, there's something to
be said for building static pages, as part of one's procedure for
publishing content to the web server. The "make" command - normally
regarded as a programming tool - can handle this kind of job too: via the
Makefile it gets told which web pages depend on which components, and then
when anything changes, a "make" command re-publishes all the pages which
depend on changed components. The server will then be in a position,
thanks to the static pages, to serve out proper cacheability indicators
such as ETag, size, and genuine last-changed date/time.
Navigation:
[Reply to this message]
|