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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание: ниже находится перевод статьи Understanding and Solving Internet Explorer Leak Patterns", в которой автор рассматривает некоторые характерные случаи утечек памяти в IE и предлагает методы для их избежания и устранения. Рассмотренные проблемы не являются чем-то новым или революционным, однако, знать об их существовании должен любой уважающий себя программист клиентских интерфейсов. Мои комментарии далее курсивом.

Опубликована: июнь 2005

Развитие веб-разработок

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

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

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

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

Примечание: ниже перевод статьи Dean Edwards «Optimising Performance» с советами по написанию CSS-кода для Internet Explorer'а, который будет быстрее отрабатывать на клиенте. Мои комментарии далее курсивом.

При первоначальном поиске информации по теме удалось только наткнуться на советы от разработчиков Firefox, однако, последняя редакция датирована 2000 годом, да и сами советы несколько противоречивы. Если кто-то может поделиться информацией по теме, сделайте это, пожалуйста, в комментариях.

Есть несколько приемов, с помощью которых можно Увеличить производительность IE7 на вашем сайте. Они перечислены в порядке убывания важности, если можно так сказать.

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

Ниже перевод статьи «Optimizing Page Load Time», в которой автор математически рассчитывает оптимальный размер файлов для эффективной передачи при веб-запросах, рассматривает некоторые прикладные вопросы оптимизации загрузки страницы с учетом особенностей браузеров, а также дает несколько развернутых и ценных советов. Мои комментарии далее курсивом.

Существует распространенное мнение, что быстро загружающая страница положительно влияет на впечатление пользователя (improve the user experience). В последние годы многие сайты начали использовать для этой цели технологию AJAX, чтобы уменьшить время ожидания (при загрузке данных). Вместо того, что запрашивать с сервера новую страницу полностью при каждом клике, браузер часто можно либо поменять вид самой страницы (отобразив или скрыв какие-либо блоки), либо подгрузить небольшую порцию HTML-, XML- или JavaScript-кода и внести изменения на существующую страницу. В любом случае, это значительно уменьшает время, проходящее между кликом пользователя и окончанием визуализации браузером нового содержания.

Что влияет на загрузку страницы?

Однако, для большинства сайтов, загрузка страницы затрагивает десятки внешних объектов, основное время загрузки тратится на различные HTTP-запросы картинок, JavaScript-файлов и файлов стилей. AJAX, возможно, поможет в данной ситуации, но ускорение или удаление этих HTTP-запросов может принести гораздо больше пользы, хотя на данный момент нет единого мнения (a common body of knowledge), как именно это следует делать.

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

Примерно три недели назад стартовал проект, посвященный методам оптимизации времени загрузки веб-страницы на клиенте.

Почему оптимизация?

На мой взгляд, на текущий момент веб-разработчики очень мало уделяют внимания доступности (accessibility) и удобству пользования (usability) проектов, над которыми работают. Для них сайт — это килобайты кода и пара картинок, которые нужно как-то показать клиенту. О пользователе никто при этом не думает, в лучшем случае, прикрываясь такими выражениями, как: «у меня отсюда и так все быстро грузится» или «каналы сейчас не те, что 10 лет назад».

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

Почему клиентской части?

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

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

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

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



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

Примечание: ниже приведен перевод заметки из блога разработчика YUI-утилит Julien Lecomte «Running CPU Intensive JavaScript Computations in a Web Browser», в которой автор рассматривает выполнение «тяжелых» вычислений в веб-браузере и приводят ряд методов для их «оптимизации». Мои комментарии даны курсивом.

Введение

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

Наиболее существенным препятствием для выполнения в веб-браузере «тяжелых» вычислений является тот факт, что весь интерфейс пользователя в браузере останавливается и ждет окончания исполнения JavaScript-кода. Это означает, что ни при каких условиях нельзя допускать того, чтобы для завершения работы скрипта требовалось более 300 мс (а лучше, если горадо меньше). Нарушение этого правила неминуемо ведет к плохому восприятию ресурса пользователем (bad user experience).

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

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

После публикации статьи на тему архивирования JS/CSS-файлов для последующей выдачи клиенту, я задумался на тему, какой же метод минимизации (minify) следует использовать. В докладе на конференции ClientSide'2007 не удалось установить четкого критерия, чем и как лучше всего сжимать JavaScript-файлы. Данная заметка посвящена рассмотрению как раз этой проблемы.

Задача

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

• Имеет ли смысл пользоваться каким-либо минимизатором JS-кода?
• Есть ли среди них универсальное средство, показывающее лучшие результаты в подавляющем большинстве случаев?
• Если такого средства нет, то каковы критерии использования набора инструментов?

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

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

Сейчас уже много где написано и упомянуто про технику CSS sprites (aka CSS Image Maps). Я не буду открывать Америку и рассказывать о ней дотошно еще раз, а просто хочу привести несколько примеров и полезных ссылок. И пару советов из собственной практики.

Сама техника заключается в том, что мы создаем комбинированное изображение, из которого затем «вырезаем» с помощью свойств background-position нужный нам в данном случае кусок. На текущем уровне поддержки браузерами (я полагаю, что 99,9%) оно является просто must-have для любого уважающего себя интернет-ресурса (ибо позволяет сократить число запросов к серверу, отделить поведение от представления, возложить труд по анимации на CSS-движок браузера, а не на JS-движок, т.е. это будет работать даже с выключенными скриптами, и много-много прочих «вкусностей»). Но обо всем по порядку. Поехали.

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

Примечание: ниже частичный перевод статьи «Compress JavaScript and CSS without touching your application code», в которой описывается статичное сжатие CSS- и JS-файлов на сервере и корректная выдача их затем клиенту. Далее даны мои комментарии с более комплексным решением. Приношу извинения, если для кого-то тема будет слишком знакома или неинтересна: в Рунете нормальной статьи на данную конкретную тематику обнаружить не удалось.

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

• Проверить, умеет ли клиент принимать файлы в формате gzip-encoded.
• Обеспечить соответствующий вывод на стороне сервера через gzip-функции, либо уповать на то, что всем этим займется непосредственно Apache.
• Поиграться с .htaccess, чтобы обеспечить корректный content type.

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

Примечание: ниже перевод статьи «How JavaScript is Slowing Down the Web (And What To Do About It)», посвященной, в основном, работе с виджетами: характерные проблемы и методы их решения.

Одна строка JavаScript является основой большинства текущих технологий, которые используют авторы блогов. Виджеты, средства (фото-/видео-)обмена, отслеживание посетителей, рекламные объявления. Во многих случаях единственная строка JavaScript — это все, что нужно автору, чтобы добавить в своей блог что-то новенькое. Проблемы начинаются тогда, когда много-много этих самых строчек собирается вместе...

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