SPIP : performances

No need for an introduction to Spip. This well known website manager is now used by major actors of the market.

"Usual" ways of optimizing Spip Several methods are already known and documented for getting better spip performances : disabling statistics, simplifying one’s templates if possible, etc..

All these solutions have a limited impact on performances as they don’t change the way spip works : every page is interpreted, and each request generates requests to the SQL database.

This article suggests an original solution letting one maximise performances of their SPIP web site.

Use SPIP for editing your website, and get the performances of a static website

What we like about SPIP is its ease of use and how it respects web standards. Unless dealing with a "special" website (such as online trading, etc.), few webmasters actually need their website accesses to connect to a database server for answering each request. (Or, if they do, that is probably the case for only a few pages on the website). In other words, most websites could run just fine as "static" websites.

To achieve this, one needs to modify slightly their website architecture. Let us define a development server, running Spip, and a production webserver, which is the pubic server, and which content is static. The document attached herein describes this architecture.

This article considers one wants to migrate their Spip production server to a static website, while still using Spip to edit the website.

In all cases, the first thing to do is a complete backup of your website! Of course, all instructions mentionned here come with no warranty of any kind, and you will follow them under your own responsability!

Step zero : set static URLs on SPIP

Spip lets one "emulate" static URLs since version 1.8.X, in a totally transparent way to visitors. Spip’s documentation (in french, contact us if you find translation of that document) show how to achieve this. This is necessary, else the new, static website URLs will differ from the static ones, and will also be pretty ugly.

Step one : duplicate one’s Spip website

Make a copy of your Spip website. This is quite simple : backup existing site’s database, create the new development site (for instance in an Apache VirtualHost, or on another box), et restore the database on that new site from your backup. The new site will now be the non-public development website : Spip administrator (you) and article writers will make modifications on that new website.

On this phase, one must also think of copying their template files, as well as CSS files, to the new development site.

Step two : setup the static website

The great tool named httrack will be used to take a "shot" of one’s development website, and to copy it as static content onto the production server.

To copy one’s website, one will type :

httrack develsite.com -d --connection-per-second=1 --footer ""

One will get from this, locally on the box where httrack was run, a static copy of the devel site.

For those using syndication, also get the backend.php3 file :

wget http://develsite/backend.php3 -q -O -|sed 's/develsitename/productionsitename/' > backend.xml

and add to the .htaccess file :

RewriteRule ^backend\.php3 /backend.xml [L]

At this step, one shall totally erase SPIP from the production website, and copy the static files got from httrack in place of it. Job’s done! Do not forget the CSS files, as well as the non-spip part of the website, if applicable.

’Old’ URLs backward compatibility

If one’s website is referenced on search engines, or bookmarked by visitors, or linked by other sites, on URLs like http://www.mysite.com/article.php3?id_article=... , one will want to maintain a compatibility of the new website with old style URLs. This can be achieved quite easily, using the script available at the bottom of this page.

This shell script, which needs the ’nc’ utility to be installed, allows an easy generation of a .htaccess file redirecting old style URLs to the new ones. You need to edit the script’s few first lines, especially the site to visit. Set that name to your development website. The script is going to visit all possible Spip-style URLs and generate the .htaccess content on standard output. You probably will want to add something like

RewriteEngine On

at the beggining of the generated .htaccess file.

Later updates of the website

All that is needed is to replay the step two when you want to. You production website is easily updated this way.

Limits of this solution

The production site is 100% static : some functions of Spip, such as the integrated search engine, or surveys, will not work on a static website. As these functions are not used by all webmasters, this solution can still be applied to a number of cases.

Benefits of this solution

Before all, this procedure aims at getting more performances from one’s website. If your Spip website is slow and you follow these changes, we feel your website’s performances will get much better : a web server is much much faster at serving plain files than at requesting accesses to databases and interpreting PHP at each request time.

A word on security : this solution can also bring you a huge security benefit : static web content is known to be 100% immune to common web attacks such as SQL injection, PHP vulnerabilities, buffer overflows, etc. If one supposes such vulnerabilities could exist in Spip, or in PHP itself, the static copy is, still, totally secured, by design (and, on the contrary, this would not be the case of the development server, of course).