Increased performance for all websites
- gzip compress files, use either htaccess (quicker) or php (compatable) nb delate is modern gzip
compressing some file types will cause the file to be larger ie PNG as it is already compress - optimize images using Smush IT, makes a big diffference. removes useless data and decreases file size
- gzip output from dynamic sites, using php headers
- minify html by removing white spaces
- aggregate and minify CSS files, gzip output
- aggregate and minify JAVA files, gzip output (not inline as they might be placed there for a reason)
- move Javascript(s) to the bottom of the page, usually just above </body>
- use CSS sprites instead of multiple images, a CSS sprite is where all the images are made in to one and called different
- optimize database via phpmyadmin when nessasary, recommended once a week, select all the joomla tables in the joomla database and then select optimize.
- keep images to a minimum
- dont gzip items more than once in a chain
- have a suitable htaccess, to large and it could slow things down
- disable Etags, unless you actually need them they are a waste of time especially in shared server environments
- make sure google analytics is latest version for speed, use asynchronous version
- make sure all you have the latest version of JAVA and scripts
-
google prefers expires and set to 1 month
-
look at apache redirect and double slash section and make run quicker ie expressions ?*+
(.*) is really hungry
- joomla recommends output buffering is disabled. this most likely creates a performance increase.
caching will increase a users experience but not increase raw speed for intial visits such as google
- set far future expires headers for files, this will tell the browser until the file expires it does not need to re-download, PHP or htaccess. htaccess is quicker
- set far future expires headers for dynamic content, this has to be done by PHP
- recommend lenght for far future is 7 days minimum, this allows you to change in a short time if you need. when set unless the clients browser is purged or runs out of room this header will be obeyed
performance items applied to a joomla setup
see - http://www.joomlaperformance.com/articles/performance/so_you_want_to_speed_up_joomla_3_14.html
- joomla global cache on, 60 mins, set in global config, i am currently trying JOT Caching instead
(this a joomla content cache to hold created content) - page cache on, 60 mins (this a joomla content cache to hold created content)
- all modules should have caching turned on, use global settings (easier to manage later) (this a joomla content cache to hold created content)
- content gzip on, set in global config
- use JFinalizer or JCH Optimizer (currently prefered) for compressing, minimizing and aggregating js and css
- optimize image files with Smush IT, using firebug and YSlow,
- turn on compression of files via htaccess that are not dynamic
- optimize database via phpmyadmin (see notes in above section)
- setup plugin order, can be important, each layer passes process content to the next plugin in the list
- Process all images with Smush IT,
- make sure google analytics is latest version for speed, use asynchronous version
- gzip joomla content see above worth 0.2 - 0.4 on a commercial template and little content, uses PHP
- disable legacy plugin, worth 50ms on code generation with cache on
- optimize database - via phpmyadmin, select all the joomla tables in the joomla database and then select optimize. do this on a regular basis
-
- joomla and jot cache do not store headers
Notes
when stuff doesnt work try this
- JCH optimize can break ajax and javascript stuff
- disabled mootools in template settings (doesnt disable joomlas own mootools, must be standard now)
- excluded mootools.js in jch optimizer and shit works. wonder why it worked before, when you swapp pages ssearch box goes gay, and sh404sef 404 errors happen
- dont minify html when using code snippets
caching
- joomla Far Future Expires Headers plugin, this adds the correct expires headers to
dynamic content (not etags currently), default settings with 1 hour interval, possible 1 week when happy - configure Far Future Expires in htaccess for files, all media files usually. 1 week when happy, longer is better but has issues
NB:
- google only downloads the html part not images etc..#
- large ip block list is worth about 2 seconds
- large ip list can add 1 - 1.5s per page load
- cache + jcoptimiser worth at least 2 secs
- install cache cleaner, not performance related but when you have made the changes this is iunvaluable to save time
- seems best. yoo phoneix with compress and gzip on. no compression on in htaccess. no gzip on in JCH optimiser, cache header plugin on.
- trying to gzip png files increases load time. optimise images instead
- dont gzip content more than once and ir could cause excessive use
To Do - investigate
- yoo login, search css.php needs adding and aggregating
- htaccess slimming down maybe
- yoo search .JS needs aggregating
- somehow make images sprites
- is sh404sef the quickest
- xmap cache ? set to 15 mins for now
- if i turn on main cache yoosearch css goes mental, disbled module cache no will turn on jch minimise css and js
- if i turn main cache on, the 2 x yoo modules search and login ccc.php references dissapear
- mess with the global cache option and the 2 x yoo modules (currently yoo search cache turned off yoologin cached 15 mins)
- add to tickets for jch optimize option of a htaccess compression similiar to jfinalizer. htaccess is quicker. no compression/gzip compatible compression/htaccess compression which also uses real files which is better.
- install the google toolbar with page rank i think deliver page speed information
- turn on global cache set to 60 mins miniumm
- far future headers should be set to 1 week minimum from what i read. will test
These are the headers that are set for the aggregated file:
- Content-type: text/css or text/javascript
- Expires: set in admin
- Last-Modified: set based on the time file was created in cache
- Cache-Control: Public This enables proxy caching
- Vary: Accept-Encoding This allows both gzipped and normal version of the file to be cached
- Content-Encoding: gzip if that option is selected
Performance Page (other notes)
- benchmark site before optimising (YSlow, WebWait.com, JoomlaPerformance.com, WebsiteOptimization.com)
Cache
- read caching tutorial (on wiki)
- enable and configure joomla cache (possibly jot cache) - http://www.theartofjoomla.com/joomla-caching-explained.html
(turned on, either from Global Configuration or enable the "System Cache" Plugin from Plugin Manager. Sometimes enabling Cache does not go well with cyrillics or special characters used) - Turn on page and module caching.
- set HTTP Cache Headers for joomla dynamic content, use "set max-age= , public , must-revalidate" (check the actual function of this as confilcting reslts)(possibly use private on shop sites)
- configure server/file cache via htaccess - http://www.mnot.net/cache_docs/
HTML Output
- CSS, combine, minify and gzip
- Java Script, combine, minify and gzip
- move/defer all Java Script to bottom of the page
- Minify HTML
- Combine background images in to a css sprite
- Make sure there aren't any Javascript issues like duplicate scripts, or clashing javascript frameworks. can cause slow performance
- Enable joomla gzip for HTML output (Site->Global Configuration->Sever->Enable GZip Compression) to test http://www.gidnetwork.com/tools/gzip-test.php
Other
- configure plugin order
- optimize image files using smusit (reduces size)
- remove unused extensions. possibly better to uninstall extension
- Check for leftover database tables of old components or plugins and drop those tables.
- Optimize and repair the database tables. Use PhpMyAdmin for this. Or 'Admin Tools from Akeeba, Databse Optimise Plugin
- Remove/solve 'Not Founds' or '404' errors they have bad effect on speed. The server/ browser is left thinking about how to deal with this missing item
- use optimised template
- Turn off Joomla error reporting off.
- htaccess performance options:
Enable HTTP Cache Headers
Enable gzip options
Disable ETags (for better performance on clustered servers), unless you need them turn them off -
dont gzip jpg and png because it makes them bigger ? (check this)
Which Parameters are Important?
- HTTP requests
- Total size
- Number of HTML / CSS images
- Number of CSS / JS (scripts) files.
- Size of CSS / JS / HTML images.
- Check for duplicate JS files.
- Check for NOT FOUND items.
PHP Compression
compressing a websites output makes the delivery of the content to the browser quicker.
Caching
- The fact is that proxy and browser caches will be used whether you like it or not. If you don’t configure your site to be cached correctly, it will be cached using whatever defaults the cache’s administrator decides upon.
- Validators are very important; if one isn’t present, and there isn’t any freshness information (Expires or Cache-Control) available, caches will not store a representation at all.
- HTTP 1.1 introduced a new class of headers, Cache-Control response headers, to give Web publishers more control over their content, and to address the limitations of Expires.
- ETags are made out of three components: the INode, MTime, and Size.
- Removing ETags & Adding Far Future Expires headers is better. ETags require server responses
- Expires Header - Set a particular time and date when the content will expire, header HTTP date is Greenwich Mean Time (GMT), not local time
- reponse to this is last accessed or lasst modified
- ie server rule 2 weks from last modified, 2 weeks from last acssessed, date this sets the expires header -
Basically most images, css, javascript, and other files can be optimized for faster download by telling your site visitors to cache them for a certain period of time. The default behaviour is to check the last-modified and/or the Etag headers of the file EVERY time it is requested.
-
So a user goes to /home/index.html, and the browser caches all the images and files. Then the user leaves the site and comes back later, and the browser has to send If-Modified-Since conditional GET requests for every cached item, basically to see if the file has been changed and if they should update their cache.
-
Dynamic content cannot be cached via htaccess, ie joomla unless you add the headers to the output via php
-
When files are then cached by your site visitors they do not send the If-Modified-Since until the set cache time has completed.
-
Once an item is cached it will remain cached until it expires or gets revalidated
-
The Expires and cache-control headers can’t be circumvented; unless the cache (either browser or proxy) runs out of room and has to delete the representations
-
the cached copy will be used until then which means less http requests
-
Expires/max-age are superior as they mean there's no need for a request. However, ETag/Last-Modified is still better than nothing.
-
less http requests
-
ETag and Last-Modified headers are on by default
-
BE WARNED. Do not set to long a expire time
-
YSlow has a minimum far future date - to be added here soon i think it is 1 week google is 1 month and wants expires
The Relevant Cache-Control Headers are:
Cache-Control : max-age = [delta-seconds]
Modifies the expiration mechanism, overriding the Expires header. Max-age implies Cache-Control : public.
Cache-Control : public
Indicates that the object may be stored in a cache. This is the default.
Cache-Control : private
Cache-Control : private = [field-name]
Indicates that the object (or specified field) must not be stored in a shared cache and is intended for a single user. It may be stored in a private cache (ie browser cache).
Cache-Control : no-cache
Cache-Control : no-cache = [field-name]
Indicates that the object (or specified field) may be cached, but may not be served to a client unless revalidated with the origin server.
Cache-Control : no-store
Indicates that the item must not be stored in nonvolatile storage, and should be removed as soon as possible from volatile storage.
Cache-Control : no-transform
Proxies may convert data from one storage system to another. This directive indicates that (most of) the response must not be transformed. (The RFC allows for transformation of some fields, even with this header present.)
Cache-Control : must-revalidate
Cache-Control : proxy-revalidate
Forces the proxy to revalidate the page even if the client will accept a stale response. Read the RFC before using these headers, there are restrictions on their use.
Caveats
- HTTP/1.0 has minimal cache control and only understands the Pragma: no-cache header. Caches using HTTP/1.0 will ignore the Expires and Cache-Control headers.
- None of the Cache-Control directives ensure privacy or security of data. The directives "private" and "no-store" assist in privacy and security, but they are not intended to substitute for authentication and encryption.
Notes
-
"max-age" value indicates the time difference (in seconds) after which the content will be expired and reloaded from the server
-
"public" keyword presence indicates that any system along the route may cache the response
-
"must-revalidate" indicates caching systems to obey other header information you may provide at a later time about the cache. This should help preventing stale caching (that is, caching that delivers content that is outdated).
-
by eliminating the Last-Modified and ETags headers, you are eliminating validation requests, leading to a decreased response time. This should work fine in most cases when dealing with static, rarely updated content.
Example 1
http://tutorialpedia.org/tutorials/Apache+enable+file+caching+with+htaccess.html
Example 2
http://linuxdevcenter.com/pub/a/linux/2002/02/28/cachefriendly.html?page=2
-
The reason I remove and disable the ETag is because supposedly some browsers will ignore your Expires header when it’s present:
-
The reason I remove the Last-Modified header is for the same reason:
-
The reason I set the Cache-Control header to ‘public’ is so the browser will cache media over HTTPS (see tip #3):
-
The reason I set the Cache-Control header to ‘no-transform’ is to prevent proxies from modifying my content.
-
Vary: Accept-Encoding response header. This instructs the proxies to cache two versions of the resource: one compressed, and one uncompressed.
Headers
Example
Header unset Server
Header unset Last-Modified
Header unset Date
Header unset Accept-Ranges
Header unset Content-Length
Header unset Keep-Alive
Header unset Connection
Header unset Content-Type
Header unset Cache-Control
Header unset Expires
Header unset Pragma:
When I uncomment my changes, then I get the full header:
HTTP/1.x 200 OK
Date: Wed, 17 Sep 2008 19:37:42 GMT
Server: Apache
Last-Modified: Wed, 17 Sep 2008 15:30:07 GMT
Accept-Ranges: bytes
Content-Length: 58
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html
Last-Modified Header
-
The Last-Modified header allows validation based on the component's timestamp
-
Removing this reduces HTTP requests and disables this type of cache header
-
The most common validator is the time that the document last changed, as communicated in
-
Last-Modified header. When a cache has an representation stored that includes a Last-Modified header,
-
it can use it to ask the server if the representation has changed since the last time it was seen, with an If-Modified-Since request.
-
if this header is present the browser checks back to the server that is has not been changed and then it uses the cached version
Last-Modified and Cache Control (No Expires set, i think)
- Server sends Last-Modified header with datetime value that means the time when content was changed last time.
Cache-Control: must-revalidate
Last-Modified: 15 Sep 2008 17:43:00 GMT - The first header Cache-Control: must-revalidate means that browser must send validation request every time even if there is already cache entry exists for this object. (because no Expires set)
- Browser receives the content and stores it in the cache along with the last modified value. Next time browser will send additional header:
If-Modified-Since: 15 Sep 2008 17:43:00 GMT - This header means that browser has cache entry that was last changed 17:43.
- Then server will compare the time with last modified time of actual content and if it was changed the server will send the whole updated object along with new Last-Modified value.
- If there were no changes since the previous request then there will be short empty-body answer:
HTTP/1.x 304 Not Modified - And browser will use the cached content.
- What if server doesn’t send Cache-Control: must-revalidate? Then modern browsers look at profile setting or decide on their own whether to send conditional request. So we better to send Cache-Control to make sure that browser sends conditional request.
- If we still want Last-Modified header (On its own) for static files and the user presses Refresh button, then the browser will send conditional request and the server will respond
“304 Not Modified”. - If you disable both Last-Modified and ETag browser will have to download the whole content again when user presses Refresh.
Etags
- The problem with ETags is that they typically are constructed using attributes that make them unique to
- a specific server hosting a site (maybe a specific inode). ETags won't match when a browser gets the original component from one
- server and later tries to validate that component on a different server, a situation that is all too common
- on Web sites that use a cluster of servers to handle requests. ie SHARED HOSTS (or load balanced servers where they do not sync etag data)
- If you're not taking advantage of the flexible validation model that ETags provide, it's better to just remove the ETag altogether
- Remove Etag headers for better performance on clustered servers, and if using joomla because of dynamic content
- Removing the ETag reduces the size of the HTTP headers in both the response and subsequent requests
- By removing the ETag header, you disable caches and browsers from being able to validate files, so they are forced to rely on your Cache-Control and Expires header.