Internet browser Safari has long been known for trying to make the web faster and faster. One of the ways it’s done so is by having a very strong browser cache – storing pages and files locally for as long as possible.

Whether Safari has the best caching amongst modern browsers or the worst is unclear. Perhaps it’s the nit-picker and is the only one which adheres 100% to HTTP conventions and rules. This has doubtlessly been worked on over and over again at Apple, as the Safari browser is built into iOS devices and so performance is critical.

For example, say that the TYPO3 CMS (v6.2) sends a page to the browser along with the default HTTP headers. The website visitor loads this page in the browser, then moves on around other pages in the website. The server has told the browser that these pages are set to expire in 24 hours, so Safari stores them in its local cache.

Then the visitor logs in, whereafter a new menu entry should appear on each page for a protected area of the website. If the visitor then returns to a page which he viewed within the past 24 hours but before he logged in, Safari draws that page from the cache. So the additional menu entry isn’t there. Clicking “reload” in the browser will tell it to go to the server and get it again, with the new menu entry… but that’s not a common (or correct) interaction.

The correct way to handle this if your TYPO3 website contains sections which are only available when a user is logged in (or logged out) is to stop TYPO3 from sending the usual Last Modified and Expires headers with each page request. This will make the browser contact the server each time for the HTML page, whereupon TYPO3 can serve the most current – and preferably server-cached – version of the page. This slows down each HTTP request for the HTML page, but tests show that from my usual shared hosting server, the difference is only around 100ms per page. Unless your website is serving thousands and thousands of pages per hour, this is within acceptable limits.

Static files (which are served directly from the webserver, such as Apache) are not served through TYPO3 and so they get stored in the browser cache as usual. TYPO3 only controls the HTTP headers of requests it answers itself. That means that the overall response time of an average page isn’t noticeably different, as most assets – images, static JavaScripts and CSS – aren’t affected.

The simply setting to achieve this is placed in the setup section of your TypoScript configuration and is documented in the TYPO3.org TypoScript reference:

config.sendCacheHeaders = 0

A final note: if your website content is “static” – i.e. doesn’t depend on whether a visitor is logged in or not – then omit this definition, so that it can work as fast as possible.

Leave a Reply

Your email address will not be published. Required fields are marked *

For security, use of Google’s reCAPTCHA service is required which is subject to the Google Privacy Policy and Terms of Use.

This site uses Akismet to reduce spam. Learn how your comment data is processed.