Еще год назад у меня вызвало некоторое сомнение, что использование HTML 4.0 Transitional для разметки страницы будет экономичнее, чем XHTML 1.0 Strict с его жесткими стандартами оформления кода. Но тогда у меня не было особого желания проверять свою гипотезу, да я и плохо представлял, как это лучше сделать.
XHTML, являясь подмножеством XML, имеет более строгие требования к синтаксису, HTML допускает более свободную запись, этим можно воспользоваться.
Полная версия доклада про оптимизацию главной Яндекса
Итак, чтобы убедиться (или, наоборот, разочароваться) в преимуществах XHTML и не быть голословным после таких громких статей, как Class быстрее ID, Транзитивность транзитивности рознь и Общие тесты CSS-производительности, а также приняв во внимание цифры из перевода "Психологические аспекты производительности веб-страниц" (про семантику вообще промолчу :) было проведен эксперимент на главной странице Яндекса. Ибо все же интересно, как же практическое применение полученных знаний.
Конечной целью всех экспериментов было установить, есть ли различие в рендеринге HTML / XHTML-документов и какова реальная польза от использования советов по оптимизации CSS-кода (имеется в виду синтаксиса селекторов, а не размера кода).
Главная Яндекса была аккуратно выкачана, были удалены все ссылки на картинки и внешние скрипты (хотя последних особо замечено не было), чтобы не мешались по ходу эксперимента. В дальнейшем полученная «чистая» версия препарировалась различными способами.
Далее была добавлена стандартная схема замерения загрузки (рендеринга) страницы: засекается время в самом начале head, и отнимается от времени срабатывания события window.onload (в данном случае это равносильно окончанию рендеринга HTML-кода). Браузеры друг с другом не сравнивались (помним о нечестной игре со стороны Safari), сравнивались только различные варианты.
Для замеров бралась серия из 12 загрузок каждой страницы, из нее выбрасывались первые 2 результата (которые сильно зависят от времени выделения памяти на текущую вкладку/окно браузера и их тяжело воспроизводить), далее бралось среднее арифметическое из 10 загрузок.
Собственно, это была та самая «чистая» версия, с которой все сравнивалось.
webo.in/tests/css-efficiency-5/ya/
Приведение к валидному XHTML Strict. Верстка немного поехала, но, в целом, результат получился весьма убедительный. Комментарии и прочий мусор (типа пустых onclick="", о них речь чуть дальше) оставил на месте. Размер, действительно, несколько увеличился (на 1Кб непожатая версия, и на 150б — пожатая).
webo.in/tests/css-efficiency-5/ya-xhtml/
Тут уже убраны все onclick. Больше ничего со страницей не делалось. Ожиданий данная версия не оправдала (только Safari показал значимых отличий от предыдущего варианта, хотя было выкошено 83 пустых onclick). Была гипотеза, что браузеры могут не отслеживать ситуацию, навешивать дополнительные обработчики, что снижает время рендеринга. Гипотеза почти не оправдалась.
webo.in/tests/css-efficiency-5/ya-noclick/
Венец оптимизационных (в отношении CSS/HTML-кода) действий. Использование ID сведено к минимуму, все селекторы для class задаются через теги. Также убраны все комментарии из кода.
webo.in/tests/css-efficiency-5/ya-optimized/
В таблице приведены результаты для основных браузеров (примерно месячной давности): размер каждого вариант в байтах и время его загрузки.
| NN | Size (b) | Gzip (b) | IE5.5 (ms) | IE6 (ms) | IE7 (ms) | IE8b (ms) | FF2 (ms) | FF3 (ms) | Opera9.5 (ms) | Safari3.1 (ms) |
|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 26275 | 8845 | 61 | 56 | 80 | 76 | 130 | 127 | 142 | 33 |
| 2 | 27173 | 8993 | 55 | 60 | 75 | 320 | 127 | 118 | 148 | 27 |
| 3 | 26260 | 8949 | 44 | 61 | 75 | 320 | 131 | 116 | 141 | 23 |
| 4 | 26660 | 8915 | 44 | 55 | 73 | 306 | 131 | 111 | 145 | 31 |
В результате тестов удалось показать, что валидный XHTML не медленнее (а даже, местами, быстрее), чем HTML. И оптимизация реально играет роль (возможно ускорение загрузки главной страницы Яндекса на 10-12%). Если говорить о конкретных примерах, то на 100Кб/с канале с включенным сжатием в FF3 оптимизированный вариант загрузится на 9мс быстрее. Для более быстрого канала или более медленного компьютера отличие будет еще разительнее.
Естественно, это все копейки для обычных пользователей (на +/-50мс — кого это волнует?). Однако, если речь идет про «экономию на спичках», когда нам важен каждый запрос к серверу и каждая миллисекунда, то тут уже стоит задуматься — что же все-таки использовать.
И, что важнее всего, если правильно расставить акценты, то загрузку XHTML можно сделать и быстрее, чем HTML. Различие в размере файлов оказалось, в итоге, минимальным (26660 против 26275 в несжатом варианте, и 8915 против 8845 в сжатом, т.е. меньше 1%). При этом во всех IE наблюдается ускорение отображения страницы на 5-15мс (от 60-80мс при загрузке страницы, кроме IE8b — этот как-то странно работает с XHTML). Это, в среднем, дает 5-10% выигрыша в скорости. FF3 ведет себя похожим образом (выигрыш в скорости 12% (16 мс от 127мс)). Все остальные браузеры показали отличие в загрузке на 2–3мс, что укладывается в погрешность.
В свете тотального распространения мобильных браузеров с их маломощными процессорами, такой вид оптимизации выглядит весьма перспективно.
P.S. немного съехавшую в результате преобразований верстку не правил. На мой взгляд, это несущественно относительно сути тестов. Да простят меня все верстальщики Яндекса, приложившие руку к главной :)
© 2016 ООО ВЕБО
