This documentation will guide you through installation and configuration of Web Optimizer.

It will also help you to better understand all optimization techniques applied by Web
Optimizer.
Web Optimizer is a web application that automates all client-side improvements for website
and significantly increases load speed of its pages. Time-proven open source solutions and
engineer genius brought together all parts of this puzzle and now you can improve your
website in a few simple steps.

Merging external and inline code

Minifying files
Gzipping files
Client-side caching
Server-side caching
Multiple hosts for static assets
CSS Sprites applying
Data:URI applying
Unobtrusive JavaScript loading
and much more...

When cache files are created Web Optimizer wastes about 1-5 ms to parse and refresh
outputted HTML document (with default settings, correct one-string mode for HTML is the
very expensive procedure and can take 50-100 ms additionally).

After series of tests on default CMS installations Web Optimizer showed average page
loading speed of 250% of normal (and up to 500% in several cases). To be accurate,
average acceleration is 2.5 times (+21 in YSlow grade, -34% in size, -43% in
objects).

Table below shows how greater website speed increases after Web Optimizer installation.
Note that all CMS are tested in one particular environment with ~100KB/s broadband and
Firefox 3.5 browser. Websites are loaded several times to fill proxy cache and to get
necessary statistics. Local cache is emptied before each load.
 Load time
CMS YSlow Size (KB) Objects
(s)
Before After Before After Before After Before After
Bitrix 8.5.1 61 92 4.37 2.21 239 194 53 28
CMS Made Simple 74 96 0.483 0.375 49 35 15 5
cogear 1.0 76 91 5.11 1.57 447 129 11 9
DataLife Engine 8.0 65 91 4.48 1.29 147 120 43 16
Drupal 6.10 72 94 4.8 1.34 102 99 32 8
Etomite 1.1 89 96 0.874 0.477 19 14 7 6
ExpressionEngine
96 99 0.584 0.257 10 4 3 2
1.6.8
IPB 2.3.6 67 89 4.38 1.81 124 52 27 25
Joomla! 1.0.15 78 92 0.996 0.521 47 39 18 13
Joomla! 1.5.10 64 94 4.38 1.57 139 73 42 9
Joostina 1.2 63 91 8.07 3.77 426 333 45 17
Livestreet 0.3.1 51 96 10.87 1.97 298 111 48 5
MaxDev Pro 1.082 75 93 2.4 0.871 51 36 27 21
MaxSite 0.3.1 71 97 2.73 1.12 152 90 15 5
MODx 0.9.6.3 69 97 2.73 0.842 109 51 18 4
OpenSlaed 1.2 77 83 5.51 3.37 257 250 92 72
osCommerce 2.2 77 93 3.05 1.24 72 65 31 31
PHP-Nuke 8.0 * 72 91 2.785 1.272 181 91 19 19
phpBB 3.0.4 72 95 0.651 0.305 85 71 19 7
SMF 1.1.8 ** 61 91 2.68 1.72 183 132 63 25
Textpattern 4.0.8 92 97 1.26 0.823 8 5 4 4
UMI.CMS 2.7 58 93 4.52 2.89 269 177 59 10
vBulletin 3.8.3 70 92 3.33 1.81 124 67 20 14
Website Baker 2.6 77 95 1.51 0.47 17 12 10 8
Wordpress 2.7.1 72 95 4.58 2.08 133 125 31 6
Xaraya 1.1.5 81 97 1.79 0.78 35 16 8 4
XOOPS 2.3.3 72 95 3.22 1.53 65 50 21 8

* for PHP-Nuke the second static host has beed added

** for SMF 2 additional static hosts have been added

Web Optimizer exists in three versions: Community, Lite and Premium Editions. Table
below describes differences between these versions.

Features and Community

Lite Edition Premium Edition
technologies Edition
CPU overhead 20-100 ms 10-50 ms 1-5 ms
Acceleration up to 100% up to 200% up to 500% and more
up to 65% less up to 65% less
Gzip options up to 88% less traffic
traffic traffic
up to 40% less up to 40% less
Client-side caching up to 85% less traffic
traffic traffic
up to 90% less CPU
Server-side caching not included not included
load
up to 25% less HTTP
CSS sprites not included not included
requests
up to 60% less up to 60% less HTTP
Data:URI not included
HTTP requests requests
up to 200% extra
Multiple hosts not included not included
website speedup
Unobtrusive up to 100% extra
not included not included
JavaScript website speedup
Premium support not included not included 24/7
Product updates free free free
Price free $19.99 $99
up to 15% CPU up to 98% CPU saved,
saved, up to 87% less traffic,
up to 50% less up to 85% less HTTP
traffic, requests,
All benefits none
up to 60% less up to 400% extra
HTTP requests, website speedup,
up to 100% extra premium support
website speedup 24/7
 PHP 4.3+ or PHP 5+
Apache or IIS server with mod_php, or Denwer, or any other server with CGI
16 MB memory available (64+ MB is desirable for correct CSS Sprites creation)
Optional: curl library enabled (for external files' fetching)
Optional: zlib library enabled (for gzip via PHP possibility)
Optional: gd library enabled (for CSS Sprites)

IE 5+
Firefox 2+
Safari 2+
Chrome
Opera 7+

Web Optimizer can be installed on any CMS that meets requirements above, but it also has
built-in compatibility with the following CMS:

4images
Bitrix (8.5+)
CakePHP (1.2.3+)
CMS Made Simple (1.6+)
CodeIgniter (1.7+)
cogear (1.0+)
DataLife Engine (7.5+)
Drupal (5.x) via native plugin
Drupal (6.x) via native plugin
Etomite (1.1+)
ExpressionEngine (1.6.8+)
Geeklog (1.6+)
Invision Power Board (2.6+)
Joomla (1.0.x) via native plugin
Joomla (1.5.x) via native plugin
Joostina (1.2+)
Kohana (2.3+)
LiveStreet (0.2+)
MaxDev Pro (1.082+)
MaxSite (0.3+)
MODx (0.9+)
NetCat
Open Slaed (1.2+)
osCommerce (2.2+)
phpBB (3.0+)
PHP Nuke (8.0+)
Santafox (1.1+)
Simpla
Simple Machines Forum (1.1.8+)
Symfony (1.2+)
Textpattern (4.0+)
Typo3 (4.2+)
VaM Shop (1.5.5+)
vBulletin (3.8.3+)
UMI.CMS (2.7+)
Website Baker (2.8+)
Wordpress (2.6+) via native plugin
Xayara (1.15+)
XOOPS (2.3.3+)
Yii (1.0+)
Zend Framework (with disabled rewrite for Web Optimizer)
Web Optimizer can be easily installed on any website that meets the system requirements.
There are two different ways of installation:

Standalone installation. It is the common way for the most of CMS.

Installing Web Optimizer as a native plugin for a supported CMS (these CMS are marked
in system requirements). Native plugin installation means more integration and thus an
extra optimization quality along with ability to configure Web Optimizer through
familiar CMS interface.
Depending on which way you want Web Optimizer to be installed on your CMS there are
detailed step-by-step instructions:

Standalone installation
Joomla plugin installation
WordPress plugin installation
Drupal plugin installation

The latest version of the software can be obtained on Web Optimizer download page
(http://code.google.com/p/web-optimizator/downloads/list) .

Web Optimizer always indicates when new version of software is released. When you choose
to update Web Optimizer, it downloads and updates all files automatically. For changes log
refer to Web Optimizer project page (http://code.google.com/p/web-optimizator/) .
Web Optimizer is available in two packages: ZIP archive and mini installer. To download the
first package please go to code.google.com/p/web-optimizator/downloads/list
(http://code.google.com/p/web-optimizator/downloads/list) and choose Featured version
0.5 or higher.

Then upload ZIP archive to the website root. If you have SSH access to the website you can
just do it through wget:
wget http://web-optimizator.googlecode.com/files/web-optimizer.v0.5.5.zip

Here you need to unzip archive to the website root to create folder web-optimizer.

If you have only FTP access to the website, then you need to download package to the local
PC, then unzip it, and then (through any FTP manager) copy to the website root.

If you don't want to upload unzipped package to the website (or unzip downloaded archive
on the server) you can just use mini installer, which (if there is curl available) can download
all required files and start installation automatically. To perform this you need to upload to
the website root only file install.me.php and then open it in your browser.

After all files are uploaded to the web server you need to set the writable access for
(required) the file web-optimizer/config.webo.php and (optional) for
web-optimizer/cache under the web server user. Otherwise settings and cached copies of
minified files' content won't be saves. You can change cache folder location, so the only
requirement is the correct rights for configuration file.
Let's open in your browser
http://your_website/web-optimizer/index.php

There can be any directory with Web Optimizer instead of web-optimizer. Here you can see
Web Optimizer welcome screen. If you can't find Web Optimizer installation there please
check where you have copied Web Optimizer and open this folder via browser.

Here are 3 possible ways:

Express install
Common install
Manual install

Express install
To start express install please enter desired login and password to access Web Optimizer in
future and press green button "Express install". After this Web Optimizer will calculates root
directory, saves all default settings and starts chained optimization of the home page to
create cached versions of minified files. Only on complete all writable files (usually just root
index.php, it depends on current CMS) are automatically changed.

If Web Optimizer can't change these files it will show information about required changes.
Common install
Common install differs from express one only with one intermediate step where you can
check and set all possible options. To reach this step please press button "Next", or on the
number 2 or 3 in the top menu, or on the orange arrow in the right.

All settings are listed and described in this article. Firstly you need to check calculated paths.
Here you also can define cache directories - this will be required to enable option "Protected
mode" properly (it is the section "Use .htaccess"). On enabling this option login and
password for Web Optimizer will be asked only via HTTP Basic Authorization. It won't be
required to enter it every time. But files that are located inside Web Optimizer folder will be
not accessible for external users, so in this case you need to change cache directories.

Manual install
You can install Web Optimizer manually on any CMS or even on a website that consists of
static HTML pages. Just add two calls at the beginning and at the end of every file that
outputs a webpage (that is index.php in many cases and *.html in case of static HTML
sites). These calls are:
<?php
require(/path/to/Web/Optimizer/web.optimizer.php);
?>
...
initial contents of the file
...
<?php
$web_optimizer>finish();
?>

As far as Web Optimizer adds about 5-10ms in common mode (after all cached files have
been created), so server side load won't be changed notably but client side will be
significantly accelerated. But you must be sure that pages on which you will add Web
Optimizer calls are parsed via PHP interpreter (will have .php extension or any other
extension defined by server settings).

Web Optimizer version 0.5+ has several tools to manage optimization activity.
First of all it's configuring all settings (hereinafter while using Web Optimizer you need to
enter your login and password if it's not the protected mode), that can be performed by
clicking on button "Next" (or by clicking on the numbers 2 or 3, or orange arrow in the right).
Secondly you can clear Web Optimizer cache, it will be required if you have changed any CSS
or JavaScript files on the website with enabled option "Don't check files mtime (and
content)"). Thirdly you can painlessly uninstall Web Optimizer (there will be deleted all calls
inside CMS files and all Web Optimizer optimization settings inside .htaccess).

If you have curl on the server and there is newer version, Web Optimizer offers upgrade
(there will be a block with button "Upgrade" appeared). During upgrade procedure all
existing settings will be saved. Also there can appear some new ones. Common view of Web
Optimizer administrative panel is the following:
If you experiencing any troubles during installation of Web Optimizer please refer to
troubleshooting and support section of documentation.
 1. Upload web.optimizer.wordpress.php to the /wp-content/plugins/ directory.
2. Make folder /wp-content/plugins/ writable for your web server.
3. Make sure that there is writable .htaccess in the website root, or website root is writable
for your web server (only if Apache is used).
4. Activate the Web Opimizer plugin through the 'Plugins' menu in WordPress.
5. Please make sure (via Web Optimizer plugin 'Settings' page) that all paths are calculated
correctly. Or just set them up before the previous step.
6. Enjoy your fast website!

Please note that Web Optimizer for WordPress requires Web Optimizer core package. It will
be downloaded automatically on plugin activation or else you will need to do it manually
from Web Optimizer Storage, version 0.5.9.4+. For this:

1. Please select full archive (not Mini Installer), it's usually about 1 Mb in size, and its file
name is web.optimizer.vX.X.X.zip (X is a number).
2. Download this package.
3. Unzip package inside /wp-content/plugins/ directory. So you will have the following
structure:
plugins
|__ web.optimizer.wordpress.php
|__ web-optimizer
. |__ cache
. |__ controller
. |__ ...

After creating such a structure please:

1. Make directory web-optimizer/cache, and file web-optimizer/config.webo.php writable

for your web server.
2. Activate the Web Optimizer plugin through the 'Plugins' menu in WordPress.

Also please deactivate (or delete) Web Optimizer itself (if it's installed for your website).

Please clear cache in WP-Super-Cache, Hyper Cache, or any other cache plugins to see
result. Or just disable them - cache files are not affected. After applying all changes in Web
Optimizer configuration you can enable cache plugins back - HTML documents will be saved
as optimized ones.
Before install please make sure that

Website root is writable for your web server process or(and) there is writable .htaccess
file.
Joomla! cache folder (/cache) writable for your web server.
Web Optimizer is the located BEFORE "System - Cache" among enabled plugins.
GZIP is disabled in Joomla! system configuration.

1. Go to Installers -> Mambots.

2. Install Web Optimizer mambot.
3. Enable it via Mambots -> Site Mambots.
4. Open your website. It can take 10-100 seconds to load it the first time (to create all cache
files).
5. Configure Web Optimizer through Mambots -> Site Mambots -> Web Optimizer.

1. Go to Extensions -> Install/Uninstall.

2. Install Web Optimizer plugin.
3. Enable it via Extensions -> Plugin Manager.
4. Open your website. It will take 10-100 seconds to load it the first time (to create all
cache files).
5. Configure Web Optimizer through Extensions -> Plugin Manager -> System - Web
Optimizer.

Joomla! 1.5.x server-side caching

Content (HTML) generation time with different caching settings

Cache Web
System-Cache Web Time
(global Optimizer JRE YSlow
(plugin) Optimizer (ms)
settings) Cache
No No No No No 315 65
Yes No No No No 200 65
Yes No Yes No No 205 93
Yes Yes Yes No No 115 93
Yes Yes Yes Yes No 115 93
No No Yes Yes No 95 93
No No Yes No Yes 63 93
Before install please make sure that website root is writable for your web server process
or(and) there is writable .htaccess file.

1. Copy all files from installation package to /sites/all/modules/weboptimizer/ directory.

2. Make this directory writable for your web server.
3. Please disable GZIP in Drupal global settings. Web Optimizer has better compression
support.
4. Activate the Web Opimizer module through the Administer -> Site building -> Modules.
5. Open your website. It can take 10-100 seconds to load it the first time (to create all cache
files).
Below are listed several groups of options to configure in latest version of Web Optimizer.

Cache Directories. Here you can set paths to cache folders (on file system), where all
minified CSS, JavaScript, and HTML files will be stored. There you can also define root
directory for your website (it's required to correct calculation of all relative paths). Be
default all cache directories are located in cache folder inside Web Optimizer
installation.
Minify and Combine. This group of settings is responsible for combining and minify
JavaScript and CSS files. Be default JavaScript files are minified with JSMin (or YUI
Compressor if there is java). Also you can obfuscate JavaScript with the help of Dean
Edwards Packer (will be the best choice on disabled gzip). Here you can also set options
to minify resulted HTML code (simple line breaks, tabulations, and spaces removal,
one-string mode, or(and) removing HTML comments). Conditional comments for IE are
not parsed in all cases.
External and inline code. Web Optimizer can download and parse external
JavaScript files (included from different domains) and inline code (located right inside
<script>). Here you can set CSS code merging, that is inside <style> (enabled by
default). Also you can set (separated by space) file names (just names, not full paths),
that must be excluded from merging logic. There are some bugs with merging initial
Tiny MCE and FCE Editor JavaScript libraries, so they are excluded by default.
Gzip Options. This group of settings manages whether JavaScript, CSS, or HTML files
will be server as archives. Gzip saves about 70-85% of traffic while transferring textual
files, but it can be not so optimal for web server (in case of gip via PHP and high load).
In any case if it's possible all gzip settings are written via .htaccess (for CSS and
JavaScript files in static mode). If it's impossible to change .htaccess gzip versions of
JavaScript and CSS files are stored inside cache directories to minimize CPU load (via
PHP).
Unobtrusive JavaScript. This group consists of settings responsible for non-blocking
load of different JavaScript approaches. For example you can move include of merged
JavaScript file before <body> (or just load it on DomContentLoaded event), you also can
move load of some JavaScript counters, advertisements, and widgets to the very bottom
of the document (after JavaScript code is loaded the results HTML code will be inserted
to the initial place on the page, that ensures load of additional ads after the main content
is loaded).
Client-side caching. This option adds an expires header to your JavaScript and CSS
files which ensures that files are cached on the client-side by the browser. When you
change your JS or CSS, a new filename is generated and the latest version is therefore
downloaded and cached.
Server-side caching. This option allow Web Optimizer to cache generated HTML
output and prevent a lot of server-side work to generate it. Note, with this option all
server-dependent logic will be disabled. All pages will be completely static. Please turn it
 on only if you are completely sure.
Performance options. Usually Web Optimizer checks if files have been changed since
the last access to the page. And uses retrieved information to give existing file from
cache or generate a new one. It's not good from the server side optimization point of
view so you can disable this check. By enabling this option you need to manage Web
Optimizer cache manually to clean cache folders from out-of-date cached files when
new assets are available.
CSS Sprites. This is maybe the most powerful and the most innovative part of the Web
Optimizer. Right usage of this technique can reduce the number of HTTP requests to the
server on the page with a lot of background images by order (!) - from 20-100 to 3-10.
But there are some troubles with displaying combined images for IE6 (images are
created as PNG32, but IE6 can't handle transparency properly for such PNGs), these
problems are solved by excluding IE6 from CSS Sprites process by CSS hacks (option is
enabled by default). Also this can be prevented by using not-transparent images. Also
you can use JPEG instead of PNG for full color images, set "aggressive" mode (repeat-x
and repeat-y will be combined without calculating actual sizes of containers and there
will be no free space between images), add free space between images (allow to resolve
some issue with scaling CSS Sprites in modern browsers). There is "restricted" memory
mode to increase stability of CSS Sprites creation process. If PHP process has less than
64 Mb of memory (this will be enough for CSS Sprites about 3000x3000 pixels, almost
all cases are covered with these dimensions), images larger 4000 square pixels will be
excluded. Also you can exclude images by their linear sizes (in pixels, 900 by default)
and their file names (not full paths just file names) from CSS Sprites creation process.
data:URI. Data:URI technique allows you to include background images right inside
CSS file. It is supported with all modern browsers and IE8. It has restriction in size with
24 Kb (32 Kb of data:URI code are encoded from 24576 bytes of binary code) - it's
adjustable. To avoid problems with IE7- there are CSS hacks included into result file, so
website design will be in order after this transformation. Also with data:URI creation it's
highly recommended to optimize images (and reduce their initial size). To perform this
operation API from smush.it (http://smush.it/) is used. For correct optimization you
need to make all images writable for your web server. This option is disabled by default
because you usually perform this optimization only once and after that all subsequent
CSS files builds will already use minified images.
Multiple hosts. This option allows you to enable images' distribution through multiple
static hosts. Every image will be associated with the only host (to avoid caching one
image from all available hosts). To use this acceleration technique you need to add to
DNS all alternative hosts for the IP address which will serve them (usually it's the same
as for the main website) and add to server configuration some aliases fir the main
website. For example:
ServerAlias i1.site.com
ServerAlias i2.site.com

After this you need to add i1 i2 to Web Optimizer hosts' list and make sure that images are
distributed through these hosts. During installation Web Optimizer automatically checks a
number of default hosts to use them as alterative (with the same website root), also all set
hosts are checked for availability (test images are loaded from them). Please keep in mind
that enabling "protection" for Web Optimizer installation (there are some words about this
option below) automatic hosts' check can be performed properly and you need to set list of
hosts by hand, without Web Optimizer installation restart. Automatic check can be disabled if
it's required.

.htaccess. Most of gzip and cache settings can be written via web server configuration
file to avoid overhead of server scripts. This can be performed with .htaccess file (if
you want you can transfer all settings to httpd.conf file manually after installation).
Web Optimizer automatically checks for available Apache modules and configures .
htaccess records accordingly (of course this file must be writeable). mod_gzip,
mod_deflate, and mod_filter handle for gzip "on fly", mod_rewrite and mod_mime —
for static archives. mod_headers and mod_setenvif — for correct rules for gzip in old
browsers and proxy servers. mod_expires — for correct cache expires headers. Also you
can place .htaccess either in the website directory (it can be useful if you have a lot of
sites inside different folders), or right in the website root. Be default both locations are
equal. Also you can protect Web Optimizer installation with .htpasswd. In this case to
perform all setup and configuration you need to provide login and password through
HTTP Basic Authorization in your browsers (this allows you to move Web Optimizer to
any folder of your website, but don't forget to move cache directories outside protected
Web Optimizer installation).
Footer text. There is small stamp in the right bottom corner of the optimized website
"Accelerated with Web Optimizer" with the link (with rel="nofollow" attribute) to the
project website. There are 3 different stamps available.
Changing /index.php. Web Optimizer supports automatic change required CMS's files
for several dozens of systems (in case of unknown system it is displayed as CMS 42, and
only root index.php is changed in a standard way). Before automatic change Web
Optimizer performs chained optimization of the home page (to create all cached files
and avoid long delay on the first load of optimized website).

Here is the list of recommended changes in Web Optimizer configuration.

Common JavaScript or CSS file inclusion on all pages. Sometimes we need to

use a common JavaScript library or general CSS file through the whole website. To tell
Web Optimizer not to include this file with the others you can exclude it in the
configuration:
External and inline code -> Excludes file from merging -> List of
files separated by space

One-string mode for HTML. Web Optimizer can merge whole resulting HTML into
one string as described above. For this you need to enable
Minify Options > Remove HTML comments > Yes
Minify Options > Shrink HTML to the one string > Yes

Please notice that these settings make additional load to the server (correct regular
expression is very expensive) and can lead to exclusion of some JavaScript code (that is
included via comments). Also all code inside script, textarea, pre won't be changed
(due to HTML specification). So please use these settings very carefully.

Images optimization via smush.it (http://smush.it/) . Smush.it service has been

developed by Yahoo! and Google engineers and allows you to optimize file size of any
images automatically. You can enable images' optimization via CSS Sprites library:
<?php
require('/full/path/to/css.sprites.php');
$smushit = new css_sprites();
$smushit->smushit('/full/path/to/image');
?>

After this instead of initial image (if there are sufficient rights to replace it) we will have
its optimized copy. It's better to perform this operation not on live images but on their
copies - to have opportunity to roll back all changes.

Protected installation. Web Optimizer can be installed into any folder (inside you
website) and protected with htpasswd. To do this you need to enable:
Use .htaccess -> Protect Web Optimizer installation via htpasswd ->
Yes

With this option you must be sure that Cache Directories are located outside the Web
Optimizer folder (otherwise the whole website will be broken for all visitors except you).
With HTTP Basic Authorization Web Optimizer will use the same username/password
you entered on installation (or on settings configuration).
The most effective optimization requires better understanding of all optimization techniques
and principles.

In following sections you will learn how Web Optimizer 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 Web Optimizer API:

Integration with Website

Optimization algorithm
Web Optimizer plugins API
Web Optimizer can be integrated into your website in several ways:

Buffered approach
Raw approach
Complex approach

Buffered approach
It's the most common way. First call of Web Optimizer (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 Web Optimizer 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 Web Optimizer 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, Web Optimizer 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:
/* 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 Web Optimizer call.

Source files changes

After installation Web Optimizer adds few lines of code in one or more files (depending on
CMS) that responds for HTML output. In most cases it is only index.php that becomes
changed.

Note that automatic installation always makes backup of all modified files so you can always
review changes or restore to original versions of files. Backup filenames gets extension
.backup. For example original index.php file will become index.php.backup after
installation.

.htaccess changes
When .htaccess support is enabled in configuration, Web Optimizer 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

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
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
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

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]

Web Optimizer can be used in deployment process of any website in static mode. Just open
all website pages when Web Optimizer 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/
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.

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.

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 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).
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.

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.

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.

Web Optimizer 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 Web Optimizer 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 Web Optimizer 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 Web Optimizer
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. Web Optimizer 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 Web Optimizer to have all these properties in
one CSS selector (no ancestors), it's also better for accelerating rendering of your pages
in browsers (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 Web Optimizer successfully.
Exclude unused CSS rules or move rarely used rules for pages where they are used. Web
Optimizer 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. Web Optimizer 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 Web Optimizer to analyze your CSS code structure and prepare
better CSS Sprites.
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 Web Optimizer installation.

onUninstall — actions that are applied on Web Optimizer uninstall.
onBeforeOptimization — actions that are applied to the web page content before any
optimization actions are performed by Web Optimizer.
onAfterOptimization — actions that are applied to the web page content after all
optimization actions are performed by Web Optimizer (can be cached).
onCache — actions that are applied every time to the web page content if it's cached (on
output of cache content).

There is general example of Web Optimizer 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;
}
}
/* class declaration ends */
}
$web_optimizer_plugin = new web_optimizer_plugin_your_cms_here();
 ?>

Good example of Web Optimizer plugin is Joomla! 1.5.x plugin (http://code.google.com

/p/web-optimizator/source/browse/trunk/plugins/joomla15.php) .

Steps to install your plugin:

Place your plugin (PHP file) into plugins folder of Web Optimizer installation.
Add file name (w/o .php) of your plugin to config.webo.php (option ['plugins'], the last
one).
Start installation process.

Note that Web Optimizer 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 — Web
Optimizer detects this file and applies it during installation to config.webo.php.
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
Web Optimizer activity on your website.

If you stumbled across a problem during Web Optimizer 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.
Sometimes Web Optimizer 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 Web Optimizer 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) Web Optimizer 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) Web
Optimizer has an option for website root. Usually it's computed automatically.
If CGI environment is setuped completely incorrectly (i.e.
$_SERVER['DOCUMENT_ROOT' isn't defined, and environmental variables
SCRIPT_NAME, SCRIPT_FILENAME are defined regarding internal PHP
process) Web Optimizer 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 Web
Optimizer interface, usually all paths are listed as the first parameters to set.

If you need to check whether Web Optimizer 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 (starting from version 0.5.2). Web Optimizer doesn't parse content
if there is no such string.

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 Web Optimizer doesn't work if there are no such sings.

If you can't find any traces of Web Optimizer you need to re-check its calls in files of your
CMS and maybe also repeat Web Optimizer installation (Web Optimizer can apply all
required changes to CMS files by automatically).

To get information about required changes you need to disable auto-rewrite during Web
Optimizer installation (so all information will be outputted on stage 3):
Changing /index.php -> Enable auto-rewrite -> No

and open tab Required changes on the last stage.

Also you can check in Web Optimizer 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 Web Optimizer for your website.

If this doesn't help please check if there are any other plugins which can gzip content (so
Web Optimizer 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.
Usually it relates to double gzipping of the HTML document. The first can be performed by
Web Optimizer, and the second - by CMS or by web server.

To resolve this issue you need to disable gzip in CMS or in Web Optimizer:
Gzip Options -> Gzip HTML -> No

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).

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 Web Optimizer options one-by-one to
find out the right combination or the clue. You should start with the root settings (Minify
Options and Gzip Options) for all three groups (CSS, JavaScript, HTML) of client side
optimization actions and move forward in enabling more detailed settings (i.e., External
and inline scripts, Far Future Expires, or CSS Sprites).

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
External and inline scripts -> Enable external and inline styles merging
-> No

or minify for CSS files

Minify Options -> Minify and combine 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:
External and inline scripts -> Exclude file from merging -> List of files
 separated by space

So you can find files that cause incorrect Web Optimizer behavior and just exclude them
from optimization process (or make them standard-complaint with jigsaw.w3.org/css-
validator/ (http://jigsaw.w3.org/css-validator/) and try once more).

In some cases installation Web Optimizer can result in disappeared or broken background
images. To resolve this issue you need to detect what initial background images cause
incorrect Web Optimizer 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:
CSS Sprites -> Apply CSS Sprites -> No

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 Web
Optimizer installation there is no such form, then there are issues with client side logic
(JavaScript) and not with design itself.

To find out the issue you can start with disabling minify for JavaScript files:
Minify Options -> Minify JavaScript files -> No

Then (if troubles still occur) you can try to exclude files one-by-one:
External and inline scripts -> Exclude file from merging -> 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 adition you can try to exclude inline JavaScript from merging

External and inline scripts -> Enable inline JavaScript merging -> No

and place combined JavaScript file in the beginning of the page

External and inline scripts -> Force moving all merged scripts to
&lt;/head> -> No

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 Web Optimizer is located, and if protection
for Web Optimizer installation is enabled:
Use .htaccess -> Protect Web Optimizer installation via htpasswd -> Yes
So you need to move cache folders outside Web Optimizer installation (i.e. to the root
directory cache, accessible via web server to write into) or disable protection for Web
Optimizer installation:
Use .htaccess -> Protect Web Optimizer installation via htpasswd -> No
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 Web Optimizer configuration:
Multiple hosts -> Allowed hosts -> List of hosts separated by space

And enable support for multiple hosts:

Multiple hosts -> Enable multiple hosts -> Yes

Web Optimizer 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 Web
Optimizer 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.

Web Optimizer 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

In this case you can use chained optimization:

Download home page (raw HTML) into cache directory as compressing.php.

Include into compressing.php Web Optimizer calls.
Redirect to compressing.php with GET parameter (web_optimizer_stage).
Compressing.php redirect before merging CSS Sprites, after p16 in CSS Spites logic
(repeat-x, repeat-y, no-repeatb, no-repeatr), after all CSS Sprites are ready and after
data:URI are ready (total 5 redirects).
Remove compressing.php.
Update existing index.php (all cached files are already exist).
Please try to resolve your problem with troubleshooting sections first.

If your problem is not described there, try to search you issue (http://code.google.com
/p/web-optimizator/issues/advsearch) in a project issues list (http://code.google.com
/p/web-optimizator/issues/list?can=1&cells=tiles) . Most likely, your problem is well known
and will be solved in one of the nearest updates. If you did not found description of your
problem there, feel free to report it via New issue form (http://code.google.com/p/web-
optimizator/issues/entry) (Google account is required). All severe issues are closed in about
one day (usually just several hours). Please, create separate issues for each unsolved problem
you have.

Customers who have purchased Premium Support 24/7 can also resolve their problems in
interactive mode using our contact information (http://www.web-optimizer.us/about
/contacts.html) .