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

При разработке сайтов все чаще и чаще приходиться использовать технологию CSS спрайтов, дабы уменьшить кол-во изображений загружаемых на странице. Создание и редактирование таких изображений является не простой задачей, на которую тратится довольно таки много времени: изначально нужно скомпоновать изображения в графическом редакторе, а после описать позиционирование и размеры каждого элемента в файле стилей (CSS). Редактирование элементов и изменение их размеров может повлечь глобальный пересмотр спрайта, вплоть до полного его пересоздания.

Вице-президент Google, Марисса Мейер, на конференции Web 2.0 поведала историю об одном пользовательском тестировании. Группа пользователей Google была опрошена на предмет, сколько результатов поиска они хотели бы видеть на одной странице. Те просили показать побольше, больше чем те 10 штук что поисковик выдаёт обычно. «Много не мало», говорили они.

Специально для них, Гугл увеличил выдачу до 30 результатов. Объём трафика и доходность сократились на 20%.

Почему им не понравилось? Ведь всё было сделано именно так как они сами хотели.

Оказалось, изменилось кое-что ещё. На генерацию страницы с десятью результатами у сервера уходило 0,4 секунды, на страницу с тридцатью — 0,9.

Всего лишь полсекунды разницы уменьшило трафик на 20% и испортило впечатление пользователей о сайте.

Такой вывод может стать сюрпризом — разве люди заметят задержку в полсекунды? — но в Amazon.com мы получали похожие данные. В порядке тестирования, мы понемногу задерживали отдачу страницы сервером и обнаружили что даже небольшие задержки приводят к значительному и дорогостоящему падению прибыли.

Потом Марисса рассказала что после того как, в своей новой версии, страницы Google Maps стали весить меньше, а карты отрисовываться быстрее, объём трафика незамедлительно вырос, как и использование сервиса вообще.

Урок в том, сказала Марисса, что скорость имеет значение. Люди не любят ждать, так что не заставляйте их делать это.

Via Fresh GUI.

Все мы знаем сотню способов загрузки скриптов. У каждого свои плюсы и минусы.

Хочу представить вам очередной метод загрузки js-файлов. Я также понимаю, что такой метод активно используется в сети, но статей про него я не видел.
Поэтому опишу способ, которым пользуюсь сам, в надежде, что он вам тоже понравится.

Цели: модульность разработки, быстрота загрузки, валидный кэш.
Бонус: индикатор загрузки

UPD. Обозначил главную цель этого метода — валидный кэш.
При использовании данного метода, у вас не будет неуверенности в том, обновится ли скрипт и будет ли он работать у конечного пользователя.

UPD 2. Для тех кто не дочитывает до конца (я вас прекрасно понимаю), в концовке сказано, как всё можно сделать намного проще.
Вместо core.633675510761.js писать core.js?v=633675510761. И там же указано, почему всё же написано так много.

UPD 3. В комментариях от david_mz, WebByte прозвучало предложение для обработки запроса использовать не JSHandler, а urlrewrite.

Примечание: ниже перевод очередной заметки «Image Optimization, Part 5: AlphaImageLoader» из блога YUI. Stoyan Stefanov на этот раз рассказывает о тонкостях применения фильтра AlphaImageLoader для IE. Мои комментарии далее курсивом.

Это пятая часть серии статей про оптимизацию изображений. С предыдущими частями можно ознакомиться по адресу:

• Image Optimization Part 1: The Importance of Images
• Image Optimization Part 2: Selecting the Right File Format
• 4 шага для уменьшения размера файлов
• Последовательные JPEG — Быть или не быть?

Данная статья из серии, посвященной оптимизации изображений, рассказывает о технике, доступной только в IE, — CSS-фильтре AlphaImageLoader, — который используется разработчиками для решения проблем с прозрачностью для полноцветных PNG-изображений в IE. Основная проблема с AlphaImageLoader заключается в том, что он влияет на производительность страницы, и тем самым ухудшает пользовательское восприятие. Я утверждаю, что стоит избегать использования AlphaImageLoader во всех возможных случаях.

Маленький экскурс

Как было сказано в одной из предыдущих статей, PNG могут быть нескольких видов, которые могут быть разделены на 2 основных:

• Индексированные (палитра), их также называют PNG8, можно использовать до 256 цветов.
• Полноцветные PNG, которые также называют PNG32 или PNG24.

Читать дальше на webo.in →

Мучения со стандартным подходом применения CSS спрайтов, а именно трудности модернизации и в некоторых случаях сложности оптимальной компоновки заставили искать альтернативный вариант оптимизации загрузки изображений. Очередной раз почитывая хабра-статьи, наткнулся на интересный подход реализации спрайтов с применением data:URI. В ходе дискуссий и умозаключений были определены слабые и сильные стороны данного подхода. Одним из значительных недостатков нового подхода является сложность сборки конечного CSS. Однако, при использовании data:URI имеет место возможность автоматизации процесса.

Примечание: ниже перевод заметки «Image Optimization, Part 4: Progressive JPEG…Hot or Not?» из блога YUI. В ней уже известный по прошлым статьям Stoyan Stefanov рассматривает использование последовательных (progressive) JPEG с точки зрения клиентской оптимизации. Мои комментарии далее курсивом.

В своей предыдущей статье «Оптимизация изображений, часть 3: 4 шага для уменьшения размера файлов» последовательные JPEG-файлы были вскользь упомянуты как одна из возможностей для оптимизации JPEG. Эта статья рассматривает данный вопрос более глубоко, включая результаты проведенного эксперимента над 10000 изображений.

Базовые (baseline) и последовательные JPEG

Базовые JPEG являются «обычными»: файлы этого типа поддерживаются всеми программами для редактирования изображений. Браузеры загружают их последовательно, сверху вниз, по мере поступления информации из сети.



Загрузка базового JPEG-файла в браузере. По нажатию откроется полная версия.

Последовательные JPEG являются другой разновидностью данного формата: они загружаются (как можно понять из названия) последовательно. Сначала вы увидите картинку низкого качества. Затем, по мере поступления графической информации, качество изображения будет постепенно улучшаться.



Загрузка последовательных JPEG. По нажатию откроется полная версия.

Читать дальше на webo.in →

Примечание: ниже расположен перевод заметки «Browser Page Load Performance» от John Resig, в которой он рассматривает тестовое окружение от Steve Souders для анализа клиентской производительности браузеров. Мои комментарии далее курсивом.

Steve Souders много внес в улучшение производительности браузеров при загрузке страницы и клиентской оптимизации более, чем кто-либо. Во время своей работы в Yahoo! он отвечал за YSlow (великолепный инструмент для измерения производительности вашего сайта) и написал книгу, посвященной улучшению производительности веб-страниц — High Performance Web Sites. Сейчас он работает в Google, но по-прежнему занимается тем же самым: делает загрузку веб-страниц чуточку быстрее.

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

Давайте взглянем на следующую таблицу:


Читать дальше на webo.in →

Предыстория

Как известно, перед тем, как выложить сайт в нет, мы его разрабатываем. И делаем мы это, как ни странно, на машине разработчика. И давно замечено, что javascript, а в некоторых случаях и css удобнее при разработке держать в нескольких файлах.Проблема в том, что, согласно принципам, описанным в статье Best Practices for Speeding Up Your Web Site (перевод доступен на сайте webo.in), для ускорения загрузки сайта нам нужно произвести следующие манипуляции над javascript и css файлами:

1. Слить весь javascript в один файл, причем, желательно так, чтобы сохранился нужный порядок — т.е., скажем, библиотека jQuery — была ближе к началу, а функции и объекты, которые ее используют — после нее.
2. Слить весь css в один файл
3. Сжать эти большие файлы с помощью какой-нибудь утилиты вроде yui-compressor (за исключением css-файлов, название которых начинается, скажем, с префикса ie_, которые содержат data:URL, и поэтому критично относятся к переходам со строки на строку, так что их для собственного спокойствия лучше не сжимать)
4. Расположить их в таком порядке — css-файл как можно ближе к открывающему тэгу head, а js-файл — как можно ближе к закрывающему тэгу body.
5. Выставить HTTP-заголовок expires на подольше, чтобы браузер пользователя их закешировал. Ну а для того, чтобы при следующем билде у пользователя обновился js и css надо этим файлам дать какое-нибудь уникальное имя.
6. Перед отдачей файлов клиенту сжимать их с помощью gzip

К чему это я?

Пункты 5 и 6 уже подробно расписаны в других местах.
Я же хочу рассмотреть в этой статье вопрос автоматизации пунктов 1,2,3,4. А точнее, я хочу предложить инструмент, с помощью которого одним (ну, максимум — двумя-тремя :) нажатием кнопки можно выполнить пункты 1, 2, 3, 4 настоящего списка и получить готовые к заливке на сервер javascript и css файлы.

Примечание: ниже расположен перевод заметки Image Optimization, Part 3: Four Steps to File Size Reduction от Stoyan Stefanov. В ней рассматриваются наиболее популярные консольные утилиты для минимизации изображений. Мои комментарии далее курсивом.
Об авторе: Stoyan Stefanov работает веб-разработчиком в команде Yahoo! по исключительной производительности и руководит разработкой инструмента для анализа производительности — YSlow. Он также внес значительный вклад в программы, разрабатываемые с открытым исходным кодом, выступает на конференциях и является техническим писателем: его последняя книга озаглавлена Объектно-ориентированный JavaScript.

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

• Оптимизация изображений, часть 1: важность картинок
• Оптимизация изображений, часть 2: выбираем нужный формат файлов

Текущая заметка посвящена некоторым наиболее часто используемым инструментам, которые можно применить для уменьшения размера изображений. Идея заключается в следующем: мы можем получать все изображения от дизайнера, но не оставлять их в исходном виде, а немного уменьшать в размере, используя указанные ниже инструменты. Это позволит автоматизировать процесс без необходимости глубокого анализа структуры изображения.
Читать дальше на webo.in →

Заметка Выносим CSS в пост-загрузку была посвящена исследованию наиболее быстрого способа добавить стилевые правила в исходный документ динамически, не затрагивая при этом стадию предзагрузки (когда у нас еще белый экран в браузере). В ней, однако, не был рассмотрен следующий вопрос: какой метод использовать для добавления массива CSS-правил в сам HTML.

Естественно, что таких вариантов существует несколько, и дальше они все будут рассмотрены с точки зрения производительности в клиентском браузере.

Тестовое окружение

Поскольку скорость загрузки отдельного CSS-файла достаточна велика, а требуется рассмотреть, как его содержимое может повлиять на скорость его динамического применения к документу, то нам нужны сотни или даже тысячи правил. В качестве отправной точки была опять взята главная страница Яндекса, стили которой были вынесены в отдельный файл и скопированы 10 раз. Это дало необходимую задержку (которая существенно больше погрешности, вносимой браузерами) и не сильно увеличило сжатый с помощью gzip файл.

Все варианты представлены на тестовой странице, вкратце опишу основные подходы.

Читать дальше yа webo.in →.

Коллеги, други и просто хабралюди. С неделю назад на Web Optimizator был выложен код для счетчика загрузки (немного более подробно об измерении времени загрузки страницы можно прочитать в статьях про анализ скорости загрузки и разгон интернет-магазина).

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


График распределения пользователей webo.in по времени загрузки у них этого сайта

Наткнулся на кучу интересных статей на webo.in и зачитался. Решил применить описанное там на реальном проекте. Вот что получилось. Проектик маленький — сайт моих друзей Bookcare. Они делают обложки для книг, а их сайт — мой «проект выходного дня».

Одновременно с окончанием конкурса WebHiTech хочу заявить о не менее важном событии в моей жизни: завершена основная работа над рукописью книги «Разгони свой сайт».

На данный момент в нее вошли несколько десятков статей, много-много мыслей хабралюдей и подробный анализ как инструментов для анализа, так и некоторых сайтов Рунета.

Загрузить последний .pdf файл (3,2 Мб, 200 264 страницы) можно всегда по этому адресу
webo.in/book

Дано: подопытный инетмагазин, вполне успешный в своей области, более тысячи посетителей ежедневно.
Задача: выяснить как скажется на выручке оптимизация загрузки страниц.

На сайт был установлен невидимый яваскрипт-счётчик, который фиксировал время до наступления события window.onload и некоторые другие параметры, в течении 5 рабочих дней собиралась статистика и обкатывался её анализатор.

В продолжение темы клиентской оптимизации слиянием ресурсов.

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

Есть три основных вида обращения к странице:

1. начальная загрузка (загружается и ядро, и ресурсы выбранной страницы)
2. загрузка новой страницы (ядро находится в кеше, загружаются ресурсы выбранной страницы)
3. загрузка старой страницы (и ядро, и ресурсы страницы находятся в кеше).

На скорость загрузки в третьем случае мы повлиять не можем. Кроме того, для ускорения начальной загрузки выгодно уменьшить объем ядра, поэтому оптимизация случая (1) ухудшает время загрузки в случае (2) и наоборот. Что делать?

update: про сервис уже рассказывали тут habrahabr.ru/blogs/webdev/41318, так что оставляю пост только для френдов, мой пост содержит картинки и может служит расширением к предыдущему.

Не секрет, что при создании web-проектов самым тяжелым контентом, зачастую, являются различные картинки, иконки и изображения. В этой заметке я хотел рассказать про сервис www.smushit.com, который позволяет оптимизировать картинки на вашем сайте для достижения максимальной производительности.

После сравнительной заметки о CSS Sprites и data:URL все мои мысли были направлены на решение основной проблемы:

В общем случае [при использовании data:URL], загрузка страницы не ускорится, а даже может замедлиться, потому что фоновые картинки (включенные через data:URL) будут грузиться в один поток, а не в несколько при обычном использовании спрайтов. Если фоновых картинок достаточно много (несколько десятков Кб), то это окажется существенным.

Данная статья как раз посвящена тому, как можно достаточно успешно справиться с указанной проблемой. Интересно? Тогда, поехали.

Читать дальше на webo.in→

 

Разгоняем счетчики: от мифов к реальности

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

На самом деле, все не так плохо. Скорее, все очень хорошо, но мало кто об этом знает :)

Заглянем внутрь

Что из себя представляет код JS-счетчика? Обычно (в 99% случаев) он «вытаскивает» из клиентского окружения набор параметров (URL текущей страницы, URL страницы, с который перешли на текущую, браузер, ОС и т.д.), которые передаются на сервер статистики. Все навороты счетчиков связаны с обеспечением максимальной точности передаваемой информации (кроссбраузерность, фактически). Наиболее мощные (Omniture, Google Analytics) используют еще и собственные переменные и события, чтобы усилить маркетинговую составляющую.

Но сейчас речь не об этом. Как собранные на клиенте данные попадают на сервер статистики? Все очень просто: в документе создается уникальный элемент, в URL которого «зашиваются» все необходимые значения (обычно в качестве GET-параметров). URL этот ведет, как можно догадаться, на сервер статистики, где данные кладутся в базу и каким-то образом показываются в администраторском интерфейсе.

Читать дальше на webo.in→

Обычно пользователю нет дела до того, какие подходы мы применяем при разработке, как настроен сервер, какие клиентские и серверные фреймвёрки мы используем. Его может волновать на сколько сайт полезный, удобный и быстрый. Наша же задача заключается в том, чтобы не доставлять пользователю неудобства, радовать его, и тем самым заставлять его покупать наш мега-продукт или смотреть на наши замечательные баннеры. Эта статья о том, как создавать быстрые сайты.