Setting up and using Web Optimizer

While the release of version 0.5 of a web application that automates client optimization for PHP sites is postponed for some indefinite time, we decided to prepare a small overview of the current settings and capabilities of the application.

Features of work

Web Optimizer intercepts the output HTML document and converts it to its optimal form. In particular, the entire head section is analyzed for CSS and JavaScript files, and when static hosts exist, images are distributed over them (the addresses of images change), and blocks with ads and counters are transferred before </body> (again, only enable the corresponding setting). Also, HTML is minimized (unnecessary line breaks and indents are removed, comments can be deleted, and in general all unnecessary characters, but these are resource-intensive operations, and by default they are turned off).

Download application

code.google.com/p/web-optimizator/downloads/list

Configuring Web Optimizer

Below are the settings available in Web Optimizer version 0.4.9.7 (they will be included in 0.5 without any changes):

Caching directories Here you can set the paths to the caching directories (on the file system) in which the saved reduced CSS, JavaScript and HTML files will be written. Also here you can determine the root directory of the site (necessary for the correct calculation of all relative paths). By default, all caching directories are assigned to the cache folder in the Web Optimizer itself.
Compression Settings This group of settings is responsible for combining and minimizing JavaScript and CSS files. By default, JavaScript files are combined and minimized using JSMin (or YUI Compressor, if java is available). You can also compress JavaScript using the Dean Edwards Packer (it is the best choice in the absence of gzip compression). Here you can also configure how to minimize the output HTML-code (simple deletion of extra line breaks and spaces, “stretching” in one line and (li) deleting comments). Conditional comments for IE are not affected in any way.
Include external javascript files . Web Optimizer can load external JavaScript files (called from other domains), as well as internal code (enclosed directly in <script> ). Here you can customize and “glue” the CSS code located in <style> (enabled by default). You can also specify (separated by a space) file names (names, not full paths) that should be excluded from the merge logic. During the testing phase, it was discovered that it was impossible to combine the source libraries of the Tiny MCE and the FCE Editor, so they are excluded by default.
Unobtrusive JavaScript . This group contains settings that are responsible for non-blocking downloading of various JavaScript options. In particular, you can put the combined JavaScript file before <body> (or even cause it to load on the DomContentLoaded event), you can put the download of some counters, ads and informers to the bottom of the document (after the JavaScript code, the resulting HTML code is inserted into the original place on the page, ensuring the gradual appearance of additional ad units after the main content has been loaded).
Do not check the time change . This setting allows you not to check when loading every page the time and the content of all files, only the existence of cached versions. Due to this, we get a significant increase in server performance (by default, the setting is enabled). In the case of debugging or very frequent changes to the original JavaScript-or CSS-files, it is better to disable the setting.
Gzip compression (archiving) . This group of settings controls whether JavaScript, CSS- or HTML-files are sent to the browser as archives. Gzip-compression saves 70-85% of traffic when transferring text files, but it may be (especially in the case of compression through PHP and high-loaded projects) that is not very optimal for the server. In any case, whenever possible, all compression settings are placed in .htaccess (for CSS- and JavaScript- in a static form). When it is impossible to change .htaccess gzip-versions of JavaScript and CSS-code are saved in caching directories, which also reduces the load on the processor (via PHP) to a minimum.
"Eternal" caching . The settings of this group are responsible for setting caching headers for JavaScript-, CSS-, HTML- or static files (images and animations). For images and animations, the corresponding rules are placed only in .htaccess ; for other files, they are duplicated as needed via PHP. By default, static files are set to a caching period of 10 years (when files change, new versions have a different name, based on the md5 hash of the total file contents). For HTML files, it is possible to manually set the appropriate expiration date of the client cache. The difference between this setting and the following group (server-side caching of HTML files) is that the HTML output is not saved on the server in any way, we only indicate to browsers that they may not re-request HTML documents for a certain time. Whether browsers will follow this directive or not remains entirely in their conscience.
Caching HTML files . To substantially speed up the server side, in almost all cases, server caching is required. And almost all CMS support it (at one level or another). Web Optimizer offers an alternative option (for those cases when the current system is not able to do this, or a more “tough” solution is needed): simple caching of HTML documents. When this setting is enabled, HTML files are saved in the caching directory and are sent the first time Web Optimizer is called, without processing the internal logic of the system. Naturally, the cache expiration date is taken into account. It is also possible to issue not the entire document at once, but the first 1-2 Kb (by resetting the document), and then calculate the rest. This can help visually speed up page loading on some environments. To configure caching, there is a list of parts of the site URL that need to be excluded (it is possible to set regular expressions) and a list of robots (USER AGENTS) for which you need to force the output of the caching file.
CSS Sprites . Perhaps the most technologically powerful and most controversial part of Web Optimizer. Proper use of sprites allows an order of magnitude (!) To reduce the number of requests to the server when loading a page with a large number of background images (from 20-100 to 3-10). However, there are some problems with the display of combined images for IE6 (images are created by default in the 32-bit palette, and IE6 cannot correctly handle transparency for such PNGs), problems are eliminated by excluding IE6 from creating sprites (with the appropriate settings) or using opaque images. Also available are settings for using JPEG instead of PNG for full-color images, “aggressive” mode ( repeat-x and repeat-y will be combined without taking into account the actual size of the containers), adding free space (avoiding rudiments when scaling such images in modern browsers).

To improve the stability of the work, the “limited” memory mode is added: if the PHP process has less than 64 MB of memory (this is enough to create a sprite of about 3000 by 3000 pixels, which is quite enough for most sites), then images with an area of more than 4000 pixels will have excluded. There is also a setting for excluding large images by their linear dimensions (in pixels, the default is 900) and direct exclusion of files (again, file names are specified, not the full path to them) from the process of creating CSS Sprites.
data: URI . The data:URI technology allows you to include background images directly in the CSS file. Supported by all modern browsers and IE8. It has an image size limit of 24 KB (32 KB data:URI code is derived from 24,576 bytes of the binary code). When creating a data:URI for IE7, hacks are inserted into the CSS file, which makes the site design unchanged for these browsers. Also, when creating a data:URI it is highly desirable to optimize images. This is done using the smush.it API. To correctly optimize images, you need write access for the web server to the images themselves. This setting is disabled by default, because it makes sense to optimize images only once, and use the ready-made result on subsequent builds of CSS files.
Multiple hosts . This setting allows you to enable the distribution of images on static hosts. Each image will always correspond to one host (to avoid clogging the cache with the same images from all available hosts). To use this download acceleration mechanism, you must register all alternative hosts in the DNS for the IP address that will serve them (usually the current site) and add aliases to the main site in the form of these hosts in the server configuration. For example:
```
  ServerAlias i1.site.ru
 ServerAlias i2.site.ru 
```
After that, you can add i1 i2 to the list of hosts for Web Optimizer and make sure that the images are scattered across these hosts. When installing Web Optimizer, a number of hosts are automatically checked for the possibility of their use as alternative (with the same site root), and all manually specified hosts are checked for availability (test images are loaded from them). It should be borne in mind that if you turn on the “safe” installation (about it below), the host check becomes inaccessible and you will need to register it manually without restarting the Web Optimizer setting.
Using .htaccess . Most of the gzip-compression and caching settings can be recorded in your server's configuration file to avoid additional work on the server-side scripts. This can be done using the .htaccess file (if necessary, you can later transfer all the settings yourself to the httpd.cond file). Web Optimizer automatically checks available modules and configures the entry to . htaccess . htaccess (of course, for this, the latter must be available for writing). mod_gzip , mod_deflate and mod_filter are responsible for on-the-fly file compression, mod_rewrite and mod_mime are for static archiving. mod_headers and mod_setenvif - for ensuring correct processing of compressed files on proxying servers and in old browsers. mod_expires - for exhibiting cache eagolovkov. It is also possible to locate .htaccess either in the site directory (this is useful if there are several sites on different directories on the same host) or at the very root of the site. By default, both locations are the same. It is also possible to protect a Web Optimizer installation with .htpasswd . In this case, to access the settings, you will need to enter your login and password through the HTTP Basic Authorization window in the browser (this allows Web Optimizer to be placed in an arbitrary directory within the site, after placing the caching directories outside the protected area).
Logo Web Optimizer . At the moment, this group of settings is not used at all. Maybe in the future, a small print “Accelerated with the Web Optimizer” will be added to each site with a link to the project. But so far no decisions have been made on this topic.
Automatic change /index.php . Web Optimizer supports automatic change of files required for correct operation for several dozen CMS (in the case of an unknown system, its name is displayed as CMS 42, and the root index.php always changed). Before the file is automatically modified, chain site optimization is launched to create all caching files and to avoid long loading of the main page of the site for the first time.

Examples of using

Web Optimizer is quite a powerful and flexible tool for client optimization of an arbitrary site. But correct setting it requires care and understanding of the desired result. Let's look at some of the most characteristic changes in the default configuration.

Connection of common (or) JavaScript or CSS file (s) on all pages . Quite often we can insert on all pages some kind of common JavaScript library or style sheet, which is necessary for the entire site. In order for Web Optimizer not to try to merge this common file with all others, you can exclude it in the configuration:
```
  Include external JavaScript files and embedded code -> Exclude files from a union -> comma-separated list of files 
```
Disable CSS Sprites . There are cases when, due to a number of reasons (lack of proper support for GDLib on hosting, memory limitations, etc.) an attempt to create CSS Sprites results in a “white screen” in the browser (and the site stops opening). In such cases, the complete disabling of the CSS Sprites usually helps:
```
  CSS Sprites -> Apply CSS Sprites -> No 
```
If desired, CSS Sprites can be created manually via Auto Sprites , specifying a minimized CSS file (or a combined source file).
Incorrect display of the site in IE6 . In this case, simply turning off sprites for IE6 can help:
```
  CSS Sprites -> Exclude IE6 (via hacks) from creating CSS Sprites -> yes 
```
It is also possible that IE6 incorrectly handles the merging of styles (and the background overlay along with a number of other hacks). Then disabling data:URI can help
```
  Data: URI -> Apply data: URI -> no 
```
or generally combining CSS files:
```
  Compression settings -> Minimize and merge CSS files -> no 
```
Secure installation . Web Optimizer can be installed in an arbitrary directory (inside the site) and protected with a password via htpasswd . To do this, enable:
```
  Using .htaccess -> Protect Web Optimizer installation with htpasswd -> yes 
```
At the same time, you need to make sure that the are located outside the folder with the Web Optimizer itself (otherwise everything will fall apart for all site visitors except yourself).
Connection for static site . Web Optimizer can be used for any site for which PHP is available. If you already have a static site, then you can enable the Web Optimizer call at the very top of each page (or index.php ):
```
  <? php
 require (/path/k/Web/Optimizer/web.optimizer.php);
 ?> 
```
and then at the very bottom of the page:
```
  <? php
 $ web_optimizer-> finish ();
 ?> 
```
Since in the planned mode (after creating all the caching files), Web Optimizer logic execution takes 5-10ms, this will not affect the server side of the download, but the client side will be significantly accelerated. You just have to make sure that the pages to which you add Web Optimizer calls will be processed through the PHP interpreter (they will have the extension .php or some other one defined by the server settings).
Schedule optimization . Already, Web Optimizer can be built into the scheme for publishing an arbitrary site in “static” mode. To do this, you need to open all the pages of the site with the installed Web Optimizer, and then just copy the output HTML and caching directories. Suppose that Web Optimizer is installed on dev.site.ru By running, for example, wget
```
  wget -d -r -c http://dev.site.ru/ 
```
we get an optimized "cast" of the site, which can be downloaded already in the working system.
Gluing HTML in one line . As already described above, Web Optimizer can “trace” all the output HTML in one line. To do this, enable
```
  Compression Settings -> Compress HTML to 1 line -> yes
 Compression Settings -> Delete HTML Comments -> Yes 
```
It should be immediately noted that these settings add additional load on the server (correct regular expression is quite resource-intensive) and can lead to cutting out some JavaScript-code (which is inserted through comments). Also, the code inside the script , textarea , pre will not change (in accordance with the specification). Therefore, you need to use these settings with great care.
Image optimization through smush.it . The smush.it service is developed by Yahoo! and Google and allows you to optimize the size of background images automatically. It is possible to connect image optimization through the CSS Sprites library (this example in version 0.4.9.7 does not work yet, but is already available in SVN and will be included in 0.5):
```
  <? php
 require ('/ full / path / to / css.sprites.php');
 $ smushit = new css_sprites ();
 $ smushit-> smushit ('/ full / path / to / image');
 ?> 
```
as a result, instead of an image (if you have rights to change it), we will get an optimized copy of it. It is better to carry out not on a group of working images, but on their copies, so that you can roll back the changes.

Download application

code.google.com/p/web-optimizator/downloads/list

Source: https://habr.com/ru/post/62009/

All Articles

Setting up and using Web Optimizer

Features of work

Configuring Web Optimizer

Examples of using

More articles: