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

Примечание: ниже перевод статьи 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 Expression Optimization», в которой автор немного освещает использование и проблематику динамических свойств в CSS (aka CSS expressions). Также автор предлагает способ их оптимизации (исполнение один-единственный раз вместо постоянного выполнения). Далее приведены несколько тезисов с ClientSide'2007 по заявленной тематике. Мои комментарии даны курсивом.

CSS expressions были впервые представлены в Internet Explorer 5.0, который позволял назначать JavaScript-выражение в качестве CSS-свойства. Например, следующий код позволит разместить элемент в зависимости от того, какого размера окно браузера.

#myDiv {
   position:   absolute;
   width:      100px;
   height:     100px;
   left:       expression(document.body.offsetWidth  - 110 + "px");
   top:        expression(document.body.offsetHeight - 110 + "px");
   background: red;
}

Не самый лучший способ решения поставленной задачи, но в качестве примера его достаточно.

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

Примечание: ниже находится перевод статьи «Client Side Load Balancing for Web 2.0 Applications», в которой затрагиваются вопросы балансировки нагрузки между несколькими серверами и рассматривается решение, обеспечивающее балансировку такой нагрузки прямо на компьютере клиента.

Сервер обрабатывает HTTP (HyperText Transfer Protocol) запросы со стороны браузеров. Если вы введете в адресной строке URL, например, www.digital-web.com, то ваш компьютер отправит поисковый запрос для определения, какие именно сервера будут обрабатывать ваш запрос и пересылать данные. Техника обработки таких запросов для кластера веб-серверов называется балансировкой нагрузки.

Балансировка нагрузки для веб-приложений

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

• Распределять нагрузку внутри кластера рабочих серверов.
• Корректно обрабатывать отказ одного из рабочих серверов.
• Весь кластер должен существовать для конечного пользователя как одна-единственная машина.

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

Примечание: ниже представлен перевод двух последовательных статей «The window.onload Problem — Solved!» и «window.onload (again)», посвященных оптимизации исполнению скриптов при загрузке страницы, эта проблема была предварительно затронута в статье: «Как JavaScript тормозит Веб (и что с этим делать)?»

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

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

Примечание: ниже перевод статьи «Event delegation without a JavaScript library», посвященной обзору методов по назначению обработчиков событий в JavaScript и их возможной оптимизации, она дополнена моими комментариями и практической частью.

Большинство статей и примеров, которые я видел в последнее время по переопределению событий, основывались на какой-либо распространенной библиотеке. Например, в своей хорошо известной статье Chris Heilmann применяет YUI-библиотеку, а в прошлом месяце Dan Webb в своей презентации на media использовал prototype.

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

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

Примечание: ниже перевод статьи «Presentation Layer Performance Tuning», в которой затрагиваются основные аспекты оптимизации загрузки веб-приложений и предлагаются некоторые практические советы.

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

Эти процессы, однако, только частично затрагивают то время, которое клиент тратит на ожидание загрузки страницы в окне своего браузера. Большая часть времени тратится на загрузку, кеширование и отображение JavaScript, CSS и картинок (прим.: не-HTML файлов). Оптимизация производительности уровня представления (presentation layer) веб-приложений, на самом деле, сводится к двум простых условиям:

• Меньше данных
• Меньше запросов

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

Примечание: ниже находится перевод двух близких статей («Delay loading your print CSS» и «JS includes — the saga continues…») по оптимизации загрузки страницы при наличии нескольких файлов стилей или скриптов.

У вас есть два вызова CSS-файлов на странице, например:

<link type="text/css" rel="stylesheet" href="screen.css"
      media="screen" />
<link type="text/css" rel="stylesheet" href="print.css"
      media="print" />

где первый используется для отображения страницы на экране монитора, а второй — для предварительного просмотра и печати. Замечательно.

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

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

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

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