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

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

Во времена 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, которые необходимы для сайта.

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

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

Кого я вижу в качестве партнера?

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

Хабралюди!

Если вы хотите задать тупой (или не очень вопрос) по клиентской или серверной оптимизации, ответить какому-нибудь ньюбу или просто узнать новости отрасли — милости просим. Специально для этой цели мы завели рассылку через Google Groups — clientside_ru. Теперь мучить меня по ICQ/Skype совсем не обязательно :)

groups.google.com/group/clientside_ru

Или галочка достала

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

P.S. В бумажную версию не вошло — может, кто-то из энтузиастов скорректирует электронные, которые затем будут печатать.

При разработке сайтов все чаще и чаще приходиться использовать технологию 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 →