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

После сравнительной заметки о 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→

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

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

Проблемы при верстке

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

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

Примечание: ниже расположен перевод статьи «Serving JavaScript Fast», написанной года два назад, но нисколько не потерявшей своей актуальности. Автор предлагает достаточно большой комплекс мер для ускорения загрузки и работы CSS/JS-файлов. Ссылки и частичные переводы данной статьи достаточно широко цитируются в Рунете, однако, полностью она еще нигде не появлялась, а полезных советов в ней довольно много. Мои комментарии далее курсивом.

Следующее поколение веб-приложений будет использовать весьма «тяжелые» JavaScript- и CSS-framework'и. Мы собираемся продемонстрировать, как увеличить скорость взаимодействия таких приложений и ускорить их работу.

Все эти так называемые «Веб 2.0» приложения, их глубокое взаимодействие с содержанием страницы и самим пользователем сильно увеличили сложность использования CSS и JavaScript. Для того чтобы быть уверенными в небольшом размере приложений, нам нужно оптимизировать как размер, так и саму природу всех файлов, которые нужны для нормальной работы нашей страницы. Мы должны быть уверены, что добились оптимума удобства использования сайта для пользователей. На практике это означает, что нам нужно добиться максимального уменьшения размера страницы и ускорения ее работы, при этом предотвращая загрузку ненужных ресурсов, которые не изменились с момента последнего обращения.

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

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

Шаг первый: простая страница

Начал я с обычной страницы, для которой использовалось только gzip-сжатие HTML-файла. Это самое простое, что может быть сделано для оптимизации страницы (на самом деле, причиной было то, что мне не хотелось специально отключать сжатие для одного хоста, а потом его включать обратно :). Данная страница бралась за основу, с которой сравнивалось все остальное.

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

Примечание: ниже находится перевод статьи «Compression using Canvas and PNG-embedded data». Автор предлагает на суд читателей еще один способ загрузить в клиентском браузере JavaScript-библиотеку, передав при этом минимум данных. Для этого используется PNG-картинка и объект canvas. Мои комментарии далее курсивом.



Недавно у меня появилась идея, что можно хранить исходный Javascript-код в PNG-картинке, а затем получать его через метод getImageData() элемента canvas. К несчастью, сейчас это означает, что только такой подход будет работать только в Firefox, Opera Beta и последних ночных сборках WebKit. Пока еще никто не указал мне, насколько gzip опережает данный метод по степени сжатия, я хочу сразу сказать что рассматриваемый метод никак не может быть практической альтернативой физическому сжатию. Чуть раньше сегодня я уже писал о сжатой версии в 8Кб скрипта Super Mario, для которого использовалась эта техника (подробнее можно прочитать в заметке про кодирование). Здесь я приведу лишь некоторые детали о действительном положении вещей.

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

Примечание: ниже перевод заметки John Resig «How JavaScript Timers Work», в которой автор jQuery ясно и подробно излагает тонкости работы различных методов отложенного исполнения функций. Мои комментарии по клиентской производительности далее курсивом.

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

• var id = setTimeout(fn, delay); — создает единичный таймер, срабатывание которого выливается в вызов определенной функции после указанной задержки. Данный метод возвращает уникальный ID, с помощью которого можно в дальнейшем отменить таймер.
• var id = setInterval(fn, delay); — похож на предыдущий метод setTimeout, но совершает вызовы заданной функции постоянно (каждый раз с заданной задержкой), пока не будет отменен.
• clearInterval(id);, clearTimeout(id); — принимают в качестве параметр ID таймера (возвращаемый двумя предыдущими методами) и предотвращают дальнейшие вызовы таймера.

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



Рисунок 1. Схема работы таймеров в JavaScript

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

Примечание: ниже находится перевод статьи «Average Web Page Size Triples Since 2003», в которой автор рассуждает о тенденциях, происшедших за последние 5 лет, касающихся размера веб-страницы и числа объектов на ней. Очень интересно сравнить полученные данные с ростом пропускной способности интернета, по моему мнению, последняя увеличилась примерно так же. Отсюда можно сделать вывод, что клиентская оптимизация ни разу не потеряла своей актуальности за последние 10—15 лет. Мои комментарии далее курсивом.

Размер средней веб-страницы увеличился более чем втрое с 2003 года. С 2003 по 2008 годы она увеличилась в размере с 93,7Кб до более 312Кб (см. рисунок 1), почти на 233% (Domenech и др. 2007, Flinn & Betcher 2008). За тот же пятилетний период число объектов на такой странице примерно удвоилось: с 25,7 до 49,9 объектов на страницу. Если взять статистику за более длительный период, то окажется, что с 1995 года размер средней веб-страницы увеличился в 22 раза, а число объектов на страницу в 21,7 раза.



Рисунок 1. Рост размера средней веб-страницы

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

В очередной презентации Yahoo! о клиентской производительности был поднят вопрос о favicon.ico. Они проводили несколько интересных фактов о данном явлении и давали пару советов. Процитирую их рекомендации:

• www.example.org/favicon.ico
• Необходимое зло:
  • Браузер ее запросит
  • Лучше не отвечать 404-ошибкой
  • Будут отправлены cookie
  • Не может быть в CDN
  • Мешается в последовательности загрузки ресурсов
• Уменьшайте ее (<=1 Кб)
• Использовать анимированные иконки ни разу не хорошо
• Выставляйте заголовок Expires
• Инструменты: imagemagick, png2ico, favicon.ru
• Материал для изучения: в поиске Yahoo! favicon.ico занимает 9% всех просмотров страниц (для webo.in это 7%)

Поскольку favicon.ico не является обычной картинкой при загрузке сайта (она, во-первых, запрашивается едва ли не один-единственный раз браузером при посещении сайта, во-вторых, загружается, игнорируя обычный порядок загрузки), то в дополнение к уже имеющейся информацией я захотел провести ряд дополнительных исследований и объединить все, что известно прогрессивному человечеству на данную тему. Однако, в ходе изучения материала оказалось, что проблема совсем не так прозрачна, как представлялось изначально. Формат .ico предстал в новом, весьма выгодном для использования в вебе, свете.

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

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

WebSiteOptimization

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

Несколько дней назад эта видео-запись размещенная на metacafe высветилась на digg. В ней объяснялось, как увеличить скорость открытия сайтов путем тонкого тюнинга браузера и изменения его настроек, отвечающих за число параллельных соединений. Чтобы объяснить, почему это работает, давайте немного углубимся в то, как браузеры обслуживают серверные соединения.

Утилитарный выбор

При разработке любых приложений всем разработчикам приходится делать то, что называется «утилитарным» выбором (utilitarian choice). Если несколько вычурно перефразировать Jeremy Bentham, то «утилитарным» можно назвать тот подход, «в результате которого мы получаем наибольшее количество добра для наибольшего числа [людей]». Много раз производительностью жертвовали для небольшого числа пользователей, чтобы, в результате, средняя производительность для всех пользователей в совокупности была бы лучше.

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

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

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

Методика

Если в первых двух исследованиях ставилась под вопрос скорость распознавания браузером CSS-правил и их применение, то сейчас интересовал другой вопрос, а именно: как быстро браузер создает DOM-дерево в зависимости от наличия в нем элементов с id или class?

Для этого было подготовлено 3 набора HTML-файлов. Первый содержал 10000 элементов, у которых часть имеет id (количество именованных элементов варьировалось от 50 до 10000). Во втором HTML-файлы были, практически, идентичными, только вместо id имели атрибут class. В третьем наборе в DOM-дереве были только элементы с id (т.е. варьировалось само число элементов). Соответственно, все измерения проводились в скрытом iframe, чтобы избежать отрисовки загружаемой страницы на экране.

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

Примечание: ниже находится перевод статьи «Embedding and Encoding in JavaScript», в которой автор (JavaScript-евангелист в Mozilla и автор библиотеки jQuery по совместительству) рассматривает способы сжатия информации и ее объединения при помощи JavaScript и некоторых других методов. Мои комментарии далее курсивом.

Грубая реализация на JavaScript (заметка на Хабре, ссылка blog.nihilogic.dk/2008/04/super-mario-in-14kb-javascript.html) первого уровня Super Mario Brothers буквально на днях обошла весь Интернет. В нее, в общем, можно играть, хотя упущены многие ключевые аспекты (нет грибов, нет флага, нет повышающих очков и т.д.). Однако, это, на самом деле, не самый интересный аспект в этой игре.

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

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

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

Примечание: ниже перевод статьи «On Streaming, Chunking, and Finding the End», в которой авторы рассматривают процесс передачи информации по HTTP-соединению и возможности для ускорения этого процесса. Мои комментарии далее курсивом.

Два способа передачи

Как и в большинстве механизмов передачи данных, в HTTP существует два основных способа отправить сообщение: «все и сразу» или «по частям». Другими словами, в HTTP есть возможность отправлять данные до тех пор, пока еще есть хотя бы что-то, что можно отправить, либо отправить все данные как одну логическую единицу, указав предварительно ее размер.

Если вы занимаетесь веб-разработками достаточно продолжительное время, скорее всего, вы уже знаете, как работает сброс буфера (flush) на стороне сервера. Этот метод позволяет начать отправку части данных пользователю, в то время как скрипт может продолжать выполнять некоторые, достаточно медленные, действия (скажем, ресурсоемкий запрос к базе данных). Если вы уже применяли эту возможность, тогда вы, вероятно, использовали преимущества потокового (streaming) механизма, хотя могли и не знать всех деталей работы HTTP-протокола.

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

Статья «Как gzip-сжатие влияет на производительность сервера» вызвала вполне понятную, но несколько неоднозначную реакцию, ибо было не понятно, насколько сильно издержки на gzip зависят от степени сжатия и как ее прогнозировать с учетом всех остальных параметров. Хочется сказать отдельное спасибо  alfa, который, собственно, и поднял этот вопрос.

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

Уже больше трех месяцев Web Optimizator живет и работает. Надеюсь, что основная его задача — изменить представление о скорости загрузке и работы сайтов — так или иначе достигается. Все больше веб-разработчиков используют «продвинутые» технологии для создания своих продуктов. Сознание пользователей начинает привыкать к мысли о том, что «быстро» — это когда сайт загружается за 2–3 секунды, а не за 10–20.

Хочу немного рассказать о том, что лежало в предыстории проекта, о появлении самой мысли о том, как мир можно сделать лучше (=быстрее), и ее материализации именно в таком виде. О том, как можно найти идеи для создания технологичных проектов и сервисов. О том, как можно развиваться. Может быть, кто-то подчерпнет из этой истории уверенности и оптимизма, а кто-то — просто практических советов.

Несколько статей и переводов по оптимизации (gzip для Apache, gzip для CSS- и JS-файлов, CSS-сжатие, JS-сжатие) уже затрагивали тему применения архивирования для уменьшения размера файлов, и, тем самым, увеличения скорости их передачи конечному пользователю. В данном исследовании я задался вопросом: а как динамическое gzip-сжатие влияет на быстродействие сервера? Рентабельно ли включать mod_gzip / mod_deflate для высоконагруженных проектов? И в каких случаях архивирование вообще лучше не использовать?

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

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