Plone, like any content management system, has slower page load speeds than static pages. Ensuring a fast enough page load speed so users won’t get turned off is therefore a big concern of Plone site maintainers. Here are some tips:
1. Avoid missing page components
If a part of a page (most commonly an image) returns a 404 or 301, it can slow down the page to more than half the speed. No matter what one does on system level you cannot make up for that kind of speed loss.
301 errors are particularly tricky since it is basically a bad link, but some code (most probably RedirectionTool) finds the requested object somewhere else and redirects the original request to the correct url. The url is served correctly, but that 301 makes the page load slow.
Actually the standard use of RedirectionTool (aliases) has the same effect, so it should be used just temporarily.
The Tamper Data extension (https://addons.mozilla.org/firefox/966/) to Firefox is a great tool because it allows you to quickly inspect headers of all the page components, not only the page itself. After installation, you will be requested to close the browser completely and start it again. Now Open Tamper Data from Tools menu in Firefox, and open a page you want to check out in Firefox. You can now see that Tamper Data window is being populated. Each line is one individual component of the requested page that has to be loaded in order to render the page. The most important column for us
is "Status". We are looking for 404 and 301 errors. 200 means you accessed site content without error and 304 means your local content is the same as in the squid, which is even better.
2. Page content – sometimes less is more
A page with twice as much content will most probably load two times slowly. Understandably that we want put as much possible into every page, but quite often less is more. Things that have to be generated by Zope (smart folders ect) will obviously take longer to load than static content
3. Caching
Most speed improvement on a system level involves caching – storing site content in easily accessible areas. Most large sites run a proxy cache like squid to serve up static content and keep Zope from doing the work. Other static content is cached in the browser itself. The most import thing is to make sure all pages and their components have correct caching headers; this is done by the CacheFu product, which now ships with Plone.
The whole plone caching business is described in http://plone.org/events/regional/nola06/collateral/make-plone-go-fast.pdf and CacheFu product documentation.
Obviously, any caching issue we fix has a double effect. The page is served from cache much faster and it does not create any load on zope server. Then the pages that have to be served by zope (cache refresh, editors) are much faster.
Another crucial point is to evaluate any new feature or product we are going to use from the caching and performance perspectives. Then we should document what adjustments have to be done when a product or a feature is deployed on a particular site. For instance if EasyBlog is installed on a site, the CacheFu will have to be set; if sdot is installed, the CacheFu will have to be set and icon image will have to be created, etc.
(Thanks to Atmasamarpan for all his help with this article)