Datasheet - Sitekit CMS Performance Tips

Datasheet - Sitekit CMS Performance Tips Document Control Address Document Title Version Number 3.1 Document Status Approved Version 3.0 Approved By Author Sitekit Team Operations Centre Bloxham Mill Barford Road Banbury Oxfordshire 0X15 4FF Datasheet - Sitekit CMS Performance Tips Approved David Morgan David Morgan Support-Services Created 06/09/2012 Last Modified 06/09/2012 Document ID Publisher Rights SKDOC-7-248 2012 Sitekit Solutions This document is uncontrolled when printed Development Centre Sitekit House Broom Place Portree Isle of Skye IV51 9HL

Datasheet - Sitekit CMS Performance Tips Table of Contents 1.0 Introduction... 3 2.0 Performance Testing... 3 3.0 Browser Caching... 3 4.0 Image Handling... 6 5.0 Minification... 7 6.0 Aggregating JavaScript files... 7 7.0 Optimizing Style and Script Order... 8 8.0 Deferred Loading of JavaScript files... 8 9.0 Externalizing JavaScript references, such as the jquery Library... 9 10.0 Parallelize Downloads... 9 11.0 Avoiding Bad Requests... 10 12.0 Avoid CSS Expressions... 10 13.0 CSS Sprites... 10 14.0 Specifying a Character set... 11 15.0 Future Sitekit Enhancements... 11 Last Modified: 06/09/2012 Title: Datasheet - Sitekit CMS Performance Tips Page: 2 of 12

1.0 Introduction Is your site as fast as it could be? If it s not, then you have three major problems. 1. You re paying too much money to Sitekit for bandwidth usage. 2. You re losing visitors, as they gradually drop dead from boredom or old age while waiting for one of your pages to download. 3. Your Google Site Ranking is lower than in need be, because Google takes page speed into account when deciding site rankings. Regular performance testing can identify any speed problems you might be suffering. Then it s up to you to solve them. These tips may help. 2.0 Performance Testing Probably the easiest way to test your site is to check it with an online test tool, such as Google Page-Speed, or Yahoo YSlow. Page-Speed is available as a browser extension for Chrome and Firefox. It enables web developers and administrators to quickly analyse the performance of their pages, and offers specific suggestions on how to optimize any weak areas. It gives each tested page a score of between 1 and 100, with 100 being considered perfect. Google preferentially rank sites according to their performance as measured by their own Page-Speed criteria so it s important to make sure your sites have a high rating. Following the tips in this article (if you re not already doing them) can easily add 10 points to your Google Page Speed rating. Yahooo YSlow is available as a browser extension for Firefox, and works in conjunction with the Firefox Firebug extension. It also works (with slight limitations) in Chrome, Opera and Safari. Like Page-Speed, YSlow analyses a selected page against a set of best practice rules, assigning an A to F rating for each of twenty three testable features. It also produces a handy pie chart, comparing cached and un-cached page weight. Both tools are free, extremely easy to use and offer detailed suggestions for improvements. They use different sets of Best Practise criteria, so when testing a page it s best to run them both, to get as broad an analysis as possible. Generally speaking, their advice can be summed up as Compress files, Reduce HTTP Requests, and Cache resources efficiently. The rest of this article describes ways to achieve these aims in Sitekit CMS. Each tip is given a general rating of *** for very Important, ** for moderately important, and * for less important. These ratings are, of course, generalisations, and in some cases a lower-ranked tip may be more beneficial than a higher-ranked tip. Last Modified: 06/09/2012 Title: Datasheet - Sitekit CMS Performance Tips Page: 3 of 12

3.0 Browser Caching *** The single most important thing you can do improve the performance of your Sitekit web site is to make sure that resources are placed in the right Asset Classes, and that Asset Class caching is set efficiently. Browser caching can easily cut download time in half for your returning visitors. For example, at the time of writing this article the Sitekit Home Page has a page-weight of 744k for a new visitor, and just 69k for a returning visitor a bandwidth saving of 90%. So it s essential that you understand how Sitekit Caching works, and then use it to its best advantage. Sitekit Caching is set at the Asset Class Level, not the individual component level, so to make best use of caching you must be careful to place components in the right Asset Class. Static components such as background images and small graphics such as buttons that make up the site s design, will rarely change. So they should be placed in an Asset Class which has been set to a one-year cache (525, 600 minutes the default cache size used by Sitekit CMS). Images used in Sitekit Content and Page Layouts are good candidates for a one-year cache. Note that it is not good practise to set a cache for longer than one year. Most Images should be put in Image Asset Classes - again set to a one year cache since the majority of images on a web page will never be updated they ll just be displayed until they re out of date, and then replaced with new images with new names. Only in situations where a graphic is likely to be changed during its lifetime should you consider placing it in an Asset Class with either a short-duration cache, or an Expires After period of -1. You should always make sure that editors are using the right Asset Class for the job. For example, it would be reasonable to place the Annual Company Report file in an Asset Class of download files with a cache of one year. But you would NOT want to place a downloadable Price List in this Asset Class. The Price List belongs in an Asset Class which has an Expires After value of -1, ensuring that a visitor always views the up-to-date version. The Sitekit Asset Class caching options are described below. You can access them by right-clicking on an Asset in the Asset Tree, then selecting Edit Permissions. 3.1 Includes Expires Header and Expires After When you check this box and select a Cache period, every asset belonging to this class will include a HTTP header telling the browser that it does not need to get a fresh copy the server until that date/time is reached. Last Modified: 06/09/2012 Title: Datasheet - Sitekit CMS Performance Tips Page: 4 of 12

So if a first-time visitor visits your site at 9 am on 31/10/10, and then downloads an image with a one year cache setting, the visitor s browser will store a copy of that image marked with an expiry date of 9 am 31/10/11. On subsequent visits to your site, if the date-time is less than 9 am 31/10/11, then the browser will use the locally cached image instead of downloading another copy of the image from the server. This is a very fast, since once an asset has been cached the browser doesn t need to download it again, nor even send a request for information to the server. If the cached version is still within date, then the browser may ignore the Include Last Mod setting described below, since it already has the information it needs. This behaviour is not mandated, so it may vary from browser to browser. 3.2 Leave the Expires Period Blank? If you want to place a no cache period on an Asset Class, then it is not a good idea to leave the Expires After period blank. Instead you should enter a value of -1. When no value is set, browsers are free to interpret this however they like, and they ll probably cache the asset for some default- and variable - period of time. So by leaving this value blank you are relinquishing control to the browser. 3.3 Include Last Mod Adds the HTTP Last Modified header to the asset. This holds the date and time upon which the asset was originally created or last modified. If this box is checked, whenever the browser has an out-of-date cached version of an asset it will send an if modified since request to the Server. The server will respond with either a not modified reply (telling the browser to use its cached version) or by sending the asset itself (if it has been modified, and hence needs to be replaced). 3.4 Preventing a Browser from Caching files In some cases you may wish to make sure that a visitor s browser does not cache an asset. For example, you may have a page which contains a data island with up-to-the-minute information, and you don t want a visitor to have a cached copy which will prevent them seeing the latest version. You can achieve this by creating an Asset Class which has the Includes Expired Header box checked, and a period of -1 in the Expires After field. This tells the browser that the asset expired as soon as it was requested. 3.5 Data Islands Data Islands have their own Header Cache. Feeds that produced the XML for data islands can involve a lot of processing and, therefore, there can be a long delay from requesting the feed and receiving the XML from the server. Data Island caching allows the resultant XML from the feed to be saved for a given period of time, so that subsequent requests can use the same, saved copy of the XML rather than requesting the feed again from the server. If the data island is on a popular page, that receives a lot of visitors, this will significantly increase the performance. 3.6 Overriding Browser Caches with File Name Fingerprinting Once a file has been stored on a visitor s cache, you have no control over it. It ll stay there until the visitor clears the cache themselves, or the file becomes outdated. Normally this is exactly what you want to happen. But sometimes you need to replace the file - perhaps you discovered an error in your JavaScript, updated a style sheet, or changed the graphics on your home page. Fortunately there s a simple way to force the browser to ignore the old copy. You just change the file name of the resource, forcing the browser to download the new version. This is generally referred to as fingerprinting the file. Last Modified: 06/09/2012 Title: Datasheet - Sitekit CMS Performance Tips Page: 5 of 12

JavaScript and CSS library managers typically add an automatic version number as part of the file name, so if you use these tools to load scripts into Sitekit you have no problem. But if you modify the files directly in Sitekit (or upload a new image over the top of an old one, keeping the original name), then remember to consider the implications of browser caching, and change the file name if necessary. 3.7 Important notes on Sitekit caching You should not modify the Advanced HTTP Header Cache Control settings in an Assert Class unless you have a good reason to do so, and a full understanding of the implications. Using the right settings will significantly speed up your site. But using the wrong settings may significantly slow down your site, and worse still, present visitors with outdated information. Remember that Caching is set for every asset in an asset class! Modify the caching header for one item in a class, and you modify the cache for every item in that class. (Setting the cache for individual items would be impossibly tedious and error-prone. Imaging having to do it for every graphic on your site, one by one ). 4.0 Image Handling *** Once browser caching is optimised, proper image handling is the most effective way to speed up the average web page. Image handling involves three things - picking the right image format, sizing it correctly, and then compressing it efficiently. 4.1 Picking the right image type Three image types are best for web pages. GIF The image is saved as a bitmap - a pixel grid. Although GIFs support 256 colours, they re best used with four colours or less, for icons, bullets, buttons, and simple charts. PNG Another bit-mapped format, PNG is an improved version of GIF, but able to support many more colours, so good for screen-shots, complex multi-colour charts, and other graphics. A good format but be aware that older versions of Internet Explorer do not fully support.png. JPEG - Used for photographs things with complex shading and potentially millions of colours. JPEGs are not transparent, so they totally obscure the background they re placed on. JPEGs can be heavily compressed, at the cost of image quality. 4.2 Compressing Images This is generally a two-step process. First you should use your normal imaging software to save a reasonably compressed version of the image. Obviously there is no point in displaying a picture in photographic quality when it is going to be displayed on a monitor with a limited number of pixels. Nor is there any point storing a threecolour chart in a million different and unused - colours. Secondly, be aware that even sophisticated tools like Photoshop and Fireworks using save for web options still leave a lot of metadata in an image, which isn t at all useful to your visitors. So you should use an image compressing package which removes this unnecessary information without reducing picture quality. There are many image compression tools that you can use, but the Yahoo smush.it service is well worth trying. The smush.it service is an excellent way of compressing image files. It s quick, easy, and free. Simply upload an image and smush.it will try to compress it, using various lossless compression routines. If the compressed version is significantly smaller than the original, download it and use it on your web site. Or you can point smush.it at a web page, and it will produce a zip file containing compressed versions of all the images on that page. Useful for remedial action, if you think some of your old pages may have uncompressed images. 4.3 Sizing Images It is pointless to store a large image on your web page, if you re just going to crop the image when it s displayed. Best to size the image correctly in the first place. If you are going to display a picture as 150px by 150px, then save it as that size. If you re going to display the same image on a page in different sizes, then save the largest size needed. Last Modified: 06/09/2012 Title: Datasheet - Sitekit CMS Performance Tips Page: 6 of 12

5.0 Minification ** Minification is the process of removing unnecessary characters from source code - such as white space, comments, new line characters, and block delimiters. Minification can reduce CSS, HTML and JavaScript files by 50%. The difference between minification and compression is that a minified file can be interpreted immediately it doesn t need to be decompressed before use. In Sitekit CMS, minification of CSS files is automatic, activated by a site setting which toggles minification on and off. The only reason a site would have this switched to off would be for development and debugging purposes. The graphic below shows the Minify Check Box, located via the Admin Configure Tab, selecting Site Settings and then General Site Settings. If your site is live, then make sure this option is checked. JavaScript is not automatically minified by Sitekit, and in fact it s unhelpful during site development and testing. But once a site is up and running Sitekit recommends that you minify these files. There are a large number of tools available to minify JavaScript. Tools such as JSCompress.com offer a free minification service which can minify JavaScript files in a few seconds, free of charge. Some tools offer obfuscation as an option, if you want to protect some nifty JavaScript you ve written. One approach taken at Sitekit is to aggregate all the JavaScript used on a site into a single file, minify it, then refer to the script from all pages via a <VARIABLEBLOCK> section positioned at the bottom of the page layout so that the page is rendered and quickly available to the visitor - without being delayed while the JavaScript is parsed. If you minify JavaScript files, it is important to keep a library of the original files! Trying to maintain a minified file is not fun. 6.0 Aggregating JavaScript files ** As mentioned above, aggregating all your JavaScript into a single file has its advantages. On the plus side it is easier to maintain and reduces the number of requests a browser makes to the Server, giving better performance. On the downside, one large JavaScript file may have a lot of code which is redundant to some pages, slowing things down again. Common sense (and perhaps some experimentation) is needed to solve this. If you have some long and complex JavaScript used by just some of your pages, then consider splitting these functions off into a separate file and only call this from the pages which need it. The average visitor is connecting to your site via DSL, which has fast download but slow upload, so multiple requests for small resources are usually much slower than one request for a large resource. So downloading half a dozen.js files is seldom, if ever, going to be more efficient than downloading one large file. When you consider that DSL upload speed may be only a fraction of download speeds, you can see why it is important to reduce the size and number of HTTP requests. Last Modified: 06/09/2012 Title: Datasheet - Sitekit CMS Performance Tips Page: 7 of 12

7.0 Optimizing Style and Script Order ** Many browsers, when they encounter a JavaScript file, stop downloading other resources until the JavaScript has been downloaded, parsed and executed. This effectively prevents the browser from concurrently downloading other resources. Since a typical browser is capable of opening half a dozen concurrent TCP connections to the same host (the actual number varies from one browser to another), this can be a significant bottleneck. So whenever possible, calls to JavaScript files should be placed at the bottom of the page. Obviously this doesn t apply if the JavaScript is needed for page startup. Conversely, style sheets need to be called early. In Sitekit this isn t a problem, because the style sheet is controlled by Sitekit CMS which places it in the Header, where it should be. So you don t need to worry about these. Sitekit is designed to work with a single Style Sheet, not counting specialised style sheets for mobile devices and printing. The basic rule of thumb is to load JavaScript files only when you need them which in most cases means they can be loaded last. You can easily achieve this by calling JavaScript from a Variable Block, placed in the Page Layout Template for pages where you want JavaScript to be called at the end of the page. For example, create a one-line Variable Block called Java-last-load, containing a call to the external JavaScript file. <script type="text/javascript" src="lasttoload.js"></script> and then place <VARIABLEBLOCK>Java-last-load></VARIABLEBLOCK> at the bottom of any Sitekit Page Layout in which you want the.js file to be called last. 8.0 Deferred Loading of JavaScript files * This is another aspect of loading items in the right order. Imagine that you have a page which contains a lot of complex user-initiated JavaScript. Obviously there s no point in having the user s browser parse this code before the page has even rendered, because the user can t respond to something which hasn t yet appeared on their screen. In an ideal world you could achieve this by simply adding the defer and async attributes to the script tag. The Defer attribute tells the browser to finishing loading the page before running the JavaScript, while the async attribute tells the browser to start downloading the linked JavaScript file -but not to run it until the page has finished loading. Unfortunately these two attributes do not have full cross-browser support, so you can t rely on them. So it s better to use the two techniques described below. The main function of the defer attribute is to make the browser treat all scripts as if they were found at the bottom of the page, therefore loading once the rest of the page is done loading/rendering. The simplest way of achieving this would be to place all scripts at the bottom of the page. If this is not possible, then a single script at the bottom of the page can add/load other scripts to the page, for example: var newnode=document.createelement('script'); newnode.type='text/javascript'; newnode.src='/folder/folder/file.js'; document.getelementsbytagname('head')[0].appendchild(newnode); Last Modified: 06/09/2012 Title: Datasheet - Sitekit CMS Performance Tips Page: 8 of 12

9.0 Externalizing JavaScript references, such as the jquery Library * During site construction some site developers load copies of JavaScript libraries - such as jquery - into the Sitekit asset library of the site itself, so they can then reference it as a local asset. Generally this isn t a good idea, and you re better off referencing it as an external file hosted on a content delivery network (CDN). Sitekit usually recommend http://ajax.googleapis.com/ajax/libs/jquery/1.7.0/jquery.min.js for the jquery library, for example. There are three advantages to this approach. Firstly you re saving a lot of chargeable Sitekit bandwidth by loading it from an external source rather than from Sitekit itself. The library is quite large, and if you are making use of it then typically every page on you site will refer to it. Secondly, if you call it from another host name you take advantage of parallelized downloads (described next) which improves page performance. Thirdly, the JQuery library is so universally used that it will be cached by proxy servers everywhere, again improving performance to your visitors. There are a couple of potential downsides. If you use a local copy then you avoid the risk of the remote library being changed. And if the remote site goes down, so does your JavaScript library. But these are minor risks, outweighed by the benefits. 10.0 Parallelize Downloads * On older browsers -which supported a limited number of concurrent connections per host name it made sense to split resource requests between two or more host names. Modern browsers support more concurrent connections, so the rationale for parallelizing resource downloads is becoming less important year by year. Even so, the technique is simple to implement in Sitekit during the initial site design stage, so it may be worth considering. 1. Go into Sitekit Admin and select Configure Domains, and add a new domain. For example, if your domain was mysite.com, you could create a subdomain called static.mysite.com. This domain (actually a subdomain) should leave the Indexed and Follow options unchecked, as pictured below, since you don t want search engines tracking it. 2. In the Admin Asset Tree, right click on the Folder you wish to attach to the new subdomain. Select the subdomain from the dropdown list, as shown below, and click the Attach to this Folder button. Last Modified: 06/09/2012 Title: Datasheet - Sitekit CMS Performance Tips Page: 9 of 12

Sitekit expects a domain to contain an index page, so you will probably receive a warning message when you first attach a folder to a subdomain. In this case you can safely ignore the message. 3. In the Static folder you should place the JavaScript files and Images called by your templates. 4. The templates themselves will have to be edited to call these resources using the absoluteurl address, for example; background-image:url(http://static.mysite.net/staticfolder/smilingmd.jpg); Note that this technique is only suitable for initial site design not for day to day use on a live site. You can t specify a subdomain when using the Image editor to place an image on a page. Also, be aware that you should only split components between 2-4 domains. This is a reasonable compromise between the advantages of parallelising downloads from different hosts, and the disadvantage of making multiple calls to a Domain Name System to find out the address of these various hosts. 11.0 Avoiding Bad Requests * Missing resources cause delays, and more importantly they annoy people. There are two ways to guard against this. Firstly you should run regular checks with the Sitekit Link Checker (or other Page Checkers, such as Google Speed page), and fix any broken links that turn up. Secondly, as a preventative action you should refer to resources by their Asset Link ID. So if a resource gets moved by accident or for a good reason links to it will still work correctly. Look at the section of code below, generated by a Sitekit page. The first line which was generated by dropping a graphic into a Text Box references the graphic by its path. The second line of code was generated by placing a graphic in a Picture Box, and here the graphic is referenced by its unique ID number. Should the graphic be moved from one image folder to another, or the folder itself moved to another location, then the first link will be broken. But the second link will be unaffected, and continue to work. 12.0 Avoid CSS Expressions * Sites written with older Internet Explorer browsers in mind (IE5 IE7) may use CSS Expressions (more generally called Dynamic Properties) to dynamically change document properties. These have been deprecated in IE8 and above, and were never supported at all in other browsers. CSS Expressions produce poor performance, and should be replaced either with standard CSS properties, or if you have to support older versions of IE - with JavaScript. 13.0 CSS Sprites ** Since every individual image requires a request from the browser, it is more efficient to combine lots of small images into one single image. By combining ten small images into one single image you re not saving any page weight but you re eliminating nine HTTP requests and their matching responses. The downside of Sprites, of course, is that they require a little extra work to create and reference, since you have to specify the coordinates of whichever section of the sprite you want to display. Therefore this technique is only cost effective for images which are permanent parts of the web site, rather than for images which have a short lifespan. Last Modified: 06/09/2012 Title: Datasheet - Sitekit CMS Performance Tips Page: 10 of 12

If you re building a new site, then the rule is simple. Use a Sprite creation tool to incorporate CSS sprites where you can. If you re maintaining an existing site that you didn t design yourself, you can check if sprites are being used efficiently by using a tool such as SpriteMe. Just point SpriteMe at a web page and it will suggest which images could usefully be turned into sprites, and even generate the css background-position references for you. 14.0 Specifying a Character set * This isn t a tip just a reassurance. Most performance improvement lists recommend that you specify a character set in HTTP response headers, since this can speed page rendering. Sitekit performs this automatically, as shown below, so it s not something you have to worry about. Page head <meta http-equiv="content-type" content="text/html; charset=utf-8"> Web config <globalization requestencoding="utf-8" responseencoding="utf-8" culture="en-gb" uiculture="en-gb"/> UTF-8 is the most popular form of character encoding on the web, and fully supports Unicode. 15.0 Future Sitekit Enhancements 15.1 Cookieless Domains There is one obvious case where it is useful to use multiple domains using a second cookieless domain to serve static resources, such as images and JavaScript files. Normally, whenever a visitor s browser requests a resource from your site, that request is accompanied by several cookies - even when the request is for some JavaScript, or an image. Since DSL uploads are so much slower than downloads these cookie-laden requests take a disproportionate amount of time, hence the advantage of serving static resources from a cookieless domain. A future update to Sitekit will enable you to create a cookieless domain via a simple tick in the box option in the Domain Manager settings. 15.2 Gzip compression Gzip (the GNU Project version) is far and away the most popular server-side compression software, and nowadays gzip compression is accepted by the vast majority of browsers. According to Google, extensive random page load tests shows that uncompressed pages take 25% longer to load than compressed pages so here s an impressive speed improvement achievable by relatively little work. When specifying which files your server should compress, HTML, Scripts and style sheets are all suitable targets. Normally you would exclude Images and other compressed files, such as.pdf s, because it s a waste of time trying to compress an already compressed file. (If gzip does succeed in compressing one of your images, then you re doing something wrong, and need to re-examine your image handling methodology). Gzip is intelligent enough to send uncompressed files to extremely old browsers (pre-ie6) which don t support gzip, so there is no down side to using gzip - apart from the Server CPU time spent compressing files. But as long as you select the right files to compress this isn t an issue, and the trade off in CPU time v reduced bandwidth is almost always favourable. Servers can also be configured to serve pre-compressed gzip files, to eliminate the on-the-fly compressions overhead, although this will involve more complex server configuration. Be aware that proxy servers and anti-virus software have been known to prevent some browsers from accepting gzipped files, meaning that they have to be sent uncompressed versions instead. IE6 is the most common culprit Last Modified: 06/09/2012 Title: Datasheet - Sitekit CMS Performance Tips Page: 11 of 12

here, dropping down to HTTP/1.0 when behind a proxy, and therefore not sending the Accept-Encoding request header needs to accept gzipped content. At the time of writing, Sitekit is testing various Gzip options on Beta servers, to find the most efficient configuration. Last Modified: 06/09/2012 Title: Datasheet - Sitekit CMS Performance Tips Page: 12 of 12