Читать «Разгони свой сайт» онлайн - страница 84

Еще одним проблемным местом, на мой взгляд, является общее выполнение скриптов при onresize. Ну и еще серьезный совет: используйте CSS-выражения по минимуму. Лучше всего будет, если они вообще не встретятся у нас сайте.

6.2. Что лучше, id или class?

Далее давайте рассмотрим, как использование id или class влияет на скорость отображения страницы в браузере (сейчас речь не идет о множественном использовании одинаковых id — это и так запрещено спецификацией). Если элемент на странице встречается единственный раз (например, «шапка» или «подвал»), то мы можем с равным успехом использовать id и class для его стилизации.

Методика. Размер файлов

Естественно, что скорость работы одиночного CSS-правила весьма высока, и даже десятки и сотни их не должны заметно замедлить работу браузеров. Поэтому нужно изучать работу нескольких тысяч правил, иначе точность результатов будет весьма невысока. Использовать JavaScript для генерации HTML/CSS-кода не представляется разумным, ибо тогда придется учитывать еще и скорость работы JavaScript-движка в браузерах, и в итоге эксперимент будет недостаточно чистым.

В результате проведенного исследования были сгенерированы статичные файлы (порядка 300 Кб каждый), которые содержали достаточное число различных CSS-селекторов. Это «достаточное» число подбиралось по нескольким параметрам, в том числе таким как размер файла и скорость работы HTML/CSS-кода в браузерах (она должна быть достаточно низкой, чтобы файлы в несколько сотен Кб уже заметно тормозили при открытии).

Итоговые файлы содержали по 4096 объявлений различных CSS-классов (или различных идентификаторов), HTML-код содержал соответствующее количество блоков, у каждого свой индивидуальный класс (или идентификатор). Дополнительно проверялась скорость работы с простым наследованием узлов (div p, CSS1) и селектор для выбора потомка первого уровня (div>p, CSS2).

Время открытия страницы

При тестировании браузеров нужно было, во-первых, открыть на клиенте соответствующую данному случаю страницу, а также как-то отследить время на отображение конкретно HTML/CSS-части (понятно, что оно не совпадает со временем открытия всей страницы, которое еще содержит некоторые дополнительные задержки).

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

Конечно, каждую тестовую страницу можно было подгружать в невидимом iframe или даже AJAX-запросом. Но ведь мы хотим узнать, фактически, скорость рендеринга браузером CSS-правил и соответствующего кода, а это время будет расходоваться только при отображении страницы в окне браузера. Поэтому подгружаемую страницу нужно отображать на экране (по возможности, максимального размера), чтобы отследить имеющуюся разницу.