Separate HTTPS cache from HTTP All HTML files requested by HTTPS (SSL connection) will be stored separately from ordinary HTML cache files. This will increase overall cache size but quarantee website consistency for different connection types. Cache engine You can choose one of the caching engines supported by your server environment to speed the HTML caching up. All engines except file system cache records in RAM by default, this decreases access time. Scale HTML images All HTML images will be resized to smaller dimensions if latter are used in HTML code. data:URI Apply data:URI Background images will be converted to base64 format and included directly into CSS files for all browsers which support data:URI. Apply mhtml Background images will be converted to mhtml format and included directly into CSS files for all versions of Internet Explorer which don't support data:URI. Maximum data:URI size Images which size is greater than given number won't be converted to base64 format. No value or zero value means no limit. Maximum mhtml size Images which size is greater than given number won't be converted to mhtml format. No value or zero value means no limit. Exclude files from data:URI Images listed in this option won't be converted to data:URI. Please provide only file names not absolute paths. Exclude files from mhtml Images listed in this option won't be converted to mhtml. Please provide only file names not absolute paths. Visit our site 51 www.webogroup.com
Separate images from CSS code Combined CSS code and images in base64 and mtml formats will be stored in different files. This should increase cachebility. CSS Sprites Apply CSS Sprites Background images will be combined with the help of CSS Sprites technique. Related CSS code will be safely modified. 'Aggressive' combine mode for CSS Sprites Number of CSS Sprites images and their size will be lower but this may lead to graphical artifacts on web pages. Exclude IE6 IE6 will receive its own CSS file without CSS Sprites. Maximum width and height of images Images higher or wider than defined number won't be included into CSS Sprites. No value or zero value means no restriction. Combine HTML images A lot of small HTML images can be merged together to reduce number of HTTP requests as well. In this case there is a transparent image inserted into HTML document instead of initial one (with data:URI if possible). And it has the initial image as a background. Maximum width and height of HTML images HTML images heigher or wider than defined number won't be included into CSS Sprites. No value or zero value means no restriction. Maximum width and height of final sprites (in pixels) Sprites' dimensions will be restricted to defined value. No value or zero value means no restriction. Combine images for the current page only HTML images can be combined for the current page only (this reduces size of the final file, but increases number of such files) or for all website pages. In the last case there will be used the only image for the whole website, but its size can be very large. 52
Exclude / include files for CSS Sprites All images listed below either won't included into CSS Sprites, or there will be included only these images. Add free space for CSS Sprites Images in CSS Sprites will be rounded with free space to prevent side effects on web page scale in browsers. CSS Sprites file size will be a bit greater. Images' format If you choose automated format detection possibility of any side effects in CSS Sprites images will be minimal. If you choose JPEG format rate quality/size for true color images will the best but there will be no transparency. Server side cache Cache generated HTML files HTML pages will be cached for timeout set in option 'Default HTML cache timeout'. This option allows you to significantly speedup web pages load with long generation time. But this is reasonable only for static pages without dynamic content. Default HTML cache timeout After this time all cached HTML pages will be recreated on server side. Time to cache cart in e-store During this time all data about user's cart will be stored locally (in user's cookie or in localStorage). Only cache first n bytes of content (flush early) HTML cache will contain not the whole web page but the first n bytes of it (set in option 'Flush content size'). And this amount of data will be flushed to browser earlier than the rest web page content. So browser will receive calls to required resources earlier and don't wait the rest of the page to start their load. Flush content size Size of cached flushed part of a web page. It can be fixed (to avoid any issues with browsers or network connection). Empty (or zero) value leads to flush the whole web page content before closing </head> tag. List of parts of URLs to ignore from caching Often server side caching can't be used for pages with dynamic content. For example user account pages, statistic pages, and more. This option allows you to set parts of URL (masks) to exclude pages from server side caching. Visit our site 53 www.webogroup.com
List of USER AGENTS (robots) to add to caching This option allows you to set a list of USER AGENTS which will receive only cached HTML pages. For example caching HTML pages for all search engines can reduce server side load. List of cookie to exclude from server side caching You can also skip server side caching for user who have one of the cookie from this list. This can be useful for authorized users or during the work with shopping cart. GET parameters list to exclude on caching (separated by space) You can define GET parameters which will be striped from hash key creation to cache any website page. This can help if you have some statistical parameters (i.e. advertisement campaigns) which don't influence your website content). This will help to reduce cache size and increase its efficiency. Extreme mode In extreme mode all HTML documents will be served from cache directly, bypassing normal CMS processing. This will significantly increase website performance (especially useful on traffic peaks), but cache can be refreshed only manually. By default extreme mode for server side caching is available only on systems which uses web-servers with .htaccess support (Apache, LiteSpeed). Other web-servers configurations should be manually changed, according to Integration with website section of documentation. Delete expired files from cache After given cache timeout all old entries (which time of creation is less than current timestamp minus given timeout) will be deleted from HTML cache. DB Cache Cache DB queries All DB queries will be cached if their execution take more than time set below. This will increase load speed of all website pages. To make DB cache working correctly you need to install WEBO Site SpeedUp as system extension (not as standalone application). Queries execution time (ms) All queries which execution time (in ms) is greater will be cached. DB cache timeout (s): After this time all SQL queries will be re-requested from the current DB. 54
Exclude table(s) (separated by space) (separated by space): ?You can exclude some tables from DB caching logic by setting their names (without prefix). All queries from such tables won't be cached. Unobtrusive JavaScript Unobtrusive JavaScript With basic mode all supported widgets will be loaded on onDOMloaded event. With advanced mode - on window.onload event (this increases website load speed by Google) according to the other options in this section. Available options: basic mode and advanced mode. Include combined JavaScript file before </body> Combined JavaScript files will be moved to closing </body> tag. This option has more priority than 'Force moving combined script to </head>'. Move all JavaScript code to </body> All JavaScript calls will be moved to closing </body> tag according to their initial order on the web page. Move JavaScript widgets calls before </body> The whole JavaScript code from widgets calls will be moved to </body>. Move counter calls before </body> The whole JavaScript code from counters calls will be moved to </body>. Move advertisement calls before </body> The whole JavaScript code from ads (context and banners) calls will be moved to </body>. Defer iframes loading The whole HTML code from iframes calls will be moved to </body>. Load background images on DOMready event Background images' load will be delayed to DOMReady event. This will increase initial web page render speed in browsers. Pre-load CSS or JavaScript files All defined URLs will be loaded on window.onload event to speed the next page view up. Visit our site 55 www.webogroup.com
Pre-load pages All resources on these pages will be loaded on window.onload event (iframes) to speed the next page view up. CDN Distribute images All images called on web page will be automatically distributed through multiple hosts (mirrors). For example URL http://www.site.com/i/logo.png or /i/bg.jpg can be replaced with http://i1.site.com/i/logo.png and http://i2.site.com/i/bg.jpg in case if both hosts i1 and i2 are available and listed in option 'Allowed hosts'. Check hosts' availability automatically Available hosts will be checked automatically for images' existence. Allowed hosts Listed hosts will be used to distribute images. Please define no more than 4 hosts. Distribute CSS files All CSS files will be served via host defined as 'Host for CSS files' in 'Combine CSS' group of options. Distribute JavaScript files All CSS files will be served via host defined as 'Host for JavaScript files' in 'Combine JavaScript' group of options. Exclude the following files from distribution (separated by space) You can set a list of files (i.e. dynamic ones) to exclude from distibution logic. CDN usage You can either setup CDN usage by yourself (with settings of the current group and host for CSS/JavaScript files) or just choose one of the supported options. Available options: manual setup, current CDN (cdn.website.com), Coral CDN (.nyud.net) FTP access to upload files If you are using paid CDN (i.e. EdgeCast) it may be necessary to setup FTP access to upload all new assets. FTP access string must be given in the format user:password@host (or user:password@host:port). Note that only combined CSS and JS files can be uploaded via FTP as this is very time consuming operation. 56
Host available via HTTPS If your website is using HTTPS, you need at least 1 domain which has SSL certificate to serve files through CDN. This host will be used to distribute all types of files with secured (HTTPS) requests. Visit our site 57 www.webogroup.com
3.3. System Status System Status is a page that consists of four tabs: Status This tab shows WEBO Site SpeedUp current mode and allows you to switch that mode by clicking Enable or Disable buttons. There are two possible modes: Debug mode and Live mode. In Debug mode WEBO Site SpeedUp performs optimization actions only if certain GET-parameter is passed with the request (that is 'web_optimizer_debug=1' by default) or if certain cookie is set. In Live mode WEBO Site SpeedUp performs optimization actions on every request. It also informs about any troubles and warnings that affects WEBO Site SpeedUp performance. To learn how to get rid of problems listed here refer to troubleshooting and support section. Warnings about Apache modules (and possible memory restriction) are not related to WEBO Site SpeedUp logic but depend on current server configuration. Please contact your hosting provider to eliminate these warnings. Usually disabled modules don't influence general optimization algorithms because WEBO Site SpeedUp has very good graceful degradation for a lot of various environments. This tab is similar to the blocks Application Status and Server Status on Control Panel page. Settings This tab allows you to review and change WEBO Site SpeedUp program settings. In most cases these settings are set automatically and should not be modified. Change them only if you know what you are doing. Settings are the following. Cache This page contains details about cache contents. These cached files are optimized files that WEBO Site SpeedUp gets from your system and sends to end users, making the optimization process much faster. Refresh button allows you to entirely clear the cache contents and fill it again as if you had opened index page of your website. Cache refreshing is usually needed: • after WEBO Site SpeedUp configuration, • when site contents is changed and Server Side HTML caching option is applied. Similar to the Cache block on Control Panel page. 58
Website address Domain name or IP address of your website. For example: mysite.com. It is used to determine external resources and also as a domain for merged CSS and JS files. You can also set here the following domains here (to use them as a static mirror for the mentioned files). • js.yourwebsite.com • css.yourwebsite.com • beta.yourwebsite.com • test.yourwebsite.com • local.yourwebsite.com • stat.yourwebsite.com • stat1.yourwebsite.com • static.yourwebsite.com • dev.yourwebsite.com • www2.yourwebsite.com • cdn.yourwebsite.com Path to website root directory Absolute path to the root directory of your website. Path to DOCUMENT_ROOT Absolute path to the root directory of the website's host. Path to CSS cache directory This directory contains all files of CSS cache. Path to JavaScript cache directory This directory contains all files of JavaScript cache. Path to HTML cache directory This directory contains all files of HTML cache. Protect WEBO Site SpeedUp installation via htpasswd This option provides additional security for WEBO Site SpeedUp installation with the help of HTTP Basic Authorization and .htaccess and .htpasswd files. Login to protect WEBO Site SpeedUp with .htpasswd To protect WEBO Site SpeedUp with .htpasswd you need to define login and password. Login is set with this option. Password is equal to WEBO Site SpeedUp installation password. Visit our site 59 www.webogroup.com
Username and Password (to access via HTTP Basic Authorization) If your website is protected via HTTP Basic Authorization you need to declare username and password so WEBO Site SpeedUp can process all required resources from the website. Exclude URL from optimization Sometimes you may need to exclude some parts of website from WEBO Site SpeedUp processing. In this case you need to set meaningful parts (masks) for such sections / URL, separated by space. Updates This tab shows information about the latest stable version of WEBO Site SpeedUp software and its changes log. When new version is out you can click the Update button and WEBO Site SpeedUp will automatically download and update all files preserving your current configuration. Also you can get the latest beta version from here. Please be careful with it - and you can always roll back to the stable one if something is wrong. This tab is similar to the block Updates on Control Panel page. Install & Uninstall This tab is only active if WEBO Site SpeedUp is installed as a standalone application. If WEBO Site SpeedUp is installed on the system that is in supported systems list this tab shows information about all changes made to the source files of that system during installation. There are two buttons that allow you to Install or Uninstall these changes. When these changes are uninstalled, system is rolled back to its original state (note that all WEBO Site SpeedUp files including configuration files and all cache files and will be preserved) , but you can always restore these changes anytime press 'Install' button. If WEBO Site SpeedUp is installed on a system that is not in the supported systems list, this tab contains instructions on how to install and uninstall WEBO Site SpeedUp manually. 60
3.4 Personal Data This page contains a single form which fields are described below. Personal Data fields License key It is the key which makes all features of Lite or Premium Editions available (depending on your license). And it is unnecessary for the Community Edition which can be used only on non-commercial websites. For commercial websites there are two editions — Lite or Premium (see Version Comparison section) and both are licensed for an unlimited period. License key registration is performed automatically. You just need to enter the valid key into the corresponding field and press the 'Save' button. You can ask any questions regarding WEBO Site SpeedUp license policy using our contacts listed on the official website. For all plugins except Joomla! new options will be visible and available just after the license key is saved. For Joomla! plugin (due to internal system API) all options are always visible but, they will become active only after you enter and save the valid license key. Also Joomla! requires to refresh WEBO Site SpeedUp cache. E-mail This e-mail address is used only for information about urgent updates, greetings, and special offers Allow to use my data about optimization results Statistical information about website acceleration can be sent to WEBO Software servers. This information won't be published and will be used only to improve WEBO Site SpeedUp services and efficiency. No private data will be sent. If WEBO Site SpeedUp is installed as a standalone program there are also three fields that allows you to change the current password. Plugin versions of WEBO Site SpeedUp do not use a password in addition to web system native authorization means. Visit our site 61 www.webogroup.com
4. Understanding WEBO Site SpeedUp The most effective optimization requires better understanding of all optimization techniques and principles. WEBO Site SpeedUp works as a very light proxy for your PHP website — it buffers all output content (or just gets it through CMS API), applies all possible optimizations, and gives accelerated HTML to your end-users. All actions are tested and verified through tough performance standards so overall server load won’t increase. Moreover by implementing caching techniques WEBO Site SpeedUp can reduce CPU computations intensity and increase your web server margin of safety. Two schemes below shows website operation cycle without WEBO Site SpeedUp and with WEBO Site SpeedUp respectively. In following sections you will learn how WEBO Site SpeedUp integrates with any CMS and even static HTML website, how it carries out all optimization actions and even how you can expand effectiveness of optimization by utilizing WEBO Site SpeedUp API: • Integration with Website • Optimization algorithm • Creating CSS for better CSS Sprites • Plugins API • System files 62
4.1. Integration with website Integration approaches WEBO Site SpeedUp can be integrated into your website in several ways: • Buffered approach • Raw approach • Complex approach • Shutdown approach Buffered approach It's the most common way. First call of WEBO Site SpeedUp (with library require) ends with ob_start(). Then all content (there can be either simple echo $content or hundreds of different echo 'some tag') echoed till the next call of WEBO Site SpeedUp will be buffered. The second (and the last) call $web_optimizer->finish(); ends buffering with ob_get_clean(). And then this content (HTML document) is parsed and optimized. Generally it looks like this: require('.../web.optimizer.php'); ... echo ... ... echo ... ... $web_optimizer->finish(); There are several issues with PHP buffers from website subsystems, so sometimes this approach won't work. But usually it can be used for any website. Raw approach There is a possibility to parse HTML content with WEBO Site SpeedUp without buffering. It can be achieved by following lines of code: $not_buffered = 1; require('.../web.optimizer.php'); $content = $web_optimizer->finish($content); As shown in the example, WEBO Site SpeedUp can receive entire HTML document on its input and return it optimized. This approach can also be useful to create a complex application with scheduled optimization. Complex approach Both described above approaches can be used in one place. A good example of usage has been implemented into WordPress plugin: Visit our site 63 www.webogroup.com
/* main function for every page execution */ function web_optimizer_init() { ob_start('web_optimizer_shutdown'); } /* envelope output buffer with optimization actions */ function web_optimizer_shutdown ($content) { $not_buffered = 1; require(dirname(__FILE__) . '/web-optimizer/web.optimizer.php'); return $web_optimizer->finish($content); } /* add init and finish hook */ add_action('plugins_loaded', 'web_optimizer_init'); Buffered approach is implemented in web_optimizer_init function, where buffering is initialized and delayed until webpage content is ready to be sent to browser. At the same time function web_optimizer_shutdown implements raw approach and returns optimized content after single WEBO Site SpeedUp call. Shutdown approach One more way to integrate WEBO Site SpeedUp into website is shutdown function registration (via ob_start). Example (at the very beginning of index.php file): $not_buffered = 1; require(dirname(__FILE__) . '/web-optimizer/web.optimizer.php'); function weboptimizer_shutdown ($content) { if (!empty($content)) { global $webo_request_uri; $_SERVER['REQUEST_URI'] = $webo_request_uri; $not_buffered = 1; require(dirname(__FILE__) . '/web-optimizer/web.optimizer.php'); if (!empty($web_optimizer)) { $weboptimizer_content = $web_optimizer->finish($content); } if (!empty($weboptimizer_content)) { $content = $weboptimizer_content; } return $content; } } ob_start('weboptimizer_shutdown'); Scheduled optimization WEBO Site SpeedUp can be used in deployment process of any website in static mode. Just open all website pages when WEBO Site SpeedUp is installed, and then just copy resulted HTML documents to cache folders. We can for example run wget and get optimized website mirror that can be deployed on production server. wget -d -r -c http://dev.yoursite.ru/ 64
Server-side changes Source files changes In case of standalone installation, WEBO Site SpeedUp adds two lines of code in the beginning and in the end of a few files which responds for HTML output (depending on system). Most often the only changed file is an index.php in a website root directory. In case of native plugin installation no changes in system files are usually made except of common changes to install the plugin. The only file which can be modified on every system is .htaccess file in website root directory. Note that this file is modified only when Enable .htaccess option on .htaccess tab of Settings page is checked. WEBO Site SpeedUp automatically backups all modified files. Backup files gets gets .backup extension. For example, original index.php file will become index.php.backup after WEBO Site SpeedUp installation. Newly created index.php file will contain all changes WEBO Site SpeedUp needs to work properly. WEBO Site SpeedUp never modifies other source files, images, CSS or JS files without your notice. Optimized files are stored and served from a separate cache directories leaving original files untouched. The exception is Image Optimization tool but it runs only on demand and backups all optimized images too. .htaccess changes If Enable .htaccess option on .htaccess tab of Settings page is checked, WEBO Site SpeedUp automatically changes .htaccess file to implement all necessary optimization techniques. These changes are described below. mod_expires – all cached headers ExpiresActive On If we cache HTML files <FilesMatch \.(html|xhtml|xml|shtml|phtml|php)$> ExpiresDefault 'access plus here_goes_HTML_timeout seconds' </FilesMatch> ExpiresByType text/html A_HTML_timeout ExpiresByType text/xml A_HTML_timeout ExpiresByType application/xhtml+xml A_HTML_timeout ExpiresByType text/plain A_HTML_timeout If we cache CSS files <FilesMatch \.css$> ExpiresDefault 'access plus 10 years' </FilesMatch> ExpiresByType text/css A315360000 Visit our site 65 www.webogroup.com
If we cache JavaScript files <FilesMatch \.js$> ExpiresDefault 'access plus 10 years' </FilesMatch> ExpiresByType text/javascript A315360000 ExpiresByType application/javascript A315360000 ExpiresByType application/x-javascript A315360000 ExpiresByType text/x-js A315360000 ExpiresByType text/ecmascript A315360000 ExpiresByType application/ecmascript A315360000 ExpiresByType text/vbscript A315360000 ExpiresByType text/fluffscript A315360000 If we cache images <FilesMatch \.(bmp|png|gif|jpe?g|ico)$> ExpiresDefault 'access plus 10 years' </FilesMatch> ExpiresByType image/gif A315360000 ExpiresByType image/png A315360000 ExpiresByType image/jpeg A315360000 ExpiresByType image/x-icon A315360000 ExpiresByType image/bmp A315360000 If we cache fonts <FilesMatch \.(eot|ttf|otf|svg)$> ExpiresDefault 'access plus 10 years' </FilesMatch> ExpiresByType application/x-font-opentype A315360000 ExpiresByType application/x-font-truetype A315360000 ExpiresByType application/x-font-ttf A315360000 ExpiresByType application/x-font A315360000 ExpiresByType font/opentype A315360000 ExpiresByType font/otf A315360000 ExpiresByType application/vnd.oasis.opendocument.formula-template A315360000 ExpiresByType image/svg+xml A315360000 ExpiresByType application/vnd.ms-fontobject A315360000 ExpiresByType font/woff A315360000 If we cache video files <FilesMatch \.(flv|wmv|asf|asx|wma|wax|wmx|wm)$> ExpiresDefault 'access plus 10 years' </FilesMatch> ExpiresByType video/x-flv A315360000 ExpiresByType video/x-ms-wmv A315360000 ExpiresByType video/x-ms-asf A315360000 ExpiresByType video/x-ms-asx A315360000 66
ExpiresByType video/x-ms-wma A315360000 ExpiresByType video/x-ms-wax A315360000 ExpiresByType video/x-ms-wmx A315360000 ExpiresByType video/x-ms-wm A315360000 If we cache other static assets <FilesMatch \.(swf|pdf|doc|rtf|xls|ppt)$> ExpiresDefault 'access plus 10 years' </FilesMatch> ExpiresByType application/x-shockwave-flash A315360000 ExpiresByType application/pdf A315360000 ExpiresByType application/msword A315360000 ExpiresByType application/rtf A315360000 ExpiresByType application/vnd.ms-excel A315360000 ExpiresByType application/vnd.ms-powerpoint A315360000 mod_deflate + mod_filter (if mod_gzip is absent) – all gzip logic AddOutputFilterByType DEFLATE text/html AddOutputFilterByType DEFLATE text/xml AddOutputFilterByType DEFLATE image/x-icon Gzip CSS files AddOutputFilterByType DEFLATE text/css Gzip JavaScript files AddOutputFilterByType DEFLATE text/javascript AddOutputFilterByType DEFLATE application/javascript AddOutputFilterByType DEFLATE application/x-javascript AddOutputFilterByType DEFLATE text/x-js AddOutputFilterByType DEFLATE text/ecmascript AddOutputFilterByType DEFLATE application/ecmascript AddOutputFilterByType DEFLATE text/vbscript AddOutputFilterByType DEFLATE text/fluffscript mod_gzip – all gzip logic if mod_deflate is absent Initialize gzip module mod_gzip_on Yes mod_gzip can_negotiate Yes mod_gzip static_suffix .gz AddEncoding gzip .gz mod_gzip update_static No mod_gzip keep_workfiles No mod_gzip minimum_file_size 500 mod_gzip maximum_file_size 5000000 mod_gzip maximum_inmem_size 60000 Visit our site 67 www.webogroup.com
mod_gzip min_http 1000 mod_gzip handle_methods GET POST mod_gzip item_exclude reqheader \'User-agent: Mozilla/4.0[678]\' mod_gzip dechunk No Add gzip for page mod_gzip_item_include mime ^text/html$ mod_gzip_item_include mime ^text/plain$ mod_gzip_item_include mime ^image/x-icon$ mod_gzip_item_include mime ^httpd/unix-directory$ Add gzip for CSS files mod_gzip_item_include mime ^text/css$ Add gzip for JavaScript files mod_gzip_item_include mime ^text/javascript$ mod_gzip_item_include mime ^application/javascript$ mod_gzip_item_include mime ^application/x-javascript$ mod_gzip_item_include mime ^text/x-js$ mod_gzip_item_include mime ^text/ecmascript$ mod_gzip_item_include mime ^application/ecmascript$ mod_gzip_item_include mime ^text/vbscript$ mod_gzip_item_include mime ^text/fluffscript$ mod_headers – to safe headers for gzip / expires + ETag Disable caching for gzipped files on proxies <FilesMatch \.(css|js)$> Header append Vary User-Agent Header append Cache-Control private </FilesMatch> Disable Last-Modified (add ETag instead) -- not vice versa? <FilesMatch \.(ico|pdf|flv|swf|jpe?g|png|gif|bmp|js|css)$> Header unset Last-Modified FileETag MTime </FilesMatch> mod_setenvif – to make gzip headers safe for all browsers Exclude problem browsers from gzip BrowserMatch ^Mozilla/4 gzip-only-text/html BrowserMatch ^Mozilla/4\.0[678] no-gzip BrowserMatch \bMSIE !no-gzip !gzip-only-text/html Finding out compression type and browser type for extreme mode of server side caching 68
SetEnvIfNoCase accept-encoding deflate WSSENC=.df SetEnvIfNoCase accept-encoding gzip WSSENC=.gz BrowserMatch 'MSIE 6' WSSBR=.ie6 BrowserMatch 'MSIE 7' WSSBR=.ie7 BrowserMatch 'MSIE 8' WSSBR=.ie8 BrowserMatch 'Android|BlackBerry|HTC|iPhone|iPod|LG|MOT|Mobile|NetFront|Nokia|Opera Mini|Palm|PPC|SAMSUNG|Smartphone|SonyEricsson|Symbian|UP.Browser|webOS' WSSBR=.ma mod_rewrite + mod_mime (in addition to mod_deflate or mod_gzip) -- to gzip CSS / JS files statically Add Encoding for gziped files AddEncoding gzip .gz Add redirects to static files (file names are set with timestamps to force cache reload on the client side properly) RewriteRule ^(.*)\.wo[0-9]+\.(css|php)$ $1.$2 RewriteRule ^(.*)\.wo[0-9]+\.(js|php)$ $1.$2 Add static gzip for CSS files RewriteCond %{HTTP:Accept-encoding} gzip RewriteCond %{HTTP_USER_AGENT} !Konqueror RewriteCond %{REQUEST_FILENAME}.gz -f RewriteRule ^(.*)\.css$ $1.css.gz [QSA,L] Add static gzip for JavaScript files RewriteCond %{HTTP:Accept-encoding} gzip RewriteCond %{HTTP_USER_AGENT} !Konqueror RewriteCond %{REQUEST_FILENAME}.gz -f RewriteRule ^(.*)\.js$ $1.js.gz [QSA,L] Adde redirect rules for extreme mode of server side caching (for WordPress, for example) RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress|wp- postpass_).*$ RewriteCond %{REQUEST_METHOD} !=POST RewriteCond /path-to-document-root/wp-content/plugins/webo-site- speedup/cache/%{HTTP_HOST}/ %{REQUEST_URI}%{QUERY_STRING}index%{ENV:WSSBR}.html%{ENV:WSSENC} - f RewriteRule (.*) /wp-content/plugins/webo-site-speedup/cache/ %{HTTP_HOST}/$1/index%{ENV:WSSBR}.html%{ENV:WSSENC} [L] Changes for nginx configuration file Following rules should be manually added to nginx configuration file to enable gzip compression, client-side caching and extreme mode server-caching. Visit our site 69 www.webogroup.com
gzip on; gzip_comp_level 7; gzip_types text/plain text/xml application/xhtml+xml image/x-icon text/css text/javascript application/javascript application/x- javascript text/x-js text/ecmascript application/ecmascript text/ vbscript text/fluffscript image/svg+xml application/x-font-ttf application/x-font font/opentype font/otf font/ttf application/x- font-truetype application/x-font-opentype; if ($http_accept_encoding ~* deflate) { set $wssenc .df; } if ($http_accept_encoding ~* gzip) { set $wssenc .gz; } if ($http_user_agent ~ 'MSIE 6') { set $wssbr .ie6; } if ($http_user_agent ~ 'MSIE 7') { set $wssbr .ie7; } if ($http_user_agent ~ 'MSIE 8') { set $wssbr .ie8; } if ($http_user_agent ~ 'Android|BlackBerry|HTC|iPhone|iPod|LG|MOT|Mobile|NetFront|Nokia|Opera Mini|Palm|PPC|SAMSUNG|Smartphone|SonyEricsson|Symbian|UP.Browser|webOS') { set $wssbr .ma; } if ($request_method != POST) { set $cache_file_name /path-to-document-root/wp-content/plugins/ webo-site-speedup/cache/$http_host$request_uri/ index$wssbr.html$wssenc; } if ($http_cookie ~* 'wordpress|wp-postpass_') { set $cache_file_name ''; } if (-f $cache_file_name) { rewrite ^ /wp-content/plugins/webo-site-speedup/cache/ $http_host$request_uri/index$wssbr.html$wssenc break; } location ~* ^/wp-content/plugins/webo-site-speedup/cache/.*\.gz { gzip_static on; rewrite ^(.*)\.gz$ $1; } 70
location ~* ^/wp-content/plugins/webo-site-speedup/cache/.*\.df { gzip_static off; add_header Content-Encoding deflate; } rewrite ^(.*)\.wo[0-9]+\.(css|php)$ $1.$2; rewrite ^(.*)\.wo[0-9]+\.(js|php)$ $1.$2; rewrite ^(.*)\.wo[0-9]+\.(jpe?g|png)$ $1.$2; location ~* \.(jpg|jpeg|gif|png|css|js)$ { root /path/to/document/root; expires max; add_header Last-Modified: $date_gmt; } Visit our site 71 www.webogroup.com
4.2. Optimization algorithm Content parsing Initial HTML file parising • Head section with: ◦ <script> tags . ◦ <style> and <link> tags. • All scripts’ content • We parse defined head section (and scripts’ array) through 3 functions (for each main group) – page, css, javascript. Parsing scripts and styles into array • Define if file has src or href – so it’s an external one. • Inline code is put into content of item in scripts array. • Full content of files is mined only if “Don’t check files’ MTIME” option is disabled. • Cache file name is generated. If cached file exists we don’t do anything more – just remove current scripts’ and put 1 generated one into head. ◦ If we have unobtrusive load of JavaScript – put JavaScript call before closing </body>. ◦ If we merged external and inline scripts – put JavaScript call before </head>. ◦ If we don’t merge all scripts – put JavaScript call after CSS file. ◦ Put CSS file after <head> -- to load it as fast as possible. • If we don’t have cached file – and we have “Don’t check files MTIME” option enabled – get all scripts’ content. Content optimization JavaScript code • All merged content is passed through JSMin / Packer or YUI Compressor. • If compression / caching isn’t via .htaccess – form .php file with all gzip / caching headers. CSS code • CSS files are merged with all @import constructions (recursively). • CSS Tidy is applied (if CSS Sprites or data:URI are used). • Otherwise simple regular expression to minify CSS content. • If compression / caching isn’t via .htaccess – form .php file with all gzip / caching headers. 72
CSS Sprites applying • CSS Tidy parses initial merged CSS file and forms hash of CSS rules. • CSS rules are parsed for background-properties (background, background- position, background-image). • CSS rules are parsed for width, height, padding. Also we try to detect correct CSS selector for pseudo-variants (i.e. :hover, :link, etc – all CSS3 selectors) and detect inherited properties. • If we have CSS image with multiple background-position – it’s excluded (seems to be initial CSS Sprite). • If we have background-repeat: repeat – it’s excluded. • If we have background-repeat: repeat-x and we don’t have height (or it’s in relative units) – mark it as repeat-xl (to merge 1 image with all repeat-x at bottom). • If we have background-repeat: repeat-x and we have height – mark is as repeat-x. • If we have background-repeat: repeat-y and we don’t have width (or it’s in relative units) – mark it as repeat-yl (to merge 1 image with all repeat-y at bottom). • If we have background-repeat: repeat-y and we have width – mark it as repeat-y. • If we have background-position: bottom and background-repeat: no-repeat – mark it as no-repeatb. • If we have background-position: right and background-repeat: no-repeat – mark it as no-repeatr. • If we have background-repeat: no-repeat and we don’t have width or height (or have them in relative units) and no right or bottom – mark it as no-repeati (to merge images as icons – by steps). • If we have background-repeat: no-repeat and we have width and height (and no right or bottom) – mark it no-repeat. • If we can’t detect proper case (i.e. background-position : none) – it’s excluded. • Get actual image size. Remember initial position (background-position), image sizes are increased by paddings. Container size (from CSS rule) is remembered as initial shift (total 3 pairs of values – position, image dimensions and possible shift). • Glue all images by their type. For repeat-x and repeat-y found small no-repeat images and put them in the beginning. At the end put 1 repeat-xl or repeat-yl image. No-repeatb are merged and glued to the bottom, no-repeatr – to the right. All this except no-repeat and no-repeati. • For no-repeat image calculate position (by 2-dimensions matrix, simple algorithm). • After include into this sprite no-repeati images (by steps to the free positions). • Include into combined sprite no-repeatb (to the left bottom corner) and no- repeatr (to the right top corner). • CSS rules are renewed with calculated images’ positions and repeat. Multiple CSS rules for 1 background-image are merged into 1 (for data:URI Visit our site 73 www.webogroup.com
optimization). • Images’ filenames are formed by md5-hash from all CSS rules that participate in Sprites’ creation. We check if image exists before creating new Sprite. • Call smush.it to optimize final CSS Sprites image. • If we don’t have CSS Spirtes image (GDlib error?) – return background property for CSS selector and don’t remove other background properties. • Apply data:URI (via CSS rules hash). 74
4.3. CSS Sprites Overview CSS Sprites as a powerful tool to merge different background images together with no restrictions in website layout or design, but with significant reduce in loaded objects number. What is a CSS Sprite? CSS Sprite actually is a single image with a lot of images included. It is very similar to an image map. With background-position CSS property we can cut from this image required part and show it on the page. Also it's important to know actual dimensions of an object with background image - to make sure that other images from CSS Sprite won't be shown. How to use it? You need to put all images together in one file and calculate their positions to insert into CSS rules. If you have several images it's not a complicated task. But if you have dozens or hundreds of images — this can be very tricky and time consuming to combine all of them into one or two CSS Sprites. How can I help? WEBO Site SpeedUp automatically parses all CSS rules, finds all possible variants to use CSS Sprites and apply them. There a number of restrictions, so you can write your CSS and keep in mind general rules to help WEBO Site SpeedUp analyze you code better and improve performance of your website. Few rules to write CSS code for better parsing. • Use only absolute positions in background-position. Using relative values (i.e. em, %, or even center, bottom, right) will force WEBO Site SpeedUp to compute dimensions of a mentioned block, and sometimes it can't be done for sure. If you can't set absolute positions - just try to set absolute dimensions for these blocks. • Use only absolute values in width, height, and padding properties. If WEBO Site SpeedUp finds absolute values for position but relative values for dimensions it can properly calculate better position for current background image. So it can be combined with a lot of free space around it, or even not combined. • Avoid using complicated CSS selectors for background images. WEBO Site SpeedUp can't parse all CSS rules tree correctly, it can apply only some actions to detect a number of required properties (background-image, background- position, background-repeat, width, height, padding). It's better for WEBO Site SpeedUp to have all these properties in one CSS selector (no ancestors), it's also better for accelerating rendering of your pages in browsers Visit our site 75 www.webogroup.com
(due to decreased numbers of CSS selectors applied). • Try to exclude complicated cascading rules for background properties. For example instead of li.item, .active, .passive try to set .menu li, .menu li.active, .menu li.passive. Such cascade can be parsed with WEBO Site SpeedUp successfully. • Exclude unused CSS rules or move rarely used rules for pages where they are used. WEBO Site SpeedUp tries to combine all found images. It can't make sure which images are used on the current web page and which are not. So removing unused selectors reduces overall CSS Sprites size (and increases web pages rendering speed due to lesser amount of CSS selectors). • Do not use different background-position for the same background image if it's not a CSS Sprite. WEBO Site SpeedUp excludes images with multiple background position (as far as they seem to be Sprites), so such images won't be combined. You can also use margin in CSS rules as a possible alternative for background-position. All these rules will help WEBO Site SpeedUp to analyze your CSS code structure and prepare better CSS Sprites. Additional notes You can use magic word 'nosprites' in your classes, or ID, or attributes (in CSS code or in images names in HTML code) to skip CSS Sprites creation. This will work both for CSS and HTML Sprites. I.e. if you have .link .nosprites{background:url(image.png)} then image.png will be skipped from CSS Sprites routine. Also if you have in HTML code <img class='nosprites_additional' src='image.jpg' alt='My Image'/> image.jpg will be excluded from HTML Sprites creation. 76
4.4. Plugins API Plugins API is aimed to allow developers one more way to optimize (accelerate) CMS automatically on server-side, on client-side or both. Right now plugins have some hooks: • onInstall — actions that are applied on WEBO Site SpeedUp installation. • onUninstall — actions that are applied on WEBO Site SpeedUp uninstall. • onBeforeOptimization — actions that are applied to the web page content before any optimization actions are performed by WEBO Site SpeedUp. • onAfterOptimization — actions that are applied to the web page content after all optimization actions are performed by WEBO Site SpeedUp (can be cached). • onCache — actions that are applied every time to the web page content if it's cached (on output of cache content). Plugin skeleton There is general example of WEBO Site SpeedUp plugin: <?php if (!class_exists('web_optimizer_plugin_name')) { /* class declaration starts */ class web_optimizer_plugin_your_cms_here { /* Constructor, actually not used */ function web_optimizer_plugin_your_cms_here() { } /* Installer */ function onInstall ($root) { /* $root can be used to operate with local files */ } /* UnInstaller */ function onUninstall ($root) { /* $root can be used to operate with local files */ } /* preOptimizer */ function onBeforeOptimization ($content) { /* $content is current web page content */ return $content; } /* postOptimizer */ function onAfterOptimization ($content) { /* $content is optimized web page content */ return $content; } /* Cacher */ function onCache ($content) { /* $content is cached web page content */ return $content; Visit our site 77 www.webogroup.com
} } /* class declaration ends */ } ?> Your plugin file name must be the same as the class plugin defines. I.e. plugin creates class named 'plugin_class' than plugin file must be named 'plugin_class.php'. If you don't want to use all avaliable hooks in your plugin you can extend your class from webo_plugin class which is included if any plgins are enabled. This class provides the default implementation of all hooks methods. Good example of WEBO Site SpeedUp plugin is Joomla! 1.5.x plugin and Cs-Cart captcha fixing plugin. Plugin installation Steps to install your plugin: • Place your plugin (PHP file) into plugins folder of WEBO Site SpeedUp installation. • Add file name (w/o .php) of your plugin to config.webo.php (option ['plugins'], the last one). • Start installation process. Note that WEBO Site SpeedUp tries to detect plugins automatically basing on current CMS. I.e. with Drupal CMS you can just place file drupal61.php or drupal56.php into plugins — WEBO Site SpeedUp detects this file and applies it during installation to config.webo.php. 78
4.5. System Files Here is a list of internal libraries and WEBO Site SpeedUp files which are being used outside of the core folder. Internal libraries These files are used to provide different parts of WEBO Site SpeedUp functionality locally on the website (WEBO Site SpeedUp can be installed outside document root, so all essential parts must exist inside website folder). wo.static.php Initially it is located inside libs/php/ folder. On installation it is copied to CSS cache directory. It is used to provide gzip / client side caching for appropriate types of files on environments w/o required Apache modules. Well-known 'static proxy' library. 0.gif Initially it is located inside libs/php/ folder. On installation it is copied to CSS cache directory. It is used to replace images with transparent ones on HTML Sprites usage. yass.loader.js Initially it is located inside libs/js/ folder. On installation it is copied to JavaScript cache directory. It is used to provide unobtrusive load for detected pieces of JavaScript code (cross browser onDOMready event). wo.cookie.php Initially it is located inside libs/js/ folder. On installation it is copied to JavaScript cache directory. It is used to check gzip support for browsers which don't send Accept-Encoding headers (.php file sends gzipped JavaScript which sets appropriate cookie). web.optimizer.stamp.png Initially it is located inside images/ folder. On installation it is copied to CSS cache directory. It it used as a water mark for Community Edition (and can be used in any other WEBO Site SpeedUp Edition). Visit our site 79 www.webogroup.com
Achievement files These files are required to display information about speedup achievements. webo-site-speedup.back.jpg Initially it is located inside libs/css/ folder. On first visit to Achievements page it is copied to CSS cache directory. It is used to display general (orange) background for Website speedup Achievements page. webo-site-speedup.rocket.png Initially it is located inside libs/css/ folder. On first visit to Achievements page it is copied to CSS cache directory. This file contains all achievements graphics to display final schema with rocket parts. webo-site-speedup88.png On every visit to Achievements page it is re-checked and the last version is downloaded from WEBO Software servers. This file contains tiny (88x88) picture of website speedup achievement. webo-site-speedup125.png On every visit to Achievements page it is re-checked and the last version is downloaded from WEBO Software servers. This file contains small (125x125) picture of website speedup achievement. webo-site-speedup161.png On every visit to Achievements page it is re-checked and the last version is downloaded from WEBO Software servers. This file contains medium (161x161) picture of website speedup achievement. webo-site-speedup250.png On every visit to Achievements page it is re-checked and the last version is downloaded from WEBO Software servers. This file contains large (250x250) picture of website speedup achievement. webo-site-speedup.php On every visit to Achievements page it is re-generated to the actual state. This file contains all HTML part of website speedup achievement page. 80
webo-site-speedup.css On every visit to Achievements page it is re-generated to the actual state. This file contains all CSS (mhtml) part of website speedup achievement page. Temporary files These files don't usually present in any of website folders, but sometimes they can be found while WEBO Site SpeedUp is operating. progress.html Can be found inside JavaScript cache directory. Contains current stage of optimization or file number for update process. htaccess.test Can be found inside JavaScript cache directory. Contains (zero) content of libs/php/css.sprites.php file (being downloaded through curl it returns no content). If this file contains some text (Apache error), .htaccess usage is possible for current website. Usually check for .htaccess possibility with this procedure causes access warning inside log files. It is OK. module.test Can be found inside JavaScript cache directory. Contains content of libs/js/wo.cookie.php, libs/js/yass.loader.php, or libs/js/yass.loadbar.js files (it depends on current testing module). It is used to check possible usage of Apache modules (if apache_get_modules returns nothing). Visit our site 81 www.webogroup.com
4.6. Configuration Algorithm Automatic tuning — Environment test 1. Disable WEBO Site SpeedUp and all its options (for correct options configuration w/o any losses in website functionality). ◦ Enable 'Add <!--WSS--> to body of optimized pages'. 2. Client side caching (Cache-Control and Expires headers setting to far future to cancel repeat requests to static assets from browsers). • Enable 'Cache CSS'. • Enable 'Cache JavaScript'. • Enable 'Cache images'. • Enable 'Cache fonts'. • Enable 'Cache video'. • Enable 'Cache other files'. • Server side caching (server side expenses elimintation to create HTML pages). • Check current server side delay for home page (if curl library exists). • Enable Server Side Caching (if WEBO Site SpeedUp is installed natively and delay is more than 500 ms). • .htaccess test (Apache modules usage for client- and server-side optimization). • Check for SymLinks possibility. • Load available Apache modules. • mod_gzip • mod_deflate (+ mod_filter) • mod_expires • mod_headers • mod_rewrite • mod_mime • Enable available modules via .htaccess. • Check if website is accessible (if curl library exists). • If website is not accessible disable all Apache modules. Automatic tuning — CSS optimization 1. Files merging (decrease of requests to CSS files). • Count number of tags (actually styles) <link> and <style> inside <body>. • If number of styles greater than 0, then enable 'Combine CSS included in tags 82
<head> and <body>' • Otherwise enable 'Combine only CSS included in tag <head>' • Enable 'Enable inline styles merging' • Enable 'Enable external styles merging' (if curl library exists). • Compare styles for optimized and intiial website home page. • Disable 'Enable inline styles merging' if styles are different • Compare styles once more, disable 'Enable external styles merging' if they are different. Compare styles once more, disable 'Combine only CSS included in tag <head>' if they are different. • Minify (decrease CSS code size). • Enable 'Minify CSS'. • Compare styles, disable 'Minify CSS' if styles are different. • Gzip (decrease CSS code size). • Enable 'Gzip CSS'. • Compare styles, disable 'Gzip CSS' if styles are different. Automatic tuning — JavaScript Optimization 1. Files merging (decrease of requests to JavaScript files). 2. Enable 'Combine only JavaScript included in tag <head>'. • Load website home page once more and compare inline JavaScript code in head section with the previous one. • Enable 'Enable inline JavaScript merging' if inline code is the same in both cases. • Enable 'Enable external JavaScript merging' (if curl library exists). • Enable 'Force moving combined script to </head>'. • Count JavaScript errors on the optimized home page. • Disable 'Enable inline JavaScript merging' if any errors exist. • Count errors once more. Disable 'Force moving combined script to </head>' if there are any. • Count errors once more. Disable 'Enable external JavaScript merging' and enable 'Force moving combined script to </head>' if there are any. • Count errors once more. Consequently add to 'Exclude file(s) from combining' option JavaScript files from initial web page. • Count errors once more. Disable 'Combine only JavaScript included in tag <head>' if there are any. • Minify JavaScript files (decrease of JavaScript code size). • Enable 'Minify with JSMin'. • Count JavaScript errors on the optimized home page. Visit our site 83 www.webogroup.com
• Disable 'Minify with JSMin' and enable 'Minify with YUI Compressor' if there are any. • Count errors once more. Disable 'Minify with YUI Compressor' and enable 'Minify with Packer'. • Count errors once more. Disable 'Minify with Packer' if there are any. • Duplicates removal (decrease of JavaScript code size). • Check for JavaScript libraries duplicates on initial page. • Enable 'Remove duplicates' if there are any. • Count JavaScript errors on the optimized page. • Disable 'Remove duplicates' if there are any. • Gzip (decrease of JavaScript code size). • Enable 'Gzip JavaScript'. • Count JavaScript errors on the optimized page. • Disable 'Gzip JavaScript' if there are any. Automatic tuning — HTML Optimization 1. Minify (descrease of HTML code size). • Enable 'Minify HTML'. • Check for HTML changes (DOM tree size for head and length of inline JavaScript inside body) for the optimized and initial web pages. • Disable 'Minify HTML' if there are any changes. • HTML comments removal (decrease of HTML code size). • Enable 'Remove HTML comments'. • Check for HTML changes for the optimized and initial web pages. • Disable 'Remove HTML comments' if there are any changes. • Gzip (decrease of HTML code size). • Enable 'Gzip HTML'. • Enable 'Gzip fonts'. • Enable 'Check for gzip possibility via cookies'. • Enable 'Use deflate instead of gzip for IE6/7'. • Load the optimized page and try to read its contents. • Disable 'Gzip HTML', 'Gzip fonts', 'Check for gzip possibility via cookies', and 'Use deflate instead of gzip for IE6/7' if can't read contents. Automatic tuning — Performance 1. Validate changse in files (decrease optimization expenses). 2. Enable 'Ignore file modification time stamp (mtime)'. • Enable 'Do not use regular expressions'. 84
• Check for HTML changes for the optimized and initial web pages. • Disable 'Do not use regular expressions' if there are any changes. Automatic tuning — data:URI 1. Background images (decrease in HTTP requests number). • Enable 'Apply data:URI'. • Enable 'Apply mhtml'. • Enable 'Separate images from CSS code'. • Enable 'Load images on DOMready event'. • Compare styles for optimized and intiial website home page. • Disable 'Apply data:URI', 'Apply mhtml', 'Separate images from CSS code', and 'Load images on DOMready event' if styles are different. • Load the second CSS file (with background images) from the optimized web page and get its size. • Disable 'Separate images from CSS code' and 'Load images on DOMready event' if file size less than 102400 bytes. Automatic tuning — CDN 1. JavaScript files distribution (increase in requests concurrency). • Get JavaScript host from initial website page with the website host. • Set 'Host for JavaScript file(s)' and enable 'Distribute JavaScript files' if calculated host differs from website host (and it is a subdomain). • CSS files distribution (increase in requests concurrency). • Get CSS host from initial website page with the website host. • Set 'Host for CSS file(s)' and enable 'Distribute CSS files' if calculated host differs from website host (and it is a subdomain). • Images distribution (increase in requests concurrency). • Get images host(s) from initial website page with the website host. • Set 'Allowed hosts' and enable 'Distribute images' if calculated host(s) differ(s) from website host (and it/they is/are subdomain(s)). Automatic tuning — HTML Sprites 1. HTML Sprites (decrease of HTTP requests). 2. Get number of small images on the initial website page which size is less than 16x16. • Enable 'Combine HTML images', 'Combine images for the current page only', and set 'Maximum width and height of HTML images' to 16 if there are more Visit our site 85 www.webogroup.com
than 2 such images. Automatic tuning — Unobtrusive JavaScript 1. Nonblocking JavaScrupt (acceleration of page rendering with JavaScript calls movement). 2. Enable 'Move all JavaScript code to </body>'. • Count JavaScript errors on the optimized home page. • Disable 'Move all JavaScript code to </body>' if there are any. • Unobtrusive JavaScript (acceleration of page rendering). • Get the number of known (supported) widgets on the initial website page. • Enable 'Move JavaScript widgets calls before </body>' if there are any widgets. • Get the number of known (supported) ads on the initial website page. • Enable 'Move advertisement calls before </body>' if there are any ads. • Get the number of frames which are not widgets or ads. • Enable 'Defer iframes loading' if there are any frames. 86
4.7. Unobtrusive JavaScript patterns All patterns for delayed JavaScript loading (to prevent its blocking behavior) are located inside libs/php/config.unobtrusive.php file in WEBO Site SpeedUp core. So you can add new patterns (or even delete old ones) if you want. Pattern description Each pattern has 7 parameters: • Group (it is used just to fit corresponding configuration option). • Identifier (must be unique, used for ID of source/destination layout blocks). • Marker (short string in HTML code to decide apply regexp pattern or not). • Regexp (the main pattern to move JavaScript chunk from its initial place to the end of the document). • Onload_before (regexp match pattern to match JavaScript code chunk to apply progressive script delaying, to window.onload event). • Onload_after (regexp replace pattern to include matched JavaScript code after onload_before pattern has been applied). • Height (is used to prevent reflow on dynamic content changes of destination container). Examples Delayed JavaScript code Let's take Amazon ads as an example. It has the following unobtrusive pattern: 'aa' => array( 'marker' => 'amazon_ad', 'regexp' => '<script[^>]+><!--[^\da-zA- Z]*amazon_ad_tag.*?ads.js\'></script>' ) How it works? If HTML document matches amazon_ad string, regular expression (regexp) is applied to the whole document to find all JavaScript code examples. Then all these code chunks are consequently replaced with (destination containers, aa is a unique block identifier through all the other patterns) and at the end of HTML document corresponding chunks are included into (source containers). After the whole JavaScript code (from the current chunk) has been loaded into source container its content (maybe be a lot of code) is moved to destination container. There are no changes in layout if height parameter is given - only dynamic (usually advertisement) content appears within given container. As the result we have no blocking JavaScript, but all 3rd party content (which is supported by patterns in configuration) is loaded correctly. In the most of cases this unobtrusive logic is enough to guarantee significant Visit our site 87 www.webogroup.com
website speedup and remove any blocking JavaScript. Progressive JavaScript movement If you want to delay for example Google Search widget to window.onload event you can't simple add this via just an event handler for window.onload. You need to emulate document.write behavior to create a correct DOM structure with the given widget code. For this purpose two advanced parameters are used: onload_before and onload_after. Let's take this example: 'gs' => array( 'marker' => 'setOnLoadCallback', 'regexp' => '<script src=\'https?://www.google.com/jsapi\' type=\'text/javascript\'>' . '[\r\n\s\t]*</script>[\r\n\s\t]*<script type=\'text/ javascript\'>(//\s*<!\[CDATA\[)?' . '[\r\n\s\t]*google\.load\(['\']search.*?</script>', 'onload_before' => '.*?google.load\(\s*[\'']search[\''](.*?)\);(.*?)google.setOnLoadCallback[' . '\r\n\s\t]*\(function\(\)\{(.*?)\},\strue\);(.*?)</script>', 'onload_after' => 'document.write(\'\x3cscript src='//www.google.com/jsapi' type='text/javascript'>' '\x3c/script>\');setTimeout(function(){if(typeof google!=='undefined'&&typeof google.load!==' . ''undefined'){google.load('search'$1);setTimeout(function(){if(typeof google.search!=='undefined'' . '&&typeof google.search.CustomSearchControl!=='undefined'){$2$3$4;setTimeout(function(){' . 'var a=document.forms,b=0,c;while(c=a[b++]){if(c.className=='gsc- search-box'){wss_onload_ready=1}}' . 'if(!wss_onload_ready){setTimeout(arguments.callee,20)}},20)}else{setTimeout(arguments.callee,10)}}' . ',10)}else{setTimeout(arguments.callee,10)}},10);' ) Both regexps are used this way $document = preg_replace('@' . $onload_before . '@is', $onload_after, $document); So you can set any regexp groups (inside the first regexp, onload_before) to include them into the result code (which will be placed to the end of the document). Also please be careful with dynamic logic, and use setTimeout to define if all required libraries have been loaded, and callback can be applied. JavaScript variable wss_onload_ready must be set to 1 after the whole code is loaded (to start the next dynamic block loading). It is required to make document.write emulation perform correctly. 88
5. Troubleshooting and Support Use Firebug extension for Firefox (or similar tools) to view pages source, objects loading diagram, request and response headers etc. This data will help you to acquire information on WEBO Site SpeedUp activity on your website. If you stumbled across a problem during WEBO Site SpeedUp installation or operation refer to one of the following sections: • Installing issues • Client-side issues • Server-side issues If none of these sections helped you resolving your issue please refer to technical support section. Visit our site 89 www.webogroup.com
5.1. Installing issues Files or directories are not writable For normal operation of WEBO Site SpeedUp, certain files and directories should be writable. • File index.php in website root directory. This file often contains calls which integrates WEBO Site SpeedUp with the system. • File .htaccess in website root directory. If this file does not exists, website root directory itself should be writable in order to create .htaccess file. This file contains important Apache instructions which are necessary for many of the WEBO Site SpeedUp features. • Directory, where WEBO Site SpeedUp is installed with all its files and subdirectories. WEBO Site SpeedUp updates gets installed in this directory, user settings are stored here as well. • Directory where HTML, CSS and JavaScript cache files are located with all their files and subdirectories. These directories contains optimized files — the result of WEBO Site SpeedUp work. By default they are placed in WEBO Site SpeedUp installation directory, but their placement could be changed by user. Website is broken but WEBO Site SpeedUp is disabled or even uninstalled Invalid .htaccess Instructions In the root directory of a website there is an .htaccess file which is often modified when WEBO Site SpeedUp is installed. There is also copy of original file named .htaccess.backup. Restore the original file or make sure that there are no Site SpeedUp instructions left in .htaccess file. Such instructions are surrounded by two lines like this: [some instructions] Client Side or Server Side Cache is Active Cached pages can refer to nonexistent resources or just contain outdated code which can make website look broken. Find all active caching solutions on a website and clear their cache to make sure that you seeing the actual but not cached pages. Restoring Password for WEBO Site SpeedUp If WEBO Site SpeedUp is installed as a standalone application, open its installation directory and find a file named config.webo.php. Empty the password parameter value on a line 7 like this: 90
$compress_options['password'] = ''; Open WEBO Site SpeedUp admin interface afterwards and enter your registration data once again. Configuration settings and cache files will be preserved. If WEBO Site SpeedUp is installed as a native plugin, password can be restored using any system specific methods. WEBO Site SpeedUp activity If you need to check whether WEBO Site SpeedUp works on the website or not (if its installation does HTML document parsing) you can just open raw HTML code of your website and find there string <!--WSS--> (starting from version 0.9.0). WEBO Site SpeedUp doesn't parse content if there is no such string (also it can be disabled in configuration, please be careful with such stuff). For earlier versions you can check HTML document for absence of tabulations at the start of strings, absence of double line breaks or some file names in head section (like cache/1234a6789b.css or cache/1234c6789d.js, where 1234c6789d is a random string in hex16). It seems WEBO Site SpeedUp doesn't work if there are no such sings. If you can't find any traces of WEBO Site SpeedUp you need to re-check its calls in files of your CMS and maybe also repeat WEBO Site SpeedUp installation (WEBO Site SpeedUp can apply all required changes to CMS files by automatically). To get information about required changes for a standalone installation you can open System Status page and go to _Instal & Uninstall& tab. Also you can check in WEBO Site SpeedUp is active in the configuration (all installations except Joomla! plugin). For this purpose you should check in the file web-optimizer/config.webo.php this string $compress_options['active'] = '1'; And set value to 1 (if it's 0). This will activate WEBO Site SpeedUp for your website. If this doesn't help please check if there are any other plugins which can gzip content (so WEBO Site SpeedUp can receive it in gzipped view, and don't parse). Try to disable gzip in every such plugin or system configuration if it can affect HTML code. Incorrect paths calculation Sometimes WEBO Site SpeedUp can't correctly calculate all default paths for correct installation (this can result in no styles or scripts on the website, or even in any PHP fatal error). Usually it appears on CGI environments. To calculate paths WEBO Site SpeedUp tries the following. • Detects document root. Usually it's defined as $_SERVERno document root is defined (or it's defined to a not accessible folder) WEBO Visit our site 91 www.webogroup.com
Site SpeedUp tries to get environmental variable SCRIPT_FILENAME and exclude from it another variable SCRIPT_NAME (usually this helps in detection). • In case of relative website installation (i.e. a folder inside document root) WEBO Site SpeedUp has an option for website root. Usually it's computed automatically. • If CGI environment has been set completely incorrectly (i.e. $_SERVER['DOCUMENT_ROOT' isn't defined, and environmental variables SCRIPT_NAME, SCRIPT_FILENAME` are defined regarding internal PHP process) WEBO Site SpeedUp fails to detect document root, so it can't set all other directories (in most of cases they are also computed automatically after document root). In the last case you need to setup all paths manually. This can be done through WEBO Site SpeedUp interface, usually all paths are listed as the first parameters to set. 92
5.2. Client-side issues Please note! After each modification you need to refresh cache to apply new configuration settings. Browser error or strange symbols instead of website or content encoding error Usually it relates to double gzipping of the HTML document. The first can be performed by WEBO Site SpeedUp, and the second - by CMS or by web server. To resolve this issue you need to disable gzip in CMS or in WEBO Site SpeedUp: Gzip -> Gzip HTML -> No White screen instead of website or too long delay The main trouble was related to CSS Sprites behavior (memory limit issues), it is resolved in versions 0.5+ (so if you are using older versions - just upgrade). In any case you can try to completely disable CSS Sprites: CSS Sprites -> Apply CSS Sprites -> No and then step-by-step increase maximum width and height of images CSS Sprites -> Maximum width and height of images (in pixels) -> 100 ... 900 or exclude a number of files from merging CSS Sprites -> Exclude files from CSS Sprites -> List of files separated by space Also try to disable HTML images combining: CSS Sprites -> Combine HTML images -> No Also you can check your web server error logs to find out what is the problem. Usually it is enough to add required fixes. Sometimes white screen refers to incorrect installation or double gzipping. Upper sections tell how to resolve these troubles. If you still can't resolve this trouble you can disable WEBO Site SpeedUp options one-by-one to find out the right combination or the clue. You should start with the main groups of settings - Combine CSS, Combine JavaScript, Minify, and Gzip - and move forward in enabling more detailed settings (i.e., Client side cache, .htaccess, data:URI, or CSS Sprites). Visit our site 93 www.webogroup.com
Incorrect design This can be caused by different issues, but you can start with disabling CSS Sprites: CSS Sprites -> Apply CSS Sprites -> No Then (if the situation isn't resolved) you can disable data:URI: Data:URI -> Apply data:URI -> No After disabling this option CSS files won't be parsed by CSS Tidy and will be just merged together (and simple optimization will be applied). If there are still some issues with design you can disable inline CSS styles merging inside head Combine CSS -> Enaable inline styles merging -> No or(and) external CSS files Combine CSS -> Enaable external styles merging -> No or minify for CSS files Minify -> Minify CSS files -> No If you have time and want to research trouble more you can disable merging CSS files inside head one-by-one with the setting: Combine CSS -> Exclude CSS file(s) from merging -> List of files separated by space So you can find files that cause incorrect WEBO Site SpeedUp behavior and just exclude them from optimization process (or make them standard-complaint with jigsaw.w3.org/css-validator/ and try once more). At the bottom line there is an option Combine CSS -> Include CSS code to all files which you can use to add any custom CSS code to the merged file and overwrite current calculated styles. This can guarantee elimination of any CSS merging troubles. Disappeared or broken background images In some cases installation WEBO Site SpeedUp can result in disappeared or broken background images. To resolve this issue you need to detect what initial background images cause incorrect WEBO Site SpeedUp behavior (using and tools to debug markup) and exclude them from the CSS Sprites creation: CSS Sprites -> Exclude files from CSS Sprites -> List of files separated by space If this doesn't resolve the trouble you can disable CSS Sprites: 94
CSS Sprites -> Apply CSS Sprites -> No Also it's possible you should use this option Combine CSS -> Include CSS code to all files to define styles more precisely because you may have some troubles with this option data:URI -> Separate images from CSS code Unavailable scripts, styles or images while using client-side caching and nginx WEBO Site SpeedUp has two ways to override client cache: • Using GET-parameters, like: 3a1a23c4ea.js?wo1285789196. In this case some proxy servers can ignore such GET-parameters and still serve older cached files. • Using filename suffixes, like: 3a1a23c4ea.wo1285789196.js. This is most recommended way but all requests for files with such suffixes should be redirected to real existing files. And as long as nginx does not support dynamic changes in its configuration, WEBO Site SpeedUp cannot create all necessary redirect rules automatically. There are several ways to solve this problem: • Disable .htaccess → Use mod_rewrite. First approach with unique GET- parameters will be used. • Disable .htaccess → Use mod_expires (if client-side caching is enabled in WEBO Site SpeedUp) or .htaccess → Use mod_deflate (if gzip compression is enabled in WEBO Site SpeedUp). Files extensions will be changed to .php, and compression and caching headers will be applied dynamically, when files are requested and they will will look like this, for example: 3a1a23c4ea.wo1285789196.php. They will be served directly with Apache (using properly working mod_rewrite), bypassing nginx. • Add to nginx configuration all necessary redirect rules as it's performed for Apache .htaccess. They can look like this: rewrite ^(.*)\.wo[0-9]+\.(css|js)$ $1.$2 break; It's recommended to apply client-side caching and compression for static resources utilizing nginx features only. Ideologically this is the most correct approach but it requires manual configuration changes for nginx. Incorrect website behavior Usually it results in disabling part of client side logic. So you should understand that if you have for example a comments form (that is shown by means of JavaScript) and after WEBO Site SpeedUp installation there is no such form, then Visit our site 95 www.webogroup.com
there are issues with client side logic (JavaScript) and not with design itself. You should start resolving this issue with disabling safe merging mode for JavaScript files Combine JavaScript -> Safe combine mode -> No because it can be too safe for your website client side logic (and thus may harm it). To find out the issue you can start with disabling minify for JavaScript files: Minify -> Minify JavaScript files -> Don't minify JavaScript Then (if troubles still occur) you can try to exclude files one-by-one: Combine JavaScript -> Exclude file(s) from combining -> List of files separated by space When you detect which file causes the issue you can just exclude it from the overall packet or try to put logic of this file in non-conflict state (usually such errors are caused by incorrect internal logic inside this file, that isn't erroneous in one environment but leads to conflicts with other environments on merging together with all other files). In addition you can try to exclude inline JavaScript from merging Combine JavaScript -> Enable inline JavaScript merging -> No and place combined JavaScript file in the beginning of the page Combine JavaScript -> Force moving combined script to </head> - > No Not accessible files for end-users Sometimes there are issues with access to the website from end-users browsers but in the same time there are no troubles in the admin browser. If you face with such issue you need to check where cache folders are located, where WEBO Site SpeedUp is located, and if protection for WEBO Site SpeedUp installation is enabled: System Status -> Settings -> Protect WEBO Site SpeedUp installation via htpasswd -> Yes So you need to move cache folders outside WEBO Site SpeedUp installation (i.e. to the root directory cache, accessible via web server to write into) or disable protection for WEBO Site SpeedUp installation: System Status -> Settings -> Protect WEBO Site SpeedUp installation via htpasswd -> No 96
WEBO Site SpeedUp favicon appears on a website WEBO Site SpeedUp can put its favicon.ico to the website root directory when it can't find current favicon in that directory, or a link to any favicon in documents sources. This step allows browsers to download the favicon just once and cache it for a long time. Otherwise, if there will be no favicon, browsers will receive 404 errors on every page load. If you want to get your own favicon, just delete WEBO Site SpeedUp favicon.ico (and its gzipped favicon.ico.gz version) from the website root directory. Browsers will update their cache after a while and you won't notice WEBO Site SpeedUp favicon again. Visit our site 97 www.webogroup.com
5.3. Server-side issues Internal Server Error or blank screen after enabling WEBO Site SpeedUp WEBO Site SpeedUp does not change website source files, but can be configured to automatically enhance Apache configuration using .htaccess file and this can causes issues. To completely disable WEBO Site SpeedUp component and to rollback all its changes just click Disable in WEBO Site SpeedUp admin panel (DO NOT uninstall it from backend until then). If website backend is unavailable: • Restore .htaccess file in website root directory using .htaccess.backup created by WEBO Site SpeedUp. If there are no .htaccess.backup file around, just remove WEBO Site SpeedUp instructions from current .htaccess file. • Find file /web-optimizer/config.webo.php and change $compress_options['active'] parameter value from '1' to '0'. If problem is still there (which is highly unlikely), analyze server error logs from your host to understand and fix the problem. Server-side resources consumption by WEBO Site SpeedUp There are three common situations and each results in different load on your system. • WEBO Site SpeedUp is installed but disabled (i.e. in debug mode). There is no additional load to your system at all. • WEBO Site SpeedUp is enabled and its cache is full. The load is minimal, almost insignificant, around 5 or 10 milliseconds. • WEBO Site SpeedUp is enabled and its cache is not full. The load can be minimal to significant. Exact amount of server expenses depends on server environment and WEBO Site SpeedUp configuration. This situation is clearly described below. So if you are experiencing heavy load for a CPU or memory, and WEBO Site SpeedUp cache was just refreshed, please wait for some time. In most cases it will take no more than one hour until all necessary cache files are created and served without extra load to your system. That is the natural result when users or search bots are browsing your website for some time. If cache was refreshed long time ago, and the load is still high, then probably some cache files are being created on every page view. You can easily track this situation by examining Cache tab on System Status page. If cache size is growing 98
with every page view, then perhaps some WEBO Site SpeedUp options causing such behavior. For example, when every page has unique set of JavaScript code, WEBO Site SpeedUp is forced to create a new cache file for every page if the Combine all JavaScript option is enabled. If every JavaScript file should be minimized after that, the load will be even higher. In this situation you can, for example, exclude some files from combining or switch to _Combine only JavaScript in head tag_ option or you can exclude inline code from combining, depending on where the problem code is located. Another similar example is when every page has unique set of images and Combine HTML images option is enabled. Here is a list of options which may cause such troubles. WEBO Site SpeedUp options which usually cause extreme resources usage: • (Performance) Ignore file modification time stamp (mtime), if disabled • (Combine CSS) Combine all CSS in tags <head> and <body> • (Combine JavaScript) Combine all JS in tags <head> and <body> • (Minify) Minify with YUI Compressor • (Minify) Compress HTML to one string Other WEBO Site SpeedUp options which usually cause significant resources usage: • (Performance) Do not use regular expressions, if disabled • (Performance) Restore CSS properties • (Unobtrusive JavaScript) Move all JavaScript code to </body> • (Unobtrusive JavaScript) Move JavaScript widgets calls before </body> • (Unobtrusive JavaScript) Move advertisement calls before </body> • (Unobtrusive JavaScript) Move counter calls before </body> • (Unobtrusive JavaScript) Defer iframes loading • (CSS Sprites) Apply CSS Sprites • (CSS Sprites) Combine HTML images Also if you have a lots of images, CSS or JavaScript assets (i.e. hundreds of them), every page view will result in high server-side load if the following options are enabled: • (CDN) Distribute images • (CDN) Distribute CSS files • (CDN) Distribute JavaScript files If you have failed to find WEBO Site SpeedUp options which drops down your server performance, create a new configuration and enable optimization options one by one to find out the bottleneck of the current configuration. Still no solution? Try to disable WEBO Site SpeedUp and check server side performance again to make sure that the problem is not caused by some other software or system plugins. Visit our site 99 www.webogroup.com
No support for multiple hosts If you want to enable multiple hosts to server your images you need to check the following: • Enable support in DNS for these hosts. So you need to write to DNS a number of records with these hosts pointing to the required IP address (usually the same as for the current website). • Enable support for these hosts on your server. For Apache you do this with ServerAlias directive, i.e.: ServerAlias i1.site.com ServerAlias i2.site.com • Check that these hosts are mirroring the main website. For this you need to open any static object on the website (for example site.com/images/my.png) and replace the host with every host from the list of enabled ones (i1.site.com/images/my.png and i2.site.com/images/my.png). If you have any troubles you need to re-check or repeat previous steps. • Add all hosts to WEBO Site SpeedUp configuration: Multiple hosts -> Allowed hosts -> List of hosts separated by space • And enable support for multiple hosts: Multiple hosts -> Enable multiple hosts -> Yes WEBO Site SpeedUp will automatically check some of the most used hosts and try to apply them for images' distribution. So the last setting maybe performed automatically during WEBO Site SpeedUp install. After all these actions all images will be server through multiple hosts that will significantly increase load speed of every page on the website. Multiple hosts aren't saved WEBO Site SpeedUp checks all entered hosts automatically to be sure that they perform as they should. You can disable this check (if it can't be performed properly): Multiple hosts -> Check hosts' availability automatically -> No Server resources are very limited In this case you can use chained optimization: • Download home page (raw HTML) into cache directory as compressing.php. • Include into compressing.php WEBO Site SpeedUp calls. • Redirect to compressing.php with GET parameter (web_optimizer_stage). • Compressing.php redirect before merging CSS Sprites, after p16 in CSS Spites 100
Search
