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

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

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

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

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

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

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

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

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

Примечание: ниже находится перевод статьи «Optimize Parallel Downloads to Minimize Object Overhead», в которой авторы рассматривают параллельную загрузку объектов, и как она влияет на производительность веб-страницы. Мои комментарии далее курсивом.

Средняя веб-страница содержит более, чем 50 объектов (Krishnamurthy и Wills 2006), при этом издержки на число объектов доминируют над всеми остальными задержками при загрузке большинства веб-страниц (Yuan 2005). Браузеры, следуя рекомендациям спецификации HTTP 1.1, обычно устанавливают не более 2 одновременных соединений (это справедливо только для IE6/7, для Firefox и Opera этот параметр настраиваемый, составляет не меньше 4, по умолчанию. Для IE8, по словам Алекса Могилевского, скорее всего, будет 6) с одним хостом. При увеличении числа HTTP запросов, требуемых для отображения страницы, с 3 до 23 время, затрачиваемое именно на «чистую» загрузку объектов, от общего времени загрузки падает с 50% до всего 14% (см. Рисунок 1).

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

Примечание: ниже располагается перевод статьи «The Cost of Banner Advertising on Web Performance», в которой рассматривается, как банерная (и не только) реклама влияет на производительность при загрузке веб-страниц. Мои комментарии далее курсивом.

Реклама является многомиллиардной веб-индустрией. Internet Advertising Bureau сообщило, что выручка от рекламы в Интернете выросла примерно на 34% за 2006 по сравнению с 2005 годом и составила в сумме около 16,8 миллиарда долларов (IAB 2007). По данным Baker годовой рост оборота рынка Интернет-рекламы составляет 28,6% в год, при этом вся рекламная индустрия показывает прирост всего в 7,7% в год (Baker 2004).

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

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

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

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

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

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

Примечание: ниже расположен перевод статьи «Inline Images with Data URLs», в которой рассматривается вопрос о внедрении картинки на веб-страницы при помощи data:URI. Эта схема позволяет вставить код картинок прямо в (X)HTML-страницу без обращений к внешним файлам, что уменьшает общее количество HTTP-обращений к серверу. Мои комментарии далее курсивом.

Встроенные (inline) изображения используют схему data:URI для внедрения прямо в тело веб-страницы. Как было определено в RFC 2397, такие URI предназначены для вставки небольших объектов как «непосредственные» данные. Такие объекты должны рассматриваться так же, как и любые другие внешние файлы. Использование встроенных изображений позволяет сэкономить HTTP-запросы к внешних ресурсах.

Поддержка браузерами data:URL

Хотя Opera 7.2+, Firefox, Safari, Netscape и Mozilla поддерживают data:URI, Internet Explorer 5–7 совсем нет. Однако, сообщается, что Internet Explorer 8 будет поддерживать эту схему, так как проходит Acid2 тест, что позволяет использовать data:URL как реальную альтернативу для внедрения небольших декоративных изображений. Существует также несколько приемов для поддержки старых версий Internet Explorer.

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

Примечание: ниже перевод статьи «JavaScript optimization, are chained calls expensive?». В ней автор тестирует, насколько медленнее производятся цепочки вызовов функций по сравнению с их кешированными аналогами. В конце приведены результаты моих тестов производительности.

Sree Kotay в своем блоге оставил небольшую заметку о JavaScript. (Если вас интересуют технические подробности, я рекомендую ознакомиться с презентацией Simon Willison «A (Re)-Introduction to JavaScript».) В своем блоге Sree пишет следующее:

Чтобы разобраться с теми различиями для простейшего случая, которые следуют из понимания (очевидных) основ JS оптимизации, стоит осознать, что:

for (i=0; i < 100; i++) a.b.c.d(v);

… ЗНАЧИТЕЛЬНО медленнее, по крайней мере, в JavaScript, чем:

var f=a.b.c.d;
for (i=0; i < 100; i++) f(v);

… потому что, в конце концов, JS — это динамический язык. Я предоставлю несколько более конкретных советов для JavaScript и тестов производительности, которые прояснят эту ситуацию.

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