Честно говоря раньше не придавал особого значения такой фазе веб-девелопмента, как верстка. Отчасти потому что никогда этим сам не занимался(на должном уровне), отчасти от того, что недопонимал некоторые аспекты веб-разработки. Недавно наткнулся на интересную статью Сергея Чикуенока (из команды никому не известного Артема Лебедева). Суть этой статьи сводится к следующему: если клиентский код работает медленно - убейте дизайнера, верстальщика или кто этим у вас там занимался. Потому как разметка влияет на скорость работы веб-приложения. Кому интересно почитать детали можно в оригинале статьи, а я лишь процитирую выводы:

1. Для интерактивных элементов лучше использовать position: absolute.
2. Большое количество элементов на странице может снизить производительность, но не стоит увлекаться их сокращением в ущерб надежности макета.
3. Не надо делать очень глубоких вложенных структур элементов.
4. Прежде чем начинать верстку макета, следует узнать, какие интерактивные механизмы там должны быть — это избавит от многих проблем уже на начальном этапе работы над проектом.
5. Не надо загонять себя в угол глупых стереотипов: «валидность» и «семантичность» никому, кроме самих разработчиков, не нужна.
6. Не стоит без надобности растягивать картинки. Если это необходимо сделать, следует воспользоваться canvas.
7. Как правило, img-элемент будет работать гораздо быстрее, чем CSS-свойство background-image.
8. Помните главное правило: оптимизировать нужно то, что требует оптимизации.

Вот так-то господа, веб разработчики...

John Resig, создатель JQuery, совсем недавно провел небольшую презентацию в Гугле. Темой встречи были улучшения производительности в браузерах(в ближайших релизах), некие новшества в Javascirpt движках, новые способы работы с DOM и изумительные эффекты с помощью CSS стилей. Но обо всем по порядку.

Количество процессов на браузер

Одним из интереснейших нововведений в IE8 и Chrome стало то, что теперь вкладки разделены на несколько процессов. Это дает огромное преимущество в производительности, так как теперь различные веб страницы могут загружаться и исполняться параллельно, не отнимая машинных ресурсов друг у друга. В тоже время такие браузеры как FF, Opera и более старые версии IE загружают/исполняют несколько страниц в одном процессе (различные страницы выполняются отдельными потоками).

Позвольте я поясню, каким же образом происходит разделение вкладок на процессы в Internet Explorer 8. Но для начала давайте вспомним модель процессов IE7:

Как видите, каждое окно браузера (UI Frame) находиться в отдельном процессе. Хотя, надо сказать, тут есть одно исключение - если вы нажмете CTRL+N, то новый UI фрейм создастся в том же процессе. Закладки, расширения браузера (toolbar extensions), вспомагательные объекты и ActiveX контролы находятся в том же процессе, что и UI фрейм. Проблема такой модели в том, что любая фатальная ошибка (например stack overflow) в одной из закладок приведет к закрытию всех закладок в этом процессе.

Рассмотрим модель процессов в IE8:

В новом браузере изменилось лишь месторасположение UI фрейма соответствующих ресурсов. Со стороны пользователя это будет выглядеть вот так:

И так как закладки изолированы от UI фрейма, то фатальная ошибка в одной из закладок приведет к закрытию всех закладок в этом процессе, но окно браузера останется открытым. Зачем нам это нужно? А для того, чтобы браузер (UI Frame) имел возможность восстановить закрытые вкладки. Но вернемся к разделению вкладок на процессы. Как вы наверное уже успели заметить закладки разделяются на процессы по принципу принадлежности к одной из моделей безопасности (medium IL или low IL). Это накладывало некоторые ограничения на процесс(окно браузера) и когда вы, например, открыли Интранет страницу в одной вкладке, а затем пытались открыть Интернет страницу в другой, то браузер вам сообщал: "Internet Explorer needs to display this webpage in a new window". Это происходило по той причине, что данный процесс(а следовательно и данное окно браузера) имело определенные security-ограничения в отношении страниц, которые он отображал. Теперь, вы можете открывать страницы с разными уровнями безопасности в одном окне.

Боюсь ввести вас в заблуждение, что и Chrome работает по тому же принципу, что и IE 8 (раз эта фича была объявлена для обоих браузеров в одном предложении ранее). Поэтому вкратце расскажу как это происходит в гугловом браузере.

Chrome создает три типа процессов:

Браузер. Существует только один процесс браузера, который управляет закладками, окнами и "хромированием" внешнего вида. Этот процесс также ответственен за операции с диском, сетью, пользовательским вводом.

Отрисовщик (Renderer). Прости господи меня за такой перевод, но этот тип процессов действительно отвечает за обработку HTML, Javascript, CSS, картинок и много чего еще.  Причем эти процессы не имеют доступа ни к вашему диску, ни к сетевым ресурсам. Все взаимодействия с пользователем, а также отрисовка на дисплее лежит на процессе типа Браузер. Такое разделение на процессы позволяет сразу убивать подозрительные процессы, которые могли быть подвержены различного рода атакам.

Плагины. Процесс браузера также создает по одному процессу для каждого типа плагина: Flash, Quicktime, Adobe Reader и тп.

Все эти процессы можно увидеть в собственном Chrome Task Managar'e:

Как только Chrome создал процесс типа Браузер, он начинает создавать по одному процессу типа Отрисовщик для каждого веб-сайта, который вы посещаете. Но тут тоже не все так просто, как кажется на первый взгляд. Ведь создавать такое количество процессов было бы весьма расточительно, учитывая то, что создание процесса это весьма трудоемкая и ресурсоемкая операция. Поэтому, если вы открываете новую закладку используюя JavaScript, или если вы открываете страницу с того же сайта, но в новой закладке, то эти закладки будут находиться в одном процессе (типа Отрисовщик). Это позволяет этим страницам на разных вкладках общаться посредством JavaScript и разделять общие закэшированные объекты. Но даже при таком подходе в группировке вкладок в процессы, существует риск создать слишком много процессов и "повесить" систему. Поэтому разработчики ввели ограничение на количество процессов, это число зависит от ресурсов вашей машины, но в среднем оно не превышает 20.

Процессы типа Плагин создаются сразу как только вы открыли страницу, нуждающуюся в этом плагине. И убивает этот процесс, вскоре после того как вы закрыли последнюю страницу, использующую этот плагин.

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

Остальные интересности и вкусности этой презентации я постараюсь осветить в ближайшем светлом будущем.

Полезные ссылки

IE8 and Loosely-Coupled IE (LCIE)

IE8 and Reliability

Группировка вкладок в IE8

Multi-process Chrome Architecture

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

Что-то случилось...

... понял я, когда в час ночи зазвонил мой телефон. Сквозь сон я выслушал все новогодние "пожелания" заказчика и краткое описание проблемы - "Страница медленно работает". Затем пока нашел штаны, пока нашел где у меня ноги, пока оделся и, спустя часы, я оказался на работе. Нагрузочное (или даже стресc-тестирование) показало, что страница действительно забирает 90% процессорного времени при больших объемах данных на ней. После небольшого разбирательства выяснилось, что показания %Time in GC счетчика производительности меньше оптимальных. После чего наш консилиум заключил, что приложение нерационально использует оперативную память сервера.

MSDN говорит:

.NET CLR Memory\% Time in GC

Threshold: This counter should average about 5 percent for most applications when the CPU is 70 percent busy, with occasional peaks. As the CPU load increases, so does the percentage of time spent performing garbage collection. Keep this in mind when you measure the CPU.

Significance: This counter indicates the percentage of elapsed time spent performing a garbage collection since the last garbage collection cycle. The most common cause of a high value is making too many allocations, which may be the case if you are allocating on a per-request basis for ASP.NET applications. You need to study the allocation profile for your application if this counter shows a higher value.

За этим последовал небольшой code review, во время которого выяснилось, что приложение создает дофига коллекций. Коллекции использовались для переноса данных из BLL в Presentation Layer, и последующей конвертации их в DataTable (для байндига в GridView). Таким образом мы создали три анти-паттерна производительности (во завернул-то!): храним много данных в памяти, создаем большое количество циклов и конвертаций типов.

Пути решения

• Байндить коллекции сразу GridView, без конвертации в DataTable
• Создавать DataTable сразу из XML файла, минуя коллекции во избежания больших циклов  и конвертации типов
• Использовать XSLT для трансофрмации XML в HTML таблицу (нафиг тогда вообще ASP.NET?)
• Использовать Response.Write(), как это предлагает сделать Майкрософт

Решили попробовать последнее.

В результате получили следующее:

GridView	Response.Write()

Интересные результаты, неправда ли? И хотя мы выиграли в производительности мы проиграли как минимум в удобстве и безопасности: GridView не просто рендерит таблицу, а и реализует некий функционал для управления и взаимодействия с данными в ней. А также делает проверки на cross-site scripting и другие виды атак. Так, что настаивать на Response.Write не буду. Решение использовать зависит от конкретной ситуации и пожеланий вашего заказчика.

Полезные ссылки

Improving ASP.NET Performance

Measuring .NET Application Performance

Code Review: .NET Application Performance

Как вы обрабатываете свои XML-данные? С помощью LINQ to XML, XPath, XmlDocument или же сами парсите (тогда вам пора в больничку). Лично я предпочитаю писать XPath-выражение, потому что они (относительно) просты в написании и, соответственно, в чтении. Да и скорость обработки этих выражений всегда радовала своей производительностью. Какое-то время назад вышел extension для LINQ to XML, позволяющий использовать XPath выражения.

Небольшой эксперимент позволил определить плюсы и минусы нового расширения по сравнению с LINQ to XML. Для начала я спер базу AdventureWorks и экспортировал данные из таблицы SalesOrderDetail в xml файлик. 120000 строк мне показались достаточным набором данных для подобного теста.

Затем я написал три различных запроса к этому набору данных с использованием LINQ to XML и тожесамое + XPath. Код и результаты тестов прилагаются.

LINQ to XML: 246.96 мс

/// <summary>
/// Выбираем все элементы для ордера с ID=46348
/// </summary>
public static int RunQuery1(XDocument xDoc)
{
IEnumerable<XElement> elements =
from result in xDoc.Descendants("dataroot").Descendants("SalesOrderDetail")
where result.Element("SalesOrderID").Value == "46348"
select result;
return elements.Count();
}

LINQ to XML с XPath: 1025.95 мс

public static int RunQuery1(XDocument xDoc)
{
return xDoc.XPathSelectElements("//dataroot/SalesOrderDetail[SalesOrderID=46348]").Count();
}

Правда код с использованием XPath выглядит элегантнее? ОК, идем дальше.

LINQ to XML: 208.88 мс

/// <summary>
/// Считаем все SalesOrderDetailы частота заказов > 2 для ProductID=761
/// </summary>
public static int RunQuery2(XDocument xDoc)
{
IEnumerable<XElement> elements =
from result in xDoc.Descendants("dataroot").Descendants("SalesOrderDetail")
where String.CompareOrdinal(result.Element("OrderQty").Value, "2") > 0
&& result.Element("ProductID").Value == "761"
select result;
return elements.Count();
}

LINQ to XML сXPath: 1013.19 мс

public static int RunQuery2(XDocument xDoc)
{
return xDoc.XPathSelectElements("//dataroot/SalesOrderDetail[OrderQty>2 and ProductID=761]").Count();
} 

LINQ to XML: 218.37 мс

/// <summary>
/// Считаем все SalesOrderDetailы, где LineTotal > $4000
/// </summary>
public static int RunQuery3(XDocument xDoc)
{
IEnumerable<XElement> elements =
from result in xDoc.Descendants("dataroot").Descendants("SalesOrderDetail")
where String.CompareOrdinal(result.Element("LineTotal").Value, "4000.00") > 0
select result;
return elements.Count();
}

LINQ to XML с XPath: 944.9 мс

public static int RunQuery3(XDocument xDoc)
{
return xDoc.XPathSelectElements("//dataroot/SalesOrderDetail[LineTotal>4000.00]").Count();
}

Для наглядности нанесем эти данные на график

Теперь всем видно, что LINQ to XML куда быстрее, чем тоже самое но с использованием XPath. Зачем же Майкрософт написало такую надстройку?

XPath удобнее использовать, когда

• код должен быть читабельным
• при миграции продуктов, использующих XPath исторически
• когда приложение не требует большой производительности от доступа к данным. Мой набор данных имел 120000 строк и при этом XPath работал на 1 секунду медленнее, чем LINQ to XML. Не так уж и плохо, верно?

Но лучше от XPath отказаться, если

• производительность делает вам погоду
• вам необходим sql-похожий синтаксис (ну мало ли, может вы sql-маньяк)
• вам необходима группировка (к примеру, посчитать сумму ордера)
• вам небоходим функционал агрегирования (суммы, среднее и прочее)

Вообщем на те вам, и выбирайте что хотите.

Ясен пень, заголовок немного провокационный. Но мне надоели эти занудные “Быстрые веб-страницы”, поэтому серия статей по оптимизации веб-приложений продолжится под заголовком “Скаженi кабани”. Уже интереснее, правда?

ОК, мальчики и девочки, тема сегодняшней лекции – создание “облегченной” версии IIS 7.0 сервера, для простейших HTML приложений и статических файлов. А нафиг надо? Понадобиться это может в случае, если вы решили вынести все свои статические ресурсы (картинки, css, js-скрипты) на другой сервер. Или же, если вы наколбасили 2000-3000 html страниц, а Апач настраивать вы не умеете… Для тех, кто еще не успел поставить IIS 7 на свой сервер, дам небольшой setup snippet:

(заметка: я опустил IIS-ManagementConsole, WAS-NetFxEnvironment, и WAS-ConfigurationAPI, чтобы сервер был дружелюбнее)

Прежде, чем следовать советам всяких умников (вроде меня) сделайте бэкап настроек сервера по умолчанию:

%windir%\system32\inetsrv\appcmd add backup "default_install"

Теперь осталось “раздеть” IIS, бережно, как любимую девушку:

%windir%\system32\inetsrv\appcmd uninstall module TokenCacheModule
%windir%\system32\inetsrv\appcmd uninstall module DefaultDocumentModule
%windir%\system32\inetsrv\appcmd uninstall module DirectoryListingModule
%windir%\system32\inetsrv\appcmd uninstall module RequestFilteringModule
%windir%\system32\inetsrv\appcmd uninstall module HttpLoggingModule
%windir%\system32\inetsrv\appcmd uninstall module ProtocolSupportModule
%windir%\system32\inetsrv\appcmd uninstall module RequestMonitorModule

%windir%\system32\inetsrv\appcmd uninstall module CustomErrorModule

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

1) UriCacheModule – кэширует информацию о URLах на уровне оболочки

2) FileCacheModule – кэширует файлы в память

3) HttpCacheModule – кэширует файлы на уровне ядра

4) StaticCompressionModule – сжимает статические файлы для уменьшения передаваемого объема данных

5) StaticFileModule – обрабатывает запросы к статическим ресурсам

6) AnonymousAuthenticationModule – модуль анонимной аутентификации (а по названию и не скажешь, правда?)

Небольшой тест показывает разницу между пропускной способностью “облегченной” версии IIS, стандартной комплектацией сервера и сервера со всеми модулями (с отключенным кэшем на уровне ядра).

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

Полезные ссылки

Install Typical IIS Workloads

Installing IIS 7.0 on Windows Server 2008

Начнем с того, что фреймворк JQuery очень быстрая штука. Да, конечно найдутся такие, кто скажет: "Короче, начал юзать джэйквери и у меня все повисло. Ну, я типа решил, что надо писать все самому...". Что ж, идиотов всегда хватало и мы не будем их переубеждать. Тем не менее, существуют некоторые практики и советы по использованию этого мощного (в руках homosapiens) инструмента.

Используйте ID, вместо классов для выборки элемента. Если у вас большой дом(не путать с дорогущим сооружением по соседству), то выборка $(.one-element') приведет к просмотру всего дерева для поиска этого элемента. Помогите ему и себе, предоставьте как можно больше информации о месторасположении объекта: ('.block1 > .block2 > .block3 …), укажите стартовую точку для поиска $('.foo', startObject) или используйте выборку по айдишнику $('#block45').

Читайте подробнее и на английском:

http://www.learningjquery.com/2006/12/quick-tip-optimizing-dom-traversal

http://blog.multitweet.com/2007/09/13/jquery-performance/

http://www.componenthouse.com/article-19

https://www.adaptavist.com/display/%7Egfraser/2008/01/12/Some+quick+tips+for+jQuery+performance

Иногда filter работает быстрее, чем find.

Читайте подробнее и на английском:

http://groups.google.com/group/jquery-en/browse_thread/thread/533451087251c952/9bb31c108c089c4f

http://www.learningjquery.com/2006/12/how-to-get-anything-you-want-part-2

Естественно это зависит от браузера, но объединение нескольких строк в одну таким способом: string1 = string2 + string3 может работать медленнее, чем если бы вы создали массив строк, а затем сделали join. В редких случаях имеет смысл использовать и третье решение - конкатенацию строк.

Читайте подробнее и на английском:

http://www.nabble.com/document.write-and-DOm-creation---performance-optimization--td18390436s27240.html

http://www.sitepen.com/blog/2008/06/09/string-performance-getting-good-performance-from-internet-explorer/

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

Недавно открыл для себя, что iterators в джаваскрипте работают медленее, чем generators при больших объемах данных. Будьте бдительны, товарищи!

Старайтесь кэшировать элементы и их коллекции, где это только возможно

   1: var myCachedObjects = $(".find-me");

   2: var anotherObjects = myCachedObjects.filter(".another-object");

   3: var favouriteObjects = myCachedObjects.filter(".favourite-object");

Ухх, за эти выходные мое javascript-мировоззрение перевернулось: xml парсится в четыре раза медленнее, чем json, if(isTrue) работает быстрее, чем if(isTrue == true) и многое другое. Не хочу превращать этот пост в энциклопедию, поэтому добро пожаловать в полезные ссылки.

Полезные ссылки

jQuery: Performance analysis of selectors

IE + JavaScript Performance Recommendations

Evaluate Low Level JavaScript Performance Characteristics

Some more JavaScript performance tips

Еще один пост до кучи к анализу и оптимизации графичесой составляющей ваших страниц.

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

Juicy Studio Image Analyser онлайновый инструмент, анализирующий каждое изображение на странице и обращающий внимание на следующие параметры:

• Указанные ширину и длину;
• Наличие alt-текста;

Оценка сервиса: 3 из 5

Обращаю Ваше внимание на то, что некоторые замеченные сервисом ошибки в исправлении не нуждаются.

Alt Text Checker отображает alt-тексты для каждого из изображений на странице:

Оценка сервиса: 3 из 5

Page Size Extractor даст Вам оперативное представление об общем количестве и весе всех изображений на веб-странице:

Оценка сервиса: 4 из 5

Web Developer FireFox: Toolbar предлагает полный анализ изображений:

• Показывает alt-тексты для изображений;
• Показывает размеры изображений;
• Показывает вес изображений;
• Показывает место расположения изображений;
• Показывает скрытые и фоновые изображения и т.д.

Оценка сервиса: 5 из 5

Firefox Accessibility Extension предлагает удобный отчет по найденным на странице изображениям в виде аккуратненькой таблицы (“Text equivalents” => “List of images“). Таблица очень удобна в использовании, т.к. там предусмотрена функции разноцветной подсветки и сортировки.

Оценка сервиса: 5 из 5

Оригинал статьи: 5 Tools for On-page Image Usage Analysis