Статьи и переводы по оптимизации скорости загрузки сайтаhttp://i.webo.in/x.pnghttp://webo.in/speed/http://webo.in/Sun, 13 Feb 2011 07:50:27 GMTFeedCreator by DreamwinDruinfo@webo.name (WEBO Software)Copyright 2008-2011, WEBO Software240http://webo.in/articles/all/2010/10-salesjump-insales-final/http://webo.in/articles/all/2010/10-salesjump-insales-final/<blockquote><p>19 ноября состоялась церемония награждения конкурса SalesJump, который проводился среди начинающих интернет-магазинов. Церемония подводила итоги четырехмесячной битвы за звание самого лучшего интернет-магазина.</p></blockquote><p>15 июля конкурсу был дан старт. Принять участие мог любой магазин, созданный не ранее 1 июня 2010 года. Магазин также мог представлять собой копию уже существующего интернет-магазина, но на новом домене. Прием заявок продолжался до 15 сентября, и за это время свыше 200 проектов изъявили желание побороться за призовой фонд, который превысил изначально заявленный миллион рублей почти на двести тысяч. К участию, однако, были допущены 148 проектов, соответствовавших всем критериям жюри. На время проведения конкурса всем участникам для работы была бесплатно предоставлена платформа InSales.</p><p>Поскольку многие только начинали свой путь в интернет-торговле, организаторы конкурса решили провести для участников серию мастер-классов, осветивших основные вопросы, с которыми сталкивается предприниматель, занимающийся организацией интернет-магазина.</p><p>В начале сентября было проведено 4 мастер-класса по следующим темам:</p><ul><li>Бизнес-планирование, юридическое оформление, бухгалтерские вопросы.</li><li>Дизайн, навигация, удобство использования вашего магазина.</li><li>Продвижение.</li><li>Организация логистики, работа с поставщиками.</li></ul><p>Кроме того, было проведено 2 онлайн-семинара, в ходе которых можно было получить ответы на интересующие вопросы, связанные как с использованием платформы InSales, так и с тонкостями продажи товаров через интернет.</p><p>С 20 сентября по 10 октября участники вели усиленную работу по подготовке магазина к финалу, ведь пройти туда должно было всего 35 магазинов. И 17 октября на сайте конкурса появился список счастливчиков, которые прошли в финал. Отбирались проекты, создавшие сайт, наполнившие каталог, зарегистрировавшие юридическое лицо или ИП и организовавшие доставку заказываемых товаров &mdash; т.е. создавшие полноценно работающий интернет-магазин. Именно они начали борьбу за основной призовой фонд. Компания InSales при поддержке компаний Yagoodza, Price.ru, Subscribe.Ru, WEBO Software, Livecontact, Nextore, 3D Bank, Unisender, МойСклад и Aviso SMS собрала беспрецедентный призовой фонд в виде программного обеспечения, услуг и рекламных бюджетов на сумму 1 193 320 рублей, который и был разыгран среди финалистов.</p><p>4 основные номинации конкурса SalesJump:</p><ul><li>«Стремительный Бизнес». В рамках номинации были отобраны лидеры по обороту, числу заказов и посещаемости.</li><li>«Выбор покупателей». Для участия в номинации были отобраны магазины с наибольшим числом заказов и самой большой конверсией.</li><li>«Удобный магазин». В данной номинации победитель определялся Жюри в ходе голосования по основному критерию: общая жизнеспособность магазина по мнению жюри.</li><li>«Выбор пользователей». В данной номинации голосование осуществлялось пользователями интернета на сайте конкурса.</li></ul><p>Также были специальные номинации:</p><ul><li>«Выбор журнала «Свой бизнес». Победитель выбирался редакцией журнала среди 12 номинантов по основным 4-м номинациям.</li><li>«Выбор сервиса 3D Bank». Победитель выбирался представителями сервиса 3D bank.</li></ul><p>На сайте конкурса за финалистов было отдано 1526 голосов.</p><p>В итоге победителями стали следующие проекты.</p><h3>В номинации «Выбор пользователей»:</h3><ol><li><a href="http://mrjones.ru/" rel="nofollow">MrJones.ru</a></li><li><a href="http://made4me.ru/" rel="nofollow">Made4Me.ru</a></li><li><a href="http://victorinoxshop.ru/" rel="nofollow">VictorinoxShop.ru</a></li></ol><h3>В номинации «Удобный магазин»:</h3><ol><li><a href="http://victorinoxshop.ru/" rel="nofollow">VictorinoxShop.ru</a></li><li><a href="http://made4me.ru/" rel="nofollow">Made4Me.ru</a></li><li><a href="http://bazar.fergaba.ru/" rel="nofollow">Bazar.Fergana.ru</a></li></ol><h3>В номинации «Стремительный бизнес»:</h3><ol><li><a href="http://sushivenik.ru/" rel="nofollow">SushiVenik.ru</a></li><li><a href="http://shop.bukashi.ru/" rel="nofollow">Shop.Bookashki.net</a></li><li><a href="http://roycan.ru/" rel="nofollow">RoyCan.ru</a></li></ol><h3>В номинации «Выбор покупателей»:</h3><ol><li><a href="http://shop.bukashki.ru/" rel="nofollow">Shop.Bookashki.net</a></li><li><a href="http://roycan.ru/" rel="nofollow">RoyCan.ru</a></li><li><a href="http://dsk-karusel.ru/" rel="nofollow">DSK-karusel.ru</a></li></ol><p>Что касается специальных призов, то журнал «Свой бизнес» в январском номере опубликует полосу о магазине <a href="http://bazar.fergana.ru/" rel="nofollow">Bazar.Fergana.ru</a>, сервис Price.ru подарил пакет кликовых объявлений «Антикризисный» проекту <a href="http://sushivenik.ru/" rel="nofollow">SushiVenik.ru</a>, а сервис 3D bank создаст 3-д витрину товаров интернет-магазину <a href="http://niirobot.ru/" rel="nofollow">niirobot.ru</a>.</p><p>Все победители получили тарифный план «Бизнес» на 1 год от компании InSales, оптимизацию скорости работы сайта интернет-магазина от WEBO Software, 1 год использования сервиса «МойСклад» по тарифу «Профессиональный», 1 год использования чата с покупателями на сайте интернет-магазина от LiveContact, 8 часов рекомендаций и консалтинга по общему развитию интернет магазина от Nextore, тарифный план «Часто 5.000» от компании UniSender на 3 месяца, 1 год оплаченного продвижения по тарифному плану «Улучшенный» от площадки Yagoodza, базовое размещение на Price.Ru, рекламный бюджет от Subscribe.ru и пакет смс-сообщений от Aviso SMS.</p><p>Номинанты, занявшие вторые места, также получили подарок от сервиса «МойСклад» &mdash; 6 месяцев использования сервиса по тарифному плану «Базовый». Кроме того, им также были вручены 1 год использования чата с покупателями на сайте интернет-магазина от LiveContact и подписка на полгода на журнал «Свой Бизнес».</p><p>Призеры, занявшие третьи места, получили 6 месяцев использования сервиса «МойСклад» по тарифному плану «Базовый», 1 год использования чата с покупателями на сайте интернет-магазина от LiveContact и книги от журнала «Свой бизнес».</p><p>Мы искренне надеемся, что наш конкурс станет ежегодным мероприятием, и в следующем году мы дадим старт еще как минимум 30 успешным проектам.</p><p>Подробнее о конкурсе SalesJump:<br/><a href="http://www.salesjump.ru/" rel="nofollow">www.salesjump.ru</a></p><p class="X"></p> Sun, 28 Nov 2010 00:00:00 GMThttp://webo.in/articles/all/2010/10-salesjump-insales-final/http://webo.in/articles/ux2010/usability-time/http://webo.in/articles/ux2010/usability-time/<h3>Привычки работы с интерфейсами</h3><p>Что такое для нас удобство использования? Всегда ли это меньше кликов и переходов, меньше смен экранов, меньше полей для заполнения? Когда мы можем увеличить количество информации, которую предоставляем пользователям, и при этом удобство использования только увеличится? Всегда ли уменьшение числа действий пользователя означает уменьшение времени работы с интерфейсами? Или же мы должны уменьшить неопределенность на каждом этапе работы, сократив при этом общее количество операций со стороны пользователя?</p><p>На эти вопросы и часть других отвечает доклад, предоставляя конкретные сценарии и подходы при создании интерфейсов, направленные на ускорение работы с ними. Но для начала давайте рассмотрим, какие сейчас существуют стандарты в области комфортного времени работы с интерфейсами.</p><p>Порядка 2-10 секунд пользователь готов ждать появления интерфейса (или хотя бы его предвестника) на экране своего компьютера. При этом еще 5-30 секунд может уходить на ознакомление с ситуацией. Если время работы с программным продуктом превышает заявленные цифры, то уже стоит забить тревогу. Однако если при этом в интерфейсе есть какой-либо индикатор загрузки, то время его ожидания может быть еще несколько (десятков) секунд. При все этом пользователь привык к достаточно быстрого реагированию на свои действия: уже после 0,2с уже будет возникать тревога, все ли в порядке с продуктом.</p><p>Из всего вышесказанного следует некоторое количество сценариев организации работы с интерфейсами.</p><h3>Сценарий 1: ускоряем ожидание</h3><p>В случае сложного интерфейса (многосоставного), время ожидания которого сложно регулировать для всех пользователей, можно использовать следующую схему работы.</p><ul><li>При первой загрузке приложения показываем ознакомительный промо-экран. Пока пользователь читает специальную информацию, вводящую его в курс дела, продукт может загрузить еще некоторое количество информации. Время реакции на промо-экран: 2-10 секунд.</li><li>После промо-экрана мы можем отобразить некоторый базовый интерфейс продукта, в котором большая часть информации уже доступна. Но есть индикаторы загрузки на месте блоков, требующих значительное количество серверных ресурсов. Пользователь готов подождать еще несколько секунд до появления полностью функционального интерфейса.</li><li>Наконец после 5-20 секунд перед пользователем оказывается полностью готовый к работе продукт (и у пользователя не остается ощущения того, что продукт &laquo;тормозит&raquo;). При этом повторная загрузка может быть значительно ускорена за счет кэширования.</li></ul><h3>Сценарий 2: информируем пользователя</h3><p>Во-первых, если пользователь привык получать обратную связь от продукта через 0,2с после своих действий, то нужно это обратную связь обеспечить! Т.е. отображать произвольный индикатор загрузки при обработке пользовательких данных и смене экрана. Однако если обработка данных происходит быстрее, то лишний раз индикатор лучше не показывать (не мелькать им). Поэтому стоит сделать переключать для отображения индикатора только в том случае, если ожидание продолжается больше 0,2с.</p><p>Очень часто интерфейс для пользователя не понятен (много новы понятий и терминов). Но отделить &laquo;продвинутого&raquo; пользователя от &laquo;обычного&raquo; нет никакой возможности. Именно с этой целью (научить новых и не раздражать старых) вводятся подсказки, которые появляются в специально отведенных местах (знак вопроса рядом с каждым термином). Это распространенная практика экономит время пользователей и снижает время ознакомления (за счет обучения) и работы (за счет минимизации обучающих элементов) с интерфейсом.</p><p>В том случае, когда необходимо разбить интерфейс на несколько последовательных шагов (экранов), то общее количество шагов обязательно должно быть выведено. Дополнительно каждый шаг стоит снабдить не только названием, но и кратким описанием или даже иллюстрацией (если шаг автоматический и не требует от пользователя никаких действий). В случае автоматических действий продукта, если требуется бездействие пользователя, то последнего обязательно нужно об этом проинформировать. Очень хорошо, если пользователя удастся развлечь, и время ожидания для него пройдет незаметно.</p><p>Если от пользователя требуется заполнить какую-то большую форму, то ее стоит разбить на несколько шагов таким образом, чтобы время работы с каждым шагом составляло 20-40 секунд. Это позволит обеспечить должную интерактивность, не раздражая пользователя частой сменой. В любом случае, после каждого внедрения или реорганизации интерфейса нужно проводить юзабилити-тестирование для оценки результатов.</p><p>Спасибо за внимание. Вопросы?</p> Sun, 10 Oct 2010 00:00:00 GMThttp://www.habrahabr.ru/blogs/ui_design_and_usability/105862/#commentshttp://webo.in/articles/add2010/open-source/http://webo.in/articles/add2010/open-source/<p>Очень часто мы слышим вокруг, что использование Open Source кода &mdash; это хорошо и правильно, это развивает ИТ-индустрию, это позволяет накапливать знания, а не тратить время разработчиков, создавая очередной &laquo;велосипед&raquo;. Но давайте разбираться, так ли дело обстоит на самом деле, какие трудности будут нас преследовать на пути распространения Open Source продуктов, и как их преодолеть.</p><h3>Задачи лицензирования</h3><p>Для чего разработчики выбирают Open Source? Во-первых, чтобы сделать продукт доступнее, понятнее для конечных пользователей (ведь тоже могут быть разработчиками, и им проще будет пользоваться продуктом, если они будут представлять основные принципы его работы). Во-вторых, для возможности внесения изменения в сам продукт (модификаций или улучшений). В-третьих, для возможности позволить эти изменения, добавленные сторонними разработчиками, внести в основной продукт без потери авторских и других прав. Тут надо сразу оговориться, что под Open Source продуктом понимается не свободное программное обеспечение (freeware), и не код, доступный публично, а опубликованный в общем доступе код с оговоренными правилами лицензирования.</p><p>Все права, оговориваемые Open Source лицензиями, можно условно разделить на авторское право (собственно, copyright), право на использование (выполнение) кода, право на демонстрацию или изучение (открытых исходные тексты продукта), право копирования, право внесения изменений в исходный код, право распространения (без или с изменениями) и право изменения лицензии или включения в свой продукт.</p><h3>Типы лицензий</h3><p>Если расположить градации лицензий по увеличению количества прав, первым будет закрытый код, который обычно сохраняет только авторское право, но очень часто право выполнения и демонстрации ограничено или является даже платным (как в случае с Windows).</p><p>Следующими, как ни странно, идут GPL и LGPL-лицензии. Исходный код, единожды открытый под GPL, уже не может быть закрыт (поскольку любой, кто его получил, может продолжить его распространение), лицензия не может быть изменена, и его использование является абсолютно свободным. Однако, при распространении необходимо прикладывать исходные коды продукта и саму лицензию.</p><p>Более свободным вариантом (также с необходимостью поставлять продукт вместе с исходными кодами) является семейство GPL-совместимых лицензий. Здесь авторы могут изменить лицензию исходного кода внутри группы без каких-либо нарушений.</p><p>Следующей градацией свободы является группа OSI-совместимых лицензий, внутри которой есть как GPL-совместимые, так и GPL-несовместимые. Миграция между этими двумя подгруппами запрещена, но GPL-несовместимых лицензий больше, и часть из них позволяет даже коммерческое использование продукта, полученного из имеющихся исходных кодов.</p><p>Наиболее свободным является открытый код (размещенный в так называемом &laquo;публичном доступе&raquo;, public domain). Но в этом случае код теряет авторское право (это противоречит российскому законодательству, поэтому в нашей стране такая практика не применима).</p><h3>Случаи использования</h3><p>Давайте рассмотрим несколько характерных случаев поведения при работы с Open Source лицензиями.</p><h4>Выбор лицензии</h4><p>К первоначальному выбору лицензии, под которой исходный код продукта будет открыт, &mdash; это ответственный процесс. Хотя если продукт предполагается развивать очень активно, то в любой момент лицензию можно будет сменить (но это не будет распространяться на уже опубликованный код под другой лицензией).</p><p>Если мы собираемся существенно ограничить коммерческое использование продукта и максимально увеличить пользовательский охват, то лучше всего использовать GPL-лицензии. Они гарантируют, что все последующие модификации будут опубликованы также под GPL-лицензиями, и сам механизм лицензирования (ограничения) запретит какие-либо ограничения.</p><p>Если мы хотим сделать наш код максимально доступным для использования (в том числе, в коммерческих продуктах), то лучше всего выбрать GPL- или даже OSI-совместимую лицензию. При этом можно выбрать и двойное лицензирование (например, BSD + Apache лицензии).</p><p>Если же нам существенно, чтобы продукт мог быть использован только в коммерческих целях (т.е. нужно ограничить права его использования и распространения), то здесь выход один &mdash; создание своей лицензии.</p><h4>Множественное лицензирование</h4><p>В том случае, если мы выбираем множественное лицензирование исходного кода (так поступают все наиболее коммерчески успешные проекты), то стоит разделить весь функционал продукта на ядро (общая часть продукта, связывающая его модули в единое целое) и модули (функционал продукта, который не может быть выполнен без ядра, но составляет существенную его часть). Затем определить набор модулей, которые будут опубликованы под OSI-совместимой лицензией (при этом можно выбирать и множественное лицензирование в этой области) и коммерческой лицензией. И в заголовок каждого файла исходного кода добавить, под какой лицензией он выложен.</p><blockquote><pre>@licensed LGPL (LICENSE-LGPL.txt) Sat, 25 Sep 2010 00:00:00 GMThttp://www.habrahabr.ru/blogs/webstandards/104931/#commentshttp://webo.in/articles/wsd2010/web-performance/http://webo.in/articles/wsd2010/web-performance/<p>Сейчас мы являемся свидетелями уникального явления: накопленный опыт, практики использования и проблемы веб-производительности обретают некоторую законченную форму в виде стандарта от W3C. Это стандарт Web Performance, над которым работает выделенная, <a href="http://www.w3.org/2010/webperf/" rel="nofollow">недавно созданная группа</a>.</p><p>Но начнем сначала.</p><h3>Вчера: немного истории</h3><p>На заре Интернета, в прошлом веке, проблемы производительности веб-сайтов не было, были проблемы медленного Интернет-соединения (потому что страницы начала века выглядят почти идеально с точки зрения текущих практик высокой производительности). Обычная страница представляла собой несколько (часто не больше 5) файлов, из которых текстовых файлов было 1-2. Лучшей практикой увеличения скорости загрузки было gzip-сжатие, но в силу слабой поддержки со стороны браузеров оно применялось редко.</p><p>Чуть позже, уже в нашем веке, с развитием технологий и стандартов, проблема &laquo;медленных&raquo; стала проявляться больше. На странице уже было несколько файлов стилей и скриптов, браузеры не умели эффективно их загружать, были разработаны все основные техники оптимизации, но до широкой общественности пока не дошли.</p><p>И на том фоне Yahoo! в 2007 году выкладывают свои советы по производительности и дополнение YSlow. Это было равносильно взрыву, о веб-производительности заговорили все. Появилась Net Panel в Firebug, появился Web Inspector в Safari в 2008 году, а в следующем году появился dynaTrace для IE и Speed Tracer.</p><p>На фоне этого бума летом 2010 года была образована отдельная группа W3C, занимающаяся разработкой соответствующих стандартов.</p><h3>Сегодня: получение данных</h3><p>Почему же возникла необходимость в создание такой группы? Ведь уже есть инструменты для анализа производительности и практики создания быстрых сайтов. Во-первых, сейчас достаточно сложно получить информации о производительности страницы &laquo;в общем виде&raquo;. Каждый из браузеров имеет собственное API (позволяющее через JavaScript получить доступ к C-данным), но экспорт всех значений кроссбраузерно очень сложен.</p><p>Во-вторых, доступный набор значений, которые тоже не так просто получить (ниже приведен пример получения времени <code>onLoad</code>, наиболее простого из всех), крайне ограничен. Сказать по нему что-то конкретное о производительности сайта сложно.</p><blockquote><pre>&lt;html&gt; Sat, 25 Sep 2010 00:00:00 GMThttp://www.habrahabr.ru/blogs/webstandards/104542/#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> Sat, 25 Sep 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> Sat, 25 Sep 2010 00:00:00 GMThttp://www.habrahabr.ru/blogs/webstandards/76607/#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> Sat, 25 Sep 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/index.php?ri=201" 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> Sat, 25 Sep 2010 00:00:00 GMThttp://www.habrahabr.ru/blogs/client_side_optimization/62907/#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: * Sat, 25 Sep 2010 00:00:00 GMThttp://www.habrahabr.ru/blogs/searchengines/73636/#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> Sat, 25 Sep 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> Sat, 25 Sep 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://www.webogroup.com/ru/home/site-speedup/">ускорение Joomla!</a>) и <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> Sat, 25 Sep 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://loadimpact.com/index.php?ri=201" 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> Sat, 25 Sep 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(){ Sat, 25 Sep 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 Sat, 25 Sep 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> Sat, 25 Sep 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> Sat, 25 Sep 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 Sat, 25 Sep 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> будут объединяться без учета фактических размеров контейнеров), добавлению свободного пространства (позволяет избежать рудиментов при масштабировании таких картинок в современных браузерах). Sat, 25 Sep 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> Sat, 25 Sep 2010 00:00:00 GMThttp://www.habrahabr.ru/blogs/client_side_optimization/60757/#comments