Статьи и переводы по оптимизации скорости загрузки сайтаhttp://i.webo.in/x.pnghttp://webo.in/speed/http://webo.in/Sat, 06 Mar 2010 17:32:40 GMTFeedCreator by DreamwinDruinfo@webo.name (WEBO Software)Copyright 2008-2010, WEBO Software240http://webo.in/articles/habrahabr/112-minify-combine-javascript-troubles/http://webo.in/articles/habrahabr/112-minify-combine-javascript-troubles/<p class="right"><a href="http://www.webogroup.com/home/site-speedup/"><img src="http://wss.2static.it/wp-content/uploads/2010/01/005-150x150.png" alt="сжатие текстовых файлов" title="сжатие текстовых файлов" width="150" height="150"/></a></p><p>После публикации ряда заметок на тему <a href="http://webo.in//articles/habrahabr/11-minifing-javascript/">сжатия</a> и <a href="http://webo.in//articles/habrahabr/70-ant-optimization-automation/">объединения JavaScirpt-файлов</a> стоит все же осветить наиболее характерные проблемы этого самого сжатия и объединения.</p><p>Начнем с простого: как JS-сжатие способно испортить нам настроение. И как его поднять обратно :)</p><h3>JavaScript-сжатие</h3><p>Вообще стоит сразу упомянуть, что сжатие JavaScript-файлов даст нам всего лишь 5-7% уменьшение размера относительно обычного gzip, который можно использовать <strong>везде</strong> (нет, реально, везде &mdash; начиная от <a href="http://code.google.com/p/web-optimizator/wiki/IntegrationWithWebsite" rel="nofollow">конфигурации Apache через .htaccess</a> и заканчивая <a href="http://webo.in//articles/habrahabr/07-gzip-all/">статическим сжатием через mod_rewrite + mod_mime</a> и <a href="http://webo.in//articles/habrahabr/58-nginx-reverse-proxy/">конфигурацией nginx</a> (или LightSpeed). Но вернемся к теме топика: мы хотим минимизировать JavaScript-файлы, как это лучше всего сделать?</p><p>Два года назад был произведен <a href="http://webo.in/articles/habrahabr/11-minifing-javascript/">обзор текущих инструментов</a>, за это время ситуация не сильно изменилась (разве что появился <a href="http://code.google.com/closure/compiler/" rel="nofollow">Google Compiler</a>). Но все по порядку.</p><ul><li>Начнем с простого. <a href="http://www.crockford.com/javascript/jsmin.html" rel="nofollow">JSMin</a> (или его клон, <a href="http://crisp.tweakblogs.net/blog/cat/716" rel="nofollow">JSMin+</a>). Работает очень универсально (по принципу <a href="http://ru.wikipedia.org/wiki/Конечный_автомат" rel="nofollow">конечных автоматов</a>). Почти всегда минимизируемый файл даже исполняется. Дополнительный выигрыш (здесь и далее относительно простого gzip) &mdash; до 7% в случае продвинутой версии, т.е. совсем мало. Процессор кушает умеренно (продвинутая версия, JSMin+ сильнее, и память значительно), но не анализирует область видимости переменных, в связи с чем не умеет сокращать их длину. В принципе, может применяться почти для всех скриптов, но иногда возможны нюансы. Например, удаляются условные комментарии (это лечится) или неверно распознаются различные конструкции (например, <code>+ +</code> преобразуется в <code>++</code>, это ломает логику), это тоже лечится, но сложнее.</li><li><a href="http://developer.yahoo.com/yui/compressor/" rel="nofollow">YUI Compressor</a>. Наиболее известный (до недавнего времени еще и наиболее мощный) инструмент для сжатия скриптов. Базируется на движке Rhino (насколько известно, корни движка где-то рядом с фреймворком Dojo, т.е. очень-очень давно). Сжимает скрипты отлично, работает над областью видимости (может уменьшать длину переменных). Степень сжатия &mdash; до 8% сверх gzip, однако, процессор кушает будь здоров (в связи с использованием виртуальной машины Java), так что с использованием в режиме онлайн стоит быть осторожным. Также в связи с уменьшением длин переменных возможны различные проблемы (и их даже потенциально больше, чем для JSMin).</li><li><a href="http://code.google.com/closure/compiler/" rel="nofollow">Google Closure Compiler</a> появился недавно, но уже завоевал доверие общественности. Базируется на том же движке Rhino (ага, нет ничего нового под луной), но использует более продвинутые алгоритмы уменьшения размера исходного кода (<a href="http://javascript.ru/optimize/google-closure-compiler" rel="nofollow">отличный обзор во всех деталях</a>), до 12% относительно gzip. Но тут стоит быть втройне острожным: может быть вырезана весьма существенная часть логики, особенно при агрессивных преобразованиях. Однако для <a href="http://stackoverflow.com/questions/1691861/jquery-compiled-with-google-closure-compiler" rel="nofollow">jQuery уже используется этот инструмент</a>. По процессорным издержкам он, видимо, еще тяжелее YUI (данный факт не проверялся).</li><li>и <a href="http://dean.edwards.name/packer/" rel="nofollow">Packer</a>. Данный инструмент уже уходит в прошлое в связи с развитием каналов связи и отставанием процессорных мощностей: ибо сжатие в нем (алгоритм, аналогичный gzip) производится за счет JavaScript-движка. Это обеспечивает очень значительное (до 55% без gzip) уменьшение размера кода, но дополнительные издержки вплоть до 500-1000 мс на распаковку архива. Естественно, это становится не актуальным, если процессорные мощности ограничены (привет, IE), а скорость соединения весьма высока (+ gzip уже почти везде применяется и поддерживается). Дополнительно, данный метод оптимизации наиболее склонен к различным багам после минимизации.</li></ul><p>Резюме здесь: проверяйте JavaScript не только на том сервере, где он разрабатывается, но и после оптимизации. Лучше всего &mdash; по одним и тем же unit-тестам. Узнаете много нового про описанные инструменты :) Если это не критично, то используйте просто gzip (лучше всего статический с максимальной степенью сжатия) для обслуживания JavaScript.</p><h3>Проблемы объединения JavaScript-файлов</h3><p>После того как мы разобрались со сжатием JavaScript-файлов, хорошо бы затронуть тему их объединения. Средний сайт имеет 5-10 JavaScript-файлов + несколько встроенных (inline) кусков кода, которые могут так или иначе вызывать подключаемые библиотеки. В итоге &mdash; 10-15 кусков кода, которые можно объединить вместе (плюсов от этого море &mdash; начиная от скорости загрузки на стороне пользователя и заканчивая отказоустойчивостью сервера под DDoS &mdash; тут каждое соединение будет на счету, даже статическое).</p><p>Но вернемся к баранам. Сейчас мы будем разговаривать про некоторую автоматизацию объединения &laquo;сторонних&raquo; скриптов. Если вы имеете к ним полный доступ (и разбираетесь в веб-разработке), то не составляет большого руда пофиксить проблемы (или исключить ряд проблемных скриптов из объединения). В противном случае (когда набор скриптов никак не хочет объединяться без ошибок) нижеследующий подход как раз для вас.</p><p>Итак, у нас есть 10-15 кусков кода (часть из них в виде встроенного кода, часть &mdash; в виде внешних библиотек, которые мы можем так же &laquo;слить&raquo; вместе). Нам нужно гарантировать их независимую работоспособность. В чем она заключается?</p><p>Если у нас есть JavaScript-ошибка в файле, то браузер прекращает выполнение этого файла на ошибке (некоторые наиболее древние еще и прекращают выполнение <strong>всех</strong> JavaScript-файлов на странице в этом случае, но мы не совсем про это разговариваем). Соответственно, если первая же библиотека, которую мы хотим объединить в общий файл, выдает ошибку, то во всех браузерах у нас клиентская логика после объединения развалится. Грустно.</p><p>Дополнительно стоит отметить, что встроенный (inline) код достаточно тяжело отлаживать. Его можно либо исключить из объединения (например, расположив вызов объединенного файла до или после кода), или же при его использовании вообще отменить объединение файлов.</p><h3>Обратная совместимость</h3><p>Что мы можем с этим поделать? Наиболее простой путь: исключать проблемные файлы (при этом ошибки могут проявляться только на этапе объединения, отдельные же файлы могут отрабатывать на ура) из логики объединения. Для этого нужно будет отслеживать, в каком месте происходить ошибка, и собрать конфигурацию для объединения для каждого такого случая.</p><p>Но можно поступить несколько проще. Для JavaScript мы можем воспользоваться конструкцией <code>try-catch</code>. Ага, мысль уловили? Еще нет? Мы можем все содержимое файлов, которые объединяем, заключать в <code>try {}</code>, а в <code>catch(e) {}</code> вызывать подключение внешнего файла примерно следующим образом:</p><blockquote><pre>try { ... содержимое JavaScript-библиотеки ... } catch (e) { document.write('исходный вызов JavaScript-файла'); // или console.log('нужно исключить из объединения JavaScript-файл'); }</pre></blockquote><p>При этом у нас у пользователя загрузится один-единственный файл, если никаких проблем не возникло. Если же ошибки были, то подключатся все внешние проблемные файлы в прежнем порядке. Это и обеспечит обратную совместимость.</p><h3>Проблемы производительности</h3><p>Очевидно, что данный подход не является &laquo;самым правильным&raquo;. Наиболее логичным было бы определить JavaScript-ошибки, их устранить, и загружать для всех пользователей один файл. Но не всегда это возможно. Также стоит учесть, что <code>try-catch</code> конструкция тяжеловата для исполнения в браузерах (добавляет 10-25% ко времени инициализации), стоит быть с ней осторожным.</p><p>Но описанный подход может замечательно применяться для отладки конкретно объединения JavaScript-файлов: ведь он позволяет точно определять, какие файлы &laquo;сыпятся&raquo; (если файлов несколько десятков, это очень и очень полезно).</p><h3>Небольшое резюме</h3><p>После дополнительной минимизации JavaScript-файлов обязательно проверяйте их функциональность. А отладку корректности объединения JavaScript-файлов можно легко автоматизировать, или даже настроить обратную совместимость в случае невозможности отладки конкретных скриптов.</p><h3>Читать дальше</h3><ul><li><a href="http://webo.in/articles/habrahabr/23-high-performance-ajax-applications/">Высокопроизводительные AJAX-приложения</a></li><li><a href="http://webo.in/articles/habrahabr/11-minifing-javascript/">JavaScript: жать или не жать?</a></li><li><a href="http://webo.in/articles/habrahabr/05-delayed-loading/">Практический JS: «отложенная» загрузка</a></li><li><a href="http://webo.in/articles/habrahabr/50-fast-fast-javascript/">Быстрый-быстрый JavaScript</a></li><li><a href="http://webo.in/articles/habrahabr/12-javascript-optimization/">Практический JS: разгоняем все, что движется</a></li><li><a href="http://webo.in/articles/habrahabr/04-speed-up-events-handlers/">Практический JS: ускоряем обработку событий</a></li><li><a href="http://webo.in/articles/habrahabr/18-solving-internet-explorer-memory-leaks/">Практический JS: избавляемся от утечек памяти в IE</a></li></ul> Sat, 06 Mar 2010 00:00:00 GMThttp://www.habrahabr.ru/blogs/client_side_optimization/86443/#commentshttp://webo.in/articles/all/2010/04-speed-for-speed/http://webo.in/articles/all/2010/04-speed-for-speed/<p class="right" style="margin:10px 0 10px 10px"><img src="http://www.webogroup.com/i/promo/speed-for-speed/prize-1.png" alt=""/></p><p>Быстрых сайтов должно быть больше. Чтобы это стало реальностью, со <strong>2 по 31 марта 2010 года</strong> WEBO Software проводит конкурс обзоров ускорения сайтов &mdash; &laquo;Скорость ради скорости&raquo;.</p><p>Среди призов: <strong>широкоформатный монитор</strong> с быстрой матрицей, быстрая <strong>веб-камера</strong>, молниеносная <strong>мышь</strong> и подписки на <a href="http://www.webogroup.com/home/site-speedup/">WEBO Site SpeedUp</a>.</p><p>Для участия в конкурсе достаточно <a href="http://www.webogroup.com/home/download/">загрузить WEBO Site SpeedUp</a>, настроить его (используя тестовый ключ для полной версии) и написать об этом. Ссылку на обзор нужно выслать на <a href="http://webo.in/articles/all/2010/04-speed-for-speed/mailto:free@webo.name">free@webo.name</a>.</p><p>Список всех обзоров будет опубликован на сайте <a href="http://www.webogroup.com/">www.webogroup.com</a>. По результатам первого тура будут отобраны 10 самых информативных обзоров, и победителей выберут на народном голосовании.</p><p><a href="http://www.webogroup.com/home/offers/speed/">Более подробно об акции можно прочитать на сайте www.webogroup.com</a>.</p><h3>О компании WEBO Software</h3><p><a href="http://www.webogroup.com/">WEBO Software</a> &mdash; инновационная компания, главной целью которой является разработка решений для оптимизации производительности веб-сайтов любой сложности. Ее основной продукт, <a href="http://www.webogroup.com/home/site-speedup/">WEBO Site SpeedUp</a>, является мировым лидером в ускорении загрузки сайтов на основе PHP и имеет тысячи реальных установок. Миссией WEBO Software является обеспечение максимальной производительности каждого сайта.</p> Fri, 05 Mar 2010 00:00:00 GMThttp://www.habrahabr.ru/blogs/web_optimizator/86035/#commentshttp://webo.in/articles/wsd2009/vrml-vml-svg-canvas/http://webo.in/articles/wsd2009/vrml-vml-svg-canvas/<h3>Предыстория векторных форматов</h3><p>В 90х годах прошлого века было довольно много попыток внести ясность в описание и представление векторных данных в вебе. Началось это примерно в 1994-1995 годах, когда несколько независимых групп разрабатывают и предлагают сначала спецификацию, а затем и плагины к браузерам для <a href="http://svf.org/svf1/" rel="nofollow">SVF (Simple Vector Format)</a>, <a href="http://www.w3.org/MarkUp/VRML/" rel="nofollow">VRML (Virtual Reality Markup Language)</a>.</p><p>Чуть позже, 19 августа 1998 года, была представлена альтернатива для CGM (Computer Graphic Metafile) &mdash; <a href="http://www.w3.org/TR/1998/NOTE-WebCGM-19980819/" rel="nofollow">Web CGM</a>,&nbsp;&mdash; которая бы позволила расширить сферу примнения данного формата.</p><p>VRML оказался самым жизнеспособным из всех представленных аналогов (наверное, в силу поддержки в Netscape), и был сначала утвержден в рамках стандарта <a href="http://www.web3d.org/x3d/specifications/vrml/VRML97Am1/" rel="nofollow">VRML97</a>, а затем преобразован в <a href="http://www.web3d.org/x3d/specifications/" rel="nofollow">X3D</a> в 2004 году.</p><h3>VML / PGML: немного истории</h3><p>Sun / IBM / Adobe 10 апреля 1998 года выкатывают свое решение для представления данных в векторном формате в вебе &mdash; <a href="http://www.w3.org/TR/1998/NOTE-PGML-19980410" rel="nofollow">PGML</a>. Microsoft тоже не дремлет и вместе с рядом крупных компаний предлагает буквально через месяц (13 мая) на <a href="http://www.w3.org/TR/NOTE-VML" rel="nofollow">рассмотрение W3C альтернативное решение &mdash; стандарт VML</a>. Дальше Microsof гнет свою линию и включает поддержку VML уже в IE 5.0 (в <a href="http://en.wikipedia.org/wiki/Internet_Explorer_5" rel="nofollow">марте 1999 года</a>).</p><p>Очевидно, что технология, обладающая такой мощной поддержкой в браузерах того времени просто так не могла умереть (в отличие от PGML, которая, по-видимому, поддерживается только в настольных приложений тех компаний, которые его выдвинули). И <a href="http://arstechnica.com/microsoft/news/2008/04/microsofts-office-open-xml-now-an-official-iso-standard.ars" rel="nofollow">в 2008 году VML окончательно закрепляется в качестве стандарта в составе Open Office XML</a>.</p><h3>Canvas: истоки</h3><p>История Canvas во многом отлична от упомянтых векторных стандартов. Во-первых, в 2005 году Apple предложила использовать <a href="http://developer.apple.com/mac/library/documentation/AppleApplications/Conceptual/SafariJSProgTopics/Tasks/Canvas.html" rel="nofollow">уже вендренную ею технику Canvas</a> для попиксельного изменения изображения внутри какой-то области (Canvas, холста). Эта идея была подхвачена Mozilla, которая интегрировала ее в Gecko 1.8 (Firefox 1.5 и выше), а позже и Opera (Opera 9.0 вышла с поддержкой Canvas).</p><p>Затем Canvas был включен в готовящийся стандарт Web Applications 1.0, который затем <a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html" rel="nofollow">вошел в состав HTML5</a>. Планируется, что поддержка Canvas пойдет в следующую версию IE.</p><h3>VML + SVG: векторные форматы</h3><p>На настоящий момент SVG поддерживается всеми современными браузерами. Для IE необходимо использовать эмуляцию всех методов через VML (либо создавать альтернативное приложение).</p><p>Для описания SVG используется XML формат. При этом, естественно, возможны любые преобразования получившегося изображения при помощи DOM-методов (т.е. можно использовать любую JavaScript-логику &laquo;поверх&raquo; векторных форматов).</p><p>Спектр использования векторной графики сейчас довольно широк: это отображение масштабируемых объектов, областей на картах, вывод графиков. Стоит отметить, что в силу XML-природы SVG может быть легко интегрирован с другими форматами, в частности, сейчас идет его интеграция с MathML. Также можно назвать одно &laquo;нестандартное&raquo; применение VML &mdash; для эмуляции полупрозрачности в PNG для IE. Для этого разработана специальная JavaScript-библиотека &mdash; <a href="http://www.dillerdesign.com/experiment/DD_belatedPNG/" rel="nofollow">DD_belatedPNG</a>.</p><h3>Canvas: растровые операции</h3><p>Основным отличием от SVG в Canvas является его чисто динамическая (можно использовать только при помощи JavaScript) и растровая (нет объектов и связе между ними) природа. Однако в некоторых случаях это только плюс (например, сложные области на картах было бы логичнее обводить при помощи растровой, а не векторной графики).</p><p>Для работоспособности в IE используется эмуляция с помощью VML.</p><p>Как и всякую популярную технологию, Canvas используют по поводу и без везде, где только можно. Например, для отображения в браузере произвольных шрифтов (поскольку корректная поддержка <code>@font-face</code> несколько запаздывает): <a href="http://typeface.neocracy.org/" rel="nofollow">typeface.js</a> (к слову есть более правильное с идеологической точки зрения решение данной проблемы - <a href="http://cufon.shoqolate.com/generate/" rel="nofollow">cufon</a>). Также хочется отметить пример портирование библиотеки Processing - <a href="http://processingjs.org/" rel="nofollow">Processing.js</a>. Множество других примеров использования технологии можно посмотреть на <a href="http://www.canvasdemos.com/" rel="nofollow">www.canvasdemos.com</a>.</p><h3>Заключение</h3><p>Если вы собираетесь использовать точечную (пиксельную) графику, то лучше Canvas для этой цели ничего не подходит. При работе с большими (по площади) векторными объектами лучше использовать SVG. Также будет необходимо дублировать всю функциональность через VML для IE 8 и ниже.</p><p>Спасибо за внимание. Вопросы?</p> Sun, 28 Feb 2010 00:00:00 GMThttp://www.habrahabr.ru/blogs/webstandards/77588/#commentshttp://webo.in/articles/wsd2009/vml-svg-canvas/http://webo.in/articles/wsd2009/vml-svg-canvas/<h3>VML / PGML: немного истории</h3><p>Sun / IBM / Adobe 10 апреля 1998 года выкатывают свое решение для представления данных в векторном формате в вебе &mdash; <a href="http://www.w3.org/TR/1998/NOTE-PGML-19980410" rel="nofollow">PGML</a>. Microsoft тоже не дремлет и вместе с рядом крупных компаний предлагает буквально через месяц (13 мая) на <a href="http://www.w3.org/TR/NOTE-VML" rel="nofollow">рассмотрение W3C альтернативное решение &mdash; стандарт VML</a>. Дальше Microsoft гнет свою линию и включает поддержку VML уже в IE 5.0 (в <a href="http://en.wikipedia.org/wiki/Internet_Explorer_5" rel="nofollow">марте 1999 года</a>).</p><p>Очевидно, что технология, обладающая такой мощной поддержкой в браузерах того времени просто так не могла умереть (в отличие от PGML, которая, по-видимому, поддерживается только в настольных приложений тех компаний, которые его выдвинули). И <a href="http://arstechnica.com/microsoft/news/2008/04/microsofts-office-open-xml-now-an-official-iso-standard.ars" rel="nofollow">в 2008 году VML окончательно закрепляется в качестве стандарта в составе Open Office XML</a>.</p><h3>SVG: немного истории</h3><p>SVG, будучи инициативой, исходящей конкретно от W3C, развивался как формат весьма динамично. В конце 1998 года была образована SVG Working Group, которая занялась разработкой этого формата, через полгода (в июле 1999 года) она предложила первый вариант спецификации, и уже в 2001 году увидел свет <a href="http://www.w3.org/TR/SVG10/" rel="nofollow">стандарт SVG 1.0</a>.</p><p>На данный момент основным работающим стандартом <a href="http://www.w3.org/TR/SVG11/" rel="nofollow">является SVG 1.1</a> (утвержденный в 2003 году). <a href="http://www.w3.org/Graphics/SVG/WG/wiki/Roadmap" rel="nofollow">В июне 2012 года</a> планируется предоставить полностью готовый SVG 2.0.</p><h3>Canvas: истоки</h3><p>История Canvas во многом отлична от упомянутых векторных стандартов. Во-первых, в 2005 году Apple предложила использовать <a href="http://developer.apple.com/mac/library/documentation/AppleApplications/Conceptual/SafariJSProgTopics/Tasks/Canvas.html" rel="nofollow">уже вендренную ею технику Canvas</a> для попиксельного изменения изображения внутри какой-то области (Canvas, холста). Эта идея была подхвачена Mozilla, которая интегрировала ее в Gecko 1.8 (Firefox 1.5 и выше), а позже и Opera (Opera 9.0 вышла с поддержкой Canvas).</p><p>Затем Canvas был включен в готовящийся стандарт Web Applications 1.0, который затем <a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html" rel="nofollow">вошел в состам HTML5</a>. Планируется, что поддержка Canvas войдет в следующую версию IE.</p><h3>VML + SVG: векторные форматы</h3><p>На настоящий момент SVG поддерживается всеми современными браузерами. Для IE необходимо использовать эмуляцию всех методов через VML (либо создавать альтернативное приложение).</p><p>Для описания SVG используется XML формат. При этом, естественно, возможны любые преобразования получившегося изображения при помощи DOM-методов (т.е. можно использовать любую JavaScript-логику &laquo;поверх&raquo; векторных форматов).</p><p>Спектр использования векторной графики сейчас довольно широк: это отображение масштабируемых объектов, областей на картах, вывод графиков. Стоит отметить, что в силу XML-природы SVG может быть легко интегрирован с другими форматами, в частности, сейчас идет его интеграция с MathML. Также можно назвать одно &laquo;нестандартное&raquo; применение VML &mdash; для эмуляции полупрозрачности в PNG для IE. Для этого разработана специальная JavaScript-библиотека &mdash; <a href="http://www.dillerdesign.com/experiment/DD_belatedPNG/" rel="nofollow">DD_belatedPNG</a>.</p><h3>Canvas: растровые операции</h3><p>Основным отличием от SVG в Canvas является его чисто динамическая (можно использовать только при помощи JavaScript) и растровая (нет объектов и связе между ними) природа. Однако в некоторых случаях это только плюс (например, сложные области на картах было бы логичнее обводить при помощи растровой, а не векторной графики).</p><p>Для работоспособности в IE используется эмуляция с помощью VML.</p><p>Как и всякую популярную технологию, Canvas используют по поводу и без везде, где только можно. Например, для отображения в браузере произвольных шрифтов (поскольку корректная поддержка <code>@font-face</code> несколько запаздывает): <a href="http://typeface.neocracy.org/" rel="nofollow">typeface.js</a> (к слову есть более правильное с идеологической точки зрения решение данной проблемы&nbsp;&mdash; <a href="http://cufon.shoqolate.com/generate/" rel="nofollow">cufon</a>). Также хочется отметить пример портирования библиотеки Processing &mdash; <a href="http://processingjs.org/" rel="nofollow">Processing.js</a>. Множество других примеров использования технологии можно посмотреть на <a href="http://www.canvasdemos.com/" rel="nofollow">www.canvasdemos.com</a>.</p><h3>Canvas против SVG</h3><p>На данный момент Canvas при решении большинства задач справляется с ними быстрее, чем SVG. Достаточно давно был разработан пример использования Canvas для <a href="http://www.ernestdelgado.com/gmaps/canvas/ddemo1.html" rel="nofollow">ряда задач Google Maps</a>. В нем зафиксирован прирост скорости в 200-500% (для всех браузеров, которые поддерживают Canvas).</p><p>Также можно <a href="http://intertwingly.net/stories/2006/07/10/penroseTiling.html" rel="nofollow">привести еще один тест</a> скорости отображения объектов в Canvas и SVG. Здесь SVG снова проигрывает.</p><p>Для уточнения вопросов производительности можно <a href="http://www.borismus.com/canvas-vs-svg-performance/" rel="nofollow">обратиться к исследованию</a>, установившему закономерность между производительностью SVG, Canvas и параметрами изображения. В результате оказывается вполне очевидным, что при увеличении числа объектов (для SVG &mdash; векторных) производительность SVG падает сильно (почти экспоненциально), а Canvas &mdash; остается на стабильном уровне. Здесь стоит отметить, что размер активной области при этом не изменяется.</p><p>Однако если мы начнем увеличивать область построения (размеры объектов), то тут векторный формат показывает себя во всей красе: производительность практически не меняется. Производительность Canvas падает (как и следовало ожидать) квадратичным образом от числа объектов (площадь активной области увеличивается квадратично).</p><p>Из этого можно сделать простой вывод: если вы собираетесь использовать точечную (пиксельную) графику, то лучше Canvas для этой цели ничего не подходит. При работе с большими (по площади) векторными объектами лучше использовать SVG. Также будет необходимо дублировать всю функциональность через VML для IE 8 и ниже.</p><p>Спасибо за внимание. Вопросы?</p> Sun, 28 Feb 2010 00:00:00 GMThttp://www.habrahabr.ru/blogs/webstandards/76607/#commentshttp://webo.in/articles/riw2009/quality-becomes-quantity/http://webo.in/articles/riw2009/quality-becomes-quantity/<h3>Быстрая оценка потенциала SEO для сайта</h3><p>В докладе идет речь, в первую очередь, о применении быстрых инструментов анализа для проверки, насколько качественно работает поисковое продвижение для небольшого сайта или насколько хорошо готов такой сайт к запуску продвижения в поисковых движках. Среди таких точек проверки (позволяющих быстро убедиться в готовности / качестве сайта с точки зрения SEO) можно назвать следующие.</p><ul><li>Файл robots.txt.</li><li>Заголовки и фрагменты текста в поиске.</li><li>Глубина индексации.</li><li>Внутренняя перелинковка.</li><li>Скорость загрузки.</li></ul><p>Давайте рассмотрим каждый из пунктов подробнее.</p><h3>Файл robots.txt</h3><p>Достаточно часто этот файл (расположенный в корне сайта) создают в соответствии со стандартами, поэтому тут проблемы маловероятны. На какие моменты стоит обратить внимание:</p><ul><li><code>User-Agent</code> &mdash; идентификатор браузера пользователя или поискового робота.</li><li><code>Disallow</code> директива позволяет исключить нежелательные страницы из индекса. Это могут быть как результаты внутреннего поиска, так и личный кабинет пользователей или раздел администратора. Также здесь можно исключить некоторые наиболее &laquo;тяжелые&raquo; страницы в плане серверной нагрузки.</li><li><code>Host</code> учитывает только Яндекс. Может быть полезно при использовании нескольких зеркал.</li><li><code>Sitemap</code> указывает на XML-файл карты сайта. Очень полезно при увеличении глубины индексации сайта при наличии нескольких (десятков, сотен) тысяч страниц.</li><li><code>Crawl-delay</code> устанавливает интервал захода поисковых роботов на сайт. Полезно для уменьшения нагрузки на сервер от индексации (в ночное время), либо для нивелирования влияния поисковых роботов на задержки для остальных посетителей сайта.</li></ul><p>Все указанные вещи можно быстро проверить либо самостоятельно, либо с помощью бесплатных инструментов, например, <a href="http://webmaster.yandex.ru/wmconsole/public_robots_txt.xml" rel="nofollow">webmaster.yandex.ru/wmconsole/public_robots_txt.xml</a>. Дополнительно при добавлении, например, в Яндекс сайта для индексации, поисковик может проверить возможность индексации данного сайта и сразу же выдать предупреждение в случае ее невозможности.</p><p>В следующем примере мы указываем для сайта <a href="http://webo.in/">webo.in</a> для всех поисковых роботов запрет на индексацию секции <code>/my/</code>, XML-файл с картой сайта и интервал между запросами страниц в 10 секунд.</p><blockquote><pre>User-agent: * Disallow: /my/ Sitemap: http://webo.in/sitemap.xml Host: webo.in Crawl-delay: 10</pre></blockquote><h3>Заголовки страниц</h3><p>Очень часто заголовки (тег <code>title</code>) страниц используют только для продвижения ключевых слов. Здесь стоит вспомнить, ваш сайт зарабатывает деньги не на поисковых роботах, а на живых пользователях. А пользователи достаточно враждебно реагирует на бессмысленные заголовки страниц.</p><p>Однако для улучшения качества поисковой выдачи для поисковых запросов сайта нужно иметь в виду, что поисковики показывают около первых 70 символов от заголовкка. Поэтому именно в них должен быть заложен основной призыв к потенциальному посетителю, чтобы он перешел из результатов поиска к вам на сайт.</p><h3>Фрагменты тексты в поиске</h3><p>Аналогичная ситуация обстоит и с фрагментами текста в поиске. Они показываются сразу под заголовками, и если пользователь сомневается, насколько может быть ему полезен данный сайт, то обязательно их просматривает. Здесь вы можете эффективно разместить до 150 символов.</p><p>Google берет этот текст из мета-тега <code>description</code>, Яндекс предпочитает текст страницы, обрамленный наиболее релевантной фразой. Для грамотного формирования этого фрагмента для Яндекса рекомендуется вставить 3-5 предложений с ключевой фразой и посмотреть, какое из них оказалось в поисковой выдаче. Затем его можно будет немного подкорректировать.</p><h3>Глубина индексации</h3><p>Глубина индексации сайта (числа проиндексированных страниц) влияет как на общий "вес" сайт при выдаче результатов поиска с него, так и позволяет показать сайт по большему количеству поисковых результатов (благодаря большему числу страниц).</p><p>Проверить ситуацию (и посмотреть на фактические страницы в индексе) можно, например, с помощью специализированных инструментов от поисковиков: <a href="http://webmaster.yandex.ru/" rel="nofollow">webmaster.yandex.ru</a> и <a href="http://www.google.com/webmasters/tools/" rel="nofollow">www.google.com/webmasters/tools/</a>.</p><h3>Проверяем ситуацию</h3><p>Почти все вышеперечисленные моменты можно быстро проверить в полуавтоматическом режиме с помощью соответствующих сервисов. Одним из таких сервисов является <a href="http://pr-cy.ru/" rel="nofollow">pr-cy</a>. На нем можно посмотреть:</p><ul><li>Состояние файла robots.txt.</li><li>PR / CY для сайта.</li><li>Проиндексированные страницы.</li><li>Внутренние ссылки на страницах.</li><li>Скорость загрузки</li></ul><h3>Внутренняя перелинковка</h3><p>Данный параметр косвенно влияет на глубину индексации (насколько быстро поисковики могут загрузить страницы вашего сайта) и прямо влияет на удобство его использование (насколько быстро можно найти требуемую информацию). К сожалению, полностью проверить последний момент автоматически довольно тяжело: необходимо иметь представление о целях пользователей.</p><p>Но ситуацию исправляет большое количество инструментов для построения дерева сайта. Все она расположены на <a href="http://code.google.com/sm_thirdparty.html" rel="nofollow">code.google.com/sm_thirdparty.html</a>, можно рассмотреть использование XENU или SiteXpert. Оба этих инструмента позволяют посмотреть &laquo;дерево&raquo; сайта таким, как видят его поисковые роботы, и увидеть, насколько глубоко расположены все страницы сайта. Это позволит сразу увидеть потенциальные проблемы с перелинковкой и их оперативно устранить.</p><h3>Скорость загрузки</h3><p>Не последнюю роль в анализе потенциала SEO для сайта играет скорость загрузки страниц. Для поисковых роботов важна серверная составляющая (насколько быстро сервер справляется с созданием HTML-документа, если справляется плохо, то сайт будет тяжело индексироваться). Для конечных пользователей, приходящих из поиска на ваш сайт, важна клиентская составляющая (насколько быстро готовая страницы загружается в их браузерах). Также последний показатель влияет на уровень доверия сайта и число повторных его посещений.</p><p>Сейчас существует большое количество инструментов для автоматической проверки скорости загрузки сайта. Для проверки серверной стороны есть <a href="http://host-tracker.com/" rel="nofollow">host-tracker.com</a> и <a href="http://webo.in/my/action/timings/" rel="nofollow">webo.in/my/action/timings/</a>. Здесь характерным параметром будет создание страницы не более, чем за 0,5с.</p><p>Для оценки отказоустойчивости сайта (насколько он готов к пиковым нагрузкам) можно воспользоваться <a href="http://www.loadimpact.com/" rel="nofollow">www.loadimpact.com</a> и понять, готов ли ваш сайт к росту числа посетителей.</p><p>Для проверки и анализа скорости загрузки страниц в браузере существует <a href="http://webo.in/" rel="nofollow">webo.in</a>. Сервис позволяет точно продиагностировать возможные проблемы и предложить возможные варианты их решения.</p><p>Для автоматического ускорения сайта на PHP существует автоматизированное решение &mdash; <a href="http://www.web-optimizer.ru/">Web Optimizer</a>, которые позволяет за считанные минуты увеличить скорость загрузки в 2-3 раза.</p><p>Спасибо за внимание, буду рад ответить на ваши вопросы.</p> Sun, 28 Feb 2010 00:00:00 GMThttp://www.habrahabr.ru/blogs/searchengines/73636/#commentshttp://webo.in/articles/weborub/speed-up-all-movable/http://webo.in/articles/weborub/speed-up-all-movable/<p><img src="http://control.ileader.biz/u/_files/files/0/14.gif"width="277"height="200"alt="ВЕБОРУБ Ice 2008"title="ВЕБОРУБ Ice 2008"/></p><h3>Оптимизация <a href="http://webo.in/">времени загрузки сайта</a></h3><p>Основные направления для проведения оптимизации с целью уменьшить время загрузки страницы включают уменьшение размера файла и уменьшение числа запросов. В качестве наиболее действенных методов, которые позволяют добиться поставленной задачи, можно рассмотреть:</p><ul><li><a href="http://webo.in/articles/all/mod-gzip-minify-on-fly/">Gzip</a> / minify для текстовых файлов (в том числе, HTML-, JS-, CSS-)</li><li><a href="http://webo.in/articles/habrahabr/08-all-about-css-sprites/">CSS sprites</a> и Image Map для картинок</li><li>ETag / Cache-Control для статических файлов</li><li>Семантическая верстка вместо табличной</li><li>Параллельные запросы на несколько &laquo;ресурсных&raquo; серверов</li><li>Убираем<ul><li>Редиректы</li><li>404-ошибки</li><li><a href="http://webo.in/articles/habrahabr/10-css-expressions-optimization/">CSS Expressions</a></li></ul></li></ul><p>Рассмотрим сжатие и минимизацию текстовых файлов. По итогам проведенных исследований, для <a href="http://webo.in/articles/habrahabr/11-minifing-javascript/">сжатия JavaScript</a> лучше использовать Dean Edwards Packer, если файлы не будут дополнительно архивироваться на сервере, иначе лучше пользоваться YUI Compressor'ом. Для <a href="http://webo.in/articles/habrahabr/14-minifing-css/">сжатия CSS-файлов</a> в любом случае лучше пользоваться CSS Tidy (но при этом возможны некоторые проблемы с хаками).</p><p>Если на сервере включено архивирование при выдачи файлов (<code>mod_gzip/deflate</code>), но CSS-/JS-файлы имеется смысл архивировать и класть в виде статических архивов, чтобы дополнительно не нагружать сервер. Процедуру минимизации/архивирования можно автоматизировать при загрузке всех изменений на production-сервер.</p><p>HTML можно также несколько уменьшить, если убрать незначащие пробелы, переводы строк, часть символов (html entities) заменить на их действительное представление.</p><h3>CSS sprites</h3><p>Число фоновых картинок на странице может достигать нескольких сотен, обычно при этом значительное их количество используется на конкретной странице с подключенным файлом стилей. Обычно все картинки небольшие по размеру и могут быть собраны в характерные группы. Группировку можно проводить по следующим критериям:</p><ul><li>Анимированные картинки</li><li>Картинки, которые повторяются по горизонтали (<code>repeat-x</code>)</li><li>Картинки, которые повторяются по вертикали (<code>repeat-y</code>)</li><li>Картинки, которые повторяются по всем направлениям (<code>repeat</code>)</li><li>Картинки, которые не повторяются (<code>no-repeat</code>)</li></ul><p>Таким образом, сотни ресурсных файлов можно свести к паре десятков, что существенным образом снизит число запросов к серверу. Однако, если вы ориентируетесь на клиентов с IE 4.0, то этот подход использовать нельзя: браузер не понимает <code>background-position</code>.</p><h3><a href="http://webo.in/articles/all/http-caching/">Кеширование</a></h3><p>Одним из наиболее действенных путей уменьшения времени загрузки страницы является кеширование. Его можно проводить на разных уровнях, но конечным его результатом должно быть сведение к минимум запросов при открытии страницы во все последующие посещения (в идеале, вообще 0 запросов).</p><p>Во-первых, для статических файлов, которые изменяются достаточно редко, можно прописать кеширующие заголовки (Cache-Control). Во-вторых, можно дополнительно выставить ETag на сервере (уникальный идентификатор ресурса). Однако, есть ряд проблем с настройкой ETag для сайтов, базирующихся на нескольких (кластере) серверах. Форсировать сброс кеша на клиенте можно выставлением уникальной GET-строки (метка текущей версии или метка текущей даты). Этот процесс также можно автоматизировать.</p><p>Очень часто при оптимизации забывают про качественное уменьшение HTML-кода, переход от табличной к семантической, смешанной или блочной, верстке. Однако, использование технологий, основанных на спецификации и передовых разработках в этой области, позволяют существенно уменьшить размер HTML. На данный момент, полностью блочная или смешанная семантическая верстка очень хорошо отображается в браузерах (корректность отображения достигается в 99,9%).</p><p>Вынесение общих стилевых объявлений и скриптов во внешние файлы также уменьшит размер страницы и позволит кешировать общую часть кода (CSS- и JS-).</p><p>При большом количестве запрашиваемых на странице ресурсов (от 20) для дальнейшей оптимизации можно распределить запросы к статическим файлам по нескольким внешним &laquo;легким&raquo; серверам (thttpd, nginx), чтобы распараллелить запросы. Более 4 таких серверов подключать не рекомендуется.</p><h3><a href="http://webo.in/">WEBo.sunnybear.ru</a></h3><p>В начале февраля был запущен проект, полностью посвященный клиентской оптимизации. На данный момент им оценено 6500 сайтов, среднее время загрузки колеблется от 11 до 100 секунд, при этом рассчитанное ускорение составляет до 1000% (в случае применения всех указанных рекомендаций).</p><p>Проект работает в режиме справочного пособия, которое позволяет проанализировать конкретный сайт, установить узкие места и эффективно их исправить. Сейчас анализатор выдает более 30 советов по возможному уменьшению времени загрузки страницы, содержит <a href="http://webo.in/articles/">несколько десятков статей</a> и докладов, в которых рассматриваются проблемы оптимизации. Также выложены <a href="http://webo.in/video/">видео-записи докладов</a> с ClientSide'2007.</p><p>Мне кажется, что у проекта большой потенциал, который можно и нужно развивать, ибо проблема оптимизации хоть и стоит перед веб-разработчиками, но о ней склонны забывать или не обращать внимание, ссылаясь на скорость современных каналов или малую нагруженность ресурса.</p><p>Спасибо за внимание. Буду рад ответить на ваши вопросы.</p><p class="X"></p> Sun, 28 Feb 2010 00:00:00 GMThttp://webo.in/articles/weborub/speed-up-all-movable/http://webo.in/articles/site2009/website-quality/http://webo.in/articles/site2009/website-quality/<p>Какую картину мы обычно наблюдаем при сдаче готовых интернет-проектов (будь то социальные сети, интернет-магазины или домашние страницы)? Исполнители сдают сайт, который хорошо выглядит в браузере заказчика, который обеспечивает заложенную функциональность, может быть, даже содержит внятную документацию и удовлетворяет нормам по серверной нагрузке. Вроде все замечательно, но этого мало.</p><p>Через несколько недель после работы такого веб-сайта становится понятно, что поддерживать его тяжело, работает он медленно и далеко не у всех пользователей корректно. ЧтО же делать?</p><h3>Ключевые моменты оценки качества веб-проектов</h3><p>На самом деле, можно достаточно быстро принять решение о качестве сдаваемого интернет-проекта с помощью бесплатных инструментов. Что же действительно влияет на качество:</p><ul><li>Совместимость сайта с браузерами.</li><li>Соответствие стандартам.</li><li>Семантика HTML-кода.</li><li>Доступность сайта для пользователей.</li><li>Скорость работы на стороне сервера.</li><li>Скорость работы на стороне браузера.</li></ul><p>Как все это проверить за 10 минут?</p><h3>Кроссбраузерность сайта</h3><p>Проверяем с помощью <a href="http://www.browsershots.org/" rel="nofollow">www.browsershots.org</a>. Выбираем наиболее распространенные браузеры для целевой аудитории (Internet Explroer 6, 7 и 8, Firefox 2 и 3, Opera 9 и 10, Safari 3, Chrome 1). Получаем пару десятков изображений главной страницы сайта, и уже по ней оцениваем качество верстки: насколько она соответствует начальному дизайн-макету.</p><h3>Соответствие стандартам</h3><p>Обычно при разработке в соответствии со стандартами уменьшается время на поддержку и развития такого сайта и увеличивается его доступность для пользователей. Какие стандарты стоит проверять?</p><p>Проверяем с помощью HTML-валидатора: <a href="http://validator.w3.org/">validator.w3.org</a>, на самом деле нам достаточно, чтобы было не более 25 ошибок на странице. Рекомендуется проверять несколько типичных страниц для устранения наиболее очевидных недочетов.</p><p>Соответствие стандартам доступности: WCAG. Проверяем с помощью <a href="http://www.contentquality.com/">www.contentquality.com</a>, достаточно соответствия первому уровню (A, WCAG Priority 1).</p><h3>Доступность и семантика кода</h3><p>Отключение стилей и JavaScript в браузере позволит &laquo;увидеть&raquo; сайт таким, как он &laquo;выглядит&raquo; для поисковых и других роботов. В Firefox это можно сделать с помощью Web Developer Toolbar. В других браузерах &mdash; в настройках отключения скриптов и с помощью:</p><blockquote><pre>javascript:document.getElementsByTagName('head')[0].innerHTML='';void(0);</pre></blockquote><p>Запуск этой адреса в браузере устранит большую (или же все) стили со страницы.</p><p>Дополнительно страница с отключенными стилями позволит проверить, насколько семантически верен HTML-код. Если содержание на странице остается понятным для пользователя, если ключевые элементы взаимодействия по-прежнему доступны &mdash; то можно считать, что страница сверстана семантически верно. Иначе нужно устранять найденные недочеты (например, отсутствующее меню или форму входа). Не стоит искать у страницы с отключенными стилями полного соответствия дизайн-макету &mdash; его и не должно быть. Но содержимое такой страницы должно быть приятно для глаза и доступно для использования. Это основное правило.</p><h3>Скорость работы сайта</h3><p>Очень часто скорость работы оказывает ключевое влияние на конвертация посетителей в доход сайта. Особенно это характерно для интернет-магазинов. Как мы можем проверить эту скорость? Для серверной стороны существует инструмент <a href="http://host-tracker.com/" rel="nofollow">host-tracker.com</a>, с помощью которого можно установить характерное время доступа к сайту из различных точек земного шара. Также он позволяет оценить характерное время создания страницы на сервере (если минимальное время доступа к сайту больше 1с, то уже стоит бить тревогу).</p><p>Для проверки отказоустойчивости сайта стоит воспользоваться сервисом <a href="http://loadimpact.com/" rel="nofollow">Load Impact</a>. Бесплатный анализ позволяет проверить до 50 одновременных посещений (каждое из которых может открывать несколько десятков страниц на сайте). Основным показателем устойчивости сайта к нагрузкам будет вид кривой, который получится после проведения теста. Если график ровный или время открытия страницы несколько падает при росте посещаемости &mdash; значит, с сайтом все нормально. Если нет, то нужно принимать решение об оптимальном потоке посетителей, которых сайт сможет обслужить.</p><p><img width="542" height="308" src="/articles/site2009/website-quality/loadimpact.png" alt="Время открытия страницы в зависимости от потока посетителей" title="Время открытия страницы в зависимости от потока посетителей"/></p><p>Для проверки качества скорости загрузки клиентской составляющей можно воспользоваться либо YSlow под Firebug для Firefox (оценка должна быть не менее 80, лучше всего не менее 90). Или же бесплатным инструментом <a href="http://webo.in/">webo.in</a> (простая оценка не ниже 70, лучше не ниже 80).</p><h3>На что влияет качество сайта</h3><p>Это, в первую очередь, стоимость его поддержки и развития. Сайт, сделанный грамотно и по всем стандартам, гораздо проще развивать, поскольку времени написание дополнительного кода при наличии хорошей, стандартной базы уходит значительно меньше. Это и масштабируемость проекта, когда разработчики предусматривают большой &laquo;запас прочности&raquo; для ежедневных посещений, и в пиковые часы сайт будет работать в штатном режиме, не требуя дополнительного масштабирования.</p><p>Скорость создания HTML-страниц и общее время загрузки очень сильно влияет на доступность сайта. Ключевым параметром здесь является &laquo;загрузка за 4 секунды&raquo; и более быстрая загрузка, чем у основных конкурентов. В отсутствии основных преимуществ на рынках с высокой конкуренцией скорость работы сайта может оказаться решающим фактором при принятии решения.</p><p>Сейчас на рынке существует несколько решений, позволяющий автоматизировать ускорение сайта на клиентском уровне. Для ASP.NET &mdash; это <a href="http://getrpo.com/" rel="nofollow">GetRPO.com</a>, для систем на базе PHP &mdash; это <a href="http://code.google.com/p/web-optimizator/" rel="nofollow">Web Optimizer</a>.</p><p>Спасибо за внимание. Вопросы?</p> Sun, 28 Feb 2010 00:00:00 GMThttp://www.habrahabr.ru/blogs/client_side_optimization/62907/#commentshttp://webo.in/articles/riw2008/move-load-to-client/http://webo.in/articles/riw2008/move-load-to-client/<p>Клиентская оптимизация оперирует двумя основными принципами: меньше данных и меньше соединений. Но именно эти принципы помогают уменьшить нагрузку на сам сервер. Давайте посмотрим, как это происходит и как перенести часть серверной нагрузки на клиентский браузер.</p><h3>3 основные правила</h3><ul><li><p><strong>Кеширование во главу угла.</strong> Сервер может управлять состоянием кеша клиентского браузера, во-первых, через заголовок <code>Cache-Control</code> (и его атрибуты <code>max-age</code>, <code>pre-check</code>, <code>post-check</code>), который может указывать на промежуток времени, в течение которого соответствующий файл следует хранить на диске и не запрашивать с сервера. Рекомендуется для всех статических файлов выставлять максимальное время жизни кеша и форсировать его обновление у пользователя через изменение URL ресурса (с помощью <code>RewriteRule</code> либо GET-параметра).</p><p>Во-вторых, состоянием клиентского кеша можно управлять через заголовки <code>ETag</code> и <code>Last-Modified</code>, которые ставят в соответствие каждому файлу уникальный идентификатор, изменяющийся при изменении файла, своеобразная цифровая подпись или хеш. При этом серверу не нужно пересылать файл заново, а лишь ответить кодом 304 на запрос браузера, если файл не изменился с момента последнего запроса. При этом сам файл не пересылается, соединение (и сокет) освобождается быстрее, и ресурса сервера также экономятся.</p></li><li><p><strong>Меньше запросов &mdash; легче серверу.</strong> Объединение файлов никто не отменял. Чтобы не заставлять сервер обмениваться с браузером заголовками для передачи, например, нескольких таблиц стилей гораздо экономичнее будет их объединить в одну. При этом браузер быстрее получит всю необходимую информацию и быстрее освободит такой важный ресурс как соединение.</p><p>Наряду с объединением текстовых файлов не стоит пренебрегать и объединением картинок. Если учитывать, что современные браузеры могут устанавливать несколько десятков одновременных соединений с сервером для получения статических файлов (и 80% из них &mdash; это именно картинки), то экономия от использования CSS Sprites или Image Map рассчитывается очень просто. В некоторых случаях удается уменьшить число соединений браузера с сервером для загрузки одной HTML-страницы в 8&ndash;10 раз.</p></li><li><p><strong>Архивировать и кешировать на сервере.</strong> Как показали проведенные исследования gzip-сжатия текстового файла &laquo;на лету&raquo; в 95&ndash;98% случаев позволяет сократить время на передачу файла браузеру. Если хранить архивированные копии файлов сервере (в памяти proxy-сервере или просто на диске), то соединение в общем случае удается освободить в 3&ndash;4 раза быстрее.</p><p>В случае высоконагруженных серверов с динамическими HTML-файлами gzip также может применим. Здесь стоит ориентироваться на минимальную степень сжатия, ибо процессорные издержки при это растут линейно, а размер уменьшается лишь логарифмически.</p></li></ul><h3>Спорные моменты</h3><p>Следующие моменты стоит рассматривать как спорные: они могут как ускорить загрузку ваших сайтов, так и замедлить ее или слишком осложнить процесс разработки.</p><h4>Параллельные загрузки</h4><p>Создание нескольких зеркал для выдачи статических файлов обычно помогает ускорить загрузку страницы в браузере, но каково при этом приходится серверу? В общем случае, если общее число файлов на странице не превосходит 10, то зеркала применять нецелесообразно. При 10-20 файлах стоит ограничиться лишь одним зеркалом, и лишь если файлов становится несколько десятков, то стоит думать о 2&ndash;3 зеркалах.</p><p>Однако, при существовании большого количества файлов (например, картинок) разумнее будет их объединять &mdash; это поможет и серверу и клиенту.</p><h4>Все-в-одном-файле</h4><p>Технология кроссбраузерного <code>data:URL</code> позволяет использовать один CSS-файл и для стилевых правил, и для небольших фоновых картинок. Это позволяет избежать использования CSS Sprites и многочисленных обращений для загрузки мелких фоновых изображений.</p><p>Однако, данный подход связан с некоторыми технологическими сложностями (необходима дополнительная обработка файлов перед их публикацией на рабочем сервере) и не позволяет осуществлять кеширование отдельных компонентов. В принципе, то же самое можно сказать и о включении CSS-/JS-файлов в HTML-страницу. Решение о таких мерах должно приниматься, исходя из индивидуальных особенностей проекта.</p><h4>Обрезание Cookie</h4><p>Cookie передаются при каждом запросе браузера на сервер. Иногда их размер может быть весьма значительным и даже превосходить полезный объем информации. К тому же, большое количество значений в заголовке Cookie несет дополнительную нагрузку на серверную логику &mdash; ведь обычно все их нужно проанализировать и переслать обратно браузеру.</p><p>Одним из наиболее распространенных вариантов является выделение статических файлов на отдельное зеркало, на которое не передаются Cookie. Однако, этот подход не позволяет, например, показывать изображения только авторизованным пользователям. Отправка пользователю только необходимых cookie также сопряжена с логическими ошибками &mdash; нужно ведь послать определенные cookie всем нужным пользователям и не послать всем ненужным.</p><h3>Выводы</h3><p>За счет объединения файлов и настройки агрессивного кеширования возможно уменьшение числа первоначальных запросов к серверу в несколько раз, и сведение повторных запросов всего к 1&ndash;2 (если все остальные десятки файлов браузер будет брать из собственного кеша). Это позволит значительно сократить число активных соединений в секунду.</p><p>Архивирование также помогает сократить нагрузку на сервер, однако, его нужно использовать более аккуратно, чтобы не навредить слишком большой степенью сжатия или архивированием не тех типов файлов (например, JPEG).</p><p>Есть также ряд других методов (параллельные загрузки, все-в-одном, cookie и т.д.), которые могут повлиять на серверную нагрузку. Однако, и все нужно использовать с крайней осторожностью, и большого снижения нагрузки за их счет добиться нельзя.</p><p>Спасибо за внимание, буду рад ответить на ваши вопросы.</p> Sun, 28 Feb 2010 00:00:00 GMThttp://www.habrahabr.ru/blogs/client_side_optimization/41716/#commentshttp://webo.in/articles/rit2008/speed-up-all-movable/http://webo.in/articles/rit2008/speed-up-all-movable/<h3>Оптимизация времени загрузки сайта: проблемы и решения</h3><p>Большинство сайтов Рунета работают :) Почти всегда. И почти всегда медленно. Иногда причина этого &mdash; плохой канал связи у конечного пользователя или самого сайта. Но ни веб-разработчики, ни онлайн-маркетологи зачастую не отдают себе отчет, насколько эту ситуацию можно изменить, и изменить кардинально.</p><h3>Основные методы</h3><p>Сегодня речь пойдет о способах ускорения загрузки сайта. О методах увеличения эффективности сайта как инструмента продаж или оказания услуг, как существенной имиджевой составляющей бренда или просто личного блога. В качестве основных технологических направлений по уменьшению времени загрузки веб-страниц можно выделить следующие:</p><ul><li>Уменьшение объема данных: большое число методов по минимизации и архивированию.</li><li>Уменьшение числа запросов: основная технология &mdash; CSS Sprites.</li><li>Кеширование.</li><li>Параллельные загрузки.</li><li>Оптимизация JavaScript.</li></ul><h3>Обзор аудитории</h3><p>Основным критерием, который должен определять, какие методы и в каком объеме стоит применять, естественно, будет аудитория ресурса. Для каждого сайта можно выделить несколько характерных групп страниц, которые посещаются тем или иным типом аудитории. В первую группу войдут веб-страницы, на которые заходят всякий раз новые пользователи. Это и специальные рекламные страницы, задачей которых является прямая продажа продукта. Это и страницы объявлений, которые пользователи должны увидеть один, максимум, два раза. И т.д. Аудитория таких страниц на 99,9% состоит из новых пользователей. Следовательно, для них нужно применять методы, снижающие, в первую очередь, число обращений к серверу для показа страницы: объединение файлов и экстремальную оптимизацию.</p><p>Во вторую группу войдут страницы, аудитория которых также часто меняется, однако, часть ее может просматривать страницы неограниченное число раз. Для таких страниц можно выделить характерное ядро постоянных посетителей, однако, оно составляет не более 30&ndash;40% от общего числа. Большинство сайтов, которые &laquo;живут&raquo; на поисковом трафике, являются замечательным примером ресурсов, полностью подходящих под эту группу. Для таких сайтов, в первую очередь, стоит рассмотреть методы уменьшения числа запросов (CSS Sprites), также возможную минимизацию всех текстовых файлов (HTML, CSS, JS). Однако, применение кеширование в данном случае оправдано в меньшей степени, так как уменьшит время загрузки страницы не так сильно (если брать средневзвешенное значение), чем, например, параллельные запросы.</p><p>Наконец, к третьей группе можно отнести все остальные страницы, а именно те, аудитория которых в большей степени постоянна (конкретные числа стоит рассматривать из параметров монетизации различных групп аудитории, однако, характерные значения здесь &mdash; это 30% постоянных пользователей ресурса). В этой группе наиболее действенным будет, конечно же, кеширование и <a href="http://webo.in/speed/javascipt/">оптимизация скорости работы JavaScript</a> и Flash-анимации &mdash; ведь именно она будет &laquo;съедать&raquo; больше всего времени у характерного пользователя такой аудитории.</p><h3>Уменьшение объема данных: сжатие и архивирование</h3><p>Основными инструментами для уменьшения объема данных являются разнообразные минимизаторы и обфускаторы (для <a href="http://webo.in/articles/habrahabr/11-minifing-javascript/">JavaScript-файлов</a>), архивирование и также ряд утилит для уменьшения размера изображений. Давайте рассмотрим их по порядку.</p><img src="http://chart.apis.google.com/chart?chs=550x300&amp;cht=lc&amp;chxt=x,y&amp;chd=t:76,72,81,79,75,81,76,80,79,79,77,61|5,7,8,18,15,15,17,23,20,21,27,52|77,75,82,82,80,84,79,81,84,83,80,77|4,0,2,11,6,7,8,13,12,13,18,45|77,73,82,81,79,83,78,81,83,82,79,74|8,9,10,18,17,16,20,25,22,23,30,53|78,75,82,82,80,84,79,82,85,83,81,77|78,75,82,81,80,84,79,81,84,83,81,78|15,20,27,24,25,27,28,31,36,30,35,57|18,14,20,23,23,24,27,31,30,30,36,54|79,76,82,82,81,84,80,82,85,84,81,77&amp;chxl=0:|5730|8573|19744|29539|11052|131446|11851|13040|58892|47175|67244|1383|1:||10%|20%|30%|40%|50%|60%|70%|80%|90%|100%&amp;chco=868686,D0EB55,D0EB55,EBD055,EBD055,5539EB,5539EB,55EBD0,55EBD0,D055EB,D055EB&amp;chg=8.33,10&amp;chf=bg,s,FFFFFF&amp;chls=2|2,6,3|2|2,6,3|2|2,6,3|2|2|2,6,3|2,6,3|2&amp;chdl=GZIP|CSSMin|CSSMin%2BGZIP|Minify|Minify%2BGZIP|YUI|YUI%2BGZIP|Minifier|Minifier%2BGZIP|CSS%20Tidy|CSS%20Tidy%2BGZIP" class="chart" alt="График сжатия CSS-файлов" title="График сжатия CSS-файлов"/><p>Как показало проведенное тестирование средств <a href="http://webo.in/articles/habrahabr/14-minifing-css/">сжатия CSS</a>, лучше всего с этой задачей справляется проект CSS Tidy (примерно на одном уровне с ним идет YUI Compressor), который вместе с дополнительным архивированием файлов позволяет получить выигрыш до 85%.</p><img src="http://chart.apis.google.com/chart?chs=550x300&amp;cht=lc&amp;chxt=x,y&amp;chd=t:43,54,60,69,71,74,70,73,77,77,82,70|1,0,0,0,0,0,17,23,30,26,35,45|43,54,60,70,71,74,75,77,83,81,85,84|1,0,0,0,0,0,17,23,30,25,34,45|44,54,60,70,71,74,75,77,83,81,85,84|0,0,0,0,0,0,11,27,31,30,36,47|43,53,59,69,71,74,74,76,81,79,84,83|13,47,52,69,71,73,72,76,83,82,81,84|0,9,15,35,34,41,32,53,61,60,56,68|1,0,6,0,0,19,18,35,41,41,40,45|44,54,61,69,71,76,74,79,84,83,86,84&amp;chxl=0:|853|9580|5857|43099|83879|39686|21414|22015|289446|124136|8867|95285|1:||10%|20%|30%|40%|50%|60%|70%|80%|90%|100%&amp;chco=868686,D0EB55,D0EB55,EBD055,EBD055,5539EB,5539EB,55EBD0,55EBD0,D055EB,D055EB&amp;chg=8.33,10&amp;chf=bg,s,FFFFFF&amp;chls=2|2,6,3|2|2,6,3|2|2,6,3|2|2|2,6,3|2,6,3|2&amp;chdl=GZIP|JSMin|JSMin%2BGZIP|Minify|Minify%2BGZIP|Rhino|Rhino%2BGZIP|Packer|Packer%2BGZIP|YUI|YUI%2BGZIP" alt="График сжатия JS-файлов" title="График сжатия JS-файлов" class="chart"/><p>Для JavaScript-файлов ситуация несколько интереснее. Если применять архивирование, то лучше всего использовать <a href="http://developer.yahoo.com/yui/compressor/" rel="nofollow" lang="en">YUI Compressor</a>, так как он, в среднем, сжимает в этом случае лучше. Если архивирование для JS-файлов применять нельзя, то лидером в сжатии является <a href="http://dean.edwards.name/packer/" rel="nofollow" lang="en">Dean Edwards Packer</a>, однако, он вносит дополнительные издержки на свою <a href="http://webo.in/articles/habrahabr/20-javascript-libraries-load-time/">&laquo;распаковку&raquo;</a>. <a href="http://webo.in/articles/habrahabr/20-javascript-libraries-load-time/">Как показали исследования</a>, для пользователей, которые будут, в основном, загружать JavaScript из кеша, лучше использовать <a href="http://webo.in/articles/habrahabr/11-minifing-javascript/">сжатие без обфускации</a>.</p><p>Использование архивирования через <a href="http://webo.in/articles/all/mod-gzip-minify-on-fly/"><code>mod_gzip</code></a> для Apache способно существенно уменьшить размер загружаемых файлов. Однако, в случае очень быстрого канала у пользователей (например, локальный ресурс) и ограниченных ресурсов сервера (высокая удельная нагрузка на создание страницы) будет разумнее <a href="http://webo.in/articles/habrahabr/30-gzip-versus-broadband/">сжатие не использовать</a>.</p><img src="http://chart.apis.google.com/chart?chs=550x300&amp;cht=lc&amp;chxt=x,y&amp;chd=t:0,1,1,3,6,12,23,47,94|0,0,0,1,1,3,6,11,22|0,0,0,0,0,1,2,3,6|0,0,0,0,0,1,2,3,6&amp;chxl=0:|500%D0%B1|1000%D0%B1|2000%D0%B1|4000%D0%B1|8000%D0%B1|16000%D0%B1|32000%D0%B1|64000%D0%B1|128000%D0%B1|1:||20%D0%BC%D1%81|40%D0%BC%D1%81|60%D0%BC%D1%81|80%D0%BC%D1%81|100%D0%BC%D1%81|120%D0%BC%D1%81&amp;chco=D0EB55,5539EB,55EBD0,EBD055&amp;chg=8.33,16.66&amp;chf=bg,s,FFFFFF&amp;chls=2|2|2&amp;chdl=100Kb%20Transfer|280MHz%20GZIP|1500Kb%20Transfer|1000MHz%20GZIP" alt="Накладные издержки на сжатие и передачу информации для 100Кб и 1500Кб и 280МГц и 1000МГц" title="Накладные издержки на сжатие и передачу информации для 100Кб и 1500Кб и 280МГц и 1000МГц" class="chart"/><p>Также стоит для архивированных файлов добавить соответствующие заголовки (<code>Cache-Control:private</code>), чтобы избежать ряда проблем с кеширующими прокси-серверами. Для архивирования CSS- и JS-файлов также нужно исключить Safari и Konqueror из тех браузеров, которым можно отправлять gzip-файлы: эти браузеры до последнего времени не умели их корректно распознавать.</p><h3><a href="http://webo.in/articles/habrahabr/26-speed-up-images-png-versus-gif/">Уменьшение размера изображений</a></h3><p>Для большинства графических элементов рекомендуется использовать формат PNG, так как он более экономичен, чем GIF. Однако, для небольших изображений GIF-формат может оказаться лучше. На данный момент PNG-изображения поддерживаются, практически, всеми браузерами, поэтому вы ничего не потеряете, если будете использовать его.</p><p>Сейчас существует проблема с поддержкой альфа-канала в Internet Explorer (которую уже исправили в 7 версии), однако, в версиях ниже 7 (5.5 и 6) она решается через <code>ImageAlphaLoader</code> (с помощью <a href="http://webo.in/articles/habrahabr/10-css-expressions-optimization/">CSS expressions</a>, CSS хаков или JavaScript), что позволяет использовать полупрозрачность, практически, в полном объеме.</p><p>В случае проблем с совпадением цветом (опять-таки в Internet Explorer) рекомендуется удалить из изображения gamma-чанков. В этом также может помочь ряд утилит, уменьшающих размер PNG-изображений: например, <a href="http://pmt.sourceforge.net/pngcrush/" rel="nofollow" lang="en"><code>pngcrush</code></a>. Для уменьшения размера JPG-изображений можно применить утилиту <a href="http://linux.about.com/library/cmd/blcmdl1_jpegtran.htm" rel="nofollow" lang="en"><code>jpegtran</code></a>, которая не затрагивает цветовые данные изображения, а удаляет комментарии и другие мета-данные.</p><p>Для анимированных изображений стоит использовать либо GIF-изображения с несколькими кадрами, либо DHTML-анимацию (JavaScript + PNG/JPEG).</p><h3>Семантическая верстка</h3><p>Когда разговор заходит про уменьшение размера кода, очень часто забывают про переход на семантическую разметку вместо табличной. Однако, она способна уменьшить не только время разработки backend-логики за счет более прозрачной структуры блоков, но и &laquo;облегчить&raquo; frontend-часть, сократив размер HTML примерно на 30%.</p><p>Сразу хочу заметить, что строгое следование семантике может отрицательно сказаться на размере кода, поэтому вам придется решить, что для вас важнее: поддержка последних тенденций (например, из мира микроформатов) или <a href="http://webo.in/speed/">скорость загрузки страницы</a>, например, интернет-магазина. Возможно, в ряде случаев будет разумно применить более простую спецификацию, сократив тем самым общее количество тегов и размер картинок (для CSS Sprites).</p><h3><a href="http://webo.in/articles/habrahabr/16-optimization-page-load-time/">Уменьшение числа запросов</a></h3><p>Для уменьшения числа запросов при загрузке страницы применяют, в основном, техники слияния, адаптированные под разные типы данных. Например, для <a href="http://webo.in/articles/habrahabr/02-delay-loading-stylesheets/">объединения CSS-файлов</a> в один стоит использовать конструкцию</p><blockquote><pre>@media тип {селекторы для этого типа}</pre></blockquote><p>например,</p><blockquote><pre>@media print {.nonprintable{display:none}}.</pre></blockquote><p>Для уменьшения числа JS-файлов у нас гораздо больше простора для фантазии. Можно просто создать один большой файл со всеми используемыми вызовами и библиотеками. Можно создать один внешний файл, который будет загружать библиотеки по мере необходимости. А можно с помощью комбинированного обработчика событий <code>window.onload</code> начать загрузку всех необходимых файлов сразу по получению HTML-кода.</p><p>Используя технику &laquo;ненавязчивый&raquo; JavaScript можно добиться существенного визуального ускорения при загрузке сложного интерфейса или веб-страниц с нетривиальной логикой.</p><h3><a href="http://webo.in/articles/habrahabr/08-all-about-css-sprites/">CSS Sprites</a></h3><p>Наиболее популярной техникой для объединения изображений является CSS Sprites (или CSS Image maps), когда для отображения нескольких (десятков или даже сотен) изображений используется один ресурсный файл. Она дает ощутимый выигрыш в <a href="http://webo.in/">скорости загрузки</a> при использовании анимационных эффектов (например, смене изображения при наведении мыши), а также при большом количестве иконок на странице.</p><p>В качестве основных рекомендаций при создании ресурсных файлов для CSS Sprites можно назвать следующие:</p><ul><li>Разбиение всех изображений на 5 основных групп (не рекомендуется использовать в одном файле изображений из более, чем 2 групп):<ul><li>Изображения, повторяющиеся по всем направлениям (<code>repeat</code>).</li><li>Изображения, повторяющиеся по горизонтали (<code>repeat-x</code>).</li><li>Изображения, повторяющиеся по вертикали (<code>repeat-y</code>).</li><li>Изображения, которые не повторяются (<code>no-repeat</code>).</li><li>И анимированные изображения.</li></ul></li><li>Размер файлов должен быть не более 10&ndash;20 Кб.</li><li>Объединение близких по цветовой гамме изображений.</li></ul><p>Если у вас на странице выводится много небольших изображений, возможно, стоит воспользоваться техникой Image Map, чтобы сократить их количество.</p><h3>Экстремальная оптимизация</h3><p>Под экстремальной оптимизацией я понимаю максимальное уменьшение размера файлов и их количества, может быть, даже в ущерб браузерной совместимости.</p><p>В качестве характерного примера использования таких техник можно примести главные страницы <a href="http://yandex.ru/" rel="nofollow">Яндекса</a> и <a href="http://www.yahoo.com/" rel="nofollow">Yahoo!</a>, на которых CSS- И JS-файлы кроме стандартной минимизации еще и включены в итоговый HTML-код, а сам HTML отдается в виде gzip-архивов.</p><p>Логическим продолжением в данном случае будет использование схемы <code>data:URL</code> и base64-кодирования для подключения фоновых и обычных изображений. Результирующий размер gzip-файла увеличится на 5&ndash;10% (от размера изображения), однако, при этом удастся сэкономить один запрос к серверу. С помощью несложных вычислений можно подсчитать, при каком размере файла это рационально применять.</p><p>Однако, Internet Explorer не поддерживает эту технику (до версии 7 включительно). Для него можно использовать специальные хаки (в том числе, <code>* html</code>), условные комментарии или mhtml-схему, которая обеспечивает, практически, ту же функциональность, что и <code>data:URL</code>.</p><h3><a href="http://webo.in/articles/all/http-caching/">Кеширование</a></h3><p>Основной техникой для ускорения загрузки страницы для постоянных посетителей является кеширование, которое может свести число запросов к серверу для отображения страницы к минимуму (в идеале, к нулю). Здесь стоит помнить о корректной настройке заголовка <code>Cache-Control</code>. Для сброса кеша всегда можно воспользоваться дополнительным параметром в GET-запросе к ресурсу, который заставит сервер взять тот же физический файл, а клиентский браузер запросить файл и сохранить его под новым именем. Для статических ресурсов стоит выставлять достаточно большой срок кеша (можно экспериментировать со значения от месяца), для остальных файлов это значение должно быть равно среднему времени изменения либо вообще отсутствовать (для HTML-файлов, например).</p><p>В качестве дополнительного кеширующего аргумента можно использовать уникальные идентификаторы ресурсов (ETag). Они позволяет серверу не отдавать файл заново даже при закончившемся времени кеширования, а просто его продлять. Однако, существует ряд проблем с распределением файлов по разным физическим серверам и настройке на них идентичных ETag, но это, скорее, относится к уже очень большим системам.</p><h3>Параллельные загрузки</h3><p>Для уменьшения удельного времени ответа от сервера при загрузке большого числа файлов можно разделить загрузку на несколько потоков (серверов). Сами сервера для такой цели (быстрой отдачи статических ресурсов) лучше настраивать под &laquo;легким&raquo; окружением (например, nginx). В качестве балансирующего параметра можно рассматривать как распределение по географическому принципу (например, кластеры в США, Европе, Азии), так и по нагрузке (пул свободных серверов определяется каждый раз при загрузке страницы). Также возможно использование балансировки на клиенте для достижения того же эффекта.</p><p>В качестве основных проблем стоит отметить необходимости создания хеш-функции от имени файла, чтобы один и тот же файл загружался только с одного сервера, иначе браузер будет запрашивать его с серверов-зеркал, пока не забьет кеш всеми его копиями. Также стоит ограничиться 4 хостами (для большого числа файлов), для небольшого (15&ndash;25) стоит использовать не более 3. 2 хоста разумно использовать, только если число файлов превосходит 10 из-за дополнительных расходов на распознавание имени в DNS-таблице.</p><h3>Оптимизация JavaScript</h3><p>Чуть ранее я уже упоминал про возможность загружать необходимые для отображения страницы JavaScript-файлы, фактически, после ее загрузки. Однако, есть еще и пара нюансов. Например, ваш сайт должен полностью функционировать и без JavaScript (должны осуществляться переходы по ссылкам, первоначальный вид страницы должен формироваться на сервере). Это позволит повысить индексируемость сайта и обезопасит тех пользователей, у которых ваши скрипты не работают по тем или иным причинам.</p><p>Используйте возможности CSS по максимуму. Вы не сможете отобразить страницу в браузере лучше, чем сам браузер, поэтому оставьте всю тяжелую работу по рендерингу для него (это относится к анимационным эффектам при наведении на кнопки, изменению разметки при изменении размеров окна и т.д.). CSS-движок, в среднем, работает быстрее, чем JavaScript. Также посоветую избегать использования CSS expressions либо оптимизировать их, чтобы они исполнялись только один раз на странице.</p><p>Обновляйте DOM-дерево большими кусками. DOM-Обращения ресурсоемки, это почти как база данных для серверных приложений. Чем меньше будет у вас работы с DOM, тем быстрее будет ваш JavaScript. Отдельное слово по поводу обработчиков событий: сводите их количество к минимуму. В идеале, стоит повесить один-единственный <code>onclick</code> на <code>&laquo;body&raquo;</code> и обрабатывать уже источник клика. Если вам требуются менее глобальные эффекты &mdash; просто ограничьтесь одним обработчиков на блоке, в котором заключена требуемая область. Большое количество обработчиков событий (которые еще и забывают убирать из изменении HTML-кода на странице) приводит к <a href="http://webo.in/articles/habrahabr/18-solving-internet-explorer-memory-leaks/">утечкам памяти в IE</a>.</p><p>И несколько общих советов: кешируйте глобальные переменные в локальные (однако, тут могут быть нюансы, особенно с <a href="http://webo.in/articles/habrahabr/28-chain-javascript-calls-optimization/">цепочками вызовов функций</a>), избегайте использовать <code>eval</code> и <code>setTimeout</code> / <code>setInterval</code> (которые выполняют <code>eval</code> на передаваемую в качестве аргумента строку). Вместо этого можно использовать анонимные функции.</p><blockquote><pre>(function(){ ... }())</pre></blockquote><p>При осуществлении тяжелых вычислений (например, подгрузка данных или сортировка больших массивов) стоит <a href="http://webo.in/articles/habrahabr/13-cpu-intensive-javascript/">обновлять интерфейс пользователя</a>, чтобы он знал, что выполняются какие-то действия, и мог немного подождать. Однако, тут главное не переусердствовать с уведомлениями: ведь каждое обновление страницы занимает некоторое время, и накладные издержки на него могут оказаться много больше &laquo;полезного&raquo; времени.</p><h3>Действенность методов</h3><p>Что же из всего вышеперечисленного больше всего влияет на скорость загрузки? Как я уже упоминал, это сильно зависит от типа оптимизируемых страниц, однако, можно выделить некоторые общие тенденции. Так, кеширование позволяет снизить время загрузки страницы вплоть до нуля (чтобы она полностью загружалась из браузерного кеша пользователя, а ведь на ней может быть реклама, которую пользователь увидит, не заходя физически к вам на сайт).</p><p>Использование нескольких серверов для параллельных запросов способно уменьшить время загрузки на где-то 85%, использование CSS Sprites &mdash; на 60%. Объединение текстовых файлов и их минимизация, в среднем, дает 40% выигрыш (однако, если у вас сложное веб-приложение, в котором функционирует десятки JavaScript-библиотек, то такая техника способно в разы ускорить его работу).</p><p>Оптимизация изображений уменьшает их удельный вес примерно на 30%. Если вы займетесь оптимизацией JavaScript-кода и вызовов функций, то сэкономите около 20%. Семантическая верстка способна уменьшить время загрузки только лишь на 10% (это связано с тем, что удельный вес HTML-кода в объеме страницы очень мал, поэтому больший выигрыш дает простое архивирование).</p><p>Что дадут оптимизационные мероприятия вашему бизнесу? По данным Yahoo! замедление страниц Google на 500мс приводит к 20% потере трафика, для Amazon 100мс обходятся в 1% продаж. Недавно проведенная оптимизация главной страницы европейского сайта <a href="http://eu.acronis.com/" rel="nofollow">Acronis</a> (время загрузки было уменьшено почти в 5 раз) привело примерно к 5% росту продаж и такому же увеличению трафика на внутренние страницы.</p><p>Также оптимизационные мероприятия позволили ускорить загрузку сайта <a href="http://www.pmexpert.ru/" rel="nofollow">www.pmexpert.ru</a> в 2,8 раза, а <a href="http://www.creative.su/">www.creative.su</a> в 2,6 раза</p><h3>Профилирующие инструменты для <a href="http://webo.in/">оптимизации</a></h3><p>Лучшим в своем классе профилирующим инструментом для <a href="http://webo.in/speed/complex/">оценки скорости загрузки сайта</a> а анализа узких мест является <a href="http://webo.in/articles/rit2008/speed-up-all-movable/https://addons.mozilla.org/ru/firefox/addon/5369" rel="nofollow" lang="en">Yslow</a> под <a href="http://webo.in/articles/rit2008/speed-up-all-movable/https://addons.mozilla.org/ru/firefox/addon/1843" rel="nofollow" lang="en">Firebug</a> для <a href="http://www.mozilla.com/en-US/firefox/" lang="en" rel="nofollow">Firefox</a>). С помощью него можно установить и отладить, практически, все, что требуется для ускорения загрузки сайта. Основным его минусом является невозможность посмотреть, как именно происходит загрузка из кеша и, естественно, распространение только под Firefox (хотя, может быть, это является и плюсом).</p><p>Недавно <a href="http://www.aol.com/" rel="nofollow" lang="en">AOL</a> выпустило <a href="http://pagetest.wiki.sourceforge.net/" rel="nofollow" lang="en">PageTest</a> для Internet Explorer'а (6 и 7), который также позволяет увидеть диаграмму загрузки сайта, однако, не выдает таких развернутых советов, как YSlow. Для нахождения утечек памяти и замыканий под IE можно воспользоваться <a href="http://outofhanwell.com/ieleak/index.php?title=Main_Page" rel="nofollow" lang="en">Drip</a>.</p><p><a href="http://www.jsunit.net/" rel="nofollow" lang="en">JsUnit</a> предоставляет мощный framework для тестирования и отладки ваших JavaScript-приложений. С помощью <a href="http://research.microsoft.com/projects/ajaxview/" rel="nofollow" lang="en">AjaxView</a> можно проксировать и анализировать <a href="http://webo.in/articles/habrahabr/23-high-performance-ajax-applications/">AJAX-запросы</a>. Для профессионального профилирования веб-приложений стоит воспользоваться <a href="http://rockstarapps.com/pmwiki/pmwiki.php?n=JsLex.JsLex" rel="nofollow" lang="en">JsLex</a>, а время выполнения различных операций на странице можно замерить с помощью <a href="http://developer.yahoo.com/yui/profiler/" rel="nofollow" lang="en">YUI Profiler</a>. Но не забывайте, что лучшей проверкой ваших приложений на прочность всегда был и остается пользователь.</p><p>Наконец, пара слов об онлайн-инструментах. Пожалуй, самым старым и профессиональным можно назвать <a href="http://www.websiteoptimization.com/">WebSiteOptimizator</a>, который получает данные о всех требуемых для загрузки страницы файлах и выдает ряд советов по оптимизации времени загрузки. Также есть ряд сервисов (<a href="http://www.octagate.com/service/SiteTimer/" rel="nofollow" lang="en">OctaGate SiteTimer</a> и <a href="http://tools.pingdom.com/fpt/" rel="nofollow" lang="en">Pingdom Tools</a>), которые отображают диаграмму загрузки сайта в режиме онлайн. Однако, на них практически отсутствуют советы по <a href="http://webo.in/">оптимизации скорости загрузки</a>.</p><p>В отличие от вышеуказанных инструментов, <a href="http://webo.in/">Web Optimizator</a> позволяет как получить сведения о всех загружаемых файлах и большое количество подробных советов (что же с этими файлами можно и нужно сделать) так и посмотреть, как эти файлы будут загружаться в различных браузерах. И что более важно, применять ряд оптимизационных методов &laquo;не отходя от кассы&raquo;, т.е. прямо на диаграмме загрузки. При этом не нужно ничего настраивать на сервере и проверять, уменьшится ли время загрузки после определенных действий или нет &mdash; все можно осуществить в режиме онлайн.</p><p>Спасибо за внимание. Буду рад ответить на ваши вопросы.</p> Sun, 28 Feb 2010 00:00:00 GMThttp://www.habrahabr.ru/blog/client_side_optimization/33670/#commentshttp://webo.in/articles/ok2009/speed-matters/http://webo.in/articles/ok2009/speed-matters/<h3>Проблема медленных сайтов реальна</h3><p>С каждым годом Интернет растет вширь и вглубь. Увеличивается пропускная способность каналов, пользователи переходят с коммутируемого доступа на безлимитный. Сайты становятся больше по размеру, больше по наполнению и сложнее во взаимодействии. Размеры загружаемых файлов при этом увеличиваются многократно, а время ожидание пользователей не уменьшается.</p><h3>Рост Интернета</h3><p>За последние 5 лет средний размер веб-страниц вырос втрое (по данным исследования Akamai), а за последний год &mdash; в полтора раза (по данным <a href="http://webo.in/">webo.in</a>). При этом каждая страница использует в среднем по 50 объектов, что крайне негативно сказывается на общем времени загрузки. Только порядка 5-10% от общего времени загрузки приходится на серверную часть. Все остальное составляет именно клиентская архитектура.</p><h3>Белый экран в браузере</h3><p>Сколько времени вы готовы смотреть на белый экран в браузере прежде, чем сайт загрузится? 75% посетителей уйдут после 10 секунд. При этом наиболее характерным временем будет 4 секунды: если за это время сайт загружается у 90% пользователей, то вы счастливый владелец быстрого интернет-ресурса.</p><p>Однако и здесь дорога каждая миллисекунда. Недаром высоконагруженные проекта типа Google, Amazon, Flickr, Netflix, Яндекс, вКонтакте и Одноклассники так серьезно подходят к вопросу скорости загрузки сайтов. За каждым потерянным моментом времени кроется определенная сумма денег. Это именно то место, где время тождественно равно деньгам.</p><h3>В чем проблема?</h3><p>Основное время при загрузке страницы уходит именно на клиентскую часть. Серверные затраты обычно крайне малы и составляют от 50 до 500 мс. Среднему пользователю на самом деле абсолютно все равно, сколько страница будет создаваться на сервере, если он ее увидит через полсекунды. В этом случае фокус смещается именно на клиентскую, а не серверную оптимизацию.</p><p>Характер проблем варьируется от сайта к сайту. Иногда он заключается в особенности интернет-подключения основной массы пользователей ресурса (например, если широко используются модемы). Иногда &mdash; в сложности самого сайта и неоправданном использовании ресурсов сети. Иногда &mdash; в неграмотном использовании клиентских технологий и большого количества разнородных решений. Но все эти проблемы можно решить.</p><h3>Кто виноват и что делать?</h3><p>Для решения описанных проблем прежде всего нужно начинать с профессионального подхода при разработке какого-либо веб-приложения. Он обязательно должен опираться на использование веб-стандартов, в том числе и в области скорости загрузки и взаимодействия с пользователем.</p><p>Для полноценной оптимизации крупные компании разрабатывают специализированные решения. Однако даже в этом случае они опираются на многочисленный свод правил, описывающих наиболее оптимальное взаимодействие браузера с пользователем. Для среднего размера сайтов, использующих какое-либо стандартное решение для обслуживания контента, стоит обратить свое внимание на решения по автоматизации клиентской оптимизации.</p><p>Это <a href="http://getrpo.com/" rel="nofollow">GetRPO.com</a>, который направлен на сайта на базе сервера IIS. Для Apache и PHP существует два аналогичных решения: <a href="http://aciddrop.com/php-speedy/" rel="nofollow">PHP Speedy</a> (как плагин для Wordpress и Joomla!) и <a href="http://code.google.com/p/web-optimizator/">Web Optimizer</a> (как отдельное веб-приложение). Каждое из описанных решений позволяет свести затраты на внедрение оптимизации к минимуму и получить весьма неплохой результат для показателя скорости загрузки страницы.</p><p>Наконец при разработке сайтов стоит руководствоваться принципом &laquo;мягкой деградации&raquo;, согласно которому нужно наращивать функциональность в зависимости от способности браузера, а не наоборот. Например, можно использовать самые передовые технологии при верстке, которые поддерживаются не очень большим числом браузером, но должны поддерживаться значительной их долей, скажем, через год. Тогда определенные решения будут выглядеть безупречно у небольшого числа пользователей, у остальных &mdash; хорошо или приемлемо. Но с прогрессом интернета число последних будет стремительно уменьшаться.</p><p>Напоследок стоит упомянуть про возможность использования распределенной сети серверов для сведения времени ответа к минимуму. В этом могут помочь существующие системы &laquo;облачных&raquo; вычислений, такие как: AMazon S3, Google Apps, Microsoft Azure. Также аналогичная система есть и на российских просторах. Это первая в России CDN &mdash; <a href="http://ngenix.net/">NGENIX</a>.</p><h3>Потенциал ускорения</h3><p>Как показывает практика, средний сайт в Рунете можно достаточно легко ускорить в 3-5 раза. И при этом не нужно быть гением в клиентской оптимизации &mdash; достаточно применить ряд широко известных советов.</p><p>Все эти советы с детальным анализом эффективности, а также большое количество прикладного и новаторского материала приведено в первой в России специализированной книге, посвященной всем тонкостям клиентской оптимизации &mdash; <a href="http://speedupyourwebsite.ru/books/speed-up-your-website/">&laquo;Разгони свой сайт&raquo;</a>. В книге описаны все тонкости архивирования и кэширования, объединения и разъединения файлов, а также особенности оптимизации CSS- и JavaScript-логики. На данный момент продается во всех больших книжных магазинах Москвы и доступна через ряд интернет-магазинов, например, <a href="http://www.ozon.ru/context/detail/id/4400714/" rel="nofollow">ozon.ru</a>.</p><p>Спасибо за внимание. Вопросы?</p> Sun, 28 Feb 2010 00:00:00 GMThttp://www.habrahabr.ru/blogs/client_side_optimization/58052/#commentshttp://webo.in/articles/oborot2009/faster-means-better/http://webo.in/articles/oborot2009/faster-means-better/<h3>Скорость как основной критерий качества интернет-магазина</h3><p>Давайте рассмотрим основные критерии качества интернет-магазина. Здесь намеренно не упоминаются методы привлечения трафика: они составляют отдельную группу характеристик.</p><ul><li><strong>Соответствие заложенной нагрузке.</strong> Сайт может хорошо справляться с 1 просмотром страницы в секунду, но не выдерживать и 3 одновременных посетителей. Здесь нужно хорошо понимать, что при заявленной разработчиками посещаемости в 10000 человек ежедневно, такой сайт может быть способен выдавать не более 30-50 тысяч просмотров, что говорит о времени создания страницы порядка секунды или даже больше. В таких условиях рассчитывать на такой сайт, как на эффективный механизм онлайн-маркетинга не приходится.</li><li><strong>Соответствие стандартам.</strong> Стандартные решения легче разрабатывать и поддерживать. Стандартный код имеет большую совместимость с текущими (и будущими) версиями браузеров. Также соответствие стандартов говорит о высокой культуре разработки при создания сайта, поэтому в большинстве случаев стандартный сайт еще и более качественный.</li><li><strong>Удобство использования.</strong> Если сайт запутанный, пугающий или просто неудобный, то им, естественно, пользоваться не будут. Простейшую проверку удобства использования можно провести среди ваших знакомых, друзей и подчиненных: попросите их выполнить с помощью сайта какую-либо задачу и смотрите на результат. Особенно важно спрашивать, какие чувства у испытуемого при выполнении это задачи: это поможет глубже понять целевую аудиторию.</li><li><strong>Решение бизнес-задач владельца.</strong> Сайт может быть быстрым, качественным, удобным, но не решать основные задачи. Например, на сайте элитной недвижимости не будет контактов обратной связи. Или на сайте интернет-магазина будут отсутствовать кнопки "Купить" или "В корзину". Решение задач бизнес &mdash; это существенное условие качественного сайта.</li></ul><h3>Существующие стандарты</h3><p>Большая часть веб-технологий уже покрыта стандартами: это, в первую очередь, RFC, описывающие протоколы, и рекомендации W3C, которые уже давно стали стандартами в мире клиентских технологий. Также широко распространено сертифицирование по серверным языкам программирования: квалификация разработчиков может быть проверена достаточно путями.</p><p>Сложнее дело обстоит с удобством использования сайта (здесь стандартом пока крайне мало, и все они относятся к области доступности) и скоростью загрузки (здесь же есть общее положение по отрасли, которое и формирует нормальные или стандартные показатели).</p><h3>Скорость загрузки как стандарт</h3><p>Теперь перейдем к основным сформировавшимся в отрасли на текущий момент показателям скорости загрузки. В первую очередь, это время создании страницы на сервере, оно не должно превышать 0,5с. Затем идет достаточно характерный параметр: время появления в браузер хотя бы какого-то изображения сайта. Пользователи не склонны ждать много больше более 1 секунды в неизвестности, если заходят на качественный сайт. Поэтому &laquo;белый экран&raquo; в браузере рекомендуется показывать также не более 0,5с. Это стадия предварительной загрузки страницы.</p><p>Далее пользователь пытается освоится на сайте, и загрузка может продолжаться в интерактивном режиме. Однако полное время загрузки страницы не должно превышать 4 секунд: именно такой сейчас характерный порог ожидания пользователя. Если сайт загружается много дольше, то пользователь будет склонен покинуть его и искать альтернативу (а их сейчас очень много).</p><p>Для сравнения: по итогам последнего исследования Akamai характерное время загрузки страницы для западных пользователей &mdash; 2 секунды, в два раза меньше.</p><h3>Скорость загрузки как критерий</h3><p>Быстрые сайты кажутся пользователям более качественными и красивыми (это подтверждено многочисленными исследованиями). Пользователи склонны больше доверять быстрому интернет-магазину (впечатление от скорости работы сайта будет распространяться и на мнение о скорости, например, доставки или ответа на запросы). По исследования Google и Microsoft увеличение времени ожидания пользователя приводит к снижению конверсию посещений.</p><p>Какие же реальные цифры? На основе нашего опыта интеграции решений для ускорения сайтов мы можем сказать следующее:</p><ul><li>увеличение скорости на 100% приводит к 5% росту продаж,</li><li>на 200% &mdash; к 10% росту,</li><li>на 300% &mdash; к 12% росту.</li></ul><p>Скорость имеет значение и может быть подсчитана! Вот характерный график внедрения простых методов ускорения сайта (приведено число просмотров страницы на пользователя):</p><p><img src="http://i.webo.in/web-optimizer/web.optimizer.results.png" alt="Результаты внедрения Web Optimizer"/></p><h3>Проверяем скорость</h3><p>Для проверки серверной стороны существует инструмент <a href="http://host-tracker.com/" rel="nofollow">host-tracker.com</a>, с помощью которого можно установить характерное время доступа к сайту из различных точек земного шара. Также он позволяет оценить характерное время создания страницы на сервере (если минимальное время доступа к сайту больше 1с, то уже стоит бить тревогу).</p><p>Для проверки отказоустойчивости сайта стоит воспользоваться сервисом <a href="http://www.loadimpact.com/" rel="nofollow">Load Impact</a>. Бесплатный анализ позволяет проверить до 50 одновременных посещений (каждое из которых может открывать несколько десятков страниц на сайте). Основным показателем устойчивости сайта к нагрузкам будет вид кривой, который получится после проведения теста. Если график ровный или время открытия страницы несколько падает при росте посещаемости &mdash; значит, с сайтом все нормально. Если нет, то нужно принимать решение об оптимальном потоке посетителей, которых сайт сможет обслужить.</p><p><img src="http://webo.in/articles/site2009/website-quality/loadimpact.png" alt="Проверка с помощью LoadImpact"/></p><p>Для проверки качества скорости загрузки клиентской составляющей можно воспользоваться либо YSlow под Firebug для Firefox (оценка должна быть не менее 80, лучше всего не менее 90). Или же бесплатным инструментом <a href="http://webo.in/">webo.in</a> (простая оценка не ниже 70, лучше не ниже 80).</p><h3>На что влияет скорость</h3><p>Скорость загрузки оказывает ключевое влияние на доступность сайта (больше психологическую, чем фактическую), активность пользователей на сайте (медленными сайтами люди предпочитают не пользоваться) и его конверсию (медленным сайтам не доверяют).</p><p>Сейчас на рынке существует несколько решений, позволяющих автоматизировать ускорение сайта на клиентском уровне. Для ASP.NET &mdash; это <a href="http://www.aptimize.com/" rel="nofollow">Aptimize</a>, для систем на базе PHP &mdash; это <a href="http://www.web-optimizer.ru/">Web Optimizer</a>.</p> Sun, 28 Feb 2010 00:00:00 GMThttp://www.habrahabr.ru/blogs/client_side_optimization/71290/#commentshttp://webo.in/articles/livejournal/01-native-browser-events/http://webo.in/articles/livejournal/01-native-browser-events/<p><em>Примечание от sunnybear: в данной заметке lusever рассматривает наиболее компактные способы назначения обработчиков событий для элементов DOM-дерева. Рекомендуется читать вместе со статьями <a href="http://webo.in/articles/habrahabr/05-delayed-loading/">«отложенная» загрузка</a> и <a href="http://webo.in/articles/habrahabr/04-speed-up-events-handlers/">ускоряем обработку событий</a>.</em></p><p>Только практические javascript решения, без всякой теории о всплытии и захвате.</p><p>Рекомендую использовать выражения, идущие в конце логического блока.</p><h3>Ловим</h3><h4>В html</h4><ul><li><strong>В начале выполнится функция, потом переход по ссылке</strong><blockquote><pre>&lt;a href="http://webo.in/articles/livejournal/01-native-browser-events/#" onclick="func()"&gt;я ссылка&lt;/a&gt;</pre></blockquote></li><li><strong>Переход не выполнится (см. <code>preventDefault</code>)</strong><blockquote><pre>&lt;a href="http://webo.in/articles/livejournal/01-native-browser-events/#" onclick="func(); return false"&gt;я ссылка&lt;/a&gt;</pre></blockquote></li><li><strong>Переход зависит от того, вернет ли <code>func</code> false</strong><blockquote><pre>&lt;a href="http://webo.in/articles/livejournal/01-native-browser-events/#" onclick="return func()"&gt;я ссылка&lt;/a&gt;</pre></blockquote></li><li><strong>Передаем доступные параметры (порядок не важен):</strong><br/><code>this</code> &mdash; нода<br/><code>event</code> &mdash; тут значение имеет то, что мы передаем:<ul><li><code>function(event)</code> &mdash; получим кросс-браузерный вариант</li><li><code>function(e)</code> &mdash; передаст объект <code>Event</code> только для не IE браузеров</li></ul><blockquote><pre>&lt;a href="http://webo.in/articles/livejournal/01-native-browser-events/#" onclick="func(this, event)"&gt;я ссылка&lt;/a&gt;</pre></blockquote></li></ul><br/><h4>В javascript</h4><ul><li><blockquote><pre>&lt;a href="http://webo.in/articles/livejournal/01-native-browser-events/#" id="link"&gt;я ссылка&lt;/a&gt;</pre></blockquote></li><li><blockquote><pre>var node = document.getElementById('link')</pre></blockquote></li><li><strong>Назначаем напрямую</strong><blockquote><pre>node.onclick = function(){ this == node // true }</pre></blockquote></li><li><strong>Если нужно несколько событий</strong>, или просто «осторожничаем». Это распространенная запись<blockquote><pre>if (node.addEventListener) node.addEventListener('click', function(e){}, false) else node.attachEvent('onclick', function(){})</pre></blockquote> </li><li><strong>То же самое, но меньше символов</strong> <blockquote><pre>if (node.attachEvent) node.attachEvent('onclick', function(){}) else node.addEventListener('click', function(e){}, false)</pre></blockquote></li><li><strong>Способ с переменной</strong><blockquote><pre>var addEvent = node.attachEvent || node.addEventListener addEvent(/*@cc_on 'on'+@*/'click', function(){}, false)</pre></blockquote></li><li><strong>В одну строку</strong> с использованием <a href="http://www.javascriptkit.com/javatutors/conditionalcompile.shtml" rel="nofollow">условной компиляции</a><blockquote><pre>node[/*@cc_on !@*/0 ? 'attachEvent' : 'addEventListener'](/*@cc_on 'on'+@*/'click', function(){}, false)</pre></blockquote></li></ul><h3>Работаем с событиями</h3><ul><li><blockquote><pre>node[/*@cc_on !@*/0 ? 'attachEvent' : 'addEventListener'](/*@cc_on 'on'+@*/'click', function(e){ var target = e.target || e.srcElement // или if (!e.target) e.target = e.srcElement // или если нам надо всего разочек (e.target || e.srcElement).tagName this == node // true везде кроме IE, в котором this == window /* Отменяем всплытие */ if (e.stopPropagation) e.stopPropagation() else e.cancelBubble // или просто: используем вариант, который для совместимости работает во всех браузерах. // В FF2 причем быстрее stopPropagation, в остальных не смотрел e.cancelBubble = true /* Убираем действие по умолчанию (в данном случае клик) */ if (e.preventDefault) e.preventDefault() else e.returnValue = false // при <var>attachEvent</var> (как здесь) работает только в IE; // при назначении напрямую (node.onclick) везде return false }, false)</pre></blockquote></li></ul><h3>Дополнительный материал:</h3><ul><li><a href="http://quirksmode.org/js/introevents.html" rel="nofollow" lang="en">Introduction to Events</a> от quirksmode.org</li><li><a href="http://dean.edwards.name/weblog/2007/03/other-way/" rel="nofollow" lang="en">Реализация addEventListener в библиотеке Base2</a> от Дина Эдвардса</li><li><a href="http://webfx.eae.net/dhtml/ieemu/eventobject.html" rel="nofolow" lang="en">Эмуляция событийной модели IE в Firefox</a> от WebFX</li></ul><p>Спасибо за помощь <a href="http://shabunc.livejournal.com/profile" rel="nofollow"><img src="http://stat.livejournal.com/img/userinfo.gif" alt="shabunc" height="17" width="17"/>&nbsp;<strong>shabunc</strong></a> и <a href="http://crazyprotein.livejournal.com/profile"><img src="http://stat.livejournal.com/img/userinfo.gif" alt="crazyprotein" height="17" width="17"/>&nbsp;<strong>crazyprotein</strong></a>.</p> Sun, 28 Feb 2010 00:00:00 GMThttp://lusever.livejournal.com/18870.html#commentshttp://webo.in/articles/icamp2008/cms-speedup/http://webo.in/articles/icamp2008/cms-speedup/<p>Данный обзор делался исключительно для презентации на конференции iCamp'2008. Я проанализировал несколько наиболее распространенных в Рунете CMS и привел все информацию по ускорению их загрузки, которую удалось обнаружить.</p><h3><a href="http://www.sbuilder.ru/" rel="nofollow">S.Builder</a></h3><p><a href="http://www.sbuilder.ru/demo/about.php" rel="nofollow">Демо-версия</a>, практически, никакой информации не дала, поэтому далее информация (цитаты) лично от директора.</p><ol><li><h4>Gzip для HTML</h4><blockquote><p>В версии 4.0 этой функцией можно управлять из настроек системы. Просто поставить галочку в поле «Использовать GZip-сжатие страниц» и если браузер человека поддерживает такую функцию, то и CMS и страницы сайта будут использовать GZip. Если на одной CMS собрано несколько сайтов, настройка отдельна для каждого сайта.</p></blockquote></li><li><h4>CSS/JS сжатие/минимизация</h4><p>Не применяется. Только руками верстальщика.</p><blockquote><p>В нашей CMS человек сам вставляет HTML, CSS и JS в том виде, в котором они были сверстаны.</p></blockquote></li><li><h4>Кеширование</h4><p>Насколько удалось установить, наиболее корректно отдается <code>Last-Modified</code> для HTML. Все остальное покрыто мраком.</p></li><li><h4>CSS Sprites / параллельные хосты</h4><p>Нет и не планируется.</p></li></ol><h3><a href="http://www.umi-cms.ru/" rel="nofollow">UMI.CMS</a></h3><p>Проверялась демо-версия, <a href="http://www.umi-cms.ru/downloads/test_umicms/" rel="nofollow">доступная с официального сайта</a>. Также была попытка установить пакет с сайта. В него не удалось залогиниться.</p><ol><li><h4>Включаем кеширование</h4><p>Оно включается в настройках <code>Модули -&gt; Конфигурация -&gt; Глобальные -&gt; Разрешить браузерам кешировать страницы</code>. В серверные заголовки при этом добавляется <code>Last-Modified</code>. Цитата из документации:</p><blockquote><p>Если эта опция включена, то браузер пользователя будет вначале проверять, изменилась ли страница, и если страница не менялась, то загрузит ее из локального кэша. При этом браузеру будет посылаться HTTP-заголовок Last-Modified, который содержит дату последнего изменения страницы. Эта опция поможет значительно снизить нагрузку на трафик и позволит быстрее открывать страницы.</p></blockquote></li><li><h4>Подключаем зеркала для ускорения выдачи статики</h4><p><code>Модули -&gt; Конфигурация -&gt; Домены</code>, выбираем наш домен и жмем <code>Зеркала</code>. На открывшейся странице можно добавить еще несколько (2&ndash;4) хоста для выдачи статики. Например, у нас был домен</p><blockquote><p>endocardial.demo-pro.umi-cms.ru</p></blockquote><p>мы добавляем еще 4 хоста</p><blockquote><pre>i1.endocardial.demo-pro.umi-cms.ru ... i4.endocardial.demo-pro.umi-cms.ru</pre></blockquote><p>и теперь все картинки можно отдавать еще и таким образом</p><blockquote><pre>http://i1.endocardial.demo-pro.umi-cms.ru/images/cms/thumbs/picture2_50_50.jpg</pre></blockquote><p>Выяснить через техническую поддержку, можно ли это как-то автоматически прикрутить к существующим модулям, не удалось. Наверное, никак.</p></li><li><h4>Сжатие и минимизация CSS/JS</h4><p>Цитирую службу поддержки:</p><blockquote><p>Возможно реализовать, но это будут уже custom-ные решения для UMI.CMS. Вы можете сделать их самостоятельно или с помощью сторонних разработчиков.</p></blockquote></li></ol><h3><a href="http://drupal.org/" lang="en" rel="nofollow">Drupal</a></h3><p>Для тестирования бралась демо-версия с <a href="http://demo.bloggyland.com/" lang="en" rel="nofollow">demo.bloggyland.com</a>. Очень много советов по оптимизации приведено на странице <a href="http://wimleers.com/article/improving-drupals-page-loading-performance" lang="en" rel="nofollow">wimleers.com/article/improving-drupals-page-loading-performance</a>, где автор разбирает все правила из YSlow применительно к Drupal. Я лишь попытаюсь дополнить своими собственными.</p><ol><li><h4>Склейка CSS-файлов</h4><p>Еще во время своего первого знакомства с Drupal порадовался наличию возможности объединять десятки CSS-файлов для различных модулей (и затем кешировать результат). Включается это через <code>Administer -&gt; Site Configuration -&gt; Performance</code>. Эта настройка также автоматически минимизирует файл (регулярными выражениями).</p></li><li><h4>Склейка JS-файлов</h4><p><del>Не</del> Доступна в базовой поставке (Drupal 6, спасибо за комментарий <a href="http://adek.habrahabr.ru/" rel="nofollow"><img src="http://www.habrahabr.ru/i/small_default_userpic.gif" alt="посмотреть профиль" title="посмотреть профиль">&nbsp;adek</a>), и нам поможет модуль <a href="http://drupal.org/project/javascript_aggregator" lang="en" rel="nofollow">Javascript Aggregator</a>. Делает, в принципе, то же самое, что и предыдущий вариант, но уже для JavaScript-файлов. К тому же есть настройка для минимизации их размера (на основе обычных регулярных выражений, это дает от 80% возможного прироста производительности).</p></li><li><h4>Gzip</h4><p>Включается автоматически (не нашел, где включается в настройках, но все Drupal-сайты уже отдавали HTML в сжатом виде). Для CSS/JS-файлов добавляется (по всей видимости) двумя вышеупомянутыми решениями. Навскидку никаких проблем замечено не было.</p></li><li><h4>Кеширование</h4><p>Для статики и HTML-файлов настраивается в <code>Administer -&gt; Settings -&gt; Cache Settings</code>.</p></li><li><h4>CSS Sprites, CDN, etc</h4><p>К сожалению, все остальные плюшки уже приходится создавать вручную (либо соответствующие модули находятся в <a href="http://drupal.org/project/cdn" lang="en" rel="nofollow">стадии разработки</a>). Однако, уже вышеперечисленного списка вполне хватит для создания производительного сайта на Drupal.</p></li></ol><h3><a href="http://joomla.org/" lang="en" rel="nofollow">Joomla</a></h3><p>Некогда весьма популярная CMS сейчас как-то меньше мелькает в обзорах. Однако, сайтов на ней порядочно, и сообщество просто громадно. Настройки проверялись на имеющихся сайтах.</p><ol><li><h4>Gzip</h4><p>Для HTML-файлов добавляется в <code>Общие настройки -&gt; Сервер -&gt; GZIP-сжатие страниц</code>. Gzip для CSS/JS не предусмотрен.</p></li><li><h4>Склейка, минимизация и кеширование CSS/JS-файлов</h4><p>В базовой конфигурации нет. Удалось найти <a href="http://extensions.joomla.org/component/option,com_mtree/task,viewlink/link_id,1341/Itemid,35/" rel="nofollow">следующее расширение</a> (Cache accelerate component), которое дополнительно позволяет дополнительно кешировать (и архивировать) CSS/JS-файлы. Однако, не все ладно с серверными заголовками. Использовать стоит с осторожностью: возможны проблемы с совместимостью.</p><p>Также попутно был обнаружен <a href="http://www.fijiwebdesign.com/products/joomla-speedy-plugin.html" lang="en" rel="nofollow">PHP Speedy plugin для Joomla</a>, который позволяет делать то же самое, но с серверными заголовками у него все в порядке. В общем, рекомендуется к использованию.</p></li><li><h4>Etc.</h4><p>К сожалению, информации об остальных оптимизационных плюшках еще меньше. Если у кого-то есть соображения, поделитесь, пожалуйста, в комментариях.</p></li></ol><h3>В качестве заключения</h3><p>Абсолютно все CMS показали небогатый набор инструментов для клиентской оптимизации. Лучше всего с этим дело обстоит у открытых CMS, которые во многом развиваются за счет комьюнити.</p><p>Спасибо за внимание. Буду рад ответить на ваши вопросы.</p> Sun, 28 Feb 2010 00:00:00 GMThttp://www.habrahabr.ru/blog/client_side_optimization/47816.html#commentshttp://webo.in/articles/habrahabr/99-web-optimizer-installation-0.5/http://webo.in/articles/habrahabr/99-web-optimizer-installation-0.5/<p class="right"><a href="http://code.google.com/p/web-optimizator/" rel="nofollow"><img src="http://web-optimizator.googlecode.com/svn/trunk/images/web.optimizer.logo.small.png" alt="Web Optimizer" title="Web Optimizer"/></a></p><p>Не так давно вышла версия 0.5 (RC3) приложения для автоматического ускорения сайтов <a href="http://code.google.com/p/web-optimizator/" rel="nofollow">Web Optimizer</a>. Поскольку с момента написания <a href="http://webo.in/articles/habrahabr/87-web-optimizer-installation/">предыдущего руководства по установке</a> прошло уже три месяца, интерфейс и логика работы приложения существенно изменились (стали проще и нагляднее), то стоит осветить процесс установки еще раз, в новом виде и с новыми подробностями.</p><h3>Шаг 1: загрузка архива</h3><p>Web Optimizer поставляется в двух вариантах: ZIP-архив и мини-установщик. Для загрузки первого варианта идем по адресу <a href="http://code.google.com/p/web-optimizator/downloads/list" rel="nofollow">code.google.com/p/web-optimizator/downloads/list</a> и выбираем Featured версию 0.5 или выше.</p><p><img width="100%" src="http://i.webo.in/web-optimizer/7-04.png" alt="Выбираем файл для загрузки" title="Выбираем файл для загрузки"/></p><p>Загружаем ZIP-архив в корень сайта. Если к сайту есть SSH-доступ, то можно использовать просто wget:</p><blockquote><pre>wget http://web-optimizator.googlecode.com/files/web-optimizer.v0.5beta.zip</pre></blockquote><p>Затем полученный архив нужно будет распаковать в корень, чтобы получилась папка web-optimizer.</p><p>Если к сайту есть только FTP-доступ, то загружаем сначала на локальный диск, потом распаковываем, а потом уже (например, через FAR) копируем в корень сайта.</p><p>При отсутствии желания загружать распакованный архив на сервер (или распаковывать на сервере загруженный архив) есть версия мини-установщика, который (при наличии <code>curl</code> на сервере) сам все загрузит и начнет установку. Для этого нужно загрузить только файл <code>install.me.php</code> в корень сайта и открыть его в браузере.</p><p>После того, как все необходимые файлы оказались на сайте, то нужно выставить права на запись, как минимум, для файла <code>web-optimizer/config.php</code> и (опционально) папки <code>web-optimizer/cache</code> для пользователя, под которым работает сервер. Иначе настройки и закэшированные версии сжатых файлов не смогут сохраниться. При желании папка кэширования может быть другой (об этом чуть ниже), поэтому будет необходимо только выставить права на конфигурационный файл.</p><h3>Шаг 2: настройка</h3><p>Заходим в браузере по адресу</p><blockquote><pre>http://ваш_сайт/web-optimizer/index.php</pre></blockquote><p>Вместо <code>web-optimizer</code> может быть произвольная директория, в которой находится Web Optimizer. Видим приветственный экран от Web Optimizer. Если не видим, то стоит перепроверить, куда был скопирован Web Optimizer, а зайти именно в ту папку.</p><p><img width="100%" src="http://i.webo.in/web-optimizer/7-05.png" alt="Настройка доступа" title="Настройка доступа"/></p><p>Здесь возможно 2 варианта развития событий:</p><ul><li>Быстрая установка</li><li>Обычная установка</li></ul><h4>Быстрая установка</h4><p><img width="100%" src="http://i.webo.in/web-optimizer/7-06.png" alt="Быстрая установка" title="Быстрая установка"/></p><p>Для начала быстрой установки вводим будущий логин и пароль доступа к административной части и нажимаем зеленую кнопку «Быстрая установка». После этого Web Optimizer вычисляет директории на сервере, сохраняет все настройки по умолчанию и осуществляет цепочную оптимизацию для главной страницы: создает закэшированные версии сжатых файлов. Только потом, если файлы (обычно только корневой <code>index.php</code>, зависит от используемой CMS) доступны на запись, производится их автоматическое изменение.</p><p><img width="100%" src="http://i.webo.in/web-optimizer/7-07.png" alt="Окончание установки" title="Окончание установки"/></p><p>Иначе Web Optimizer выведет инструкции по изменению этих файлов.</p><p><img width="100%" src="http://i.webo.in/web-optimizer/7-12.png" alt="Инструкции по изменению файлов" title="Инструкции по изменению файлов"/></p><h4>Обычная установка</h4><p>Обычная установка отличается от быстрой только наличием промежуточного шага с редактированием настроек. Запустить ее можно, нажав по кнопке «Далее», цифре 2 или 3 в верхнем меню или оранжевой стрелочек справа.</p><p><img width="100%" src="http://i.webo.in/web-optimizer/7-11.png" alt="Настройки" title="Настройки"/></p><p>Подробно все настройки и их особенности <a href="http://webo.in/articles/habrahabr/96-web-optimizer-settings/">описаны в соответствующей статье</a>. Прежде всего нужно убедиться в том, что вычисленные пути являются правильными. Также можно задать произвольные директории кэширования: это будет необходимо при включении настройки «Защищенный режим» (находится в разделе «Использование <code>.htaccess</code>»). После этой настройки пароль при доступе к Web Optimizer будет запрашиваться только через HTTP Basic Authorization. Дополнительно вводить его не потребуется. Однако файлы, которые находятся внутри папки с Web Optimizer, станут не доступны обычным пользователям, поэтому директории кэширования нужно из нее перенести.</p><p><img width="100%" src="http://i.webo.in/web-optimizer/7-10.png" alt="Защищенный режим" title="Защищенный режим"/></p><h3>Шаг 3: Управление</h3><p>В Web Optimizer версии 0.5 доступно несколько инструментов для управления приложением.</p><p><img width="10)%" src="http://i.webo.in/web-optimizer/7-09.png" alt="Обычный режим. Обновление" title="Обычный режим. Обновление"/></p><p>Во-первых, это конфигурирование всех настроек (здесь и далее при работе не в защищенном режиме нужно будет ввести логин и пароль), которое можно осуществить по кнопке «Далее» (или клику по цифрам 2 или 3 или оранжевой стрелочке справа). Во-вторых, это очистка кэша (будет необходимо, если вы провели изменение каких-либо CSS- или JS-файлов на сервере при включенной настройке «Не проверять время изменения файлов») кнопка «Очистить кэш». В-третьих, это возможность безболезненно удалить Web Optimizer (будут удалены все добавленные в файлы CMS вызовы, а файл <code>.htaccess</code> будет очищен от оптимизационных директив) кнопка «Удалить».</p><p>При наличии <code>curl</code> на сервере и существовании более новой версии, чем текущая, будет предложено обновиться (появится блок с кнопкой «Обновить»). При обновлении все исходные настройки будут сохранены. Также могут добавиться некоторые новые. В обычном режиме панель администрирования для Web Optimizer выглядит следующим образом:</p><p><img width="100%" src="http://i.webo.in/web-optimizer/7-08.png" alt="Обычный режим" title="Обычный режим"/></p><h3>Решение возникающих проблем</h3><p>Часть известных проблем и методов решения уже <a href="http://webo.in/articles/habrahabr/96-web-optimizer-settings/">описана в предыдущей статье</a>. Если вы обнаружили некорректное поведение Web Optimizer для вашего сайта, вы можете <a href="http://code.google.com/p/web-optimizator/issues/entry" rel="nofollow">опубликовать описание ошибки</a> (требуется Google-аккаунт) или <a href="http://code.google.com/p/web-optimizator/issues/list?can=1&amp;cells=tiles" rel="nofollow">посмотреть все известные (или решенные) вопросы</a>. На данный момент среднее время решения проблемы составляет около суток (обычно несколько часов).</p><p>Также можно попробовать решить проблему в интерактивном режиме, <a href="http://webo.in/contacts/">используя указанные контакты</a>.</p><h3>Эффективность</h3><p>Несколько результатов использования Web Optimizer (для «чистой» установки системы, без каких-либо предварительных оптимизаций) <a href="http://webo.in/articles/habrahabr/93-web-optimizer-0.4.5/">приведено здесь</a>. Оценка YSlow поднимается до 89-97, скорость клиентской загрузки в 2-3 (реже 3-5) раз. Сам Web Optimizer после создания кэшированных файлов тратит всего 3-10мс на проверку и обновление выходного HTML-документа (при настройках по умолчанию, корректное сжатие HTML в одну строку достаточно ресурсоемкая операция и может занимать еще 50-100мс).</p><p>Загрузить Web Optimizer <a href="http://code.google.com/p/web-optimizator/downloads/list" rel="nofollow">code.google.com/p/web-optimizator/downloads/list</a></p><h3>Читать дальше</h3><ul><li><a href="http://webo.in/articles/habrahabr/98-web-optimizer-0.5/">Web Optimizer 0.5 "cheetah"</a></li><li><a href="http://webo.in/articles/habrahabr/93-web-optimizer-0.4.5/">Web Optimizer. Версия 0.4.5 &mdash; Release Candidate 2</a></li><li><a href="http://webo.in/articles/habrahabr/92-web-optimizer-0.4/">Web Optimizer. Версия 0.4 &mdash; Stable Release Candidate</a></li><li><a href="http://webo.in/articles/habrahabr/89-css-sprites-2.0/">CSS Sprites 2.0</a></li><li><a href="http://webo.in/articles/habrahabr/85-web-optimizator/">PHP Speedy &mdash; наше все</a></li></ul> Sun, 28 Feb 2010 00:00:00 GMThttp://www.habrahabr.ru/blogs/web_optimizator/62861/#commentshttp://webo.in/articles/habrahabr/98-web-optimizer-0.5/http://webo.in/articles/habrahabr/98-web-optimizer-0.5/<p class="right"><a href="http://code.google.com/p/web-optimizator/" rel="nofollow"><img src="http://web-optimizator.googlecode.com/svn/trunk/images/web.optimizer.logo.small.png" alt="Загрузить Web Optimizer"/></a></p><p>Мы снова здесь со свежей версией приложения для автоматизации клиентской оптимизации Web Optimizer. Больше месяца прошло с момента выхода последней стабильной версии, более 300 реальных сайтов испытали феноменальное ускорение, но нам этого показалось мало. И мы сделали хороший продукт еще лучше.</p><p>Итак, встречайте: версия 0.5 под кодовым именем «cheetah» (гепард), Release Candidate 3.</p><p>Загрузить: <a href="http://code.google.com/p/web-optimizator/downloads/list" rel="nofollow">code.google.com/p/web-optimizator/downloads/list</a></p><h3>Что нового?</h3><p>Естественно, весь месяц мы не сидели сложа руки и писали, тестировали, обновляли и тестировали вновь. Изменения по сравнению с версией 0.4.5:</p><ul><li>Одним из главных бонусов является включение в состав Web Optimizer последней версии библиотеки для форматирования и оптимизации CSS-кода CSS Tidy (наверное, в ближайшем будущем выйдет ее новая версия, 1.4, а то уже все заждались). Исправлено несколько очевидных и не очень ошибок (в частности, связанных с CSS3-селекторами).</li><li>Была существенно переработана логика самого Web Optimizer для максимальной производительности. По последним тестам время его работы для отдельной страницы составляет 3-10мс (в среднем сайт на Joomla! требует 200-500мс для выполнения всей серверной логики).</li><li>Исправлена проблема с «белым экраном» при использовании CSS Sprites (связана с «вылетом» GDLib при попытке создать слишком большое изображение). Теперь при недостатке памяти просто создается не такой большой спрайт, как хотелось бы. Видимо, в будущих версиях алгоритм расходования памяти будет существенно улучшен.</li><li>Полностью обновлен пользовательский интерфейс (спасибо <a href="http://fade.habrahabr.ru/" rel="nofollow"><img src="http://www.habrahabr.ru/i/small_default_userpic.gif" alt="посмотреть профиль" title="посмотреть профиль"/>&nbsp;fade</a> ). Мы продолжаем <a href="http://sprites.in/donate/">собирать деньги</a>, чтобы отблагодарить автора дизайна. Еще не поздно внести свою лепту.</li><li>Авто-изменение PHP-файлов CMS включено по умолчанию. В случае невозможности такого изменения на последнем шаге выводится полный список необходимых изменений для файлов.</li><li>Добавлена возможность создать «защищенную» установку: Web Optimizer может находиться в произвольной директории и быть закрытым при помощи <code>.htpasswd</code>. Более подробно данная тема раскрывается в <a href="http://webo.in/articles/habrahabr/96-web-optimizer-settings/">статье про настройки</a>.</li><li>В настройки Web Optimizer добавлены ссылки на соответствующие статьи, в которых заявленные техники освещаются в полном масштабе.</li><li>Добавлено достаточно простое кэширование для HTML-документов. Помогает в случае простых сайтов снять нагрузку с сервера (создаваемые HTML-документы надежно кэшируются). Доступные настройки: время кэширования, регулярное выражение для запрета кэширования, список USER AGENTS для форсирования кэширования, возможность сделать быстрый сброс документа.</li><li>Благодаря сотрудничеству с <a href="http://ort.habrahabr.ru/" rel="nofollow"><img src="http://www.habrahabr.ru/i/small_default_userpic.gif" alt="посмотреть профиль" title="посмотреть профиль"/>&nbsp;ort</a> значительно улучшена стабильность работы и функционирование распределения изображений по статическим хостам. Все обнаруженные проблемы совместимости с LiveStreet 0.3 были устранены.</li><li>Добавлена возможность оптимизации фоновых изображений через API сервиса <a href="http://smush.it/" rel="nofollow">smush.it</a>.</li><li>По умолчанию добавлено статическое архивирование для CSS/JS-файлов. Это означает, что если сжатием у вас заправляет сервер, то ему не придется каждый раз сжимать эти файлы перед отдачей клиенту gzip-версии будут храниться на сервере рядом с обычными и отдаваться в случае необходимости. Даже если сжатием заправляет PHP, все равно он будет отдавать уже готовые сжатые файлы, а не запускать <code>ob_gzhandler</code> каждый раз.</li><li>Улучшен алгоритм работы <code>data:URI</code>: немного увеличен максимальный размер файла и добавлены исключения для некоторых типов (<code>.htc</code>, <code>.cur</code>, <code>.eot</code> и т.д.).</li><li>Добавлена возможность вынести сгенерированный JS-файл перед <code>&lt;/body&gt;</code>. Также добавлена возможность вынести загрузку счетчиков и рекламы в самый низ документа, чтобы избежать блокирующего влияния скриптов.</li><li>Добавлена очистка кэша из панели администрирования.</li><li>Добавлена возможность корректно сжимать HTML в одну строку.</li><li>Добавленные системы:<ul><li>Textpattern 4.0</li><li>Kohana 2.3</li><li>phpBB 3.0</li><li>Yii 1.0</li><li>SMF 1.1.8</li><li>IPB 2.3.6</li><li>Bitrix</li><li>cogear 1.0</li></ul></li><li>Ну и сотня-другая не столь крупных исправлений и улучшений.</li></ul><h3>Что дальше?</h3><p>Видимо, главным приоритетом для новой версии станет максимальная совместимость с самыми различными вариантами поддерживаемхы CMS и максимальная производительность при любых настройках и любом серверном окружении (не у всех же сайтов выделенный сервер с 1Гб оперативной памяти?). На данный момент есть весьма интересная задача по оптимизации создания CSS Sprites (как показала практика, они стабильно создаются уже в 95-99% случаев) в случае ограниченной памяти. Если кто соберется помочь пишите в комментариях, приват и по <a href="http://webo.in/contacts/">указанным контактам</a>. Только давайте не так, как вышло с версткой для нового интерфейса, когда 5 верстальщиков один за другим сошли с дистанции.</p><h3>Замеченные ошибки и документации</h3><p>Документация и описание приложения будет ширится и расти. на данный момент уже опубликована <a href="http://webo.in/articles/habrahabr/96-web-optimizer-settings/">статья с описанием настроек</a>, готова к публикации статья с пошаговым руководством по установке. В процессе подготовки статья с описанием известных проблем под наиболее популярные CMS.</p><p>Часть документации (в основном, касательно принципов работы) выложена на английском здесь: <a href="http://code.google.com/p/web-optimizator/w/list" rel="nofollow">code.google.com/p/web-optimizator/w/list</a></p><p>Некоторые известные проблемы и методы их решения уже <a href="http://webo.in/articles/habrahabr/96-web-optimizer-settings/">описаны в предыдущей статье</a>. Если вы обнаружили некорректное поведение Web Optimizer для вашего сайта, вы можете <a href="http://code.google.com/p/web-optimizator/issues/entry" rel="nofollow">опубликовать описание ошибки</a> (требуется Google-аккаунт) или <a href="http://code.google.com/p/web-optimizator/issues/list?can=1&amp;cells=tiles" rel="nofollow">посмотреть все известные (или решенные) вопросы</a>. На данный момент среднее время решения проблемы составляет около суток (обычно несколько часов).</p><p>Также можно попробовать решить проблему в интерактивном режиме, <a href="http://webo.in/contacts/">используя указанные контакты</a>.</p><h3>Монетизация</h3><p>На данный момент доступна платная установка и настройка приложения дл вашего сайта. <a href="http://webo.in/speed/">Заказать можно здесь</a>. Также есть вероятность того, что будет выпущена отдельная, коммерческая ветка приложения, которая будет каким-либо образом продаваться (политика лицензирования обсуждается).</p><p>Если у вас есть какие-то конкретные коммерческие предложения, их всегда можно озвучить по <a href="http://webo.in/contacts/">указанным контактам</a>.</p><h3>Эффективность</h3><p>Несколько результатов использования Web Optimizer (для «чистой» установки системы, без каких-либо предварительных оптимизаций) <a href="http://webo.in/articles/habrahabr/93-web-optimizer-0.4.5/">приведено здесь</a>. Оценка YSlow поднимается до 89-97, скорость клиентской загрузки в 2-3 (реже 3-5) раз. Сам Web Optimizer после создания кэшированных файлов тратит всего 3-10мс на проверку и обновление выходного HTML-документа (при настройках по умолчанию, корректное сжатие HTML в одну строку достаточно ресурсоемкая операция и может занимать еще 50-100мс).</p><p>Ну, вроде все. До новых встреч :)</p><p>Загрузить Web Optimizer: <a href="http://code.google.com/p/web-optimizator/downloads/list" rel="nofollow">code.google.com/p/web-optimizator/downloads/list</a></p><p>Поддержать проект материально: <a href="http://sprites.in/donate/">sprites.in/donate/</a></p><h3>Читать дальше</h3><ul><li><a href="http://webo.in/articles/habrahabr/93-web-optimizer-0.4.5/">Web Optimizer. Версия 0.4.5 &mdash; Release Candidate 2</a></li><li><a href="http://webo.in/articles/habrahabr/92-web-optimizer-0.4/">Web Optimizer. Версия 0.4 &mdash; Stable Release Candidate</a></li><li><a href="http://webo.in/articles/habrahabr/89-css-sprites-2.0/">CSS Sprites 2.0</a></li><li><a href="http://webo.in/articles/habrahabr/85-web-optimizator/">PHP Speedy &mdash; наше все</a></li></ul> Sun, 28 Feb 2010 00:00:00 GMThttp://www.habrahabr.ru/blogs/web_optimizator/62009/#commentshttp://webo.in/articles/habrahabr/97-css-tidy/http://webo.in/articles/habrahabr/97-css-tidy/<p><a href="http://csstidy.sourceforge.net/" rel="nofollow">CSS Tidy</a> является полностью открытой и на данный момент одной из самых мощных библиотек по преобразования CSS-кода. В большинстве случаев ее используют для минимизации CSS-кода (что позволяет добиваться <a href="http://webo.in/articles/habrahabr/14-minifing-css/">весьма впечатляющих результатов</a>, <a href="http://csstidy.sourceforge.net/example.php" rel="nofollow">пример с сайта CSS Tidy</a>). Огромное количество сайтов предлагают минимизаторы, основанные именно на CSS Tidy: <a href="http://www.cleancss.com/" rel="nofollow">CleanCSS</a>, <a href="http://hellobmw.com/csstidy/" rel="nofollow">CSS Formatter and Optimizer</a>, <a href="http://www.csscompressor.com/" rel="nofollow">CSS Compressot</a> и многие другие. Даже <a href="http://developer.yahoo.com/yui/compressor/" rel="nofollow">YUI Compressor</a> год назад уступал CSS Tidy по степени сжатия.</p><h3>Преамбула</h3><p>Количество настроек CSS Tidy впечатляет: это и сжатие наименований свойств (цветов, шрифтов, фона), и регистро-независимый вывод, и объединение селекторов для максимальной минимизации кода, и их сортировка, и исключение нестандартных CSS-свойств, и сохранение синтаксиса введенного кода, и т.д. (<a href="http://csstidy.sourceforge.net/usage.php" rel="nofollow">полный список поддерживаемых настроек с примерами</a>).</p><p>Поскольку библиотека направлена на разбор и стандартизацию (как следует из названия - Tidy), а не только на минимизацию кода, то с ее помощью можно проворачивать довольно любопытные вещи. Например, выводить CSS-код в стандартном виде в любом формате (CSS Tidy <a href="http://csstidy.sourceforge.net/templates.php" rel="nofollow">поддерживает шаблоны вывода</a>). Или осуществлять любые преобразование с таблицей стилей на странице (к слову, именно она используется для <a href="http://sprites.in/">создания CSS Sprites</a> и, естественно, в приложении для автоматической клиентской оптимизации &mdash; <a href="http://code.google.com/p/web-optimizator/" rel="nofollow">Web Optimizer</a>). В Web Optimizer уже включена самая последняя версия CSS Tidy, в которой исправлены некоторые ошибки.</p><p>Так как приложение написано с учетом высоких требований к производительности, то работает оно очень шустро (в несколько раз быстрее того же YUI Compressor).</p><p>Но речь не совсем об этом.</p><h3>Амбула</h3><p>На данный момент (<a href="http://en.wikipedia.org/wiki/CSSTidy" rel="nofollow">как написано в Wikipedia</a>) автор (Florian Schmitz) ищет людей, который смогли бы вести проект дальше. PHP-часть библиотеки не так сложна, и я справляюсь с ней самостоятельно. Но проблемы возникли при необходимости параллельно поддерживать Win32-версию (CPP). Беглый взгляд на текущий состав файлов мне ничего не подсказал, поэтому я прошу у сообщества помощи и в свою очередь ищу людей, которые смогли бы поддерживать актуальность CPP-ветки.</p><p>Для примера текущий список файлов в ней:</p><blockquote><pre>SConscript background.cpp background.hpp conversions.cpp conversions.hpp cssopt.cpp cssopt.hpp csspp_globals.cpp csspp_globals.hpp csspp_private.h csstidy.cpp csstidy.hpp datastruct.hpp file_functions.cpp file_functions.hpp important.cpp important.hpp main.cpp misc.cpp misc.hpp parse_css.cpp parse_css.hpp prepare.cpp prepare.hpp print_css.cpp trim.cpp trim.hpp umap.cpp umap.hpp win32_resource.rc</pre></blockquote><h3>Заключение</h3><p>CSS Tidy уже два года "застрял" на версии 1.3. Очень хотелось бы сдвинуть эту библиотеку с мертвой точки и продолжить ее полноценную разработку, ибо с появлением CSS3-селекторов задача эта становится уже гораздо интереснее.</p><p>Если добровольцы найдутся, то можно писать в комментариях, приват или <a href="http://webo.in/contacts/">используя контакты</a>. Будем решать, как организовывать дальнейшую работу.</p><h3>Читать дальше</h3><ul><li><a href="http://webo.in/articles/habrahabr/93-web-optimizer-0.4.5/">Web Optimizer. Версия 0.4.5 &mdash; Release Candidate 2</a></li><li><a href="http://webo.in/articles/habrahabr/92-web-optimizer-0.4/">Web Optimizer. Версия 0.4 &mdash; Stable Release Candidate</a></li><li><a href="http://webo.in/articles/habrahabr/89-css-sprites-2.0/">CSS Sprites 2.0</a></li><li><a href="http://webo.in/articles/habrahabr/85-web-optimizator/">PHP Speedy &mdash; наше все</a></li><li><a href="http://webo.in/articles/habrahabr/14-minifing-css/">CSS: все о сжатии</a></li></ul> Sun, 28 Feb 2010 00:00:00 GMThttp://www.habrahabr.ru/blogs/web_optimizator/62464/#commentshttp://webo.in/articles/habrahabr/96-web-optimizer-settings/http://webo.in/articles/habrahabr/96-web-optimizer-settings/<p class="right"><a href="http://code.google.com/p/web-optimizator/"><img src="http://web-optimizator.googlecode.com/svn/trunk/images/web.optimizer.logo.small.png" alt="Загрузить Web Optimizer"/></a></p><p>Пока выпуск версии 0.5 веб-приложения, автоматизирующего клиентскую оптимизацию для PHP-сайтов, отодвигается на некоторое неопределенное время, мы решили подготовить небольшой обзор текущих настроек и возможностей приложения.</p><h3>Особенности работы</h3><p>Web Optimizer перехватывает выводимый HTML-документ и преобразовывает его к оптимальному виду. В частности, анализируется вся секция <code>head</code> на предмет CSS- и JavaScript-файлов, также при существовании статических хостов изображения распределяются по ним (меняются адреса у изображений), а блоки с рекламой и счетчиками переносятся перед <code>&lt;/body&gt;</code> (опять-таки только при включении соответствующей настройки). Также HTML подвергается минимизации (удаляются лишние переводы строк и отступы, могут удаляться комментарии и вообще все лишние символы, но это ресурсоемкие операции, и по умолчанию они выключены).</p><p>Загрузить приложение: <a href="http://code.google.com/p/web-optimizator/downloads/list" rel="nofollow">http://code.google.com/p/web-optimizator/downloads/list</a>.</p><h3>Настройка Web Optimizer</h3><p>Ниже приведены настройки, доступные в Web Optimizer версии 0.4.9.7 (войдут в 0.5 без изменений):</p><ul><li><strong>Директории кэширования</strong>. Здесь можно выставить пути к кэширующим директориям (на файловой системе), в которых будут записываться сохраненные уменьшенные CSS-, JavaScript- и HTML-файлы. Также здесь можно определить корневую директорию сайта (необходима для правильного расчета всех относительных путей). По умолчанию все кэширующие директории назначаются в папке <code>cache</code> в самом Web Optimizer.</li><li><strong>Настройки сжатия</strong>. Эта группа настроек отвечает за объединении и минимизацию JavaScript- и CSS-файлов. По умолчанию JavaScript-файлы объединяются и минимизируются при помощи JSMin (или YUI Compressor, если доступна <code>java</code>). Также можно сжимать JavaScript при помощи Dean Edwards Packer (является лучшим выбором при отсутствии <code>gzip</code>-сжатия). Здесь также можно настроить, каким образом минимизировать выводимый HTML-код (простое удаление лишних переводов строк и пробелов, &laquo;вытягивание&raquo; в одну строку и(ли) удаление комментариев). Условные комментарии для IE не затрагиваются ни в каком случае.</li><li><strong>Включить внешние JavaScript-файлы</strong>. Web Optimizer может загружать внешние JavaScript-файлы (вызываемые с других доменов), а также внутренний код (заключенный прямо в <code>&lt;script&gt;</code>). Здесь можно настроить и &laquo;склеивание&raquo; CSS-кода, находящегося в <code>&lt;style&gt;</code> (по умолчанию включено). Также можно указать (через пробел) названия файлов (названия, а не полные пути), которые нужно исключить из логики объединения. На этапе тестирования была обнаружена невозможность объединить исходные библиотеки Tiny MCE и FCE Editor, поэтому они исключаются по умолчанию.</li><li><strong>&laquo;Ненавязчивый&raquo; JavaScript</strong>. В этой группе собраны настройки, отвечающие за неблокирующие загрузку различных вариантов JavaScript. В частности, можно вынести объединенный JavaScript-файл перед <code>&lt;body&gt;</code> (или вообще вызывать его загрузку по событию <code>DomContentLoaded</code>), можно вынести загрузку некоторых счетчиков, рекламы и информеров также в самый низ документа (после JavaScript-кода результирующий HTML-код вставляется в исходное место на странице, обеспечивая постепенное появление дополнительных рекламных блоков после того, как загрузилось основное содержание).</li><li><strong>Не проверять время изменения</strong>. Данная настройка позволяет не проверять при загрузке каждой страницы время изменение и содержание всех файлов, только существование закэшированных версий. За счет этого мы получаем существенный прирост серверной производительности (по умолчанию настройка включена). В случае отладки или очень частого изменения исходных JavaScript- или CSS-файлов настройку лучше отключить.</li><li><strong>Gzip-сжатие (архивирование)</strong>. Данная группа настроек регулирует, отдавать ли браузеру JavaScript-, CSS- или HTML-файлы в виде архивов. Gzip-сжатие позволяет сэкономить 70-85% трафика при передаче текстовых файлов, однако может быть (особенно в случае сжатия через PHP и высоконагруженных проектов) не очень оптимальной для сервера. В любом случае по возможности все настройки сжатия выносятся в <code>.htaccess</code> (для CSS- и JavaScript- в статическом виде). При невозможности изменения <code>.htaccess</code> gzip-версии JavaScript- и CSS-кода сохраняются в кэширующих директориях, что также сводит нагрузку на процессор (через PHP) к минимуму.</li><li><strong>&laquo;Вечное&raquo; кэширование</strong>. Настройки этой группы отвечают за выставление кэширующих заголовков для JavaScript-, CSS-, HTML- или статических файлов (изображений и анимации). Для изображений и анимации соответствующие правила размещаются только в <code>.htaccess</code>, для остальных файлов они дублируются по необходимости через PHP. По умолчанию для статических файлов выставляется срок кэширования на 10 лет (при изменении файлов новые версии имеют другое имя, создаваемое на основе md5-хэша от общего содержимого файлов). Для HTML-файлов есть возможность вручную выставить подходящий срок действия клиентского кэша. Отличие этой настройки от следующей группы (серверного кэширования HTML-файлов) заключается в том, что выводимый HTML никак на сервере не сохраняется, мы только указываем браузерам, что они могут не перезапрашивать HTML-документы в течение определенного времени. Будут ли браузеры следовать этому указания или нет, остается полностью на их совести.</li><li><strong>Кэширование HTML-файлов</strong>. Для существенного ускорения работы серверной стороны практически во всех случаях требуется применять серверное кэширование. И практически все CMS это поддерживают (на том или ином уровне). Web Optimizer предлагает альтернативный вариант (для тех случаев, когда текущая система это не умеет, либо нужно более &laquo;жесткое&raquo; решение): простое кэширование HTML-документов. При включении этой настройки HTML-файлы сохраняются в директории кэширования и отдаются при первом вызове Web Optimizer, без обработки внутренней логики системы. Естественно, учитывается срок действия кэша. Также возможно выдавать сразу не весь документ, а первый 1-2 Кб (через сброс документа), а потом рассчитывать остальную часть. Это может помочь визуально ускорить загрузку страницы на некоторых окружениях. Для настройки кэширования доступен список частей URL сайта, которые нужно исключить (есть возможность задавать регулярные выражения) и список роботов (USER AGENTS), для которых нужно форсировать выдачу кэширующего файла.</li><li><strong>CSS Sprites</strong>. Пожалуй, самая технологически мощная и самая спорная часть Web Optimizer. Правильное использование спрайтов позволяет на порядок (!) уменьшить число запросов к серверу при загрузке страницы с большим количеством фоновых изображений (с 20-100 до 3-10). Однако существуют некоторые проблемы с отображением комбинированных картинок для IE6 (картинки по умолчанию создаются в 32-битной палитре, а IE6 не умеет корректно обрабатывать прозрачность для таких PNG), проблемы устраняются исключением IE6 из создания спрайтов (соответствующей настройкой), либо использованием непрозрачных картинок. Также доступны настройки по использованию JPEG вместо PNG для полноцветных изображений, &laquo;агрессивному&raquo; режиму (<code>repeat-x</code> и <code>repeat-y</code> будут объединяться без учета фактических размеров контейнеров), добавлению свободного пространства (позволяет избежать рудиментов при масштабировании таких картинок в современных браузерах). Для повышения стабильности работы добавлен режим &laquo;ограниченной&raquo; памяти: если у PHP-процесса меньше 64 Мб памяти (этого хватает для создания спрайта примерно 3000 на 3000 пикселей, что вполне достаточно для большинства сайтов), то изображения, по площади большие 4000 пикселей, будут исключены. Также есть настройка по исключению больших изображений по их линейным размерам (в пикселах, по умолчанию 900) и прямому исключения файлов (опять-таки задаются имена файлов, а не полный путь к ним) из процесса создания CSS Sprites.</li><li><strong>data:URI</strong>. Технология <code>data:URI</code> позволяет включать фоновые изображения прямо в CSS-файл. Поддерживается всеми современными браузерами и IE8. Имеет ограничение на размер изображения в 24 Кб (32 Кб <code>data:URI</code> кода получаются из 24576 байтов бинарного кода). При создании <code>data:URI</code> для IE7- в CSS-файл вставляются хаки, благодаря чему дизайн сайта остается неизменным для этих браузеров. Также при создании <code>data:URI</code> крайне желательно оптимизировать изображения. Для этого используется API от <a href="http://smush.it/" rel="nofollow">smush.it</a>. Для корректной оптимизации изображений нужны права на запись для веб-сервера на сами изображения. Эта настройка по умолчанию отключена, потому что оптимизировать изображения имеет смысл всего один раз, и при последующих сборках CSS-файлов использовать уже готовый результат.</li><li><strong>Множественные хосты</strong>. Данная настройка позволяет включить распределение изображений по статическим хостам. Каждому изображению всегда будет соответствовать один хост (чтобы избежать забивания кэша одними и теми же изображениями со всех доступных хостов). Для использования данного механизма ускорения загрузки необходимо прописать в DNS все альтернативные хосты на тот IP-адрес, который будет их обслуживать (обычно это текущий сайт) и добавить в конфигурации сервера алиасы для основного сайта в виде этих хостов. Например:<blockquote><pre>ServerAlias i1.site.ru ServerAlias i2.site.ru</pre></blockquote> После этого можно добавить <code>i1 i2</code> в список хостов для Web Optimizer и убедиться в том, что изображения &laquo;раскидываются&raquo; по этим хостам. При установке Web Optimizer автоматически проверяется ряд хостов на возможность их использования в качестве альтернативных (с тем же корнем сайта), также все вручную указанные хосты проверяются на доступность (с них загружаются тестовые картинки). Стоит иметь в виду, что пи включении &laquo;безопасной&raquo; установки (о ней чуть ниже) проверка хостов становится недоступной и их прописывать нужно будет вручную, не перезапуская настройку Web Optimizer.</li><li><strong>Использование <code>.htaccess</code></strong>. Большая часть настроек gzip-сжатия и кэширования могут быть записаны в конфигурационном файле вашего сервера для избежания дополнительной работы на стороне серверных скриптов. Это может быть проделано с помощью файла <code>.htaccess</code> (при необходимости вы можете впоследствии самостоятельно перенести все настройки в файл <code>httpd.cond</code>). Web Optimizer автоматически проверяет доступные модули и конфигурирует запись в <code>. htaccess</code> (естественно, для этого последний должен быть доступен на запись). <code>mod_gzip</code>, <code>mod_deflate</code> и <code>mod_filter</code> отвечают за сжатие файлов &laquo;на лету&raquo;, <code>mod_rewrite</code> и <code>mod_mime</code> &mdash; за статическое архивирование. <code>mod_headers</code> и <code>mod_setenvif</code> &mdash; за обеспечение корректной обработки сжатых файлов на проксирующих серверах и в старых браузерах. <code>mod_expires</code> &mdash; за выставление кэширующих эаголовков. Также возможно расположить <code>.htaccess</code> либо в директории сайта (это бывает полезно, если на одном хосте располагается несколько сайтов в разных дирекориях), либо в самом корне сайта. По умолчанию оба месторасположения совпадают. Также возможно защитить установку Web Optimizer с помощью <code>.htpasswd</code>. В этом случае для доступа к настройкам нужно будет ввести логин и пароль через окно HTTP Basic Authorization в браузере (это позволяет вынести Web Optimizer в произвольную директорию внутри сайта, предварительно расположив директории кэширования вне защищенной области).</li><li><strong>Логотип Веб Оптимизатора</strong>. На данный момент эта группа настроек никак не используется. Может быть, в будущем на каждый сайт будет добавляться небольшая печать &laquo;Ускорено при помощи Веб Оптимизатора&raquo; со ссылкой на проект. Но пока решения на эту тему не принято.</li><li><strong>Автоматическое изменение <code>/index.php</code></strong>. Web Optimizer поддерживает автоматическое изменение необходимых для корректной работы файлов для нескольких десятков CMS (в случае неизвестной системы ее название выводится как CMS 42, и изменяется всегда корневой <code>index.php</code>). Перед автоматическим изменением файла запускается цепочная оптимизация сайта, чтобы создать все кэширующие файлы и избежать длительной загрузки главной страницы сайта в первый раз.</li></ul><h3>Примеры использования</h3><p>Web Optimizer &mdash; достаточно мощный и гибкий инструмент для клиентской оптимизации произвольного сайта. Но правильная его настройка требует внимательности и понимания желаемого результата. Давайте рассмотрим некоторые наиболее характерные изменения в конфигурации по умолчанию.</p><ul><li><strong>Подключение общего(-их) JavaScript- или CSS-файла(-ов) на всех страницах</strong>. Достаточно часто мы можем вставить на все страницы какую-то общую JavaScript-библиотеку или таблицу стилей, нужную для всего сайта. Для того чтобы Web Optimizer не пытался объединить этот общий файл со всеми остальными, можно исключить его в конфигурации:<blockquote><pre>Включить внешние JavaScript-файлы и встроенный код -&gt; Исключить из объединения файлы -&gt; список файлов через запятую</pre></blockquote></li><li><strong>Отключение CSS Sprites</strong>. Зафиксированы случаи, когда в силу ряда причин (отсутствия корректной поддержки GDLib на хостинге, ограничениях по памяти, и т.д.) попытка создания CSS Sprites приводит к &laquo;белому экрану&raquo; в браузере (и сайт перестает открываться). В таких случаях обычно помогает полное отключение CSS Sprites:<blockquote><pre>CSS Sprites -&gt; Применить CSS Sprites -&gt; нет</pre></blockquote>При желании CSS Sprites можно создать вручную через <a href="http://sprites.in/">Auto Sprites</a>, указав минимизированный CSS-файл (или объединенный исходный).</li><li><strong>Некорректное отображение сайта в IE6</strong>. В этом случае может помочь простое отключение спрайтов для IE6:<blockquote><pre>CSS Sprites -&gt; Исключить IE6 (через хаки) из процесса создания CSS Sprites -&gt; да</pre></blockquote>Также возможно, что IE6 некорректно обрабатывает объединение стилей (и наложение фона вместе с рядом других хаков). Тогда может помочь отключение <code>data:URI</code><blockquote><pre>Data:URI -&gt; Применить data:URI -&gt; нет</pre></blockquote>или вообще объединения CSS-файлов:<blockquote><pre>Настройки сжатия -&gt; Минимизировать и объединить CSS-файлы -&gt; нет</pre></blockquote></li><li><strong>Безопасная установка</strong>. Web Optimizer может быть установлен в произвольную директорию (внутри сайта) и защищен с помощью пароля через <code>htpasswd</code>. Для этого нужно включить:<blockquote><pre>Использование .htaccess -&gt; Защитить установку Веб Оптимизатора с помощью htpasswd -&gt; да</pre></blockquote>При этом нужно убедиться, чтобы <code>Директории кэширования</code> были расположены вне папки с самим Web Optimizer (иначе все развалится для всех посетителей сайта кроме вас самих).</li><li><strong>Подключение для статического сайта</strong>. Web Optimizer может быть использован для любого сайта, для которого доступен PHP. Если у вас уже есть статический сайт, то вы можете подключить вызов Web Optimizer в самом верху каждой страницы (или <code>index.php</code>):<blockquote><pre>&lt;?php require(/путь/к/Web/Optimizer/web.optimizer.php); ?&gt;</pre></blockquote>и затем в самом низу страницы:<blockquote><pre>&lt;?php $web_optimizer-&gt;finish(); ?&gt;</pre></blockquote>Поскольку в плановом режиме (после создания всеъ кэширующих файлов) высполнение логики Web Optimizer занимает 5-10мс, то на серверную сторону загрузки это не повлияет, зато клиентская будет существенно ускорена. Только надо убедиться, что те страницы, на которые вы добавите вызовы Web Optimizer будут обрабатываться через PHP-интерпретатор (будут иметь расширение <code>.php</code> или какое-либо другое, определяемое настройками сервера).</li><li><strong>Оптимизация по расписанию</strong>. Уже сейчас Web Optimizer может быть встроен в схему публикации произвольного сайта в &laquo;статическом&raquo; режиме. Для этого необходимо открыть все страницы сайта с установленным Web Optimizer, а потом просто скопировать выведенный HTML и кэширующие директории. Предположим, что Web Optimizer установлен на <code>dev.site.ru</code>. Запустив, например, <code>wget</code><blockquote><pre>wget -d -r -c http://dev.site.ru/</pre></blockquote>мы получим оптимизированный &laquo;слепок&raquo; сайта, который можно загрузить уже в рабочую систему.</li><li><strong>Склейка HTML в одну строку</strong>. Как уже было описано выше, Web Optimizer может &laquo;слеить&raquo; весь выводимый HTML в одну строку. Для этого нужно включить<blockquote><pre>Настройки сжатия -&gt; Сжать HTML до 1 строки -&gt; да Настройки сжатия -&gt; Удалить HTML-комментарии -&gt; да</pre></blockquote>Стоит сразу отметить, что данные настройки вносят дополнительную нагрузку на сервер (корректное регулярное выражение достаточно ресурсоемко) и могут привести к вырезанию некоторого JavaScript-кода (который вставляется через комментарии). Также код внутри <code>script</code>, <code>textarea</code>, <code>pre</code> изменяться не будет (в соответствии со спецификацией). Поэтому использовать данные настройки нужно с большой осторожностью.</li><li><strong>Оптимизация изображений через <a href="http://smush.it/" rel="nofollow">smush.it</a></strong>. Сервис smush.it разработан инженерами Yahoo! и Google и позволяет оптимизировать размер фоновых изображений в автоматическом режиме. Подключить оптимизацию изображений можно через библиотеку CSS Sprites (данный пример в версии 0.4.9.7 пока не работает, но уже доступен в SVN и будет включен в 0.5):<blockquote><pre>&lt;?php require('/полный/путь/до/css.sprites.php'); $smushit = new css_sprites(); $smushit->smushit('/полный/путь/до/изображения'); ?&gt;</pre></blockquote>в результате вместо изображения (при наличии прав на его изменение) мы получим его оптимизированную копию. Лучше проводить не на группе рабочих изображениях, а на их копиях, чтобы была возможность откатить изменения.</li></ul><p>Загрузить приложение: <a href="http://code.google.com/p/web-optimizator/downloads/list" rel="nofollow">http://code.google.com/p/web-optimizator/downloads/list</a>.</p><h3>Читать дальше</h3><ul><li><a href="http://webo.in/articles/habrahabr/93-web-optimizer-0.4.5/">Web Optimizer. Версия 0.4.5 &mdash; Release Candidate 2</a></li><li><a href="http://webo.in/articles/habrahabr/92-web-optimizer-0.4/">Web Optimizer. Версия 0.4 &mdash; Stable Release Candidate</a></li><li><a href="http://webo.in/articles/habrahabr/89-css-sprites-2.0/">CSS Sprites 2.0</a></li><li><a href="http://webo.in/articles/habrahabr/85-web-optimizator/">PHP Speedy &mdash; наше все</a></li></ul> Sun, 28 Feb 2010 00:00:00 GMThttp://www.habrahabr.ru/blogs/web_optimizator/62009/#commentshttp://webo.in/articles/habrahabr/95-data-uri-sprites-1.1/http://webo.in/articles/habrahabr/95-data-uri-sprites-1.1/<p><img src="http://duris.ru/images/logo.png" width="434" height="85" alt="data:URI [CSS] Sprites" title="data:URI [CSS] Sprites"/></p><p>Многим профессиональным веб-разработчикам известны приемы оптимизации сайтов. Одним из способов оптимизации является использование <a href="http://webo.in/articles/habrahabr/08-all-about-css-sprites/">CSS спрайтов</a>. Этим же разработчикам известно, какие существуют трудности с формированием, сборкой и пересборкой стандартных спрайтов. В инете можно найти инструменты для автоматизации этого процесса. При использовании стандартных спрайтов полностью автоматизировать сборку для всех случаев проблематично, из-за специфики background в css. Иногда камнем преткновения является свойство repeat фоновой картинки.</p><h3>Data:URI CSS</h3><p>Существует альтернативный вариант генерации CSS спрайтов, на основе <a href="http://ru.wikipedia.org/wiki/Data:_URL" rel="nofollow"><code>data:uri</code> схемы</a>. Данный подход интересен тем, что максимально минимизируется кол-во обращений к серверу, + самое важное &mdash; можно <strong>полностью</strong> автоматизировать процесс сборки и перегенерации спрайтов. Для <strong>полной автоматизации</strong> процесса оптимизации работы сайтов и сборки css спрайтов на основе <code>data:uri</code> схемы была разработана специальная библиотека. На базе созданной библиотеки развернут сайт <a href="http://duris.ru/">Duris.ru</a>. Те кто ранее не слышал про данную разработку могут почитать <a href="http://webo.in/articles/habrahabr/74-data-uri-sprites-automation/">предыдущую статью</a> на эту тему.</p><h3>Обновление версия 1.1</h3><p>Теперь о главном. Инструмент генерации спрайтов обновился и заимел рад дополнительных возможностей:</p><ul><li>обработка <code>media</code> в <code>link</code>, <code>style</code> &mdash; теперь css стили собираются в зависимости от <code>media</code>, генерация происходит только для <code>@media = null || all || screen</code></li><li>улучшена обработка <code>@import</code></li><li>корректно обрабатываются условные комментарии (comment conditional) для IE</li><li>теперь спрайты работают и для IE8, причем независимо от режима работы (при разных <code>X-UA-Compatible</code>)</li><li>устранен ряд ошибок с последовательностью формирования правил в css стилях</li><li>добавлена возможность обрабатывать Javascript, а именно склеивать в один файл и применять компрессию</li><li>устранены все известные баги</li><li>добавлена возможность работы с локальной файловой системы (для интеграции в свои проекты)</li></ul><p>Указанный инструмент генерации data:uri спрайтов интегрирован в один из серьезных проектов, естественно показать который на данный момент не могу, но результат интеграции больше чем просто радует. Наконец-то мучения со спрайтами закончены.</p><h3>Будущее</h3><p>При появлении поддержки в IE8 <code>data:uri</code> схемы разработанный подход становится довольно перспективным, теперь все современные браузеры поддерживают такие спрайты. Для полного счастья осталось браузеру Opera увеличить размер поддерживаемой <code>data:uri</code> схемы (пока в Opera имеется ограничение ~ 4кб). <em>Примечание от sunnybear: подтверждения этого найти не удалось, но есть <a href="http://msdn.microsoft.com/en-us/library/cc848897(VS.85).aspx" rel="nofollow">ограничение на 32Кб в IE8</a></em></p><p>Детально ознакомится с принципами генерации и подключения data:uri css спрайтов можно в разделе <a href="http://duris.ru/faq/">FAQ</a>. Если у вас возникли вопросы или предложения по работе сайта или алгоритма в целом, вы можете оставить свои пожелания на нашем сайте в виджете обратной связи, или просто пишите в комментарии.</p><p>Напоследок, отличная подборка инструментов для генерации CSS спрайтов <a href="http://www.smashingmagazine.com/2009/04/27/the-mystery-of-css-sprites-techniques-tools-and-tutorials/">www.smashingmagazine.com/2009/04/27/the-mystery-of-css-sprites-techniques-tools-and-tutorials/</a></p><p>Пользуйтесь на здоровье.</p><p><strong>UPD</strong>: Сайт <a href="http://artlebedev.ru/" rel="nofollow">artlebedev.ru/</a>, на который настроен duris.ru по умолчанию «в тумане», соот-но чтобы оценить работу вставляйте свои или какие-то другие рабочие на данный момент сайты.</p><h3>Читать дальше</h3><ul><li><a href="http://webo.in/articles/habrahabr/87-web-optimizer-installation/">Установка Web Optimizer</a></li><li><a href="http://webo.in/articles/habrahabr/86-auto-css-sprites/">Автогенерация CSS Sprites</a></li><li><a href="http://webo.in/articles/habrahabr/85-web-optimizator/">PHP Speedy &mdash; наше все</a></li><li><a href="http://webo.in/articles/habrahabr/76-web-evolution/">Развитие веба с 2000 до 2007</a></li><li><a href="http://webo.in/articles/habrahabr/74-data-uri-sprites-automation/">Data:URI CSS Sprites современный подход к генерации CSS спрайтов</a></li><li><a href="http://webo.in/articles/habrahabr/69-total-image-optimization/">Оптимизация изображений, часть 3: 4 шага для уменьшения размера файлов </a></li><li><a href="http://webo.in/articles/habrahabr/67-practical-example/">Оптимизация загрузки страниц на практике</a></li><li><a href="http://webo.in/articles/habrahabr/66-online-store-speed-up/">Эксперимент сколько живых денег может принести ускорение загрузки сайта?</a></li></ul> Sun, 28 Feb 2010 00:00:00 GMThttp://www.habrahabr.ru/blogs/client_side_optimization/60757/#commentshttp://webo.in/articles/habrahabr/94-web-optimizer-faq-1/http://webo.in/articles/habrahabr/94-web-optimizer-faq-1/<p class="right"><a href="http://code.google.com/p/web-optimizator/"><img src="http://web-optimizator.googlecode.com/svn/trunk/images/web.optimizer.logo.small.png" alt="Загрузить Web Optimizer"/></a></p><p>Добавление DLE в список поддерживаемых систем <a href="http://datalife-engine.net/blog/web-development/123.html" rel="nofollow">вызвало</a> <a href="http://skripters.com/raznoe_skripti/3446-web-optimizer.html" rel="nofollow">бурный</a> <a href="http://6dle.ru/dle_hak/1113-web-optimizer-046-zastav-datalife-engine-rabotat.html" rel="nofollow">отклик</a> (мною замечено порядка 5 новостей на различных <a href="http://4dle.ru/tips/1147157490-web-optimizer-0.4.6-zastav-datalife.html" rel="nofollow">про-DLE сайтах</a>), поэтому ниже постараюсь ответить на несколько наиболее распространенных вопросов.</p><ol><li><strong><a href="http://code.google.com/p/web-optimizator/">Web Optimizer</a> платный проект?</strong> Нет, проект (на данный момент) абсолютно бесплатный и загружаемый свободно. Есть некоторые планы по его монетизации, но они пока не озвучены (может быть, платной будет только установка для сайтов с посещаемостью более 1000 хитов в сутки, например). Если у вас есть предложения, которые позволил бы окупить качественную разработку и были бы выгодны вам лично, их можно написать в комментариях.</li><li><strong><a href="http://code.google.com/p/web-optimizator/">Web Optimizer</a> от гугла?</strong> Нет, проект разрабатывается группой активистов (прямо или косвенно связанных с <a href="http://webo.in/">webo.in</a>). <a href="http://code.google.com/" rel="nofollow">Google Code</a> &mdash; просто хостинг для файлов и SVN, почти что <a href="http://narod.yandex.ru/" rel="nofollow">narod.yandex.ru</a>. Вы же сайты на Народе не называете проектами Яндекса, правда?</li><li><strong><a href="http://code.google.com/p/web-optimizator/">Web Optimizer</a> грузит сервер?</strong> Нет, проект разрабатывается с учетом самых высоких требований к производительности. Наоборот, при правильной настройке сервера нагрузка только уменьшится. Давайте рассмотрим такой случай: на странице у нас находится 3 файла стилей и 5 файлов скриптов. Средний посетитель просматривает за присест 3 страницы. Web Optimizer создаст 1 файл скриптов и 1 файл стилей. При загрузке каждой страницы данные файлы будут только проверены на существование (это менее ресурсоемко, чем их отдача пользователю). За счет клиентского кэширования данные файлы будут запрошены пользователем только при первом заходе на сайт. Итого имеем выигрыш на каждого пользователя в:<blockquote><pre>(3 + 5) * 3 &mdash; (2 + 2 * 3 *~0,2) ~= 20 запросов к серверу.</pre></blockquote>Налицо явное преимущество.</li><li><strong>Фигня полная?</strong> Нет, не полная :). Проект разрабатывается отечественными разработчиками и по функциональности не имеет аналогов в мире. При правильной установке и настройке способен обеспечить ускорение сайта порядка 10 раз. Обычно это 3-5 раз.</li><li><strong>После установки возможны ошибки?</strong> Да, естественно. Поскольку приложение некоммерческое, то тестами покрыты далеко не все случаи. Если у вас возникли проблемы в ходе или после установки, то стоит запостить их сюда: <a href="http://code.google.com/p/web-optimizator/issues/list" rel="nofollow">http://code.google.com/p/web-optimizator/issues/list</a>. Они будут довольно быстро решены (при воспроизводимой по описанию ошибке).</li><li><strong>Сколько гугл запросил за скриптик?</strong> Пока предложений от гугла не поступало :)</li><li><strong>Куда и зачем он лезет?</strong> Алгоритм оптимизатора довольно сложен, в двух словах его не описать. Более-менее подробные документы выложены здесь (на английском): <a href="http://code.google.com/p/web-optimizator/wiki/Welcome">http://code.google.com/p/web-optimizator/wiki/Welcome</a>. Если совсем кратко, то <a href="http://code.google.com/p/web-optimizator/">Web Optimizer</a> перехватывает выводимый HTML от серверного движка, оптимизирует его (создает кэшированные версии необходимых файлов) и отдает в браузер уже полностью «перелопаченным» (на данный момент изменяется только head-секция + при наличии параллельных хостов меняются пути к ним в самом документе).</li><li><strong>Многа букв!</strong> Здесь все описано намного подробнее: <a href="http://webo.in/articles/">http://webo.in/articles/</a>, <a href="http://speedupyourwebsite.ru/books/speed-up-your-website/online/">http://speedupyourwebsite.ru/books/speed-up-your-website/online/</a>. Если будет желание, можно значительно увеличить свой багаж знаний о клиентской оптимизации</li><li><strong>Лень раздолбиватся с настройками...</strong> Настройки по умолчанию конфигурируется для оптимальной производительности при установке приложения. Сам <a href="http://code.google.com/p/web-optimizator/">Web Optimizer</a> спроектирован таким образом, чтобы не перегружать ненужной информацией (есть режим «Быстрой установки»). Также доступны опции «Изменение настроек», «Обновление», «Очистка кэша» и «Удаление».</li></ol><p>Если есть еще вопросы &mdash; можно задать в приват, комментариях или по: <a href="http://webo.in/contacts/">http://webo.in/contacts/</a></p><h3>Читать дальше</h3><ul><li><a href="http://webo.in/articles/habrahabr/93-web-optimizer-0.4.5/">Web Optimizer. Версия 0.4.5 &mdash; Release Candidate 2</a></li><li><a href="http://webo.in/articles/habrahabr/92-web-optimizer-0.4/">Web Optimizer. Версия 0.4 &mdash; Stable Release Candidate</a></li><li><a href="http://webo.in/articles/habrahabr/89-css-sprites-2.0/">CSS Sprites 2.0</a></li><li><a href="http://webo.in/articles/habrahabr/85-web-optimizator/">PHP Speedy &mdash; наше все</a></li></ul> Sun, 28 Feb 2010 00:00:00 GMThttp://www.habrahabr.ru/blogs/web_optimizator/60313/#commentshttp://webo.in/articles/habrahabr/93-web-optimizer-0.4.5/http://webo.in/articles/habrahabr/93-web-optimizer-0.4.5/<!--#set var="TITLE" value="Web Optimizer. Версия 0.4.5 - Release Candidate 2" --><!--#include virtual="/includes/top.shtml" --><div class="i y"><span></span><i></i><b></b><p><a href="http://webo.in/articles/" rel="directory">Статьи</a><i> </i><a href="http://webo.in/articles/archive/" rel="directory" class="current">Архив статей</a><b> </b></p><div><strong>Автор:</strong> Мациевский Николай aka sunnybear</div><div>Опубликована: 13 мая 2009</div></div> <p class="right"><a href="http://code.google.com/p/web-optimizator/" rel="nofollow"><img src="http://web-optimizator.googlecode.com/svn/trunk/images/web.optimizer.logo.small.png" alt="Загрузить Web Optimizer" title="Загрузить Web Optimizer" width="151" height="150"/></a></p> <p>Можно снова радоваться. Веб-приложение для автоматизации клиентской оптимизации дошло до версии 0.4.5 &mdash; RC 2. Значительно улучшено быстродействие, потребление памяти, добавлено много новых возможностей и поддерживаемых CMS.</p> <p><a href="http://webo.in/articles/habrahabr/87-web-optimizer-installation/">Подробное руководство по установке</a> (устарело уже, правда)</p> <p><a href="http://code.google.com/p/web-optimizator/downloads/list" rel="nofollow">Загрузить последнюю версию или мини-установщик</a></p> <p><a href="http://sprites.in/donate/">Помочь проекту материально</a></p> <h3>Что нового?</h3> <ul> <li>Переработано ядро разбора HTML-файла. Теперь весь функционал вызывается только по необходимости и только нужное число раз (таким образом улучшено быстродействие и потребление оперативной памяти). Дополнительно в «зачистке» HTML добавлено удаление комментариев (по умолчанию отключено, ибо не для всех систем безопасно).</li> <li>Стили, заданные через <code>&lt;style type="text/css"&gt;</code> в <code>head</code>, теперь тоже объединяются (настройка «Объединять внешние файлы и встроенный код»).</li> <li>Настройка «Не проверять дату изменения» исправлена. Теперь по умолчанию (наличию файлов в кэше) индекс строится на основе только имен файлов, что исключает множественные обращения к файловой системе (проверяется только существование 1-2 закэшированных файлов).</li> <li>Очередной пакет улучшений для CSS Sprites:<ul> <li>Изменен порядок сортировки изображений для работы с большим количеством «разнокалиберных» изображений.</li> <li>Теперь учитываются отступы (<code>padding</code>), заданные в стилям.</li> <li>Добавлена настройка для исключения IE6 из процесса создания спрайтов.</li> <li>Исправлена проблема с приоритетами стилей. Теперь отсутствие фона задается через <code>!important</code>.</li> <li>Ускорена работа с полноцветными изображениями (теперь все по умолчанию создается в 32битной палитре).</li> <li>Изображения при создании дополнительно проверяются не только по расширению, но и по допустимому формату.</li> <li>Добавлено ограничение при создании больших спрайтов (теперь должно работать на системах с 16 или 32 Мб оперативной памяти).</li> <li>Добавлена автоматическая оптимизация изображений при помощи API <a href="http://smush.it">smush.it</a>.</li> </ul></li> <li>Добавлена поддержка множественных хостов для распараллеливания загрузки картинок и проч. Необходимо наличие соответствующих записей в DNS и конфигурации сервера, но возможность загрузки с этих хостов проверяется автоматически (по умолчанию проверяется 16 названий типа <code>img</code>, <code>css</code>, <code>js</code>, и т.д.).</li> <li>По умолчанию <code>.htaccess</code> создается в той же папке, что и сайт. Есть настройка для вынесения его в общий Document Root. Также исправлена небольшая ошибка при настройке <code>mod_deflate</code> (необходим <code>mod_filter</code>). Улучшена работа сжатия и кэширования при отключенном <code>.htaccess</code>.</li> <li>Добавлено сжатие JS через YUI Compressor (требуется установленная java, наличие проверяется автоматически).</li> <li>Добавлена HE-локализация (иврит) от <a href="http://mamyta.habrahabr.ru/" rel="nofollow">mamyta</a>.</li> <li>Добавлено простейшее кэширование созданного HTML (со задаваемым временем кэширования). Может помочь для совсем «слабых» серверов и CMS, не обладающих этой функциональностью. Надо понимать, что при наличии любой серверной динамики (публикация комментариев, например) данный подход может быть не применим. Также добавлен список частей URL для исключения из логики кэширования (можно сразу не кэшировать часть сайта).</li> <li>Добавлена очистка кэша прямо из панели администрирования.</li> <li>Все файлы теперь подключаются через абсолютные пути. Это помогло настроить приложения использование для фреймворков.</li> <li>В список поддерживаемых систем добавлено:<ul> <li>Symfony 1.2</li> <li>CodeIngiter 1.7 вместе с MaxSite 0.3</li> <li>Zend Framework</li> <li>MODx 0.9</li> <li>DataLife Engine 8.0</li> </ul></li> <li>А также сотня-другая мелких правок и улучшений.</li> </ul> <h3>Планы на будущее</h3> <p>Следующий выпуск (0.5) будет посвящен безопасности. Планируется полностью изолировать установку Web Optimizer от его работы (и закрыть заодно доступ к нему через <code>.htaccess</code>). Естественно, в него войдут все замеченные ошибки, часть новых CMS и фреймворков и некоторый новый функционал. Поскольку почти весь план по автоматизации клиентской оптимизации уже выполнен, то текущую версию можно считать весьма близкой к финальной.</p> <h3>Дизайн</h3> <p>На данный момент у нас готовы макеты дизайна (<a href="http://fade.habrahabr.ru/" rel="nofollow">fade</a> ), но верстать и прикручивать клиентскую логику к ним некому. Поэтому если кто хочет поучаствовать в проекте пока еще не поздно присоединиться. Надеюсь, что новый дизайн войдет в версию 0.5</p> <p><img src="http://i.webo.in/web.optimizer.design.01.png" alt="Дизайн для Web Optimizer" title="Дизайн для Web Optimizer" width="624" height="423"/></p> <p><img src="http://i.webo.in/web.optimizer.design.02.png" alt="Дизайн для Web Optimizer" title="Дизайн для Web Optimizer" width="624" height="423"/></p> <h3>Примеры оптимизации</h3> <p>Слева YSlow для сайта до установки Web Optimizer, справа тот же самый сайт после установки (сама установки занимает менее минуты). Дополнительного тюнинга (типа ручной настройки CDN-хостов в Firefox) не производилось.</p> <h4>LiveStreet 0.3alpha</h4> <p><img src="http://i.webo.in/web.optimizer.livestreet.png" alt="Web Optimizer для LiveSteert 0.3alpha" title="Web Optimizer для LiveSteert 0.3alpha" width="732" height="549"/></p> <h4>MODx 0.9</h4> <p><img src="http://i.webo.in/web.optimizer.modx.png" alt="Web Optimizer для MODx 0.9" title="Web Optimizer для MODx 0.9" width="581" height="249"/></p> <h4>DataLife Engine 8.0</h4> <p><img src="http://i.webo.in/web.optimizer.dle.png" alt="Web Optimizer для DataLife Engine 8.0" title="Web Optimizer для DataLife Engine 8.0" width="672" height="223"/></p> <h3>Монетизация</h3> <p>Поскольку регулярно достаточно большое число человек проявляет недюжинную активность и засыпает вопросами, связанными с особенностями конкретного хостинга или интеграцией с конкретной CMS, то большая часть технической поддержки и интеграции будет проводиться далее на платной основе.</p> <p>Если вы хотите заказать установку или настройку Web Optimizer для вашего сайта, то <a href="http://webo.in/speed/">можно воспользоваться этой формой</a>.</p> <p>Если вы хотите добавить поддержку какой-либо CMS или нашли явный баг, то <a href="http://code.google.com/p/web-optimizator/issues/list" rel="nofollow">стоит опубликовать запрос здесь</a>. С вероятностью, близкой к 1, проблема будет решена, и решена достаточно быстро.</p> <h3>Использование Web Optimizer</h3> <p>Ранее уже заходил разговор о том, как приложение можно внедрять в текущую схему публикации сайта или «оптимизации по расписанию». Поскольку при установке используется «цепочная оптимизация», то никаких сложностей в ее настройке и запуске по событию или по расписанию для произвольных страниц нет. Подробности можно уточнить в привате.</p> <p>На данной этапе Web Optimizer можно смело использовать также как API для автоматической оптимизации любой системы. Поскольку лиценция MIT, то достаточно просто сохранить комментарии в PHP-коде.</p> <h3>Поддержка</h3> <p><a href="http://twitter.com/dreamwind" rel="nofollow">Подписаться на twitter-канал</a></p> <p><a href="http://sprites.in/donate">Помочь проекту материально</a></p> <p>Вы также можете перевести Web Optimizer на свой язык. Всего сейчас порядка 200 фраз в файле локализации.</p> <p><a href="http://code.google.com/p/web-optimizator/downloads/list" rel="nofollow">Загрузить последнюю версию или мини-установщик</a>.</p> <h3>Читать дальше</h3><ul><li><a href="http://webo.in/articles/habrahabr/87-web-optimizer-installation/">Установка Web Optimizer</a></li><li><a href="http://webo.in/articles/habrahabr/86-auto-css-sprites/">Автогенерация CSS Sprites</a></li><li><a href="http://webo.in/articles/habrahabr/85-web-optimizator/">PHP Speedy &mdash; наше все</a></li><li><a href="http://webo.in/articles/habrahabr/76-web-evolution/">Развитие веба с 2000 до 2007</a></li><li><a href="http://webo.in/articles/habrahabr/74-data-uri-sprites-automation/">Data:URI CSS Sprites современный подход к генерации CSS спрайтов</a></li><li><a href="http://webo.in/articles/habrahabr/69-total-image-optimization/">Оптимизация изображений, часть 3: 4 шага для уменьшения размера файлов </a></li><li><a href="http://webo.in/articles/habrahabr/67-practical-example/">Оптимизация загрузки страниц на практике</a></li><li><a href="http://webo.in/articles/habrahabr/66-online-store-speed-up/">Эксперимент сколько живых денег может принести ускорение загрузки сайта?</a></li><li><a href="http://webo.in/articles/habrahabr/54-psychology-web-performance/">Психология веб-производительности, или когда время равно деньги</a></li></ul> Sun, 28 Feb 2010 00:00:00 GMThttp://www.habrahabr.ru/blogs/web_optimizator/59403/#comments