tl;dr – Как сделать профессиональный высокопроизводительный сайт на DocPad

• Используйте плагин docpad-plugin-menu для автоматической генерации меню сайта.
• Используйте grunt-frontend и docpad-plugin-frontend для сборки CSS и JS ресурсов и правильного кэширования.
• Создайте специальное debug-окружение для плагина docpad-plugin-frontend для поиска проблем в исходниках CSS и JS, а не их минифицированных версиях.
• Настройте веб-хуки на GitHub и Gith на сервере для автоматической сборки сайта после каждого коммита.
• Настройке nginx для правильного кэширования статических файлов и экономии ресурсов процессора.

DocPad — это генератор статических сайтов, написанный на CoffeeScript. В отличие от сайтов, созданных с использованием обычных CMS вроде Django, Drupal и WordPress, статические сайты потребляют минимальное количество серверных ресурсов, так как представляют собой набор заранее сгенерированных обычных HTML-файлов. То есть кроме обычного веб-сервера вроде nginx или Apache для работы сайта ничего не нужно.

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

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

• docpad-plugin-menu — автоматическая генерация меню для сайта.
• grunt-frontend — «умная» сборка CSS и JS файлов.
• docpad-plugin-frontend – вывод собранных с помощью grunt-frontend CSS и JS файлов с учётом правильного кэширования, а также управление наборами файлов между шаблонами.

Если вы ещё не знакомы с DocPad, рекомендую вам посмотреть и прочитать Введение в DocPad, чтобы вы представляли, о чём в дальнейшем пойдёт речь.

Генерация меню

Плагин docpad-plugin-menu умеет геренировать структурированное меню для всех страниц сайта (то есть для всех файлов из папки src/documents). Этот плагин добавляет метод generateMenu(url) в объект templateData, в контексте которого отрисовываются все шаблоны проекта. На вход этот метод принимает URL страницы, относительно которого нужно создать меню, на выходе вы получите структуру разделов сайта, которую удобно отрисовывать, например, с помощью partials.

Подробнее о возможностях плагина и примерах его использования читайте на основной странице проекта.

Сборка фронт-энд ресурсов

Для удобства разработки я разбиваю CSS и JS файлы на отдельные модули, которые затем склеиваются и минифицируются – это стандартная практика высокопроизводительных сайтов. Для сборки я использую Grunt.js в котором, казалось бы, уже есть все необходимые инструменты для выполнения этих задач.

Но и тут я не нашёл ничего подходящего. Дело в том, что мне важна дата последнего обновления минифицированного файла, потому что я хочу её подставлять в URL файла для эффективного сброса кэша. Поэтому обновлять конечный файл нужно только тогда, когда поменялся один исходных файлов.

Для решения этой задачи я написал свой сборщик: grunt-frontend. Работает он следующим образом. Во время конкатенации и минификации нескольких файлов в один он записывает структуру исходных файлов и их md5-отпечаток в специальный файл .build-catalog.json. При следующей сборке плагин смотрит на структуру и содержимое исходных файлов: если ничего не поменялось, то и конечный файл не минифицируется и не обновляется.

Это не только сокращает время сборки, но и позволяет сохранить такие важные данные конечного файла как дату обновления и md5-отпечаток. Все эти данные хранятся в .build-catalog.json, его желательно хранить вне версионного контроля.

Для минификации используются библиотеки CSSO (с автоматическим инлайнингом всех подключённых через @import файлов) и UglifyJS.

Подробнее об использовании grunt-frontend.

Управление CSS и JS ресурсами

Очень часто возникает необходимость управлять подключением CSS и JS файлов на различных страницах сайта. Скажем, на всех страницах нужно использовать набор файлов set1; для всех внутренних страниц раздела /about/ нужно дополнительно использовать set2 и set3, но для страницы /about/contacts/ вместо set2 нужно использовать set4 (то есть set1, set4, set3, именно в таком порядке). Кроме того, в URL всех ресурсов нужно подставлять дату модификации файла чтобы эффективно сбрасывать кэш.

Для решения этих задач был написан плагин docpad-plugin-frontend. Он добавляет метод assets(prefix), который позволяет доставать отсортированный список ресурсов из текущего документа и всей цепочки шаблонов, применяемых к документу. Если в корневой папке проекта существует файл .build-catalog.json, то плагин считывает его и возвращает список ресурсов с префиксом в виде даты модификации файла.

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

---
js: "/js/fileA.js"
---

В шаблоне about.html.eco, который наследуется от основного шаблона и применяется ко всем документам /about/*, указываем следующие данные:

---
layout: default
js2: ["/js/fileB.js", "/js/fileC.js"]
js3: ["/js/fileD.js", "/js/fileE.js"]
---

В документе /about/contacts/index.html перекрываем набор js2:

---
layout: about
js2: "/js/contacts.js"
---

Теперь, при рендеринге страницы /about/contacts/index.html, вызов assets('js') вернёт следующий набор файлов:

• /js/fileA.js
• /js/contacts.js
• /js/fileD.js
• /js/fileE.js

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

Более подробную информацию о возможностях плагина и примерах использования читайте на главной странице репозитория.

Режим отладки

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

В будущем эти проблемы можно будет находить с помощью Source Maps, но сейчас далеко не все минификаторы и браузеры их поддерживают.

В плагине docpad-plugin-frontend есть специальный режим отладки. Так как структура всех минифицированных файлов хранится в JSON-каталоге, нам не составит труда при необходимости вывести список исходных файлов вместо скомпилированного.

Для этого в DocPad я создаю отдельное окружение, в котором указываю опцию frontendDebug: true. Если опция frontendDebug равна true, то метод assets() плагина docpad-plugin-frontend будет по возможности возвращать список исходных файлов вместо минифицированных. Пример настройки docpad.coffee:

module.exports = {
    …
    environments:
        debug:
            frontendDebug: true
}

Теперь при запуске DocPad в окружением debug, вы получите HTML-страницы с исходными CSS и JS файлами и сможете легко найти ошибку:

docpad run --env=debug

Автоматический деплой с GitHub

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

Со стороны GitHub я использовал обычный “WebHook”, а на стороне сервера – Gith.

Gith – это удобный веб-сервер для Node.JS, который умеет принимать и фильтровать данные веб-хуков GitHub. Мой сервер, который запускает сборку сайта, выглядит следующим образом:

var childProc = require('child_process');
var path = require('path');

var gith = require('gith').create(3000);

gith({
    // Слушаем хуки только для ветки "master"
    branch: 'master'
}).on('all', function(payload) {
    console.log('Run deply script on', new Date());

    // Запускаем скрипт сборки сайта
    var deploy = childProc.spawn('sh', ['/web/deploy.sh']);

    deploy.stdout.on('data', function(data) {
        var message = data.toString('utf8');

        if (~message.indexOf('subscribe')) {
            // Docpad может спросить про подписку на рассылку, откажемся
            deploy.stdin.write('n');
        } else if (~message.toLowerCase().indexOf('privacy')) {
            // Docpad может спросить про политику безопасности, согласимся
            deploy.stdin.write('y');
        }
    });

    deploy.stderr.on('data', function(data) {
        console.log('Error: ', data.toString('utf8'));
    });

    deploy.on('exit', function(code) {
        console.log('Deploy complete with exit code ' + code);
    });
});

Сам скрипт сборки проекта deploy.sh выглядит следующим образом:

#! /usr/bin/env bash
git pull
git submodule foreach 'git checkout master && git pull origin master'
npm install
grunt
docpad generate
find ./out -type f ( -name '*.html' -o -name '*.css' -o -name '*.js' )  -exec sh -c "gzip -7 -f < {} > {}.gz" ;

Настройка nginx

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

• Прописать рерайты для статических файлов: отсекать дату модификации в начале пути и посылать правильные кэширующие заголовки.
• Отдавать статику в gzip для снижения объёма передаваемых файлов.

Если посмотреть на скрипт deploy.sh, то вы увидите, что в последнем шаге создаются gzip-версии всех HTML, CSS и JS файлов. У nginx есть специальный модуль HttpGzipStaticModule, который может отдавать заранее созданные gzip-версии файлов вместо автоматической генерации для каждого запроса. Этот трюк позволит нам сэкономить процессорные ресурсы. Для того, чтобы воспользоваться этим модулем, его нужно добавить в nginx при компиляции:

./configure --with-http_gzip_static_module

Мой конфиг nginx выглядит так:

server {
    server_name  your-server.com;
    root         /path/to/web-site/out;

    index  index.html index.htm;

    # отсекаем дату модификации со статических ресурсов
    location ~* ^/d+/(css|js)/ {
        rewrite ^/(d+)/(.*)$ /$2;
    }

    # кэшируем всю статику
    location ~* .(ico|css|js|gif|jpe?g|png)$ {
        expires max;
        access_log off;
        add_header Pragma public;
        add_header Cache-Control "public";
    }

    # включаем поддержку статических gzip-версий файлов
    gzip_static on;
}

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

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

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

• Запись качественного ролика требует слишком много времени. Например, на создание шестиминутного ролика про Zen Coding v0.5 у меня ушло около четырёх часов.
• Видео довольно сложно обновлять. Например, если обнаружится ошибка или пользователям будет не понятно, как работает какое-то действие, скорее всего, понадобится ещё несколько часов на перезапись ролика.
• Так как сам Emmet написан на чистом JS (а значит работает в браузерах), хотелось, чтобы пользователи не только смотрели, как работает Emmet, но и пробовали его в действии прямо на страницах документации.

Для решения этих и многих других проблем и был создан CodeMirror Movie. Принцип его работы довольно прост: вы создаёте небольшой сценарий, в котором указываете, что нужно сделать, например, написать текст, немного подождать, а потом показать всплывающую подсказку.

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

Создание презентации

Как правило, для создания экземпляра редактора CodeMirror вы создаёте элемент <textarea> с начальным содержимым редактора и вызываете следующий JS-код:

var myCodeMirror = CodeMirror.fromTextArea(myTextArea);

Создать презентацию так же легко: вы создаёте <textarea> с начальным содержимым редактора и дописываете туда сценарий презентации, разделив эти секции строкой @@@:

<textarea id="code">
&lt;div class="content"&gt;
    |
&lt;/div&gt;
@@@
type: Hello world
wait: 1000
tooltip: Sample tooltip
</textarea>

Для инициализации ролика нужно вызвать метод CodeMirror.movie(), передав первым параметром ID элемента <textarea> или сам элемент:

var movie = CodeMirror.movie('code');

// начинаем воспроизведение
movie.play();

Сценарий презентации

Как было отмечено выше, для создания презентации вам нужно написать её сценарий.

Сценарий представляет собой список команд, которые нужно выполнить. Каждая команда пишется на отдельной строке в виде название: значение. В качестве значения записывается JS-объект с параметрами команды, однако каждая команда имеет довольно неплохие базовые значения, поэтому достаточно передать всего лишь значение самого главного параметра. Например, вот как выглядит сценарий ролика, который должен набрать «Hello world», а через секунду после завершения набора показать всплывающую подсказку с текстом «Movie tooltip»:

type: Hello world
wait: 1000
tooltip: Movie tooltip

Более подробную информацию о всех командах и примеры использования можно найти на странице плагина. Сам плагин вы можете использовать как угодно (лицензия MIT), особенно хорошо он будет смотреться в JS-движках презентаций вроде impress.js или reveal.js. Надеюсь, вам понравится!

Что поменялось со времён Zen Coding?

Во-первых, поменялось название. Emmet будет брэндом для новых инструментов и не все они будут связаны с написанием кода (coding).

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

В-третьих, улучшилась работа с CSS: значения свойств можно писать прямо в аббревиатуре. Также был учтён опыт и пожелания пользователей: благодаря модулю нечётного поиска вам необязательно запоминать громоздкие названия аббревиатур, достаточно написать всего несколько символов (например, ov:h == ov-h == o-h == oh == overflow: hidden);

Вот список остальных значимых изменений:

• Полностью переписан код проекта. Он стал более модульным и расширяемым.
• Отказ от Python-версии. Мне было довольно сложно поддерживать две версии ядра. Вместо отдельной версии теперь используются мосты на Python, Objective-C и Java, это позволит править баги и добавлять новые возможности очень быстро и сразу на все платформы.
• Улучшен модуль определения неявных имён тэгов. Ранее, если вы пытались развернуть аббревиатуру вроде .item, то в результате могли получить либо <div class="item">, либо <span class="item">, в зависимости от типа родительского тэга. Теперь модуль смотрит на название тэга и может вывести, например, <li>, <td>, <option>.
• Поддержка расширений. Теперь, чтобы добавить новую аббревиатуру или настроить вывод результата, не надо лезть в код плагина, достаточно создать несколько простых JSON-файлов в специальной папке.
• Генератор «Lorem Ipsum». Ранее, чтобы получить «рыбный» текст для сайта, надо было пользоваться сторонними ресурсами, а затем форматировать результат. Теперь получить такой текст можно прямо в редакторе, причём количество слов в тексте можно регулировать просто дописав число после аббревиатуры. Более того, генератор использует все возможности аббревиатур Emmet, позволяя дописывать нужные атрибуты к генерируемым элементам и регулировать количество создаваемых блоков.
• Новый оператор ^. Несмотря на то, что в Emmet/Zen Coding довольно давно существует более мощный инструмент в виде группировки элементов, зачастую осознание того, что следующий элемент в аббревиатуре должен находится уровнем выше, приходит довольно поздно. Пользователям приходилось возвращаться обратно, добавлять скобки и дописывать нужный элемент. Теперь достаточно написать оператор ^, чтобы подняться на уровень выше, причём можно использовать несколько операторов подряд.

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

Дизайнер очень хорошо постарался: страница выглядит очень красиво и современно. Осталось только перенести всё эту красоту из фотошопа в веб.

Центральный элемент страницы — сцена, на которой показываются новинки нашего каталога. На фоне сцены находится очень большая картинка с кулисами. Если присмотреться, то эти кулисы покрыты лёгким шумом, что придаёт им особый колорит:

Однако вся эта красота на проверку оказалась очень тяжёлой: в одной картинке объединилось всё худшее, что плохо влияет на сжатие. Это и красный цвет (даёт очень сильные артефакты сжатия в JPEG), и мелкий шум (сильные артефакты в JPEG; плохо упаковывается в PNG). Приемлемое качество картинки было достигнуто при размере в 330 КБ, что, на мой взгляд, довольно много для одной картинки. Очень хочется, чтобы главная страница загружалась как можно быстрее. Поэтому я решился на один эксперимент.

Изучаем картинку

При детальном изучении картинки можно заменить, что состоит из двух слоёв: собственно, сама сцена с кулисами и слой с шумом. Но шум — это процедурная текстура, которую можно легко сгенерировать прямо в браузере пользователя с помощью canvas. Тогда я смогу отдавать пользователю только базовую картинку, которая очень хорошо сжимается за счёт плавных цветовых переходов.

Простой алгоритм монохромного шума выглядит так:

var canvas = document.createElement('canvas');
canvas.width = canvas.height = 200;
var ctx = canvas.getContext('2d');

// получаем все пиксели изображения
var imageData = ctx.getImageData(0, 0, canvas.width, canvas.height);
var pixels = imageData.data;

for (var i = 0, il = pixels.length; i < il; i += 4) {
	var color = Math.round(Math.random() * 255);
	// так как шум монохромный, в каналы R, G и B кладём одно и то же значение
	pixels[i] = pixels[i + 1] = pixels[i + 2] = color;

	// делаем пиксель непрозрачным
	pixels[i + 3] = 255;
}

// записываем пиксели обратно на холст
ctx.putImageData(imageData, 0, 0);

document.body.appendChild(canvas);

Получим вот такой результат:

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

Режимы наложения

Каждый, кто работал с фотошопом и другими продвинутыми графическими редакторами, знает, что такое режимы наложения слоёв:

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

(colorA * colorB) / 255

То есть просто умножаем два цвета и делим результат на 255 (отсюда и название Multiply: «умножение»).

Доработаем нашу функцию: загрузим картинку, сгенерируем шум и наложим его в режиме Multiply:

// Загружаем картинку. Обязательно ждём, пока она полностью загрузится
var img = new Image;
img.onload = function() {
	addNoise(img);
};
img.src = "stage-bg.jpg";


function addNoise(img) {
	var canvas = document.createElement('canvas');
	canvas.width = img.width;
	canvas.height = img.height;

	var ctx = canvas.getContext('2d');

	// нарисуем картинку на холсте, чтобы получить её пиксели
	ctx.drawImage(img, 0, 0);

	// получаем все пиксели изображения
	var imageData = ctx.getImageData(0, 0, canvas.width, canvas.height);
	var pixels = imageData.data;

	for (var i = 0, il = pixels.length; i < il; i += 4) {
		// генерируем пиксель «шума»
		var color = Math.random() * 255;

		// накладываем пиксель шума в режиме multiply на каждый канал
		pixels[i] = pixels[i] * color / 255;
		pixels[i + 1] = pixels[i + 1] * color / 255;
		pixels[i + 2] = pixels[i + 2] * color / 255;
	}

	ctx.putImageData(imageData, 0, 0);
	document.body.appendChild(canvas);
}

Получим что-то типа этого:

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

Альфа-композиция

Процесс смешивание двух цветов с учётом прозрачности называется «альфа-композиция». В простейшем варианте алгоритм смешивания выглядит так:

colorA * alpha + colorB * (1 - alpha)

где alpha — это коэффициент смешивания (прозрачность) от 0 до 1. В данном случае важно правильно выбрать, что будет фоновым изображением (colorB), а что будет накладываемым (colorA). В нашем случае фоновой будет сцена, а шум — накладываемым.

Добавим в функцию addColor() дополнительный параметр alpha и модифицируем сам алгоритм с учётом альфа-композиции:

var img = new Image;
img.onload = function() {
	addNoise(img, 0.4);
};
img.src = "stage-bg.jpg";


function addNoise(img, alpha) {
	var canvas = document.createElement('canvas');
	canvas.width = img.width;
	canvas.height = img.height;

	var ctx = canvas.getContext('2d');
	ctx.drawImage(img, 0, 0);

	var imageData = ctx.getImageData(0, 0, canvas.width, canvas.height);
	var pixels = imageData.data, r, g, b;

	for (var i = 0, il = pixels.length; i < il; i += 4) {
		// генерируем пиксель «шума»
		var color = Math.random() * 255;

		// высчитываем итоговый цвет в режиме multiply без альфа-композиции
		r = pixels[i] * color / 255;
		g = pixels[i + 1] * color / 255;
		b = pixels[i + 2] * color / 255;

		// альфа-композиция
		pixels[i] =     r * alpha + pixels[i] * (1 - alpha);
		pixels[i + 1] = g * alpha + pixels[i + 1] * (1 - alpha);
		pixels[i + 2] = b * alpha + pixels[i + 2] * (1 - alpha);
	}

	ctx.putImageData(imageData, 0, 0);
	document.body.appendChild(canvas);
}

Получаем именно то, что нам нужно: слой шума, наложенный на картинку в режиме Multiply и прозрачностью 20%:

Оптимизация

У меня картинка генерируется примерно за 400 мс, что довольно заметно. Поэтому мы оптимизируем код, чтобы он работал быстрее.

Размер моей картинки 1293×897 пикселей, что в итоге даёт 1 159 821 итераций цикла. Это довольно много, поэтому в первую очередь нужно оптимизировать операции вычисления, а именно убрать ненужные и повторяющиеся операции.

Например, в цикле три раза высчитывается значение 1 - alpha, хотя это постоянное значение для всей функции, поэтому делаем новую переменную за пределами цикла:

var alpha1 = 1 - alpha;

Далее, при генерации пикселя шума используется формула Math.random() * 255, однако дальше мы делим этот цвет на 255: r = pixels[i] * color / 255. Соответственно, умножение и деление на 255 можно смело убирать.

Эти простые операции снизили время выполнения скрипта с 400 мс до 300 мс (-25%).

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

var origR = pixels[i],
	origG = pixels[i + 1],
	origB = pixels[i + 2];

Это экономит ещё около 40 мс.

С учётом всех оптимизаций функция addNoise() выглядит вот так:

function addNoise(img, alpha) {
	var canvas = document.createElement('canvas');
	canvas.width = img.width;
	canvas.height = img.height;

	var ctx = canvas.getContext('2d');
	ctx.drawImage(img, 0, 0);

	var imageData = ctx.getImageData(0, 0, canvas.width, canvas.height);
	var pixels = imageData.data, r, g, b, origR, origG, origB;
	var alpha1 = 1 - alpha

	for (var i = 0, il = pixels.length; i < il; i += 4) {
		// генерируем пиксель «шума»
		var color = Math.random();

		origR = pixels[i];
		origG = pixels[i + 1];
		origB = pixels[i + 2];

		// высчитываем итоговый цвет в режиме multiply без альфа-композиции
		r = origR * color;
		g = origG * color;
		b = origB * color;

		// альфа-композиция
		pixels[i] =     r * alpha + origR * alpha1;
		pixels[i + 1] = g * alpha + origG * alpha1;
		pixels[i + 2] = b * alpha + origB * alpha1;
	}

	ctx.putImageData(imageData, 0, 0);
	document.body.appendChild(canvas);
}

Скорость выполнения скрипта — около 170 мс (было 400 мс), что довольно неплохо.

Ещё больше оптимизаций

Внимательный читатель мог заметить, что картинка с кулисами — красная. То есть информация об изображении присутствует только в красном канале, в синем и зелёном её нет. Если её нет, зачем делать вычисления для этих каналов? Поэтому оставляем расчёты только для красного канала: конкретно в моём случае это даст аналогичный результат, а время выполнения снизит до 80 мс:

for (var i = 0, il = pixels.length; i < il; i += 4) {
	origR = pixels[i];
	pixels[i] = origR * Math.random() * alpha + origR * alpha1;
}

Добавлено: читатель @Sergeyev указал, что можно ещё сократить время выполнения скрипта (-20%), убрав ненужные операции:

for (var i = 0, il = pixels.length; i < il; i += 4) {
	pixels[i] = pixels[i] * (Math.random() * alpha + alpha1);
}

Результат

Результат получился довольно неплохим:

• Вес изображения снизился с 330 КБ до 70 КБ + 1 КБ пожатого JS-кода. На самом деле, картинку можно было бы ещё больше ужать, потому что слой с шумом скроет большинство артефактов JPEG-сжатия.
• Такая оптимизация соответствует практикам progressive enhancement: пользователи с браузерами, в которых нет canvas (например, IE6) или отключён JS всё равно получат картинку, но менее детализированную.

Единственный минус, который я вижу — это выполнение наложения каждый раз при загрузке страницы, в то время как обычная картинка может быть просто закэширована браузером. Но, во-первых, время выполнения наложения довольно низкое (80 мс), а во-вторых, как вариант, результат можно хранить в localStorage в виде data:url и при следующей загрузке страницы доставать из кэша. Но моя картинка занимает более 1 МБ, так что я не стал сохранять её — доступное пространство можно и нужно использовать с большей пользой.

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

Добавлено: некоторые читатели и Денис в частности справедливо заметил в комментариях, что практически идентичного результата можно добиться наложением слоя с шумом поверх картинки. Тут скорее речь идёт о не совсем удачном примере, выбранном для статьи, нежели о неправильности подхода в целом.

В JSDT меня больше всего привлекло следующее:

• Рефакторинг: переименование объектов, выделение блока в отдельную переменную, объединение определения переменной и присваивания и т.д. Некоторые вещи вроде выделения в метод пока толком не работают, но, надеюсь, в ближайшее время это будет исправлено.
• Валидация кода. Помимо обычной проверки синтаксиса, можно настроить более сложные проверки вроде поиска неиспользованных переменных, недостижимый код, переопределение переменной из внешней области видимости и т.д.
• Выделение фрагментов camelCase-переменных с помощью Shift+Alt+← и Shift+Alt+→
• Поддержка JSDoc.
• Удобный Outline/Quick outline; дополнительные окна, в которых показывается документация и код определения текущего объекта.
• Автоматическая отбивка кода при его перемещении из/в блок.
• Подключение внешних библиотек.
• Встроенный дебаггер.

Лучше всего будет, если читатель поставит Eclipse for JavaScript Web Developers и изучит все настройки и менюшки — в том числе контекстные — JSDT (лучше включить перспективу JavaScript), потому что возможностей действительно очень много и их сложно описать в одной статье.

Однако при всей «крутости» этой среды разработки, в ней есть ряд проблем, с которыми пришлось столкнуться прежде, чем окончательно перейти на JSDT.

Начинаем работу

Для того, чтобы полноценно использовать все возможности JSDT, обязательно нужно создать проект с JavaScript-природой. Делается очень легко: вызываем File > New > Project… и в появившемся окошке выбираем JavaScript Project. В появившемся диалоговом окне вводим название проекта и жмём Finish. По умолчанию создаётся веб-проект с поддержкой DOM, папкой с JS-исходниками является сам проект. Когда вы лучше освоитесь с JSDT, то сможете более тонко настраивать проект: указывать подключаемые библиотеки, исключать ненужные файлы и папки из индекса. Пока оставим как есть.

Module pattern

Главным преимуществом для меня в Spket IDE была поддержка современных паттернов, в том числе и модуля:

var module = (function() {
	return {
		method: function() {}
	};
})();

В Spket такая конструкция без проблем отображается в outline и по ней работает code complete, но в JSDT ни то, ни другое не работает:

Небольшой JSDoc исправит ситуацию:

/**
 * @type module
 */
var module = (function() {
	return {
		/**
		 * @memberOf module
		 */
		method: function() {}
	};
})();

Теперь работает как надо:

Но есть ещё одна проблема: приватные переменные и методы модуля не отображаются в Outline, а очень хотелось бы. Это можно исправить, описав самовызывающуюся функцию как конструктор несуществующего класса:

/**
 * @memberOf __module
 * @type module
 */
var module = (/** @constructor */ function() {

	function myPrivateMethod() {

	}

	return {
		/**
		 * @memberOf module
		 */
		method: function() {}
	};
})();

Как видно из примера, я описал несуществующий класс __module, двойное подчёркивание я использую в качестве своеобразного соглашения об именовании объектов. Проблема в том, что этот несуществующий класс попадёт в code complete всего проекта, и использование двойного подчёркивания — простой и понятный способ отфильтровать ненужные данные при вызове code complete. Однако этот недостаток очень легко можно превратить в достоинство: таким образом можно описывать структуры объектов, доступ к описанию которых затруднён из-за отсутствия строгой типизации в JS:

Поддержка популярных библиотек

Базовый набор библиотек для JSDT довольно невелик: это стандартные объекты JavaScript (Array, String и прочее) и стандартный DOM (HTMLElement, document и так далее). То есть если мы напишем, например, document. и вызовем code complete, то увидем список свойств и методов объекта document, экземпляра класса Document. Но современная веб-разработка немыслима без использования популярных библиотек вроде jQuery.

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

jsdt-docs — JSDoc для популярных библиотек

В этом проекте сейчас есть следующие библиотеки:

• Modernizr 2
• Browser Addons — разные методы и свойства, которые почему-то отсутствуют в стандартном описании DOM в JSDT.
• console — небольшое описание объекта console, который присутствует в современных браузерах.
• CSS2Properties — список CSS-свойств для свойства style DOM-элементов. Несмотря на то, что он называется CSS2, в нём присутствуют и CSS3-свойства: такое название выбрано потому, что в стандартном описании Element.prototype.style является объектом класса CSS2Properties.
• JS SIgnals
• Node.JS
• Socket.IO
• Underscore.js.
• Zepto.js

Добавить библиотеку довольно просто:

1. Идём в настройки: Preferences > JavaScript > Include Path > User Libraries.
2. Создаём новую библиотеку: нажимаем кнопку New…
3. Вводим название библиотеки в появившемся окне и жмём ОК.
4. Выделив только что добавленную библиотеку, нажимаем на кнопку Add .js file… и выбираем один или несколько файлов, относящихся к данной библиотеке.

После того, как библиотека была создана, нужно добавить её в проект:

1. Идём в настройки проекта: Project > Properties > JavaScript > Include Path > Libraries.
2. Жмём кнопку Add JavaScript Library, выбираем User Library, а затем и библиотеки, которые хотим добавить.

Теперь у вас в проекте будет работать code complete для указанных библиотек:

Поддержка jQuery

Добавление поддержки своего любимого фреймворка оказалась не такой уж и простой задачей. Во-первых, он довольно большой и содержит внушительных объемов документацию. Во-вторых — многие методы в нём «перегружены»: например, val() возвращает текстовое значение поля, а val(str) — записывает его и возвращает уже jQuery-объект.

К счастью, у документации к jQuery есть публичный API, который выдаёт описание всех методов в XML. Я написал парсер на node.js, который опрашивает API и преобразует XML в JSDoc, понятный для JSDT (и, надеюсь, другим IDE). Так что в случае выхода новой версии jQuery можно быстро перегенерировать всё документацию. Парсер я писал для себя и по-простому, он не поддерживает передачу параметров через командную строку, всё настраивается в main.js:

• Можно сгенерировать документацию для определённой версии jQuery (TARGET_VERSION).
• Можно сгенерировать описание в виде нескольких файлов. Это связано с особенностью JSDT. Как уже отмечалось ранее, в jQuery много «перегруженных» методов, и если их описать в одном JS-файле, то JSDT будет использовать только одно (самое последнее) описание. Однако если сохранить описание методов с одинаковым названием в разных файлах, то JSDT вполне неплохо покажет по ним code complete и документацию. Так что у вас есть выбор: при создании библиотеки jQuery добавить все файлы вида jquery-jsdoc-N.js (Eclipse JSDT) или же только jquery-jsdoс.js если ваша IDE способна прочитать описание с перегруженными методами.
• Можно переписать некоторые определения для более удобной работы с code complete (class_map, prefix_map). Например, так переписываются описания для Deferred и Promise объектов, чтобы можно было использовать их описание в JSDoc:

В описании есть ряд классов, которые можно использовать в JSDoc: __jQueryDeferred, __jQueryPromise и __jQueryEvent.

Пишем плагины к jQuery

Собственно, как писать плагины рассказывать нет смысла, это подробно описано в документации. Покажу лишь как сделать так, чтобы ваш плагин появился в code complete. А сделать это очень просто, достаточно методу плагина указать, что он является членом класса jQuery:

jQuery.extend(jQuery.fn, {
	/** @memberOf jQuery */
	myPlugin: function() {

	}
});

$('div').m // тут можно вызвать code complete

Поддержка Node.JS

Отдельно стоит упомянуть Node.JS, так как к модулям нужно обращаться не напрямую, а через функцию require():

var http = require('http');
http.createServer(function() {

});

То есть подсказки для модуля должны зависеть от того, какой аргумент передали в функцию require(). В целом, в JSDT эта ситуация решаема: нужно написать отдельный плагин в виде подключаемой библиотеки, который будет находить вызовы функции require(), смотреть на аргумент и возвращать виртуальный объект с необходимыми методами, и может быть я когда-нибудь напишу такую библиотеку. А пока будем довольствоваться малым: указывать тип модуля через JSDoc.

Все модули в моей документации описаны в виде классов Node{Name}Module, например: http → NodeHttpModule, util → NodeUtilModule. Поэтому для переменной, в которую записывается модуль, указываем через JSDoc нужный тип:

/** @type NodeHttpModule */
var http = require('http');
http. // вызываем code complete

Советы

В качестве заключения дам несколько советов, которые помогут вам в работе с JSDT:

• Не используйте фигурные скобки при указании типа переменной с помощью тэга @type — в некоторых случаях JSDT не сможет подцепить тип переменной. Лучше писать так: @type Array (вместо @type {Array}).
• При описании модуля тэг @memberOf moduleName достаточно указать только у одного свойства/метода в литерале, все остальные подцепятся автоматически.
• Если у вас в проекте есть непосредственно код библиотек (например, jQuery), то его лучше исключать из индекса, чтобы он не мешал работе code complete. Делается это так: заходите в настройки проекта Project > Properties > JavaScript > Include Path > Source. Разворачиваете папку с исходниками, двойной клик по фильтру Excluded и в диалоговом окне в секцию Exclusion patterns добавляете файлы, которые надо исключить.

Самая главная проблема всех редакторов для веб-разработки: они пишутся людьми, которые этой самой веб-разработкой не занимаются. Нет, они [программисты], конечно, могут на досуге собрать в своём редакторе сайтик-другой, но что делать тем, кто занимается веб-разработкой профессионально? Выход я вижу только один: взять хорошую платформу и доработать её до нужного состояния.

Как я уже написал, Aptana превратилось в некого монстра, с избыточным для не-Rails технологам функционалом. Поэтому в качестве платформы я выбрал более простой и, главное, лучше интегрированный в IDE плагин — Eclipse Web Tools Project.

Eclipse Web Tools Project

Как можно понять из названия, Eclipse WTP — это инструменты для веб-разработки, а не законченный проект (как Aptana, например). Цель этого проекта: создать платформу, на основе которой можно создавать другие, узкоспециализированные инструменты. Этот проект включает в себя редакторы для CSS, HTML, XML, XSL, JavaScript (отдельный большой проект под названием Eclipse JSDT; о нём расскажу в следующих частях). Проект частично включён практически во все официальные сборки Eclipse, но для начинающих пользователей рекомендую ставить Eclipse for JavaScript Web Developers, в ней есть всё.

Чтобы не пересказывать документацию, кратко приведу основные возможности:

• подсветка кода;
• сворачивание/разворачивание кусков кода (code folding);
• outline и quick outline (на последний рекомендую обратить особое внимание, по умолчанию вызывается через Ctrl+O или ⌘O);
• выделение границ тэгов (aka Balancing), смотрите в основном меню Edit > Expand Selection To;
• content assist по тэгам, атрибутам и значениям некоторых атрибутов;
• quick fix: переименование тэга (автоматически меняет открывающий и закрывающий тэги), обрамление тэгом;
• форматирование всего/выделенного кода;
• автоматическое закрытие тэгов.

Итак, с платформой определились, теперь нужно её настроить для комфортной работы.

Включаем поддержку HTML5 и CSS3

Eclipse WTP в версии 3.3 (которая доступна для Eclipse Indigo) появилась поддержка тэгов HTML5 и некоторых свойств CSS3. Однако сразу они не доступны, нужно немного пошаманить с проектом:

1. Открываем свойства проекта: Project > Properties.
2. Переходим на вкладку Project Facets и жмём на ссылку Convert to faceted form…
3. В появившемся окне выбираем фасет Static Web Module, жмём Apply.
4. Закрываем окно с настройками проекта.

Теперь в content assist будут доступны новые тэги и свойства. Если нет — снова открываем свойства проекта и идём на вкладку Web Content Settings, где настраиваем профили для HTML и CSS.

Включаем проверку правописания

Eclipse IDE с версии 3.4 (если мне не изменяет память) поддерживает проверку правописания, и по умолчанию доступен только английский словарь. Чтобы включить проверку правописания русского языка, делаем следующее:

1. Скачиваем и распаковываем русский словарь.
2. Открываем настройки Eclipse, идём в General > Editors > Text Editors > Spelling
3. В User defined dictionary выбираем распакованный ru.dict.
4. Ставим кодировку UTF-8

Всё, теперь, если редактор, которым вы пользуетесь, написан по гайдам Eclipse Platform, вам будет доступна проверка правописания.

Eclipse WTP Sugar

Самую большую ломку при переходе с Aptana на Eclipse WTP у меня вызывало отсутствие content assist для путей к файлам (например, в <script src="...">): приходилось писать все пути к файлам вручную, что сильно утомляло. Да и в Aptana он был не идеальным: работал только внутри атрибута src (<script src="...">, <img src="..."> и т.д.), но не работал внутри href (<link href="...">, <a href="...">) и уж тем более не в CSS (background url(...), @import url(...)).

Поэтому, потратив несколько месяцев на изучение Java и архитектуры Eclipse IDE, я написал свой content assist, который исправит этот недостаток, а заодно несколько других (о них чуть позже).

Свой проект я назвал Eclipse WTP Sugar, репозиторий для установки: http://media.chikuyonok.ru/eclipse/webdev/updates/, исходный код доступен на GitHub.

Плагин устанавливается очень просто, как и все остальные:

1. Идём в Help > Install New Software…
2. В качестве репозитория (поле Work with) вбиваем http://media.chikuyonok.ru/eclipse/webdev/updates/.
3. В появившемся списке плагинов выбираем необходимые и жмём кнопку Next.
4. Далее проходим стандартную процедуру установки (соглашаемся с лицензией, всё время жмём Next или Finish) и перезапускаем Eclipse.

Теперь, при нажатии Ctrl+пробел внутри атрибутов src и href можно увидеть список файлов:

Список файлов также выдаётся и в CSS, внутри функции url():

Список файлов по возможности фильтруется. Например, если его вызвал внутри тэга <script>, то увидите список файлов с расширением js, если внутри <link rel="stylesheet"> — файлы с расширением css.

Возвращаясь к разговору о том, что создатели программ для вёрстки сами толком сайты не верстают. Что если нужно использовать абсолютные пути для ссылок на файлы? По умолчанию считается, что абсолютный путь нужно резолвить относительно папки с проектом. Но почему никому не пришла в голову мысль, что веб-пространство проекта не всегда совпадает с корневой папкой проекта? В этом плагине проблема решена: в настройках проекта можно указать, относительно какой папки нужно резолвить абсолютные пути (Project > Properties > Document root):

Quick outline

Следующее, что хотелось изменить, так это quick outline: специальное контекстное окошко, которое показывает в компактном виде текущую структуру документа:

Эту структуру можно фильтровать, чтобы найти нужны элемент (поиск осуществляется с начала строки, можно использовать символы * и ?). Но, как видно из скриншота, в структуре выводятся только названия тэгов, что делает её малопригодной. WTP Sugar исправляет этот недостаток, выводя гораздо больше полезной информации, по которой, в том числе, можно искать:

Eclipse XV Browser

Не так давно я написал просмотрщик XML-файлов под названием XV Browser. В том посте я показал, что его можно использовать внутри Eclipse, однако не учёл один важный факт: работать это будет только если у вас Mac, а в качестве основного браузера используется Safari с установленным плагином XV

Eclipse XV Browser исправляет этот недостаток. Он представляет из себя обёртку для встроенного браузера (это может быть Webkit либо Mozilla, в зависимости от ваших настроек и версии Eclipse). С помощью этого плагина можно прросматривать любой сайт в виде XML-структуры (Window > Show View > Other… > XV Browser), либо открывать просматривать XML-файлы проекта (правый клик по файлу, Open With… > XV Browser).

Пожелания?

Если есьт какие-то идеи по улучшению плагинов — пишите в Issues проекта. Пока в планах:

• content assist по классам и идентификаторам, описанных в CSS;
• быстрый переход к CSS-определению класса или идентификатора;
• виджеты для редактирования CSS Gradients и CSS Box Shadow.

В следующей статье рассмотрим, как улучшить работу с Eclipse JSDT (JavaScript).

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

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

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

Такое расположение усложняется тем, что это не единственный режим просмотра: можно переключится на более крупный, двухколоночный режим. Причём желательно по-меньше трогать DOM-дерево — не делать специальных обёрток вокруг трёх или двух блоков, чтобы потом скриптом их перестраивать. Идеальный вариант — просто менять класс у контейнера и отдать всё изменение структуры на откуп CSS.

Как ни странно, но решение задачи нашлось, причём довольно элегантное.

Обычно такие последовательности блоков делаются самым очевидным образом: через float-элементы. Но этот способ нынче не в моде: все правильные ребята уже давно прочитали статью в блоге Мозиллы о том, как делать их через display: inline-block;.

А что будет, если поставить рядом блоки разной высоты?

<style type="text/css">
	.wrap, .h, .f {
		display: inline-block;
	}

	.h {
		background: red;
		height: 100px;
		padding: 0 10px;
	}

	.f {
		background: blue;
		height: 20px;
		padding: 0 10px;
		color: #fff;
	}
</style>

<span class="wrap">
	<span class="h">header</span>
	<span class="f">footer</span>
	<span class="h">header</span>
	<span class="f">footer</span>
</span>

Получим вот такой результат:

По умолчанию у всех блоков vertical-align: baseline, то есть вертикальное выравнивание по базовой линии (в данном случае, если проще — по последней строке текста). Если указать для .h{ vertical-align: top; } и для .f { vertical-align: bottom; }, то получим довольно интересное решение:

Блоки выровнены именно так, как нужно. Убеждаемся в правильности решения, изменив высоту одного из блоков:

Дальше всё просто: у шапки и подвала одинаковая и вполне определённая ширина, поэтому прописываем её каждому блоку, а подвал убираем из потока с помощью отрицательного margin’a:

Чтобы семантически объединить шапку и подвал, можно использовать любой элемент с display: inline. Итоговая версия доступна на тестовой странице.

Самое интересное, что этот код работает даже в IE6. Помним, что inline-block в этом браузере эмулируется с помощью display: inline и волшебного hasLayout, например, так: display: inline; zoom: 1;.

В этом решении важно помнить следующее:

1. Шапка и подвал в примере пересекаются, поэтому шапке нужно снизу давать отступ и подтягивать подвал любым доступным способом.
2. Между элементами конструкции не должно быть переводов строк и пробелов, иначе блоки визуально будут разделены.

В данном случае мне очень помогло то, что у подвала вполне предсказуемая высота, поэтому у шапки был добавлен снизу большой фиксированный отступ, чтобы блоки не перекрывались. Это решение полностью решило проблему и отображения, и переключения режимов. Можно пойти дальше и подключить CSS3 Media Queries, чтобы обладатели новых браузеров и больших мониторов могли видеть более трёх предложений в ряду, но это уже другая история. Думаю, читатели смогут найти более творческие и интересные применения этого небольшого трюка

Поэтому решил написать свой просмотрщик XML-файлов для браузеров на движке Webkit. Встречайте — XV:

Что умеет

• Сворачивание/разворачивание элементов. Для избавления от визуального шума соответствующие стрелочки появляются при наведении на элемент. Alt-клик по стрелке сворачивает/разворачивает все внутренние элементы.
• Outline для удобного обзора больших документов
• Поиск по названию или XPath. По умолчанию ищет вхождение подстроки в названии тэгов и атрибутов, если используются спецсимволы вроде ‘/’ или ‘[‘ то поиск автоматически переключается в XPath-режим.
• Режим Quick XPath — моя самая любимая фича. Зажмите клавишу Control (Mac) или Ctrl (PC) при наведении курсора на название элемента или атрибута чтобы войти в этот режим (появится специальный тултип). Нажимайте на клавишу Shift чтобы переключаться между доступными вариантами XPath, а затем просто перетаскивайте текущий элемент в текстовый редактор (используется drag’n’drop). Пользователи Google Chrome могут кликнуть по элементу, чтобы скопировать XPath в буфер обмена. Этот режим очень удобно использовать внутри IDE, например, вот так:

Скачать

• Расширение для Google Chrome
• Плагин для Safari (Mac) — обновлённый xmlview Марка

Можно также использовать и в Firefox как стандартный стиль для XML-файла, если скачать соответствующий XSL-файл:
<?xml-stylesheet type="text/xsl" href="xv-browser.xsl"?>.

Демонстрация

Посмотреть, как это выглядит, можно на тестовой страничке (хорошо работает в Safair/Chrome, в Opera и Firefox глючит drag’n’drop).

Исходный код доступен на GitHub: http://github.com/sergeche/xmlview/
Там же можно сообщения об ошибках (тестировал только на своих XML-файлах) и пожелания.

И мы сразу же начали получать жалобы о жутких тормозах на главной странице. На поиск и устранение проблем у меня ушло два дня. О том, как находились узкие места и будет сегодняшний рассказ. А заодно научимся пользоваться инструментами вроде Web Inspector’s Timeline (если вы их ещё не освоили).

Поиск проблемы

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

Самые большие проблемы наблюдались в Firefox: загрузка процессора на главной странице доходила до 70%. Поэтому я начал рассматривать скрипт таймера под микроскопом, а именно в Web Inspector, который по умолчанию входит в состав браузеров Safari и Chrome. Вообще, многие ребята довольно снисходительно относятся к этому инструменту, продолжая по привычке работать в Firebug’е, а зря. Лично для меня Web Inspector стал основным инструментом для отладки: выглядит он приятнее и содержит ряд полезных нововведений.

Исследуем узкие места

Так как сам скрипт таймера довольно простой, то не было смысла заниматься его профилированием — проблема явно где-то в reflow и repaint. Поэтому скрипт нужно исследовать через Timeline:

Полагаю, что многие читатели ещё ни разу не сталкивались с этим инструментом, поэтому принцип его работы и поиска проблем опишу в небольшом уроке. Стоит отметить, что Web Inspector в Chrome немного круче, чем в Safari, поэтому рекомендую пользоваться первым браузером.

Timeline показывает нам практически все процессы, которые происходят в браузере: запуск скрипта, отработка события, перерисовка экрана, установка таймера, отправка аякс-запроса и т.д. Так как данных довольно много и в них легко запутаться, я рекомендую изолировать исследуемый скрипт — выделить его в отдельную страницу. Для практики можно начать с простого шаблона, на котором мы будем экспериментировать.

Открываем шаблон в браузере и запускаем Web Inspector, вкладка Timeline. На странице есть красный квадратик и кнопка «Test». Чтобы начать исследование, нужно нажать на кнопку записи вкладки Timeline , а потом нажать на кнопку «Test» в основном окне браузера. Наш квадратик посинел и стал больше по высоте, а в Timeline записались следующие события:

Первые три записи относятся непосредственно к кнопке, которую нажали: применили псевдо-класс :active (Recalculate style), отобразили изменения на экране (Paint), вернули кнопку в исходное состояние, убрав :active (Recalculate style). После того, как пользователь отпустил кнопку мышки сработало событие click, и именно оно и всё, что ниже, нас будет интересовать.

Во время клика сработал следующий скрипт:

function test() {
	var el = document.getElementById('test');
	el.style.backgroundColor = 'blue';
	el.style.height = '100px';
}

Ничего особенного: просто получили ссылку на элемент и поменяли у него цвет фона и высоту. Этот процесс был отображён на временной шкале: пересчитали стили (Recalculate style), пересчитали геометрию объектов (Layout) и отобразили изменения (Paint).

Как видите, несмотря на то, что мы поменяли два СSS-свойства, пересчёт стилей произошёл всего один раз. Поменяем скрипт:

function test() {
	el.style.backgroundColor = 'blue';
	var height = el.offsetHeight;
	el.style.width = '100px';
}

Между присваиванием новых стилей мы решили получить высоту объекта. Но временная шкала сильно преобразилась:

Теперь у нас уже два события Recalculate style, а у самого события click появилась группировка (треугольник слева от жёлтой полоски), которая указывает, какие именно события произошли во время клика.

Этот небольшой пример указывает на две очень важные особенности браузеров — это откладывание перерисовки на момент выхода из функции (первый пример) и существование определённых свойств у элемента, которые принудительно вызывают пересчёт стилей (далее restyle; второй пример). О существовании особых свойств, вызывающих restyle, думаю, многие уже знали: это свойства вроде offsetLeft/Right/Width/Height, clientLeft/Right/Width/Height и так далее. Во втором примере, после установки свойства backgroundColor браузер пометил дерево элементов как требующего пересчёта стилей. А обращение к offsetHeight принудительно вызвало этот пересчёт. Затем мы установили свойство width, которое отложило пересчёт стилей, геометрии и отображения на момент выхода из потока JS-функций.

Отсюда первое правило: нужно стараться не смешивать получение и запись CSS-свойств. Лучше, например, сначала получить нужные свойства элемента, а затем присвоить новые.

Для любителей jQuery более красноречивым будет вот такой пример:

function test() {
	var e = $('#test');
	var width = e.css('width');
	if (width == '50px')
		e.css('width', '100px');

	var height = e.css('height');
	if (height == '50px')
		e.css('height', '100px');
}

Вот его шкала:

Как видите, помимо лишнего Recalculate style появился Layout (reflow), что сделало выполнение скрипта более медленным. Если немного оптимизировать, переместив получение высоты выше в коде:

function test() {
	var e = $('#test');
	var width = e.css('width'),
		height = e.css('height');

	if (width == '50px')
		e.css('width', '100px');

	if (height == '50px')
		e.css('height', '100px');
}

…получим совершенно иную картину:

Лишний Layout (помимо Recalculate style) объясняется тем, что jQuery каждый раз при получении CSS-свойств вызывал window.getComputedStyle(), который принудительно запускает reflow. Справедливости ради стоит отметить, что в функции jQuery.css() есть оптимизация, которая сначала проверяет наличие запрашиваемого свойства в element.style и если его там нет, вызывает window.getComputedStyle(). Но в любом случае, лучше всегда разделять чтение и изменение свойств.

Таймеры

Напомню, что я занимался оптимизацией таймеров, которых было несколько. И каждый таймер работает через свой setTimeout(). Посмотрим, что это означает на практике:

function test() {
	var el = document.getElementById('test');
	setTimeout(function(){
		el.style.backgroundColor = 'blue';
	}, 10);
	setTimeout(function(){
		el.style.width = '100px';
	}, 10);
}

У обоих таймеров одинаковый период ожидания и момент исполнения. На шкале видно, что после каждого таймера был запущен пересчёт стилей. Но в реальности момент исполнения будет далеко не всегда одинаковым. Поэтому поменяем задержку у последнего таймера — поставим 11 мс вместо 10 мс:

function test() {
	var el = document.getElementById('test');
	setTimeout(function(){
		el.style.backgroundColor = 'blue';
	}, 10);
	setTimeout(function(){
		el.style.width = '100px';
	}, 11);
}

И мы видим, что на шкале появился дополнительный repaint:

В итоге получалось, что из-за нескольких запущенных setTimeout() срабатывали ненужные перерисовки, которые пользователь всё равно не увидит, но процессор это нагружало прилично. Я переписал код таймеров таким образом, чтобы всё работало через один глобальный таймаут.

Итак, суммируя всё вышесказанное, для оптимизации я

• разделил чтение и запись CSS-свойств;
• дополнительно сделал кэширование текущих значений анимации, чтобы меньше обращаться к элементам;
• заменил несколько таймаутов на один.

В итоге в Firefox нагрузка на процессор снизилась… всего на 10%. Вообще, это было крайне странно: даже при наличии всего одного анимированного таймера на странице Firefox грузил процессор на 60%, при том что Webkit грузил всего на 5%. Нужно копать дальше.

Влияние вёрстки на производительность

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

Так как все restyle и reflow процессы я оптимизировал, проблема явно была где-то в repaint. Вспомнил, что в Firefox 3.5 появилось событие mozAfterRepaint, которое позволяет увидеть области, которые были перерисованы во время repaint. Для удобства было поставлено расширение Firebug Paint Events, которое позволяет отслеживать перерисовки экрана.

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

Я специально оставил только 8 из 30 предложений, чтобы картинка не распирала страницу, но смысл, думаю, ясен: во время анимации даже одного таймера перерисовывалось примерно 90% страницы, 15 раз в секунду. И это при условии, что у цифр таймера указан position:absolute, а у их контейнера overflow:hidden. То есть сама анимация по определению никак не могла повлиять на области вне контейнера (на скриншоте обозначен синим прямоугольником), но перерисовывалась почти вся страница.

Около часа мне понадобилось на то, чтобы найти причину такого странного поведения. Ей оказалось… свойство float:left у одного из контейнеров. Как только я заменял его на float:none нагрузка на процессор падала ниже 10% (с float:left была около 60%).

Проблема проявляется стабильно, причём не только в Firefox, но и в Opera и IE8. Я сделал простую демку, где можно в живую увидеть эту проблему. В ней всего несколько блоков, однако у них указан box-shadow — очень тяжелое в плане нагрузки на процессор CSS-свойство. В правом верхнем углу есть кнопка, которая всего лишь переключает float у контейнера. Понаблюдайте за нагрузкой на процессор при разных состояниях кнопки, а также за областью перерисовки.

В общем виде проблему можно описать так:

Repaint срабатывает на контейнере самого дальнего родителя, у которого указан float:left|right.

Схематично это выглядит так:

Причём проблема не только во float. Я перепробовал различные варианты горизонатльной группировки блоков: display:inline-block, display:table-cell, таблицы и даже новомодные flex box — во всех случаях проблема оставалось. Помогало только абсолютное позиционирование боковых блоков.

В общем виде я проблему решил: поставил боковую панель в коде перед основным контейнером и только ей указал float. Основной контейнер был без float и repaint происходил именно там, где нужно. Однако на живом сайте решить проблему не удалось, так как на большинстве страниц стояли clearfix-элементы, из-за которых макет разваливался. Поэтому пришлось пока отключить анимацию с таймеров

***

Честно говоря, после таких браузерных крендебобелей на всякие пузомерки типа Peackeeper, которыми так хвастаются разработчики с каждым новым релизом своего браузера, без слёз смотреть не получается. Поэтому мой вам совет: заранее узнавайте о всех интерактивных элементах на странице, не увлекайтесь новым CSS3, продумывайте рост сайта заранее и пользуйтесь правильными инструментами для отладки производительности — тогда будет вам счастье и высокая производительность.

Если хотите узнать больше о профилировании производительности, очень рекомендую статью Стояна Стефанова на эту тему.

Как это делается сейчас? На сервере мы смотрим на заголовок User Agent и определяем, что это за браузер. Но этот заголовок можно легко подменить (причём необязательно это делать в самом браузере, это может сделать прокси-сервер), поэтому такая проверка совсем ненадёжна. На клиентской стороне у нас гораздо больше возможностей: мы можем не только проверить User Agent браузера, но и его возможности (например, поддержку определённых CSS и JS свойств), что даст нам более точные характеристики браузера.

Собственно, сама идея как раз заключается в том, чтобы скрестить эти два способа: определить с помощью CSS и JS характеристики браузера и в нужный момент сообщить их на сервер. Основа алгоритма — Chunked Transfer Encoding, позволяющий передать ответ (например, HTML-документ) не целиком, а кусками. Итак, сам алгоритм:

1. Когда пользователь запрашивает HTML-страницу, отдаём ему первый фрагмент (chunk), в котором содержится sniffing-код. После этого соединение удерживается на некоторое время, чтобы отдать второй фрагмент документа.
2. Браузер, получив первый фрагмент, тут же его парсит и пытается отобразить.
3. В этом первом фрагменте у нас sniffing-код, результатом работы которого является CSS-свойство background-image, применяемое к элементу <html>.
4. Путь к этой фоновой картинке является уникальным для каждого браузера и так уж получилось, что как только мы применили это свойство элементу, браузер открывает второе соединение и тут же пытается загрузить эту картинку.
5. Сервер, получив запрос к нашей «картинке» понимает, каким браузером мы зашли и отдаёт вторую часть ответа в первом соединении.
6. Если обращения к «картинке» не было (например, зашли поисковым роботом), то через какой-нибудь небольшой промежуток времени отдаём стандартный ответ.
7. После первого «вынюхивания» можно поставить куку, чтобы потом сразу отдавать нужный ответ.

В итоге получаем следующие преимущества:

• Нет никаких редиректов: ответ о типе браузера получаем в одном соединении (полезно для SEO).
• Очень сложно обмануть такой сниффер: можно до посинения менять строку User Agent, но результат останется прежним. Гугл сможет эффективней банить Оперу.
• Более сложные проверки: можно не просто определять название браузера, но и его возможности, благодаря CSS Media Queries.

Для желающих поэкспериментировать я написал демонстрацию этого подхода на node.js. К сожалению, у меня на VPS не хватает памяти, чтобы собрать node.js, поэтому предлагаю читателю самому его установить и проверить у себя. Если кто выложит это в онлайн — буду премного благодарен. Выложили: http://tbms.ru:8126/ (спасибо Николаю Митину).

Полезные уроки

Пока писал эту демонстрацию, вынес для себя много ценной информации:

1. Первый чанк должен быть достаточно большим, чтобы все браузеры смогли его применить. Самый большой лимит — у движка Webkit: около 2 КБ. Поэтому приходится «добивать» первый фрагмент пробелами, чтобы всё работало как надо.
2. Webkit очень плохо ведёт себя при переопределении CSS-свойств. Например:

   html { background-image:url(image1.png); }
   html { background-image:url(image2.png); }
   		

   В этом случае Webkit (и десктопный, и мобильный) загрузит обе картинки, хотя понятно, что нужна только последняя. Это ещё одно подтверждение, что мобильные версии сайта лучше делать отдельным проектом, а не вставлять через CSS Media Queries. Иначе попытки сократить траффик заменой больших фоновых картинок на маленькие приведёт к обратному эффекту. Хотя тут нужно больше исследований, возможно, это издержки работы с локальным сервером.

3. Firefox не отработает первый чанк до тех пор, пока не получит элемент <body>. Это довольно серьёзный недостаток в том случае, если вы захотите выдавать уникальные стили и скрипты для браузера в секции <head>. С другой стороны, если послать <script>alert(1)</script>, то чанк отработает нормально, даже без <body>. Что наталкивает на мысль о существовании неких триггеров, которые заставят браузер сделать то, что нам нужно, осталось только найти наиболее безопасный.

Повторюсь, что это только идея, а не призыв к действию. Буду рад, если кто-то на её основе сделает что-то крутое и интересное.