на главную | войти | регистрация | DMCA | контакты | справка | donate |      

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
А Б В Г Д Е Ж З И Й К Л М Н О П Р С Т У Ф Х Ц Ч Ш Щ Э Ю Я


моя полка | жанры | рекомендуем | рейтинг книг | рейтинг авторов | впечатления | новое | форум | сборники | читалки | авторам | добавить

Разгони свой сайт

Разгони свой сайт
Название: Разгони свой сайт
Автор:
Оценка: 3.8 из 5, проголосовало читателей - 57
Жанр: компьютерная литература
Издание:
Содержание:

скрыть содержание

  1. Методы клиентской оптимизации веб-страниц
  2. Введение
  3. Об этой книге и проекте webo.in
  4. Вопрос скорости загрузки веб-страниц привлекает внимание всех веб-разработчиков уже очень давно — практически с того момента, как в HTML-документе появились картинк
  5. За последние 10 лет уже многократно менялся сам подход к созданию сайтов. В эпоху браузерных войн и ограниченного доступа по модему наиболее важными аспектами клиен
  6. Но ситуация изменилась. Сейчас средняя веб-страница уже крайне тяжело вписывается в установленные когда-то рамки «загрузка за 10 секунд на модеме». В среднем на ней
  7. Данное издание старается объединить в себе все современные подходы к построению высокопроизводительных веб-приложений и просто веб-сайтов, которые быстро загружа
  8. Кроме теоретических аспектов производительности приведено также большое количество практических рекомендаций, примеров конфигурационных файлов, различных прие
  9. Web Optimizator
  10. Идея организовать ресурс, как посвященный теоретическим аспектам оптимизации времени загрузки веб-страницы, так и предлагающий online-инструменты для этой самой опт
  11. За основу online-инструмента были взяты замечательные примеры с
  12. Именно с этой целью и был создан Web Optimizator ( http://webo.in/ ).
  13. Благодарности
  14. Книга не увидела бы свет без помощи, советов и рекомендаций огромного количества людей. Каждый из них добавил что-то новое в нижеизложенный материал, поэтому у меня
  15. Во-первых, хочу высказать персональную благодарность Виталию Харисову за несколько очень своевременных замечаний относительно производительности CSS-движка в бра
  16. Во-вторых, нельзя не упомянуть Павла Димитриева и его замечательный перевод классических советов от группы разработчиков Yahoo! (
  17. Значительный вклад в продвижение идей «ненавязчивого» JavaScript и обратной совместимости в работе веб-сайтов (когда пользователь может взаимодействовать со странице
  18. Также необходимо упомянуть Евгения Степанищева ( http://bolknote.ru/
  19. Естественно, нельзя обойти вниманием всех моих соратников по российскому крылу Web Standards Group (
  20. Кроме этого Антон Лобовкин ( http://anton.lobovkin.ru/ ), Денис Кузнецов
  21. И конечно, обязательно хочу поблагодарить всех пользователей
  22. Глава 1. Что такое клиентская оптимизация?
  23. 1.1. Цели и задачи оптимизации
  24. Каждая веб-страница состоит из основного HTML-файла и набора внешних ресурсов. Говоря о размере страницы (или сайта), очень часто имеют в виду размер именно первого фа
  25. Рис.1 .1 . Тенденция изменения размера страницы и числа объектов для сайтов, проверяемых через Web Optimizator в 2008 году
  26. В настоящее время на каждой странице вызывается несколько десятков внешних объектов, а размер исходного файла составляет не более 5% от общего размера. Как показали
  27. Естественно, что технологии эти не ограничиваются сжатием текстовых (HTML, CSS, JavaScript) файлов на стороне сервера. Как несложно понять, основную часть внешних объектов н
  28. Основные задачи оптимизации
  29. Если говорить кратко, то можно выделить 3 основных задачи клиентской оптимизации:
  30. Оптимизация размера файлов.
  31. Оптимизация задержек при загрузке.
  32. Оптимизация взаимодействия с пользователем.
  33. Краткий обзор технологий
  34. При этом все основные методы можно разбить на 6 групп (каждая из которых позволяет решить одну из заявленных задач).
  35. Уменьшение размера объектов. Здесь фигурируют сжатие и методы оптимизации изображений, подробнее об этом можно прочитать во второй главе.
  36. Особенности кэширования , которые способны кардинально уменьшить число запросов при повторных посещениях, раскрываются в третьей главе.
  37. Объединение объектов. Основными технологиями являются слияние текстовых файлов, применение
  38. Параллельная загрузка объектов , влияющая на эффективное время ожидания каждого файла. В пятой главе помимо этого приведены примеры балансировки запросов со стороны клиентского приложения.
  39. Оптимизация CSS - производительности , что проявляется в скорости появления первоначальной картинки в браузере пользователя и скорости ее дальнейшего изменения. О CSS-производительности рассказывает ш
  40. Оптимизация JavaScript . Есть достаточно много проблемных мест в JavaScript, о которых необходимо знать при проектировании сложных веб-приложений. Обо всем этом можно прочитать в седьмой главе.
  41. Хочется отметить, что, несмотря на всю сложность затрагиваемой темы, первоначального ускорения загрузки веб-страницы можно добиться в несколько очень простых шаго
  42. Все советы в книге упорядочены по увеличению сложности внедрения и уменьшению возможного выигрыша при загрузке страницы. Для простых веб-проектов можно ограничит
  43. 1.2. Психологические аспекты производительности
  44. Терпимое время ожидания
  45. Эффекты медленной скорости загрузки
  46. Как время ответа сайта влияет на пользовательскую психологию
  47. 1.3. Стадии загрузки страницы
  48. Рис. 1. 2. Стадии загрузки страницы
  49. Расставляем приоритеты
  50. Узкие места
  51. 1.4. Клиентская и серверная оптимизация: сходство и различия
  52. Кэширование во главу угла
  53. Меньше запросов — легче серверу
  54. Архивировать и кэшировать на сервере
  55. Кто у кого на службе?
  56. 1.5. Применение в разработке приложений
  57. Пользователи обычно не знают, какие подходы применяются при разработке, как настроен сервер, какие клиентские и серверные средства разработки используются. Для ни
  58. Ниже рассказывается, как можно организовать создание веб-приложения, ориентируясь на самые важные аспекты клиентской оптимизации.
  59. Этап 1: Доставка информации и оформления
  60. На этом этапе разработчики должны сделать все возможное, чтобы не замедлить скорость загрузки страницы. Фактически идет речь об ускорении первой стадии загрузки. Н
  61. При загрузке страницы браузер запросит все CSS-файлы, объявленные в head страницы, последовательно. Поэтому каждый файл добавляет задержку в загрузке, равную времени з
  62. Итог первого этапа — это доставленный и оформленный HTML. И издержки на доставку JavaScript сведены к минимуму (на этом этапе он только мешает, поскольку замедляет отображ
  63. Этап 2: Кэширование файлов оформления и параллельные запросы
  64. На данном этапе разработчики должны обеспечить быструю загрузку других страниц сайта (если посетитель решит туда перейти). Этот этап должен проходить параллельно
  65. Одно или несколько дополнительных зеркал для выдачи статических ресурсов легко настраиваются в конфигурации, однако внедрить это в схему публикации изменений гор
  66. CSS Sprites достаточно трудоемки в автоматической «склейке», поэтому их внедряют обычно на первом этапе (при создании макета страниц). При использовании метода data:URI на первом
  67. Этап 3: Жизнь после загрузки страницы
  68. Целью данного этапа является создание различных обработчиков событий, которые должны взаимодействовать с пользователем. Это могут быть и всплывающие подсказки, и
  69. Говорят, что иногда «грамм видимости важнее килограмма сути» — это как раз про JavaScript. Ведь именно на нем можно реализовать механизмы, упрощающие действия пользоват
  70. К этому моменту мы должны иметь оформленную HTML-страницу, на которой все ссылки и формы
  71. У нас должны быть готовы серверные интерфейсы для AJAX-запросов; структура страницы должна быть такой, чтобы для аналогичных кусков HTML-кода не приходилось реализовыв
  72. Чтобы не уменьшать скорость доставки контента и оформления, JavaScript-файлы (лучше всего, конечно,
  73. Задача по обеспечению взаимодействия пользователя с интерфейсом сайта сводится к выполнению следующих действий:
  74. Все это напрямую следует из концепции «ненавязчивого» JavaScript, которая описана в седьмой главе.
  75. Поиск необходимых DOM-элементов должен нам дать список названий JavaScript-компонентов. Названия компонентов должны однозначно соответствовать названиям файлов на серв
  76. Список названий компонент можно объединить в один запрос к серверу. В итоге на стадии пост-загрузки должны осуществляться запросы к файлам вида
  77. У данного подхода есть два недостатка:
  78. В папке /jas/ (которую мы, например, используем для кэширования наиболее частых вариантов подключения модулей) через некоторое время может оказаться очень много файл
  79. Иногда на странице может оказаться очень много компонент, причем так много, что длина имени запрашиваемого объединенного файла перевалит за возможности файловой с
  80. Этап 4: Предупреждаем действия пользователя
  81. Если после посещения главной страницы большинство пользователей попадают внутрь сайта, то логично будет после полной загрузки главной страницы запрашивать стили
  82. Аналогично можно рассмотреть и предзагрузку некоторых наиболее часто используемых картинок, которые отсутствуют на главной странице, и дополнительных JavaScript-моду
  83. Естественно, что за балансировку третьей и четвертой стадий отвечает уже JavaScript-разработчик и фронтенд-архитектор — ведь именно в зоне ответственности последнего
  84. Глава 2. Уменьшение размера
  85. 2.1. Насколько ресурсоемко архивирование HTML
  86. Издержки на использование mod_gzip
  87. Формализация модели
  88. Набор тестов
  89. Результаты тестирования
  90. Пара слов о файловой системе
  91. Что быстрее: gzip или канал?
  92. Исследование степени gzip-сжатия и загрузки процессора
  93. Рассмотрим далее, насколько сильно издержки на gzip зависят от степени сжатия, и как их прогнозировать с учетом всех остальных параметров. Новая серия тестов была нап
  94. Как и ранее, на сервере проводились серии тестов по 10000 итераций в каждом. Замерялось время работы gzip при различных степенях сжатия. Затем оно усреднялось по серии, и
  95. Рис. 2.5 . Издержки на gzip от степени сжатия
  96. Далее график эффективности полученного сжатия (в % от оригинального размера файлов) от степени сжатия.
  97. Рис. 2.6 . Эффективность различных степеней gzip-сжатия
  98. Окончательные выводы
  99. Конфигурируем Apache 1.3
  100. Конфигурируем Apache 2
  101. 2.2. CSS и JavaScript в виде архивов
  102. Статическое архивирование в действии
  103. Проблемы для Safari
  104. Конфигурируем Apache
  105. Маленькие «но»
  106. Два слова о nginx
  107. 2.3. Все о сжатии CSS
  108. Инструменты
  109. Графические результаты
  110. Рис. 2.7 . Эффективность различных инструментов для минимизации CSS-файлов по сравнению с
  111. Рис. 2.8 . Эффективность различных инструментов для минимизации CSS-файлов вместе с дополнительным архивированием по сравнению с
  112. Рис. 2.9 . Эффективность различных инструментов для минимизации CSS-файлов вместе с дополнительным архивированием, увеличенный масштаб
  113. Выводы
  114. Практический пример
  115. 2.4. JavaScript: жать или не жать?
  116. Инструменты и методика
  117. Графические результаты
  118. Рис. 2 .10 . Эффективность различных инструментов для минимизации JavaScript-файлов вместе по сравнению с gzip
  119. Рис. 2.1 1 . Эффективность различных инструментов для минимизации JavaScript-файлов вместе с дополнительным архивированием по сравнению с
  120. Рис. 2.12 . Эффективность различных инструментов для минимизации JavaScript-файлов вместе с дополнительным архивированием, увеличенный масштаб
  121. Промежуточные выводы
  122. Есть ли жизнь после сжатия?
  123. Скорость загрузки JavaScript-библиотек
  124. Методы упаковки JavaScript
  125. Вариант
  126. Среднее время
  127. Уменьшенный
  128. 519.7214
  129. Упакованный
  130. 591.6636
  131. Нормальный
  132. 645.4818
  133. Производительность загрузки JavaScript-библиотек
  134. Инструментарий
  135. Среднее время
  136. jquery-1.2.1
  137. 732.1935
  138. dojo-1.0.1
  139. 911.3255
  140. prototype-1.6.0
  141. 923.7074
  142. yahoo-utilities-2.4.0
  143. 927.4604
  144. protoculous-1.0.2
  145. 1136.5497
  146. Инструментарий
  147. Среднее время
  148. yahoo-utilities-2.4.0
  149. 122.7867
  150. Jquery-1.2.1
  151. 131.1841
  152. prototype-1.6.0
  153. 142.7332
  154. dojo-1.0.1
  155. 171.2600
  156. protoculous-1.0.2
  157. 276.1929
  158. 2.5. PNG против GIF
  159. Алгоритмы сжатия
  160. Возможности PNG
  161. Поддержка PNG в браузерах
  162. PNG и проблема соответствия для фоновых CSS-изображений
  163. Анимированные PNG: MNG против "PNG+"
  164. Двигаемся к маленьким PNG
  165. Полезные советы
  166. Ниже приведено несколько простых советов, как текущие изображения можно дополнительно уменьшить в размере. Можно написать простой скрипт, который перебирает дире
  167. Преобразовывает GIF в PNG (и проверяет, есть ли при этом выигрыш):
  168. или так
  169. Уменьшает PNG-файлы в размере:
  170. если при этом нужно удалить и gAMA-чанк, то:
  171. если при этом хотим удалить другие чанки, отвечающие за цветовую коррекцию, то:
  172. Уменьшает JPEG-файлы в размере (без потери качества):
  173. Под Windows для уменьшения PNG-изображений можно использовать
  174. Для отдельно взятой страницы общий размер изображений может быть уменьшен на 20–30% только благодаря следованию этим простым советам.
  175. 2.6. Разгоняем favicon.ico — это как?
  176. Краткое описание формата
  177. Боевое крещение
  178. Оптимальные размеры
  179. Палитра
  180. Размер (в байтах)
  181. 2 бита
  182. 198
  183. 4 бита
  184. 318
  185. 8 бит
  186. 1406
  187. 24 бита
  188. 894
  189. 32 бита
  190. 1150
  191. PNG — быть или не быть?
  192. А если еще и сжать?
  193. data:URI нас спасет?
  194. Заключение
  195. 2.7. Режем cookie
  196. Оптимизируем размер, зону и время действия
  197. Хостинг для компонентов без cookie
  198. Глава 3. Кэширование
  199. 3.1. Expires, Cache-Control и сброс кэша
  200. Настройка заголовка HTTP Expires
  201. Спецификация кэширования
  202. Практическое запрещение кэширования
  203. Разрешение кэширования
  204. Форсированный сброс кэша
  205. 3.2. Кэширование в IE: pre-check, post-check
  206. Спецификация
  207. Рассматриваем подробнее
  208. Рис. 3.1 . Диаграмма работы pre-check и post-check
  209. Пример использования
  210. 3.3. Last-Modified и ETag
  211. Давайте рассмотрим, какие существуют альтернативы прямому ограничению повторных загрузок ресурсов со стороны сервера и сохранению их в пользовательском кэше.
  212. Last-Modified
  213. Дополнительно к заголовку Cache-Control, который предупреждает браузер, что последний может не запрашивать исходный документ с сервера некоторое время, будет полезно пр
  214. Как это работает? Дополнительно к периоду кэширования сервер может также отправить заголовок Last-Modified, который будет обозначать время последнего изменения файла на
  215. Данная схема позволяет экономить время, затрачиваемое на передачу данных, однако при ее использовании браузер все равно будет устанавливать соединение с сервером
  216. ETag
  217. ETag ( англ . Entity Tags — тэги сущностей) — механизм, который используют браузеры и веб-серверы, чтобы определить, является ли объект, находящийся в кэше браузера, таким же, как соответств
  218. Позднее, если браузер хочет определить актуальность компонента, он передает заголовок If-None-Match для передачи ETag обратно на сервер. Если ETag совпадают, ответ от сервера
  219. Включить ETag для Apache можно, например, следующей директивой в конфигурации:
  220. При этом ETag будет сформирован из даты изменения файла и его размера.
  221. Синхронизация ETag и Last-Modified
  222. Проблема ETag состоит в том, что обычно они используют атрибуты, специфичные в пределах одного сервера. ETag не совпадут, если браузер загрузит компонент страницы с одн
  223. Apache 1.3 и 2 генерирует ETag в формате inode-size-timestamp. Даже если один и тот же файл на разных серверах лежит в одной и той же папке, имеет те же права, размер и время, номер его иногда
  224. IIS 5.0 и 6.0 имеют похожий формат ETag: Filetimestamp:ChangeNumber. ChangeNumber — внутренняя переменная IIS для отслеживания изменений в конфигурации самого IIS, и нет гарантии, что эта переменна
  225. В результате ETag, которые сгенерирует Apache или IIS для одного и того же файла, будут отличаться на разных серверах. Если ETag не будут совпадать, пользователь не будет пол
  226. Если сайт находится только на одном сервере, это не будет большой проблемой. Но если вы используете несколько серверов с Apache или IIS, устанавливающие ETag в соответстви
  227. Если вы не получаете всех преимуществ, которые предоставляет ETag, тогда лучше совсем отключить его. Тег Last-Modified позволяет проверять актуальность компонента на основ
  228. в конфигурационный файл сервера.
  229. 3.4. Кэширование в iPhone
  230. Попадание в кэш
  231. Сжатые компоненты
  232. После перезагрузки
  233. Заключение
  234. Глава 4. Уменьшение числа запросов
  235. 4.1. Объединение HTML- и CSS-файлов
  236. CSS- файлы в начале страницы
  237. Объединение CSS-файлов
  238. Практическое решение
  239. Два слова об условных комментариях
  240. 4.2. Объединение JavaScript-файлов
  241. Все внешние JavaScript-файлы с сайта можно слить в один большой, загружаемый только один раз и навсегда. Это очень удобно: браузер не делает тысячу запросов на сервер для
  242. Как всегда, в бочке меда есть ложка дегтя: в объединенный файл попадает много того, что при первом запросе можно было бы и не загружать. Чаще всего для борьбы с этим п
  243. Конструктивные предложения
  244. Для начала стоит разобрать используемый фреймворк на составные части. JSON — отдельно, AJAX — отдельно, работа с DOM — отдельно, формы — отдельно. После этого задача «вы
  245. Информацию о зависимостях между составными частями можно хранить в удобном для автоматического использования виде. (Формы используют функции DOM, JSON — AJAX и так дале
  246. Также можно хранить информацию о том, какие именно модули нужны сайту в целом. Используется ли AJAX? Если ли формы? Может быть, какие-то необычные элементы управления?
  247. Да, естественно, все это можно и нужно автоматизировать.
  248. В теории
  249. С формальной точки зрения, после того как первые два предложения воплощены в жизнь, у нас появляется дерево зависимостей. Например, такое:
  250. Дальше мы выбираем непосредственно нужные сайту вершины. Пусть это будут dom.js и animated.pane.js. Теперь это дело техники — обойти получившийся набор деревьев в глубину:
  251. ... удалить повторяющиеся элементы:
  252. и слить соответствующие модули воедино.
  253. На практике
  254. Хранить информацию о зависимостях можно, например, следующим образом (добавляя в «модули» служебные комментарии):
  255. Выделить подобные метки из текстового файла не составляет труда. Естественно, чтобы получить полное дерево зависимостей, надо будет пройтись по всем доступных фай
  256. К чему мы пришли?
  257. Затратив один раз кучу времени на формирование модулей и зависимостей между ними, мы экономим время
  258. Итак, мы оставили нового пользователя наедине с единственным JavaScript-файлом, не включающим ничего лишнего. Стал ли при этом пользователь счастливее? Ничуть. Наоборот
  259. Немного из теории HTTP-запросов
  260. Время загрузки ресурса через HTTP-соединение складывается из следующих основных элементов:
  261. Итак, время загрузки страницы будет состоять из времени загрузки HTML-кода и всех внешних ресурсов: изображений, CSS- и JavaScript-файлов. Основная проблема в том, что CSS и JavaS
  262. Общие временные затраты при этом составят 3(T1+L) + R(A+B+C).
  263. Объединяя файлы, мы уменьшаем количество запросов на сервер:
  264. Очевидна экономия в 2(T1 + L).
  265. Для 20 ресурсов эта экономия составит уже 19(T1 + L). Если взять достаточно типичные сейчас для домашнего/офисного Интернета значения скорости в 256 Кбит/с и пинга ~20-30 мс,
  266. На первый взгляд, теория говорит, что загрузка страниц должна стать быстрее. В чем же она
  267. Суровая реальность
  268. Пусть у нашего сайта есть три страницы — P1, P2 и P3, поочередно запрашиваемые новым пользователем. P1 использует ресурсы A, B и C, P2 — A, С и D, а P3 — A, С, E и F. Если ресурсы не о
  269. Если мы слили воедино абсолютно все JavaScript-модули сайта, получаем:
  270. Результатом становится увеличение времени загрузки самой первой страницы, на которую попадает пользователь. При типовых значениях скорости/пинга мы начинаем прои
  271. Если мы объединили только модули, необходимые для текущей страницы, получаем следующее:
  272. Каждая отдельно взятая страница при пустом кэше будет загружаться быстрее, но все они вместе — медленнее, чем в исходном случае. Получаем, что слепое использование
  273. Возможное решение
  274. Конечно же, выход из сложившегося положения есть. В большинстве случаев для получения реального выигрыша достаточно выделить «ядро» — набор модулей, используемых
  275. Вдумчивый читатель сейчас возмутится и спросит: «А что, если ядра нет? Или ядро получается слишком маленьким?». Ответ: это легко решается вручную выделением 2-3 незав
  276. Реализация на PHP
  277. PHP Speedy
  278. 4.3. Техника CSS Sprites
  279. Простой rollover-эффект
  280. Рис. 4.1 . Пример фонового изображения для простого rollover-эффекта. Источник: www.websiteoptimization.com
  281. Сложный rollover-эффект
  282. Рис. 4.2 . Пример фонового изображения для сложного rollover-эффекта. Источник: www.spegele.com
  283. Проблемные места в IE
  284. CSS Image map
  285. Рис. 4.3 . Пример изображения для CSS Image Map. Источник: www.acronis.com
  286. Статичные картинки
  287. Рис. 4.4 . Пример фонового изображения «все-в-одном». Источник: webo.in
  288. Онлайн-генераторы
  289. Полезные советы
  290. Рис. 4.5 . Пример фонового изображения с расположением картинок «лесенкой». Источник: webo.in
  291. 4.4. Картинки в теле страницы с помощью data:URI
  292. Поддержка браузерами
  293. Схема data:URI
  294. Рис. 4.6 . Пример изображения, вставленного с помощью data:URI. Источник webo.in
  295. CSS и встроенные изображения
  296. Проблемы data:URI
  297. Работа в Internet Explorer
  298. Преимущества и недостатки data:URI
  299. Дополнительные соображения по оптимизации
  300. Кроссбраузерное использование data:URI
  301. О, этот странный Microsoft!
  302. Объединяем несовместимое
  303. Панацея или ящик Пандоры?
  304. Валидность
  305. Некоторые итоги
  306. Включение музыки (base64)
  307. 4.5. CSS Sprites и data:URI
  308. Проблемы при верстке
  309. Рис. 4.7 . Пример CSS Sprites со страницы поиска Google. Источник: www.google.com
  310. Проблемы при загрузке
  311. Проблемы при использовании
  312. Шаг за шагом
  313. Выносим CSS-файлы в пост-загрузку
  314. При использовании data:URI итоговый CSS-файл занимает довольно большой объем (фактически равный 110-120% от размера всех картинок и набору базовых CSS-правил). И это в виде арх
  315. Для решения этой проблемы, во-первых, нам нужно разделить весь массив CSS-правил на относящиеся к фоновым изображениям и не относящиеся. Во-вторых, сообщить браузерам
  316. Фактически, используя такой подход, мы создаем другой контейнер для фоновых изображений (не ресурсное изображение, а CSS-файл), который удобнее использовать в большинстве случаев. Мы объединяем все фо
  317. Теоретическое решение
  318. Все гениальное просто, поэтому мы можем загружать в самом начале страницы достаточно небольшой CSS-файл (без фоновых изображений, только базовые стили, чтобы только
  319. Тут есть и возможные минусы: после загрузки каждого дополнительного CSS-файла будет происходить перерисовка страницы. Однако если таких файлов всего 1 или 2, то отобр
  320. Почему мы не может распараллелить загрузку файлов стилей в самом начале документа? Потому что два файла будут загружаться медленнее, чем один (файлы загружаются по
  321. На практике
  322. На практике все оказалось не сильно сложнее. Мы загружаем в head страницы (до вызовов любых внешних файлов) наш «легкий» CSS:
  323. а затем добавляем в комбинированный обработчик window.onload (подробнее о нем рассказывается в седьмой главе) создание нового файла стилей, который дополняет уже загрузи
  324. В результате мы имеем максимально быстрое отображение страницы, а затем стадию пост-загрузки, которая вытянет с сервера все дополнительные картинки (тут уже сам бр
  325. А доступность?
  326. Внимательные читатели уже заготовили вопрос: а что, если у пользователя отключен JavaScript? Тут всё должно быть просто: мы добавляем соответствующий
  327. После небольших экспериментов было выделено следующее изящное решение, обеспечивающее работу схемы во всех браузерах (замечание: после многочисленных эксперимен
  328. В результате браузер с включенным JavaScript запишет начало комментария, а закроет его только после
  329. Делаем решение кроссбраузерным
  330. В ходе тестирования в Internet Explorer обнаружилось, что если добавлять файл стилей сразу параллельно со скриптами (в функции, которая для него срабатывает по onreadystatechange), т
  331. В Safari же логика отображения страницы в зависимости от загружаемых файлов отличается от всех браузеров. Если в двух словах, то можно жестко определить начальный наб
  332. У Safari второй подход, поэтому ничего лучше выноса загрузки динамического CSS-файла с фоновыми картинками после срабатывания window.onload для этого браузера пока не сущест
  333. Итак, давайте объявим функцию для создания динамического файла стилей:
  334. Выигрыш
  335. При наличии у вас большого количества маленьких декоративных фоновых изображений, которые к тому же могут повторяться по различным направлениям, может быть очень
  336. Описанная техника (кроссбраузерный data:URL плюс динамическая загрузка файлов стилей) позволяет добиться всех преимуществ технологии CSS Sprites, не затягивая загрузку ст
  337. Таким образом, data:URI (в смысле влияния на скорость загрузки) равносильны CSS Sprites (или даже предпочтительнее последней, если учесть, что для повторяющихся и полупрозра
  338. 4.6. Методы экстремальной оптимизации
  339. Чем больше число внешних ресурсов, к которым браузер обращается при загрузке, тем больше время требуется для отображения страницы. Как правило, веб-страницы обраща
  340. Объединение JavaScript и CSS в одном файле
  341. Однако существует способ объединения CSS с JavaScript и сведения количества загрузок к одной. Техника основана на том, как CSS и анализатор JavaScript ведут себя в IE и Firefox.
  342. Рассмотрим на примере
  343. Когда анализатор CSS будет разбирать вышеупомянутый код, символы комментария HTML будут пропущены, и код станет эквивалентным следующему примеру:
  344. Анализатор CSS видит только CSS-код, а код скрипта закомментирован (/* ... */).
  345. Когда анализатор JavaScript станет разбирать код, символы комментария HTML будут интерпретированы в комментарии строки (//), и, следовательно, код станет таким:
  346. Анализатор JavaScript видит только код скрипта, а все остальное закомментировано. Чтобы ссылаться на этот ресурс, можно использовать теги
  347. Заметим, что эти два тега ссылаются на один тот же ресурс и, следовательно, он загрузится всего один раз и будет интерпретирован и как стили, и как скрипты.
  348. Есть еще одна вещь, о которой стоит позаботиться, — Content-Type ответа. Его необходимо выставлять в */*, чтобы дать подтверждение Firefox: содержание может быть обработано ка
  349. Указанное решение не работает в Safari (1-5% пользователей), однако конкретно для этого браузера (определив его через User-Agent) уже можно вставить загрузку еще одного файла
  350. Объединение HTML, CSS и JavaScript в одном файле
  351. Чтобы избежать дополнительных запросов со стороны браузера, можно включить непосредственно стилей и(ли) скриптов в сам HTML-документ.
  352. Здесь стоит остановиться на следующем моменте: если размер CSS- (или JavaScript-) файла больше, чем 20% (и при этом больше 5 Кб в сжатом виде), лучше вынести его как отдельный ко
  353. Рассматривать включение всех ресурсов в исходную HTML-страницу стоит только в том случае, если достаточно большой процент посетителей (больше 90%) пришли на нее в перв
  354. Во всех остальных случаях — когда можно выделить достаточно большие ресурсные файлы или когда достаточное количество пользователей приходят не в первый раз — так
  355. Как рабочий пример можно привести заглавные страницы Яндекса и Google — на них вызывается минимум внешних ресурсов, а стилевые правила включены в саму страницу.
  356. Глава 5. Параллельные соединения
  357. 5.1. Обходим ограничения браузера на число соединений
  358. Активное ( англ. keep-alive ) соединение стало настоящим прорывом в спецификации HTTP 1.1: оно позволяло использовать уже установленный канал для повторной передачи информации от клиента к серве
  359. Однако HTTP 1.1 добавил веб-разработчикам головной боли по другому поводу. Давайте будем разбираться, как нам устранить и эту проблему.
  360. Издержки на доставку объектов
  361. Средняя веб-страница содержит более 50 объектов, и издержки на число объектов доминируют над всеми остальными задержками при загрузке большинства веб-страниц. Брау
  362. Если число объектов на странице превышает 4, то издержки на ожидание доступных потоков и разбор чанков для присланных объектов превалируют над общим временем загру
  363. При увеличении числа подключаемых объектов сверх 10 время, затрачиваемое на инициализацию соединения, возрастает до 80% и более от общего времени, уходящего на получ
  364. Ограничения спецификации HTTP/1.1
  365. Спецификация HTTP, приблизительно 1999 года, рекомендует, чтобы браузеры и серверы ограничивали число параллельных запросов к одному хосту двумя. Эта спецификация был
  366. Времена меняются
  367. «Режем» соединения
  368. Вы можете, естественно, настроить несколько серверов для обслуживания выдачи картинок или других объектов, чтобы увеличить число параллельных загрузок. Например:
  369. Однако каждый из этих поддоменов не обязан находиться на отдельном сервере.
  370. Реальный выигрыш
  371. Подводим итоги
  372. Сейчас средняя веб-страница состоит более чем из 50 объектов (для Рунета, по статистическим данным
  373. При этом нужно помнить, что увеличение одновременных запросов повлечет задействование дополнительных ресурсов со стороны сервера (это может быть, например, как ма
  374. Стоит коснуться еще одного, весьма интересного момента в оптимизации времени загрузки путем увеличения числа параллельных потоков. Заключается он в выравнивании
  375. Можно пойти и дальше и загружать, например, 4 картинки по 50 Кб в 4 потока, достигая просто феноменального ускорения. Однако тут играет роль психологический фактор: по
  376. Стоит подчеркнуть, что данный подход применим и к другим ресурсным (в том числе и HTML) файлам, однако стоит помнить о весьма жестких ограничениях браузеров на загрузк
  377. 5.2. Content Delivery Network и Domain Name System
  378. Подключаем CDN
  379. Yahoo! и Google
  380. Количество DNS-запросов
  381. 5.3. Балансировка на стороне клиента
  382. Балансировка нагрузки повышает надежность веб-сайта путем распределения запросов между несколькими (кластером) серверами, если один из них перегружен или отказал
  383. Round-Robin DNS
  384. Популярным, хотя и очень простым подходом для балансировки запросов является циклический DNS. Он подразумевает создание нескольких записей в таблице DNS для одного д
  385. После каждого пользовательского запроса к таблице DNS для www.loadbalancedwebsite.ru, запись, стоящая первой, меняется. Ваш браузер будет использовать первую запись, поэтому все
  386. Можно, конечно, перенести IP-адрес на соседний сервер, который может нести нагрузку. Однако данная процедура весьма хлопотная, чтобы проводить ее в условиях аврала.
  387. Балансировка на сервере
  388. Другим популярным подходом для балансировки запросов является создание одного выделенного сервера, который отвечает за распределение запросов. Примерами таких с
  389. Балансировка на стороне клиента
  390. Существует еще один подход для распределения нагрузки на серверы от современных веб-приложений, который не нуждается в дополнительном балансирующем оборудовании
  391. Вместо того чтобы сказать клиенту, что у нас единственный сервер, можно сообщить о нескольких серверах — s1.loadbalancedsite.ru, s2.loadbalancedsite.ru и так далее. При этом клиентское п
  392. В отличие от веб-приложений, которые хранят код (Javascript или Flash) на одном сервере, обеспечивающем доступ к этой информации, клиентское приложение не зависимо от серве
  393. Рис. 5 .3 . Пример балансировки нагрузки и масштабируемости на клиенте
  394. Итак, можно ли эту технику применить к веб-приложениям? Веб-приложения самой своей сутью размывают границу между клиентской и серверной частями любого стандартног
  395. Сейчас сервер обеспечивает такие ресурсы, как картинки. Но этот факт становится не столь очевидным, если рассмотреть технику CSS Sprites, когда одна картинка является ис
  396. Для обеспечения балансировки на стороне клиента от современного веб-приложения требуется три основных составляющих:
  397. Заметно проще повысить доступность и масштабируемость HTML-кода страниц и других файлов, требуемых на клиенте, чем осуществить то же самое для серверных приложений:
  398. Мы можем включить список доступных серверов в клиентский код точно так же, как сделали бы это для настольного приложения. У веб-приложения доступен файл servers.xml, в ко
  399. Осуществляем кросс-доменные запросы
  400. Даже при небольшом опыте работы с AJAX уже должно было возникнуть закономерное возражение: «Это не будет работать из-за кроссдоменной безопасности» (для предотвраще
  401. Для обеспечения безопасности пользователей веб-браузеры и Flash-клиенты блокируют пользовательские вызовы к другим доменам. Например, если клиентский код хочет обра
  402. Для Flash-клиентов можно просто создать файл crossdomain.xml, который будет разрешать запросы на *.loadbalancedwebsite.ru:
  403. Для клиентского кода на AJAX существуют жесткие ограничения на передачу данных между доменами, которые зависят от методов, используемых для серверных вызовов. Приме
  404. Но что, если на клиенте используется XMLHttpRequest? XHR попросту запрещает клиенту запрашивать отличный от исходного домена сервер. Однако существует небольшая лазейка: е
  405. А если все же AJAX?
  406. Проблема решена.
  407. Преимущества балансировки на стороне клиента
  408. Итак, как только мы обговорили технику, позволяющую осуществлять кроссдоменные вызовы, можно обсудить, собственно, как работает сам балансировщик и как он удовлетв
  409. Подведем итог: каковы же преимущества балансировки на стороне клиента перед балансировкой на стороне сервера? Наиболее очевидное заключается в том, что не требует
  410. Другим преимуществом является то, что все серверы не обязаны быть расположенными в одном месте. Клиент сам выбирает, к какому серверу ему лучше подключиться, в отли
  411. Используем Cloud Computing для балансировки на стороне клиента
  412. В качестве серверной основы приложения можно рассмотреть сервисы Simple Storage Service (S3) и Elastic Computing Cloud (EC2) от
  413. Изначально сервис S3 предоставлял прекрасную возможность для хранения и доставки видеосообщений, а EC2 был спроектирован именно для работы с S3. Он позволяет расширят
  414. Однако большим минусом для EC2 является невозможность проектирования балансировки нагрузки на стороне сервера, у которого не было бы уязвимых мест. Многие веб-прило
  415. Пример приложения
  416. При использовании описанной выше балансировки на стороне клиента становится возможным избежать этого неприятного момента и существенно повысить надежность всег
  417. Чуть раньше указывалось на использование файла servers.xml для оповещения клиента о доступных серверах, но для S3 можно использовать более простой способ. При обращении
  418. Например, по адресу http://s3.amazonaws.com/application/?actions=loadlist будет находиться следующий файл:
  419. В этом примере присутствуют два EC2-сервера в кластере, с IP-адресами 216.255.255.1 и 216.255.255.2 соответственно.
  420. Логика для скрипта, запускающегося по расписанию
  421. Так как скрипт, запускающийся по cron, является частью виртуальной машины EC2, каждая такая машина автоматически регистрируется как доступный сервер в кластере. Клиен
  422. Если виртуальная машина EC2 отказывает или выключается, то другие машины самостоятельно убирают ее запись из сегмента: в сегменте остаются только доступные серверы
  423. 5.4. Редиректы, 404-ошибки и повторяющиеся файлы
  424. Редиректы
  425. 404- ошибки
  426. 5.5. Асинхронные HTTP-запросы
  427. Моделируем параллельные запросы
  428. Рис. 5.4 . Влияние HTTP - конвейера и постоянного соединения на скорость передачи данных. Источник: www.die.net
  429. Предварительные выводы
  430. Рис. 5.5 . Выигрыш при включении постоянного соединения и нескольких хостов для различных пользователей. Источник: www.die.net
  431. Влияние заголовков
  432. Рис. 5.6 . Влияние заголовков на эффективную пропускную способность канала
  433. 5.6. Уплотняем поток загрузки
  434. Реальная ситуация
  435. Рис. 5.7 . Диаграмма загрузки (неизмененного) сайта WebHiTech .
  436. Шаг первый: простая страница
  437. Шаг второй: уменьшаем изображения
  438. Шаг третий: все-в-одном
  439. Шаг четвертый: нарезаем поток
  440. Шаг пятой: алгоритмическое кэширование
  441. Итоговая таблица
  442. Номер шага
  443. Описание
  444. Общий размер (кб)
  445. Время загрузки (мс)
  446. Шаг шестой: балансируем стадии загрузки
  447. Шаг седьмой: балансируем кэширование
  448. Заключение
  449. Глава 6. CSS оптимизация
  450. 6.1. Оптимизируем CSS expressions
  451. CSS- выражения
  452. Динамические выражения
  453. Вычисление постоянных
  454. Использование
  455. Реализация
  456. Все так просто? Нет, еще проще
  457. 6.2. Что лучше, id или class?
  458. Методика. Размер файлов
  459. Время открытия страницы
  460. Результаты
  461. Firefox 2
  462. Opera 9.5
  463. Safari 3
  464. IE 7
  465. IE 6
  466. IE 5.5
  467. p.class
  468. .class
  469. p#id
  470. #id
  471. div > p.class
  472. div > .class
  473. div > p#id
  474. div > #id
  475. div p.class
  476. div .class
  477. div p#id
  478. div #id
  479. div.div p.class
  480. div.div .class
  481. div.div p#id
  482. div.div #id
  483. Выводы
  484. 6.3. Влияние семантики и DOM-дерева
  485. Давайте рассмотрим сейчас другой вопрос, а именно: как быстро браузер создает DOM-дерево в зависимости от наличия в нем элементов с id или class?
  486. Для этого мы подготовим 3 набора HTML-файлов. Первый будет содержать 10000 элементов, у которых только часть будет иметь id (количество именованных элементов варьируется
  487. Графики влияния DOM-дерева
  488. Ниже приведены разделенные графики по средневзвешенному (естественно, основную роль играет Internet Explorer, ибо сейчас им пользуются от 50% до 70% посетителей наших сайтов)
  489. Рис. 6.1 . Скорость создания документа, средневзвешено по всем браузерам
  490. и график для времени выборки одного элемента из дерева (по идентификатору) при наличии в этом же дереве различного числа элементов с идентификаторами. ID (10000 get) пока
  491. Рис. 6.2 . Скорость выбора элемента, средневзвешено по всем браузерам
  492. Выводы по DOM-дереву
  493. По графику средневзвешенных значений хорошо видно, что при прочих равных условиях создание документа с class обходится меньшей кровью, чем с id (в общем случае от 2% до 1
  494. Для документа со 100 элементами выигрыш может составить почти 1 мс, для документа с 1000 — 8,5 мс! Стоит заметить, что средняя страница в интернете имеет 500–1000 элементов.
  495. javascript:alert(document.getElementsByTagName(*).length)
  496. Естественно, что приведенные цифры — это уже то, за что можно побороться.
  497. В случае больших веб-приложений задержка в 100 мс (при числе элементов более 10000) уже может оказаться критичной. Ее можно и нужно уменьшать (наряду с другими «узкими» м
  498. Что и требовалось доказать: значительную нагрузку составляет именно создание DOM-дерева в документе. В целом, на эту операцию уходит от 70% всего времени рендеринга (т
  499. На скорость вычисления одного элемента по идентификатору, как ни странно, наибольшее влияние оказывает опять-таки DOM-дерево, а не количество таких элементов. Даже п
  500. Семантическое DOM-дерево
  501. Логическим продолжением уже проведенных исследований CSS/DOM-производительности браузеров стало рассмотрение зависимости времени создания документа от числа тегов
  502. В итоге мы получили примерно следующую картину:
  503. Рис. 6. 3 . Средневзвешенное значение времени создания документа от числа узлов в DOM-дереве
  504. Что быстрее?
  505. Да, очевидно, что размер DOM-дерева влияет на скорость загрузки страницы. Одной из целей данного исследования было показать, как именно влияет (в конкретных числах). С
  506. Различия между линейной и древовидной структурами находятся в пределах погрешности, однако семантическое дерево оказалось самым медленным (чуть ли не на 50%). Но в л
  507. Конечной же целью всех экспериментов было установить, есть ли различие в отображении HTML 4.0 Transitional и XHTML 1.0 Strict документов и какова реальная польза от использования с
  508. Методика для DOCTYPE
  509. Была аккуратно выкачана главная страница Яндекса (она уже хорошо оптимизирована с точки зрения производительности, поэтому проводить эксперименты на ней весьма п
  510. Далее была добавлена стандартная схема измерения загрузки (рендеринга) страницы: время в самом начале head засекается и затем отнимается от времени срабатывания соб
  511. В качестве второй версии страницы бралось приведение ее к валидному XHTML Strict виду. Верстка при этом немного изменилась, но в целом результат получился весьма убедите
  512. Далее в третьей версии уже были убраны все onclick. Больше ничего со страницей не делалось. Ожиданий данная версия не оправдала (только Safari показал значимые отличия от
  513. В четвертом варианте — венце оптимизационных (в отношении CSS/HTML-кода) действий — использование id было сведено к минимуму, все селекторы для class задавались без тегов
  514. Результаты оптимизации
  515. В таблице приведены результаты для основных браузеров (август 2008): размер каждого варианта в байтах и время его загрузки. Времена приведены в миллисекундах.
  516. Size (b)
  517. Gzip (b)
  518. IE6
  519. IE7
  520. IE8b
  521. Firefox 2
  522. Firefox 3
  523. Opera 9.5
  524. Safari 3.1
  525. 1
  526. 26275
  527. 8845
  528. 56
  529. 80
  530. 76
  531. 130
  532. 127
  533. 142
  534. 33
  535. 2
  536. 27173
  537. 8993
  538. 60
  539. 75
  540. 320
  541. 127
  542. 118
  543. 148
  544. 27
  545. 3
  546. 26260
  547. 8949
  548. 61
  549. 75
  550. 320
  551. 131
  552. 116
  553. 141
  554. 23
  555. 4
  556. 26153
  557. 8862
  558. 55
  559. 73
  560. 306
  561. 94
  562. 102
  563. 178
  564. 28
  565. «Экономия на спичках»?
  566. В результате тестов удалось показать, что валидный XHTML не медленнее (а даже местами быстрее), чем HTML. И оптимизация реально играет роль (возможно ускорение загрузки H
  567. Естественно, это все «копейки» для обычных пользователей (+/-50 мс —это совершенно не критично). Однако если речь идет про «экономию на спичках», когда нам важен кажды
  568. И что важнее всего, если правильно расставить акценты, то загрузку XHTML можно сделать и быстрее, чем HTML. Различие в размере файлов оказалось в итоге минимальным (26153 пр
  569. В целом в свете тотального распространения мобильных браузеров с их маломощными процессорами такой вид оптимизации выглядит весьма перспективно.
  570. 6.4. Ни в коем случае не reflow!
  571. offsetHeight и style.display
  572. IE sp62
  573. IE8b
  574. Firefox 2.0.0.12
  575. Opera 9.22
  576. Safari 3.04b
  577. clean
  578. 128
  579. 153
  580. 15
  581. 15
  582. 16
  583. offsetHeight
  584. 23500
  585. 10624
  586. 4453
  587. 4453
  588. 5140
  589. style.display
  590. 171
  591. 209
  592. 56
  593. 56
  594. 34
  595. height vs. style
  596. 140 раз
  597. 50 раз
  598. 80 раз
  599. 80 раз
  600. 150 раз
  601. Немного теории
  602. Использование Computed Style
  603. IE sp62
  604. Firefox 2.0.0.12
  605. Opera 9.22
  606. Safari 3.04b
  607. offsetHeight
  608. 23500
  609. 4453
  610. 4453
  611. 5140
  612. style.display
  613. 171
  614. 56
  615. 56
  616. 34
  617. getStyle
  618. 5219
  619. 5318
  620. Оптимизация: определение класса hide
  621. IE sp62
  622. Firefox 2.0.0.12
  623. Opera 9.22
  624. Safari 3.04b
  625. offsetHeight
  626. 23500
  627. 10624
  628. 4453
  629. 5140
  630. isHidden
  631. 231
  632. 351
  633. 70
  634. 71
  635. isHidden2
  636. 370
  637. 792
  638. 212
  639. 118
  640. offsetHeight vs. isHidden
  641. 102 раза
  642. 30 раз
  643. 73 раза
  644. 92 раза
  645. Заключение
  646. В качестве послесловия: стили или классы?
  647. Метод
  648. IE 6
  649. IE 7
  650. Firefox 1.5
  651. Firefox 2.0
  652. Opera 9
  653. element.className
  654. 512
  655. 187
  656. 291
  657. 203
  658. 47
  659. element.style.color
  660. 1709
  661. 422
  662. 725
  663. 547
  664. 282
  665. Перерисовка страницы
  666. Групповое изменение стилей
  667. Два слова о таблицах
  668. Глава 7. Оптимизация JavaScript
  669. 7.1. Кроссбраузерный window.onload
  670. Firefox впереди планеты всей
  671. А Internet Explorer?
  672. Условные комментарии
  673. Все так просто?
  674. Двойное выполнение
  675. Избавляемся от внешнего файла
  676. Полное решение
  677. Неблокирующая загрузка JavaScript
  678. Число загрузок с одного хоста
  679. Неблокирующие скрипты
  680. Зависимости
  681. А если по-другому?
  682. Метод
  683. Недостатки
  684. В будущем
  685. 7.2. Основы «ненавязчивого» JavaScript
  686. Javascript: храним отдельно
  687. Javascript — это расширение
  688. Доверять, но проверять
  689. Доступ к элементам
  690. Полезные советы
  691. Добавляем обработчики событий
  692. Ускоряем обработку событий
  693. Немного усложним
  694. Боремся с Internet Explorer
  695. Пойдем дальше
  696. Обработка событий в браузерах
  697. Давайте рассмотрим несколько практических способов работы с обработчиками событий в браузерах. Например, можно назначить обработчик напрямую:
  698. Если нужно несколько событий или просто «осторожничаем», то можно воспользоваться следующей распространенной записью:
  699. Или таким модицифицированным вариантом (меньше символов):
  700. Можно также использовать отдельную переменную для обработчика события:
  701. Или записать в одну строку с использованием условной компиляции:
  702. Работаем с событиями
  703. Давайте рассмотрим, что мы можем извлечь из события после перехвата его с помощью соответствующего обработчика:
  704. 7.3. Применение «ненавязчивого» JavaScript
  705. В предыдущих разделах были представлены некоторые теоретические аспекты построения клиентской логики, ориентированной на максимальное быстродействие и адекватн
  706. Принципы «ненавязчивой» рекламы
  707. document.write против innerHTML
  708. Контекстная реклама
  709. TopLine, Pop-Up, Pop-Under и RichMedia
  710. Внутренние рекламные сети
  711. Идеальная архитектура рекламной сети
  712. Разгоняем счетчики: от мифов к реальности
  713. Разбираем по косточкам
  714. А если сложнее?
  715. Делаем статистику динамической
  716. 7.4. Замыкания и утечки памяти
  717. Шаблоны утечек
  718. Циклические ссылки
  719. Более сложный случай
  720. Замыкания
  721. Постраничные утечки
  722. Псевдо-утечки
  723. Проектируем утечки
  724. 7.5. Оптимизируем «тяжелые» JavaScript-вычисления
  725. Оптимизируем вычисления
  726. Улучшаем шаблон
  727. Советы и замечания
  728. Заключение
  729. 7.6. Быстрый DOM
  730. DOM DocumentFragment: быстрее быстрого
  731. Нормальное добавление
  732. Добавление при помощи DocumentFragment
  733. Браузер
  734. Нормальный
  735. Fragment
  736. Firefox 3.0.1
  737. 90
  738. 47
  739. Safari 3.1.2
  740. 156
  741. 44
  742. Opera 9.51
  743. 208
  744. 95
  745. IE 6
  746. 401
  747. 140
  748. IE 7
  749. 230
  750. 61
  751. IE 8b1
  752. 120
  753. 40
  754. А если еще быстрее?
  755. innerHTML нам поможет
  756. Его можно значительно ускорить, если добавлять узлы не последовательно один за другим, а сначала создав HTML-строку со всем необходимым кодом, которая будет вставлен
  757. В данном примере кроме уже указанного ускорения еще используется первоначальное создание массива элементов, которые можно объединить через свойство join в строку. Д
  758. 7.7. Кэширование в JavaScript
  759. Итерации и локальное кэширование
  760. Кэширование ресурсоемких вызовов
  761. Кэшируем цепочки вызовов
  762. 7.8. Быстрые итераторы, регулярные выражения и другие вкусности
  763. Итераторы
  764. Браузер
  765. Обычный
  766. С кэшем
  767. for-in
  768. Обратный
  769. do-while
  770. Обратный while
  771. Firefox 3.0.3
  772. 714
  773. 657
  774. 835
  775. 280
  776. 297
  777. 217
  778. Safari 3.1.2
  779. 141
  780. 140
  781. 157
  782. 125
  783. 125
  784. 93
  785. Opera 9.61
  786. 188
  787. 125
  788. 765
  789. 94
  790. 94
  791. 78
  792. IE 6
  793. 1281
  794. 1219
  795. 1094
  796. 468
  797. 500
  798. 360
  799. IE 7
  800. 1391
  801. 1297
  802. 1250
  803. 515
  804. 532
  805. 406
  806. IE 8b2
  807. 954
  808. 906
  809. 922
  810. 406
  811. 422
  812. 328
  813. Chrome 0.2
  814. 288
  815. 246
  816. 332
  817. 117
  818. 114
  819. 95
  820. Регулярные выражения
  821. Браузер
  822. search
  823. match
  824. «На лету»
  825. Локальный
  826. exec
  827. test
  828. Firefox 3.0.3
  829. 2120
  830. 2041
  831. 1295
  832. 1273
  833. 1225
  834. 1348
  835. Safari 3.1.2
  836. 453
  837. 469
  838. 344
  839. 359
  840. 360
  841. 359
  842. Opera 9.61
  843. 2141
  844. 2063
  845. 406
  846. 344
  847. 312
  848. 313
  849. IE 6
  850. 2594
  851. 2516
  852. 1875
  853. 1859
  854. 1953
  855. 1906
  856. IE 7
  857. 2562
  858. 2469
  859. 1859
  860. 1844
  861. 2000
  862. 1860
  863. IE 8b2
  864. 2140
  865. 2032
  866. 1453
  867. 1453
  868. 1547
  869. 1469
  870. Chrome 0.2
  871. 856
  872. 870
  873. 416
  874. 397
  875. 385
  876. 392
  877. Глава 8. Приложение
  878. 8.1. Обзор аналитических инструментов
  879. Измеряем эффективную ширину канала пользователей
  880. Apache Benchmark и JMeter
  881. Кэширование на сервере
  882. Web Developer Toolbar для Firefox
  883. Firebug NET Panel для Firefox
  884. Yslow для Firebug для Firefox
  885. Web Inspector для Safari
  886. HttpWatch
  887. Fiddler
  888. Live HTTP Headers
  889. Прокси-эмулятор каналов Sloppy
  890. Analyze.WebSiteOptimization.com
  891. Octagate.com/service/SiteTimer/
  892. Tools.Pingdom.com
  893. AlertSite.com
  894. Site-Perf.com
  895. GetRPO.com
  896. Webo.in
  897. Профилирование JavaScript
  898. 8.2. Несколько советов для браузеров
  899. Ускоряем загрузку страниц в Firefox 3
  900. Как это работает?
  901. Ускоряем загрузку страниц в Opera 9
  902. Interner Explorer
  903. 8.3. Оптимизированные конфигурации
  904. Конфигурация Apache 1.3
  905. Конфигурация Apache 2
  906. Конфигурация nginx 0.7+
  907. Настройка IIS
  908. 8.4. Разбор полетов
  909. vkontakte.ru
  910. odnoklassniki.ru
  911. yandex.ru
  912. rambler.ru
  913. mail.ru
  914. rbc.ru
  915. lenta.ru
  916. kommersant.ru
  917. marketgid.ru
  918. habrahabr.ru
  919. Заключение
  920. В качестве послесловия


Ваше впечатление от этой книги  


Полный текст книги (читать онлайн): Разгони свой сайт

Скачать эту книгу (3535k) в формате: fb2, epub, mobi, txt, html

close [X]

close [X]


Комментарии


Ваше имя:     Ваше впечатление от этой книги

Комментарий:


получать комментарии о книге Разгони свой сайт на e-mail

Код авторизации Anti spam Capcha