Клиентская оптимизация *

Уважаемый пользователь системы WebVisor!

Извещаем вас, что с 10 июня сервис WebVisor.ru прекращает свою работу в связи с переходом технологии WebVisor в компанию Яндекс. Вся функциональность, которая была доступна в сервисе WebVisor.ru, будет доступна в сервисе Яндекс.Метрика.

Благодарим вас за использование нашего сервиса. В качестве компенсации за возможные неиспользованные в системе WebVisor.ru бонусы предлагаем вам инвайт в систему ВебВизор, интегрированную в Яндекс.Метрику.

В этом сообщении написано о компенсации для текущих пользователей Webvisor. Из сообщения можно понять, что инвайт был отправлен всем пользователям сервиса. В сервисе были как платные так и бесплатные аккаунты. И у меня, как у пользователя, который оплатил удобный для себя сервис в надежде на его развитие, сложилось двоякое впечатление об этом сообщении.

Мысли о таком закрытии сервиса и вопросы разработчикам этой технологии в Яндекс:

Введение

Предлагаю Вашему вниманию обзор посвященный оптимизации изображений формата PNG и JPEG без потери качества. Под «без потери качества» подразумевается, что визуально оригинальные и оптимизированные изображения ни чем не будут отличаться. Я читал на Хабре довольно много статьей посвященных данному вопросу, но скажу, большая часть — полная чушь, в них констатируются факты, а не причины. Данный обзор посвящен людям, которые имеют базовые знания об оптимизации изображений.

Храните мелкие картинки, которые нельзя засунуть в спрайты, в data:image base64 в CSS — это экономит кучу запросов к вебсерверу.

Да, инструменты для создания CSS спрайтов существуют. Я даже сделал один такой сервис. Но они время от времени ломаются (как сейчас, мой). Но и командная многого стоит, и imagemagick. Давайте посмотрим, как мы можем создавать CSS спрайты только из командной строки.

Создание картинки

Начнем с того, что у нас есть список отдельных файлов:

$ ls

1.png  2.gif  dot.png  phoney.gif  tw.gif

• — 1.png
• — 2.gif
• — dot.png
• — phoney.gif
• — tw.gif

Сделаем из них спрайт:

$ convert *png *gif -append result/result-sprite.png

Да, это все. Смотрим результат.

 

Еще с самого начала своей деятельности как web-разработчика я мечтал иметь инструмент, который позволял бы автоматически получать оптимизированую версию моего сайта или веб-приложения. В прошлом оптимизация сводилась к ручному формированию обычных спрайтов, потом к сжиманию скриптов и стилей по отдельности. При внесении каких либо изменений геморрой частично повторялся заново. Благодаря новому сервису клиентской оптимизации теперь это в прошлом.

Пусть мы хотим написать свой хабрахабр с блекджеком и прочими прелестями. Страница статьи у нас стостоит из 3 объёмных блоков:
1. собственно текст статьи. меняется очень редко.
2. дерево комментариев. меняется относительно часто, но со временем всё реже и реже.
3. прямой эфир. небольшой, но меняется очень часто.

Допустим, что страница с этой статьёй доступна по адресу ?article:right.cache
Но внутрь неё мы не будем помещать никакого контента, а вынесем его в отдельные ресурсы, как это обычно делается со скриптами и стилями. Внутри ?article:right.cache будет лишь индекс подключаемых ресурсов с версиями.

?article:right.cache/content/version:123
?article:right.cache/comments/time:2010-12-01
?live/time:2010-12-01
?style:article/version:666
?script:article/version:333

Указание версии позволяет задать для ресурсов жёсткое кэширование. А для индексного файла, наоборот, зададим необходимость проверять при каждом запросе изменился ли он.

Такая организация гарантирует нам, что при появлении новых комментариев не придётся грузить статью заново. И наоборот, при изменении статьи не надо будет перегружать всё дерево комментариев. А уж про то, что из-за часто меняющегося прямого эфира нам не надо по новой грузить весь контент, и заикаться не стоит ;-)

Важно, чтобы поисковики видели ссылки на ресурсы и могли их проиндексировать. Однако, из поиска люди будут приходить на конкретный ресурс и даже на конкретную его версию. Соответственно, ресурс должен определять загружен ли он по прямой ссылке и если это так, то после загрузки клиентскими средствами редиректить на индекс. Если актуальная версия ресурса не изменилась, то он потом будет взят из кэша. Если же изменилась — будет загружена новая версия. Не такая уж страшная беда, на самом деле ;-)

Реализации с использованием фреймов и аякса довольно банальны, так что воспользуемся хтмл-инклудами.

Сейчас многие сайты насыщены графикой в разных видах: аватары, иллюстрации к постам, галереи и тп.

Читатели блога «Клиентская оптимизация» как никто другой знают цену лишних запросов к серверу.

Количество обращений к серверу можно легко уменьшить с помощью техники пост загрузки изображений, которые не попадают в область видимости(первый экран). Т.е изначально будут загружаться только те изображения которые пользователь способен увидеть, остальные будут загружаться по мере скролинга страницы.

После публикации ряда заметок на тему сжатия и объединения JavaScirpt-файлов стоит все же осветить наиболее характерные проблемы этого самого сжатия и объединения.

Начнем с простого: как JS-сжатие способно испортить нам настроение. И как его поднять обратно :)

UPD стартовал конкурс ускорения сайтов. В призах: монитор, веб-камера, мышь. Все гипер-быстрое.

Скачивание объёмных ресурсов, связанных с веб-страницей, таких как JavaScript файлы и CSS, влияет не только на скорость загрузки страницы, но и увеличивает трафик, проходящий от сервера к клиентскому браузеру. Последнее обстоятельство особенно важно в подключениях с ограниченным тарифом или при размещении сайта на хостинге с заранее оговоренным объёмом исходящих данных.

Один из способов борьбы с лишними байтами – сжатие данных на сервере и передача gzip'ированного потока браузеру, который уже распаковывает его во время отрисовки страницы. Обсуждение данного способа не входит в данную статью. Я бы хотел рассказать о способе уменьшения данных с помощью удаления всех незначащих символов из сопутствующих веб-странице файлов: JavaScript и CSS – минимизации.

Сегодня, при разработке приложений в интернете, вопрос клиентской оптимизации встает все чаще. Если раньше, страница отправленная клиенту содержала только информацию, то сегодня очень часто такая страница содержит много JavaScript-кода. Для достижения наилучшей производительности и снижения нагрузки на сервер применяются правила клиентской оптимизации.

В этой статье речь пойдет про Bundler — удобное средство клиентской оптимизации JavaScript для .net-проектов.

Как справляются браузеры с параллельной загрузкой скриптов?

Во времена IE7 и Firefox 2.0 ни один браузер не загружал скрипты параллельно с другими ресурсами. Вместо этого старые браузеры блокировали все последующие запросы до полной загрузки, парсинга и выполнения скрипта. Вот так выглядел лог HTTP-запросов при подобной блокировке в старых браузерах:



На тестовой странице, по которой была сгенерирована данная диаграмма, есть шесть HTTP-запросов:

• HTML-документ;
• первый скрипт — 2 секунды на скачивание, 2 секунды на выполнение;
• второй скрипт — 2 секунды на скачивание, 2 секунды на выполнение;
• картинка — 1 секунда на скачивание;
• стилевой файл — 1 секунда на скачивание;
• iframe — 1 секунда на скачивание.

На диаграмме видно, как скрипты блокируют друг друга, а также картинку, стилевой файл и iframe. Последние загружаются параллельно друг другу, но только после того, как завершена последовательная загрузка скриптов.

Собственно, из заголовка должно быть почти все понятно. Но картинка не очень в тему: на ней надо нарисовать Лису, ползущую вслед догоняющему IE.

Это пост является ответом на «За бугром», ибо нашлась пара свободных часов, и было, чем их занять.

UPD Был обнаружен плагин — Wappalyzer — который на порядок замедлял отображение data:URI в Firefox. Но даже с его отключением Firefox продолжает проигрывать почти всем браузерам.

Но все по порядку.

Многим уже известна техника оптимизации сайтов на основе data:uri технологии. Последнее время все больше и больше к относительно новой технологии проявляется интерес мирового сообщества разработчиков. В интернете можно найти уже достаточно много статей на эту тему. Радует, что одним из первых, кто задумался серьезно о разработке кросс-браузерного data:uri это «наш человек» — Евгений Степанищев aka bolk. Ну так вот, речь не об этом, это так для истории…

Наткнулся мне «забугорный» блог www.ravelrumba.com, автор которого последнее время активно занимается исследованием эффективности data:uri css sprites. О чем свидетельствует ряд интересных статей о его работе.
CSS Images and Data URIs
Data URIs for CSS Images: More Tests, More Questions

Я решил поддержать его и провел анализ скорости загрузки разработанных им тестовых страниц.

Частяком, когда я работаю с множеством сайтов, какая-нибудь самая наглая страничка отнимает слишком много процессорного времени, из-за чего система неприятно подтормаживает. Чаще всего оказывается, что виновник — это какой-нибудь хитрый баннер на Flash или совершенно бесполезная приблуда на JavaScript, выполняющаяся в фоне.

Как и многие вебмастера, я сталкиваюсь с тем, что Яндекс-Директ, бывает, подтормаживает при загрузке. Причина — использование

document.write("

в любом месте страницы, что при отсутствии ответа от сервера - приводит к блокировке HTML-парсера и “зависанию” страницы.

Сам Яндекс предлагает бороться с этой проблемой следующим образом, однако, как-то не уверенно ;-) - о возможности создания такого подключения можно узнать только из FAQ, а не из самого интерфейса системы при создании и подключении блоков.

Все здорово, правда в случае, если на сайте несколько блоков Директа - становится немного неудобно.

Сегодня я написал небольшую “оберточку”, которая может кому-нибудь пригодится


Ни для кого не секрет, что в протоколе HTTP, а точнее в той его части, что является ответом с сервера, есть такие замечательные заголовки, как Last-Modified и ETag (Подробнее можно прочитать в спецификации протокола). Призваны они ускорить процесс получения контента с сервера, а точнее избавить клиента от загрузки данных, которые не были изменены с момента предыдущего запроса.

Так вот. Для меня факт существования двух, по-сути одинаковых, механизмов сообщить клиенту изменилось ли содержимое страницы или нет немного настораживал. Немного. Точнее я его не понимал для чего нужен ETag, если мне всегда было достаточно одного Last-Modified и юзкейса для другого я даже и представить не мог (хотя меня этот вопрос, признаться честно, не особо и волновал).

Последнее время в инете стало появляться все больше публикаций про использование data:uri css sprites. Приведу две ссылки из блога Steve Souders, известный всему миру «оптимизатор» работающий в Google.

CSSEmbed — automatically data: URI-ize
Aptimize: realtime spriting and more

Наш отечественный герой «веб-оптимайзер» sunnybear намного раньше поднимал вопрос про использование data:uri в css и нами совместно был проведен ряд исследований. В то время вылезло много интересных моментов и особенностей о которых мы писали в предыдущих статьях. Последние эксперименты вскрыли ряд ранее неизвестных моментов по работе браузеров с data uri css спрайтами.

Всё началось с создания сложного AJAX приложения с применением java технологий GWT, GXT, Spring, Hibernate, Terracota, AndroMDA, ActiveMQ и множеством других волшебных звуков за которыми прячется вся мощь и могущество java технологий создаваемых десятками тысяч гениальнейших программистов уже второе тысячелетие подряд …

Но статья не об этом. Требовалось решить скромную, но очень интересную задачу, — не осилив всю технологичность, продуманность и совершенство решений на базе платформы java, снизить время загрузки клиентской части приложения.

Входные данные: размер текстовых данных js, css, xml, html, images коло ~1,2MБ(+ флэш), время загрузки в Москве более полутора минут, при хождении по ссылкам заметное время(1-15 секунд) на загрузку картинок, при повторном обращении картинка загружалась повторно.

Тем кто следит за статьями про клиентскую оптимизацию уже известен современный подход к созданию CSS спрайтов на базе data:uri технологии. Указанный подход имеет весомые достоинства:

• абсолютная минимизация конектов к серверу за изображениями определенных в css — сделать еще меньше уже невозможно.
• полная 100%-ая автоматизация процесса создания спрайтов независимо от свойств backgroud-position и background-repeat.
• предзагрузка всех изображений определенных в css, которые необходимы для сайта.