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

Примечание: ниже расположен перевод заметки «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→

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

Еще год назад у меня вызвало некоторое сомнение, что использование HTML 4.0 Transitional для разметки страницы будет экономичнее, чем XHTML 1.0 Strict с его жесткими стандартами оформления кода. Но тогда у меня не было особого желания проверять свою гипотезу, да я и плохо представлял, как это лучше сделать.

XHTML, являясь подмножеством XML, имеет более строгие требования к синтаксису, HTML допускает более свободную запись, этим можно воспользоваться.

Полная версия доклада про оптимизацию главной Яндекса
Читать дальше на webo.in→

Несколько читателей блога webo.in просили меня выложить конфигурацию связки nginx + Apache, на которой работает сервер. Хотя это и не относится напрямую к теме клиентской оптимизации. Однако, большинству специалистов, занимающихся клиентской оптимизацией, будет интересно узнать о настройке нескольких хостов для выдачи статики и пара других трюков, связанных с балансировкой запросов.

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

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

В этом топике я постараюсь обобщить материал про сжатие данных. Сжиматься будет css, js, html.

Примечание: ниже перевод статьи «Non-blocking JavaScript Downloads», в которой автор рассказывает о проблемах, связанных с подключением JavaScript-файлов, и возможной параллелизации их загрузок. Мои комментарии далее курсивом.

Об авторе: Stoyan Stefanov является веб-разработчиком Yahoo! в группе Exceptional Performance и курирует разработку YSlow — инструмента по измерению производительности. Он также внес значительный вклад в разработку продуктов с открытым кодом, выступал на конференциях и автор технических текстов. Его последняя книга Object-Oriented JavaScript.

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

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

Примечание: ниже перевод заметки от John Resig DOM «DOM DocumentFragments», в которой автор рассказывает об опыте использования DocumentFragment и сравнивает его быстродействие с обычным appendChild. Мои комментарии далее курсивом.

Недавно я игрался с DOM DocumentFragment в JavaScript, пробуя, что же можно с ним сотворить. Если вкратце, то DocumentFragment является облегченным контейнером для DOM-узлов. Он является частью спецификации DOM 1 и поддерживается во всех современных браузерах (был добавлен в Internet Explorer в 6 версии).

В процессе чтения я наткнулся на интересную вещь. Цитирую из спецификации:

Также различные операции — например, добавление узлов как дочерних для другого Node — могут принимать в качестве аргумента объекты DocumentFragment; в результате этого все дочерние узлы данного DocumentFragment перемещаются в список дочерних узлов текущего узла.

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

Полгода работы Web Optimizator — 20000 проверенных сайтов, 2000 зарегистрированных пользователей, около 100000 посетителей, 50 статей и переводов по оптимизации, сотни статей, заметок и отзывов по всему Рунету. Проект выстрелил.

Ниже я хочу поделиться парой мыслей о том, как я продвигал ресурс в Рунете и как пытался (местами неплохо) окупить поток посетителей. Итак, поехали.