This tip assumes you have access to your web server to allow creating subdomains, and for optimal results, permissions to alter the httpd.include apache configuration file.
Why?
Google provides a handy Firebug extension, Page Speed, which examines a web page and provides various tips and tools for speeding up the serving and rendering of a website. Some of those methods involve serving static files (such as images, css and JavaScript) from different domains than the html page. The advantages being:
- A modern browser by default downloads 2 files per domain at the same, but can also download 2 files for another domain simultaneously, and 2 for another domain, and so on. It’s known as parallelisation.
- There is a good chance your main domain has cookies assigned to it, for example if you use Google Analytics then it sets it’s own cookies. On every asset download (html, image, etc) it adds the cookie, adding a bit of latency to the download. A cookieless subdomain will not have this issue (if you use Google Analytics you need to change the default configuration to specifically target only the www domain
'_setDomainName','www.example.com'
otherwise it will apply it’s cookies to subdomains too (because the default GA setup is'_setDomainName','.example.com'
).
OK, we know the theory, now lets look at the execution. The next 2 methods are independent of each other – if you have no access to editing the apache config files and don’t feel confident changing potentially site-breaking stuff, then you can use method 1 which gives partial speed benefits. If you have the ability to alter apache configs then use method 2.
How? Method 1 – Partial serving of static content (non TXP content) from 1 subdomain
This is the simple and potentially less risky method. First create a subdomain such as static.example.com
.
Move all your current static (non TXP managed) files such as css, scripts and site styling images (ie. ones not in Textpattern) to the subdomain – might be worth following the directory structure you previously had on the main domain, so create an images directory, js directory and css directory on the subdomain (or whatever naming methods you use) and place each file in its corresponding place.
Go through all your Textpattern pages and forms (and any static pages) and change the paths of these assets to their new domain (so http://www.example.com/images/header.png
becomes http://static.example.com/images/header.png
). Remember that if you used absolute or relative paths for these assets before (such as /images/header.png
or ../images/header.png
) you need to change them to the full path. Be careful to check any JavaScript too for absolute paths or relative paths and change accordingly.
Congratulations, you now have a speedier website – check your page speed rating with the Google Pagespeed firebug extensions for more speed tips.
How? Method 2 – Serving all static content from one or more virtual subdomains
This is the method I use, as it means you can leave all you files where they currently are (on the main domain) and simply fool the browser into loading them via the subdomains (and take advantage of parallelisation and ‘cookielessness’). Use this method if you have access to the apache config files and only if you are confident in amending them, as this can quite easily break a site.
First, you need to set up at least one subdomain, I personally use 2 subdomains, static1.example.com
and static2.example.com
(you can in theory use any number of subdomains but it seems that parallelisation is adversely affected once you go past about 4 domains (so 8 simultaneous files downloading at once).
Now edit your apache file for the domain (usually there is a httpd.include
file per hostname which you will edit instead of the main httpd.conf
file). Remember to make a backup of the original file just in case things go awry!
Within each subdomains’ blocks of code, there will be a DocumentRoot
line, which you’ll need to repoint back to your main domain.
For example (your setup might be different),:
DocumentRoot /var/www/vhosts/example.com/subdomains/files/httpdocs
Change to:
DocumentRoot /var/www/vhosts/example.com/httpdocs
That means that although the browser URL is pointing to the subdomain, apache is then rerouting back to the main domain. Remember to restart apache for the changes to be loaded). Side note: I have Plesk running on my server which annoyingly seems to rewrite the httpd.include files if you upgrade the Plesk software. So take a backup of this file and if you do at any time upgrade Plesk, simply place you backup httpd.include back over the rewritten one (and restart apache).
Go through all your Textpattern pages and forms (and any static pages) and change the paths of all your current static (non TXP managed) files such as css, scripts and site styling images (ie. ones not in Textpattern) to the new subdomains (so http://www.example.com/images/non-cms/header.png
becomes http://static2.example.com/images/non-cms/header.png
). Because you are using these ‘virtual’ subdomains you can mix and match which files are ‘static1’ and ‘static2’ but as a general rule I make all non-Textpattern based static assets ‘static2’ and reserve ‘static1’ for Textpattern-based images (which I’ll cover in the next paragraph). Remember that if you used absolute or relative paths for these assets before (such as /images/header.png
or ../images/header.png
) you need to change them to the full path. Be careful to check any JavaScript too for absolute paths or relative paths and change accordingly.
Now for the Textpattern images – TXP 4.3.0 introduced a new configuration constant ihu
in config.php
– ihu, which is used to repoint where it serves images from. Uncomment the line and make it:
define('ihu', 'http://static1.example.com/')
Now all your Textpattern based images will be served from the subdomain ‘static1’, but of course they are actually still residing in your main domain.
Congratulations, you now have a speedier website – check your page speed rating with the Google Pagespeed firebug extensions for more speed tips to make your site really zippy.
Final notes
You may wonder why we have to set up ‘virtual’ subdomains for method 2, why can’t we just physically move all these files actually into the subdomains? Well, although the ihu definition can be set, images uploading to Textpattern are always uploaded to the domain where the Textpattern install resides – you cannot make Textpattern upload images directly to a subdomain.
The above tutorial covers changing an apache file to repoint subdomains to the main domain, but you could in theory use other methods to achieve this, which each have their own benefits/drawbacks.
If you use Ruud’s rvm_css plugin (which uses a ‘css’ folder by default) you can do this:
ln -s /home/hostuser/public_html/mysite.com/css /home/hostuser/public_html/mysite.com/style
This creates a symbolic link from the style subdomain to the css folder. So you can use
<link rel="stylesheet" href="http://style.mysite.com/css/screen.css" media="screen" />
in your pages. This allows you to still edit your css in txp admin where it is automatically saved to the css folder as a static file, so saving some ftping.(There may be variations in making the symbolic link depending on your host. For example it might be:
ln -s /home/hostuser/mysite.com/public_html/css /home/hostuser/style.mysite.com/public_html/style
or something)You could also use a symbolic link from subdomain img.mysite.com to mysite.com/images and use the ihu thing in config.php instead of changing the DocumentRoot although I have no idea if this affects anything speedwise.
Joebaich points out that you can also use the following method to restrict Google Analytics to your main domain…
Useful if you use http://example.com as your domain name (instead of the www. prefix).
What exactly does
ihu
influence? Only files with a certain extension or from a specific directory? How can I include my CSS or Javascripts as well?Stephan, there’s probably more to it, but if you look in txp 4.3.0 config.php, at the end, you will see it is for serving images
Thanks for this TXP tips. This is very handy. I haven’t yet checked how much this will improve loading speed, but any increase in performance is good.
(Article’s Author link to Twitter page doesn’t work.)
@Petri – thanks for letting me know about the URL not working. Fixed now.
Sorry! I need to be a little harsh/direct here …
I’ve seen a number of posts promoting this technique regarding Google Analytics cookies.
It’s dangerous.
The _setDomainName method is to configure the way Google Analytics functions – this is not a “pick a folder” type setting that merely informs GA where to write the cookies.
More GA problems relate to the (mis-)use of _setDomainName than any other.
See
Tips Tricks, Traps and Tools: # 3 of many: Quick Diagnostics
Search the page for “_setDomainName” to get right to the nub.
There are also other posts relating to that topic linked there.
Brian Katz – Analytics – VKI