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

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

Примечание: ниже перевод свежей презентации от Yahoo! «High Performance Web Pages» с новыми советами по оптимизации. Yahoo известна своими статьями на тему оптимизации клиентской части и является мировым лидером в этой области. Однако, с уходом Julien Lecomte (ведущего специалиста отдела оптимизации, автора YUI Compressor) в Apple ситуация может измениться. Посмотрим.

Мои комментарии далее курсивом. Я постарался, по возможности, расставить ссылки на упоминаемые в презентации инструменты и связанные статьи.

Этот медлительный веб

• Мы используем Интернет для решения наших повседневных задач
• Мы все хотим испытывать при этом комфорт
• Мы не выносим медленные страницы (хотя есть варианты)
• На 500 мс медленнее = 20% уменьшение трафика (Google)
• На 100 мс медленнее = 1% уменьшение продаж (Amazon)

Разговор на сегодня

• Как улучшить производительность веб-страниц
• Фокус на клиентской части
• 14 отличных советов для быстрых страниц
• … и еще 20!

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

Примечание: ниже приведен перевод статьи «Replace GIF with PNG Images» о том, в каких случаях стоит использовать PNG-формат вместо GIF. Мои комментарии далее курсивом.

Введение

Переносимый сетевой графический формат (Portable Network Graphics, PNG) разрабатывается как более эффективная, гибкая и свободная от патентов замена GIF-формату. PNG был задуман для хранения отдельных растровых изображений для дальнейшего распространения по компьютерным сетям (1). PNG был создан в 1995 в ответ на давление со стороны Unisys и их патента на алгоритм LZW-сжатия, используемый в GIF. Хотя срок действия патента Unisys уже закончился, причины на переход от GIF к PNG остались, практически, прежними (2). Заменив ваши GIF-изображения теми же самыми, но в формате PNG, вы можете ускорить загрузку ваших страниц и сэкономить трафик ваших пользователей.

PNG против GIF: алгоритмы сжатия

PNG использует алгоритм deflate-сжатия обычно с 32Кб скользящим (sliding) окном. Deflate является улучшенной версией алгоритма сжатия Lempel-Ziv (LZ77), который используется в ZIP- и GZIP-файлах (3, 4). Созданный Phil Katz для второй версии PKZip, deflate совмещает LZ77 с кодированием Huffman и является от 10% до 30% более эффективным, чем LZW при сжатии без потери информации. Так же, как и GZIP, некоторые инструменты по PNG-сжатию предполагают опциональный параметр «степень сжатия», которая варьируется от 1 до 9. По умолчанию выставляется 6. 9 является практически всегда лучшим выбором для максимального сжатия.

Не удивительно, что изображения, сохраненные как PNG, обычно от 10% до 30% меньше, чем GIF, хотя в некоторых редких случаях они могут быть больше по размеру (5, 6). В нашем тестировании мы обнаружили, что часть картинок могут быть сжаты от 40% до 50% или даже больше (до 85% для одного примера), в зависимости от изображения. По большей части изображения с большими однотонными областями сжимаются лучше, чем градиентные с большим количеством переходов между цветами.

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

После статьи «Разгоняем CSS-селекторы: стоит ли?» было предложено рассмотреть несколько дополнительных случаев, учитывающих транзитивность селекторов (например, насколько быстрее a c, чем a b c, или наоборот). Данное исследование посвящено как раз разбору таких случаев.

Методика

Методика и уменьшение погрешности подробно рассматривались в первой статье, на них сильно много останавливаться не буду. Скажу лишь, что при наращивании количества классов и идентификаторов Opera стала значительно медленнее (раза в 3) отображать код (при этом общий его объем увеличился примерно в 1,5-2 раза). Скорее всего, в следующую статью войдет исследование влияния количества классов/идентификаторов/размера кода на общую производительность браузера.

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

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

Примечание: ниже перевод заметки «Tools for Detecting Memory Leaks» от John Hrvatin (менеджера команды разработчиков IE). В ней автор рассказывает о прогрессе в устранении утечек памяти в текущих реализациях IE, а также делает краткий обзор существующих инструментов для детектирования таких утечек.

Всем привет. Веб-разработчики знают, как легко создать сайт, который будет «течь» в памяти при просмотре в Internet Explorer. Члены команды IE написали специальную статью в MSDN по поводу утечек памяти, также существует большое количество статей, написанных в подобном ключе, в которых освещается эта проблема, в зависимости от той или иной степени авторской озабоченности.

Очень часто эти утечки памяти возникают из-за циклических ссылок между объектами Jscript и IE DOM (объектной модели документа). Так как движок Jscript и IE имеют независимые схемы для управления выделением памяти, каждый из них не в состоянии отследить полный цикл таких ссылок.

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

Прошло чуть больше месяца с последней публикации о проекте webo.in, полностью посвященном клиентской оптимизации веб-сайтов и веб-приложений, и чуть больше 2 месяцев с момента его появления в сети.

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

Примечание: ниже перевод презентации «High Performance Ajax Applications», подготовленной ведущим специалистом из Yahoo (а теперь уже из Apple) Julien Lecomte. В ней автор освещает некоторые аспекты оптимизации как JavaScript-приложений, так и веб-сайтов вообще. В целом, советов много, и почти все, действительно, по делу. Однако, встречается и откровенная реклама Yahoo :) Мои комментарии далее курсивом.

Часть 1. Разработка для высокой производительности

Планируем и проектируем для высокой производительности

• Ориентируемся на производительность с самого первого дня
• Тесно работаем с дизайнерами и менеджерами продукта
• Понимаем рациональность дизайна
• Объясняем компромиссы между дизайном и производительностью
• Предлагаем альтернативы и показываем, что еще возможно (на уровне прототипа)
• Пробуем силы в реализации нетривиального дизайна (нельзя сразу говорит «нет»)
• Помогаем упростить дизайн и взаимодействие с пользователем (добиваемся компромисса)

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

Примечание: ниже находится перевод статьи с MSDN «Building High Performance HTML Pages», в которой приводится ряд советов от экспертов из Microsoft по оптимизации времени загрузки страниц. Очень интересно сравнить их подход с аналогичным для Yahoo!. На мой взгляд, большая часть советов уже не является такой актуальной (спасибо Zeroglif, все приведенные советы, скорее всего, десятилетней давности), но в свое время все они были весьма действенны. Мои комментарии далее курсивом.

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

Коммуникационные возможности, обеспечиваемые Microsoft Internet Explorer 4.0 и более поздними версиями, помогли превратит Веб в мощное пространство, где можно как работать, так и играть. Число HTML-страниц и их сложность вместе с общим количеством потребителей конечных продуктов существенно увеличили общий интернет-трафик. Вместе со всеми выгодами, которые получили разработчики приложений, это привело и к ряду проблем. Среди этих проблем можно выделить:

• Доставка содержания через интернет (across the wire).
• Будучи доставленным, содержание должно быстро отобразиться на экране.

В этой статьи предлагается несколько советов, как добиться максимальной производительности ваших страниц.
читать дальше на webo.in →

Виталию Харисову посвящается

После перевода заметки «Оптимизируем CSS-производительность» и справедливых замечаний Виталия vithar, я решил поставить серию экспериментов по скорости работы CSS-селекторов внутреннего движка браузеров. Результаты получились весьма забавными, а местами, наверное, даже интересными.

Методика. Размер файлов

Естественно, что скорость работы одиночного CSS-правила весьма высока, и даже десятки и сотни их не должны заметно замедлить работу браузеров. Поэтому нужно ставить эксперимент по работе с несколькими тысячами правил, иначе точность результатов будет весьма невысока. Использовать JavaScript для генерации HTML/CSS-кода не представляется разумным, ибо тогда придется учитывать еще и скорость работы JS-движка в браузерах, в итоге, эксперимент будет недостаточно чистым.

В конце концов, было решено сгенерить статичные файлы (порядка 300Кб), которые будут содержать достаточное число различных CSS-селекторов. Это самое «достаточное» число подбиралось по нескольким параметрам, в том числе: размер файла (гонять несколько Мб через браузер и интернет совсем не хотелось) и скорость работы HTML/CSS-кода в браузерах (она должна быть достаточно низкой, чтобы файлы в несколько сотен Кб уже заметно тормозили при открытии).

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

Примечание: ниже перевод заметки John Resig (автора jQuery) «JavaScript Library Loading Speed», в которой он рассматривает, как сжатие, обфускация и архивирование влияет на производительность наиболее распространенных на данный момент JavaScript-библиотек. Мои комментарии даны курсивом.

Опубликована: 5 февраля 2008

Введение

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

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