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

Примечание: ниже находится перевод статьи «The Psychology of Web Performance», в которой автор поднимает психологические аспекты производительности веб-страниц: чем она обусловлена, как ее измерить — и описывает некоторые сопутствующие (коммерческие) эффекты. Мои комментарии далее курсивом.

Предыдущем исследование продемонстрировало, что пользовательское раздражение сильно возрастает, если скорость загрузки страницы превышает 8–10 секунд безо всякого уведомления пользователя о процессе загрузки (Bouch, Kuchinsky и Bhatti, 2000, King, 2003). Последние работы в этой области показали, что пользователи с широкополосным доступом еще менее терпимы к задержкам при загрузке веб-страниц по сравнению с пользователями с более узким каналом. В опросе, проведенном JupiterResearch, было установлено, что 33% пользователя скоростного соединения не хотят ждать более 4 секунд при загрузке страницы, при этом 43% пользователей не ждут более 6 секунд (Akamai, 2006).

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

Логическим продолжением уже проведенных исследований CSS/DOM-производительности браузеров (часть 1, часть 2, часть 3) стало рассмотрение зависимости времени создания документа от числа тегов (узлов дерева). Раздельно анализировались случаи, когда DOM-дерево было чисто линейным (все div лежали прямо внутри body, когда оно было разветвленным (ветки по 10 вложенных div наращивались внутри body) и когда вместо ветки из div использовалась некоторая семантическая конструкция.



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

После многочисленных статей (на русском и английском) на тему использования стилей для 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 →

Cache — временные данные или устройство по их хранению, созданные для ускорения чтения/записи. Все программисты это знают. Ускорение загрузки web-сайтов тема обширная, начинающаяся с сервера и заканчивающаяся клиентом. К сожалению я не нашёл более-менее подходящих решений по объединению и кэшированию js-кода, поэтому к своему блогу я написал свою схему, о которой вкратце и расскажу..
Существует сжатие «packer», которое убирает все символы форматирования и переименовывает имена функций и переменных в js и предоставляет т.н. minified-версию скрипта. Все с этим прекрасно знакомы на примере больших библиотек jQuery, TinyMCE, prototype. Кроме того что код становится совершенно не читаемым, это может вызвать неработоспособность кода, когда имена переменных динамические.
Моя идея простая — разделять js/css по файлам разработчикам надо для поддержания модульной структуры. Обычно я в контроллере создаю список файлов которые надо присоединить к данному документу, вместо того что-бы прописывать это вручную в темплейте. Но теперь надо сделать так, что-бы до показа темплейта вызывалась функция кэширования, которая проходилась бы по списку, проверяла из них локальные файлы на время изменения, объединяла в один файл и создавала или перезаписывала gz-файл с именем, сформированным из md5-хэша имён входящих файлов.
Всё просто и в сумме заняло часа 4 на раздумье. Привожу метод cache_js из класса Controller.

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

О чем идет речь? IE (до версии 7 включительно) не поддерживает протокол data:URL, а вместе с ним base64-кодирование внешних файлов и включение их прямо в тело необходимого документа (будь то HTML или CSS/JS-файл). Однако, если рассмотреть использование протокола mhtml (который, конечно же, поддерживается только в IE), многое становится более ясным, и base64-кодирование удается использовать в полной мере.

читать дальше на 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 →

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

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

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

Изображения, используемые в правилах CSS, загружаются, даже если эти правила не применяются.

Просто факт на заметку. Проверено с помощью Firebug в Firefox 3.0.

И в принципе это правильно :-)

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

Примечание: ниже находится перевод заметки «Search and Don't Replace». В ней автор размышляет о методах преобразования строки запроса в массив на JavaScript при минимальных затратах процессорного времени. Мои комментарии далее курсивом.

Немного ранее сегодня мой друг, Marc Grabanski, подкинул мне вопрос: как наиболее оптимальным образом на JavaScript преобразовать строку запроса вида foo=1&foo=2&foo=3&blah=a&blah=b во что-то вроде foo=1,2,3&blah=a,b? У него уже было на тот момент собственное решение, и ему было любопытно, нельзя ли его как-либо улучшить.

Я подумал немного и предложил следующее решение:

function compress(data){
    var q = {}, ret = "";
    data.replace(/([^=&]+)=([^&]*)/g,     function(m, key, value){
        q[key] = (q[key] ? q[key] + "," : "") + value;
    });
    for ( var key in q )
        ret = (ret ? ret + "&" : "") + key + "=" + q[key];
    return ret;
}

читать дальше на 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 →.

Примечание: ниже находится перевод статьи «Performance Research, Part 5: iPhone Cacheability — Making it Stick» из блога производительности YUI. Авторы исследовали поведение iPhone при загрузке страницы и сделали некоторые интересные выводы по производительности веб-страниц для этого мобильного устройства. Мои комментарии далее курсивом.

Эта статья, написанная в соавторстве с Wayne Shea, пятая в серии, посвященной описанию экспериментов, которые направлены на исследование производительности веб-страниц (часть 1, часть 2, часть 3 и часть 4). Вы, наверное, удивлены, почему статьи по производительности находятся в блоге YUI (Yahoo! User Interface, пользовательских интерфейсов Yahoo!). Так получается, что программирование клиентской части, что, по сути, равносильно разработке и созданию пользовательских интерфейсов, оказывает наибольшее воздействие на производительность веб-страниц (в свете ведущей роли инженеров Yahoo! в изучении производительности клиентской части, наверное, более удивителен тот факт, что такие статьи все еще находятся в этом блоге, а не выделены в отдельное направление).

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

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

Приведу характерный пример кода для jQuery, который использует движок CSS-селекторов:

$(function(){
    $("a.clip").click(function(){
        $("#clip"+$(this).attr("rel")).slideToggle(500);
        if($(this).html() == "+") {
    $(this).html("–");
        } else {
    $(this).html("+");
        }
        return false;
    });
})

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