Проект компаний
 
 
 
 
RU|CMS и клиентские технологии

Мониторинг серверных и клиентских веб-решений

Дата публикации: 17/04/2013

В декабре 2012 года сообщалось о начале проекта, связанного с регулярным мониторингом распространенности различных технологических решений на веб-узлах Интернета. К настоящему моменту накоплена и систематизирована интересная статистика, относящаяся как к российским, так и к зарубежным веб-узлам. Эта статья представляет собой максимально подробный отчет о текущих результатах работы.

Предмет, цели и задачи мониторинга

В основе технической реализации проекта — сбор данных при помощи скрипта (робота, «паука»; описание его поведения приводится на специально созданной странице monoid.nic.ru), опрашивающего хосты из заданного списка по протоколу HTTP.

На момент написания этой статьи (первая половина апреля 2013 года) обработаны, в частности, следующие выборки:

Основу предметной области мониторинга составляют:

Главной целью мониторинга является детализация исследования структуры рынка веб-разработки в технологическом разрезе.

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

Методика исследования

Использующиеся для анализа данные собираются со всех хостов из заданного списка, отвечающих на GET-запрос ресурса / (корневой каталог дерева документов веб-сервера) сообщением с кодом статуса 200, содержащим в теле объект с заявленным MIME-типом text/html. Обращения осуществляются по протоколу HTTP 1.1 на порт 80.

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

Запросы к хостам, доменные имена которых предваряются префиксом www. (речь идет о доменах третьего и более глубоких уровней иерархии), обрабатываются независимо от запросов к хостам, размещенных в соответствующих родительских доменах. Иными словами, каждый исследуемый хост опрашивается дважды — в вариантах с и без www. в начале своего доменного имени. В рамках описываемой методики делается допущение, что доменные имена с префиксом www. в подавляющем большинстве случаев практического использования настраиваются как алиасы своих родительских доменов.

Вообще говоря, при разработке системы мониторинга принят ряд упрощений и допущений, продиктованных, с одной стороны, ограниченностью ресурсов, имеющихся в распоряжении у авторов проекта (сюда относятся и численность команды разработчиков, и сроки реализации системы, и доступные вычислительные и телекоммуникационные мощности — все подробности не подлежат публикации), а, с другой стороны, потребностью достаточно быстро собирать данные для анализа с относительно большого количества хостов. (Так, множество хостов, соответствующих всем делегированным доменам второго уровня в домене верхнего уровня RU, не размещенным на парковках, опрашивается в течение нескольких дней. Численность подобных хостов, как упоминалось выше, — порядка 3 миллионов.)

Для каждого веб-узла, имеющего индексную HTTP-страницу, наличие которой определено описанным выше в данном разделе способом, анализируются:

В текущей версии системы мониторинга никак не анализируется содержимое каких бы то ни было ресурсов, размещенных на исследуемых веб-узлах, помимо индексных страниц. Сказанное относится, в частности, к внешним таблицам стилей, внешним скриптам и ресурсам, размещенным по адресам, похожим на служебные URL для известных CMS. Вероятно, в будущем ситуация изменится.

Содержимое HTML-кода индексных страниц не сохраняется системой мониторинга в непосредственном или каким-либо образом проиндексированном виде. Сохраняются только данные об исследуемых признаках (речь идет, главным образом, о количестве обнаружений каждого из них на каждом веб-узле) и показателях. Суммарный объем данных, накопленных за первые месяцы жизни проекта, не превышает 100 гигабайт (в несжатом виде).

При анализе содержимого HTML-кода индексных страниц не используются алгоритмы, характерные для HTML-парсеров, свойственных браузерам или валидаторам. Так, в процессе исследования не строится дерево DOM и не производится валидация (проверка лексики и синтаксиса языка разметки формальным требованиям спецификаций HTML). Эти алгоритмы требуют значительных затрат вычислительных ресурсов. Кроме того, их использование подразумевает задействование модулей сторонних разработчиков, от чего на начальном этапе реализации проекта решено по возможности воздерживаться.

В основе работы анализатора HTML-кода лежит простейший разборщик на составляющие (более точный англоязычный эквивалент — tokenizer). Интересные в рамках задачи вхождения внутрь этих составляющих детектируются при помощи регулярных выражений. По сути это напоминает доступный во многих текстовых редакторах контекстный поиск внутри выделенного фрагмента.

В нынешних условиях HTML-код индексной страницы среднего объема обрабатывается за сотые доли секунды. Одновременно, параллельно друг с другом исполняются порядка тысячи процессов скрипта, опрашивающего веб-узлы.

Серия HTTP-запросов к одному веб-узлу (индексная страница плюс гипотетические служебные URL) предусматривает секундные перерывы между соседними запросами с тем, чтобы минимизировать нагрузку, создаваемую роботом на исследуемый веб-сервер. При этом запросы потенциальных служебных URL осуществляются только в случае обнаружения индексной страницы на данном веб-узле. Веб-узел считается «мертвым» и не учитывается в статистике, если процесс его опроса не завершается в течение 5 минут.

Об оценке точности методики

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

Факторы, снижающие общую точность собираемых статистических данных, проявляются на более сложных, интегральных уровнях.

Одна группа таких факторов связана с растянутостью процесса сбора статистики во времени. Важно понимать, что не существует практической возможности обеспечить постоянство состояний каждого из исследуемых хостов на весь период сбора данных. Это означало бы «законсервировать» Интернет. В то же время, приблизительно неделя на обход нескольких миллионов хостов — это относительно краткий срок, в течение которого не успевает произойти существенных изменений общей картины.

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

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

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

Ситуация осложняется тем, что системы управления сайтов прямо идентифицируют себя в HTTP-заголовках ответов веб-серверов или в метатегах относительно нечасто. (Это зависит, в частности, от политики производителей CMS, от доступных настроек CMS, от состояния этих параметров по умолчанию, от конфигурации веб-сервера, от степени свободы веб-разработчика по возможностям контроля над кодом разметки шаблонов веб-страниц.)

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

Полнота определений CMS того или иного типа системой мониторинга весьма существенно зависит от качеств набора характерных признаков, детектируемых в рамках описываемой методики.

Так, например, у системы управления сайтами «1С-Битрикс» — весьма богатый ассортимент неповторимых косвенных признаков, позволяющий обнаруживать едва ли не все имеющие место установки данной CMS на анализируемых сайтах. А, скажем, у системы NetCat набор специфичных признаков довольно скуден, и надежно проявляются они далеко не на всех веб-узлах под управлением данной CMS. В итоге количество обнаружений NetCat рассматриваемой в статье системой мониторинга может оказаться несколько меньше реальной распространенности этой CMS; некоторые установки NetCat, вероятно, остаются «в тени».

Противоположный полюс — возможность ложных обнаружений тех или иных CMS. Команда разработчиков системы мониторинга довольно скрупулезно отнеслась к выбору весов характерных для различных CMS признаков и подбору «порога срабатывания» — совокупности обнаружений признаков, достаточной для того, чтобы сделать вывод о том, что на данном конкретном сайте c высокой вероятностью имеет место та или иная CMS. Любопытная подробность: при исследовании миллиона случайных хостов в доменах второго уровня зоны COM (а в этой выборке выявлено 681 967 действовавших веб-узлов) количество признанных надежными обнаружений коммерческих CMS российских производителей — «1С-Битрикс», UMI.CMS и NetCat — в сумме составило 140. Даже если допустить, что все эти обнаружения — ложные (что, разумеется, вызывает весомые сомнения, хотя речь и идет преимущественно о западных сайтах), доля их — всего 0,02% от общего количества проанализированных сайтов.

Так что, скорее, описываемая в данной статье система мониторинга отсечет какие-то спорные случаи, нежели припишет лишнего. К слову, в спорных, «пограничных» случаях и другие системы обнаружения CMS работают нестабильно. Возьмем, в частности, онлайн-сервис определения CMS компании iTrack. Так, на сайте webhitech.ru данный сервис не обнаруживает вообще никакой CMS, хотя сайт заведомо работает на Drupal. По данным же системы мониторинга, описываемой в этой статье, Drupal на упомянутом сайте обнаруживается с высоким показателем вероятности (практически гарантированно). В то же самое время, на сайте web-standards.ru сервис iTrack уверенно определяет заведомо установленную там CMS WordPress, тогда как обсуждаемая в настоящей статье система мониторинга предполагает этот факт с показателем вероятности, недостаточным для регистрации достоверного обнаружения.

Можно сформулировать в некоторой мере крамольную мысль. С точки зрения front-end-разработчика, уважительно относящегося к основополагающим концепциям современных веб-стандартов (разделение содержания и представления, семантика, валидность) и радеющего за чистоту кода разметки, идеальная CMS — это такая, которую невозможно определить без специальных привилегий доступа к серверу.

И еще один важный момент. Для авторов описываемого в статье проекта первоочередной интерес представляют веб-узлы, именно индексные (то есть заглавные) страницы которых в данный момент обладают явными и очевидными признаками того, что сайт управляется той или иной конкретной CMS. В ситуации, когда заметное количество относительно старых сайтов переоснащались, меняя в том числе и систему управления, причем порой неоднократно, на одном веб-узле вполне можно обнаружить работающие или хотя бы просто присутствующие служебные компоненты нескольких различных CMS. Поэтому результаты, полученные в рамках рассматриваемого в этой статье проекта, могут в той или иной мере отличаться от данных похожих по смыслу исследований — например, от статистики уже упоминавшейся компании iTrack, которая, судя по опубликованному на ее сайте описанию методики анализа, уделяет первоочередное внимание «отпечаткам» CMS, полученным от непосредственных производителей продуктов. А такие «отпечатки» зачастую имеют отношение в большей степени именно к разного рода служебным компонентам — например, административным интерфейсам CMS, нежели к реальным заглавным страницам сайтов.

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

Описание некоторых полученных результатов

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

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

Важное замечание. Авторы проекта отдают себе отчет в том, что 1 000 000 доменов второго уровня в домене верхнего уровня COM — это менее 1% численности всей зоны. В то же самое время, опыт исследования тестовых выборок показывает, что порядок относительных величин существенно не зависит от численности случайной выборки, если речь идет хотя бы о нескольких десятках тысяч хостов.

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

Доступность веб-узлов

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

Веб-узлы, RU

Веб-узлы, COM

Веб-узлы, Alexa

Наивысшую долю действующих веб-узлов предсказуемо демонстрирует множество хостов из верхушки рейтинга Alexa, и все равно значительная часть их оказалась недоступной (по крайней мере, в рамках использованной методики исследования).

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

Наименьшая доля обнаружений действующих веб-узлов приходится на выборку из миллиона случайных делегированных доменов в зоне COM. Это, очевидно, в значительной мере связано с тем, что авторы исследования не располагают такой полнотой сведений о доменах второго уровня в зоне COM, как об аналогичных доменах в зоне RU. Так что в состав выборки попало много различного, образно говоря, мусора, который был отфильтрован уже непосредственно в процессе опроса хостов.

Крайне интересные результаты показывают исследования доступности веб-узлов с использованием префикса www. в составе доменного имени хоста и без использования такового. Соответствующая статистика представлена в диаграммах блока «Доступность в зависимости от префикса 'www.'».

Доступность в зависимости от префикса 'www.', RU

Доступность в зависимости от префикса 'www.', COM

Доступность в зависимости от префикса 'www.', Alexa

Веб-узлы, размещенные в доменах второго уровня зон RU и COM, почти одинаково хорошо доступны в обоих вариантах обращения. Но когда речь заходит только о каком-либо одном варианте, получается, что веб-узлы в доменах зоны RU вдвое чаще доступны без префикса www., нежели с таковым, тогда как веб-узлы в доменах зоны COM почти так же вдвое чаще доступны с префиксом www., нежели без него. Вероятно, объясняется это историческими причинами — зона COM существенно более старая, чем зона RU, и в ней размещено (в относительном выражении — как, впрочем, и в абсолютном) ощутимо больше сайтов-долгожителей, существующих с тех времен, когда префикс www. играл роль или хотя бы оставался общепринятой традицией.

Описываемая картина еще более выражена в случае с сайтами из верхушки рейтинга Alexa. Огромная их доля доступна только в варианте с использованием префикса www. — в результате чего сайты, доступные в обоих вариантах обращения, остаются в меньшинстве по отношению к множеству всех веб-узлов из обсуждаемой выборки.

Системы управления сайтами

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

Общие доли обнаружений всех этих 7 CMS в каждом из трех исследованных множеств веб-узлов иллюстрируются диаграммами блока «Обнаружения CMS».

Обнаружения CMS, RU

Обнаружения CMS, COM

Обнаружения CMS, Alexa

На веб-узлах в доменах второго уровня зоны RU общая доля обнаружений перечисленных CMS сравнительно высока, превышая четверть всех веб-узлов. Ненамного отстает множество веб-узлов из верхушки рейтинга Alexa — это предсказуемо, поскольку в данной выборке относительно много качественных и востребованных аудиторией сайтов, причем среди них немало русскоязычных.

На веб-узлах в доменах второго уровня зоны COM общая доля обнаружений семи перечисленных CMS не дотягивает до десятой доли всех веб-узлов. Вероятно, это связано с распространенностью в зоне COM простых статичных сайтов, существующих с незапамятных времен. Также нужно учитывать тот факт, что из исследованной выборки не отфильтрованы домены, размещенные на парковках.

Долю каждой из 7 обсуждаемых CMS в структуре общего множества их обнаружений отражают диаграммы блока «Популярные CMS». Так, в российском сообществе веб-разработчиков феноменальной популярностью пользуется Joomla!, тогда как на преимущественно западных сайтах безраздельно царствует WordPress. Относительно велика на российских веб-узлах доля использования отечественных коммерческих CMS, которые практически не применяются на Западе.

Популярные CMS, RU

Популярные CMS, COM

Популярные CMS, Alexa

Время загрузки и объемы индексных страниц веб-узлов

Авторам системы мониторинга интересно было проверить, насколько быстро загружаются индексные страницы исследуемых веб-узлов и насколько «тяжеловесными» они являются.

Объем HTML-кода измеряется непосредственно скриптом системы мониторинга. Текущая версия системы никак не анализирует HTML-код, сжатый на стороне сервера при помощи алгоритмов gzip, deflate или compress (в том числе не измеряет объем этого содержимого), отправляя в заголовке HTML-сообщения запроса поле Accept-Encoding: identity. Количеством веб-узлов, не учитывающих эту информацию в заголовке запроса, на данном этапе развития проекта вполне можно пренебречь. Так, в отношении всех опрашиваемых хостов в доменах второго уровня зоны RU всякий раз выявляется менее 10 тысяч подобных случаев.

Такой показатель, как время загрузки, конечно же, нельзя воспринимать как некий абсолют. Речь идет только о результатах конкретных исследований, проведенных с использованием для осуществления запросов к удаленным веб-узлам машины, установленной в Москве на территории Курчатовского института. Время загрузки индексных страниц зарубежных веб-узлов, таким образом, вполне закономерно оказывается существенно превышающим аналогичный показатель для российских веб-узлов. К тому же, для веб-узлов в доменах второго уровня зоны RU были предварительно определены их IP-адреса, что в значительной мере ускоряет доступ к соответствующим хостам.

Для сравнения в диаграммах блока «Время загрузки и объемы индексных страниц» приводятся данные измерений для веб-узлов, расположенных в том числе в доменах второго уровня в зонах РФ и SU (опросы которых производились соответственно 21—22 января и 17 января нынешнего года). Для этих доменов не производилось предварительного разрешения IP-адресов — обращения к серверам службы DNS осуществлялись непосредственно в ходе опроса хостов.

Среднее время загрузки индексной страницы в миллисекундах

Средний объем HTML-кода индексной страницы в байтах

В случае с доменами второго уровня в зонах РФ и SU, как и в случае с доменами второго уровня в зоне COM, не производилась никакая дополнительная фильтрация — исследовались хосты, соответствующие всем делегированным доменам. Закономерно, что по результатам исследования более качественной выборки веб-узлов в доменах второго уровня зоны RU средний объем HTML-кода индексной страницы заметно превысил аналогичный показатель для веб-узлов в доменах второго уровня зон COM, РФ и SU. Вполне объясним и тот факт, что у веб-узлов из верхушки рейтинга Alexa индексные страницы в среднем почти вдвое «тяжелее», чем даже у веб-узлов в доменах второго уровня зоны RU. Веб-ресурсы на верхних позициях рейтинга Alexa — как правило, содержательные, насыщенные контентом сайты, тогда как в выборке веб-узлов в доменах второго уровня зоны RU несравнимо больше информационного мусора.

Типы и версии веб-серверов

Показалось интересным выяснить порядок цифр, отражающих распространенность наиболее популярных веб-серверов — Apache и nginx, — на основе анализа содержимого поля Server заголовков сообщений HTTP-ответов. Полученные данные иллюстрируют диаграммы блока «Веб-серверы».

Веб-серверы

На веб-узлах, размещенных в доменах второго уровня зоны RU, оказалась весьма широко распространенной российская разработка — nginx. Следует понимать, однако, что nginx зачастую используется не как самостоятельный веб-сервер, а как обратный прокси, выполняющий те или иные посреднические функции и ретранслирующий клиентские запросы, например, тому же Apache.

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

Объявления <!DOCTYPE …> и режимы рендеринга

Конструкция <!DOCTYPE …> обычно является первой строкой HTML-кода, предшествуя всем другим конструкциям. Иногда до объявления <!DOCTYPE …> может встретиться XML-декларация с возможным указанием кодировки. На морально устаревших сайтах объявление типа документа отсутствует как таковое. От вида конструкции <!DOCTYPE …> зависит, в каком режиме браузер будет отрисовывать (рендерить, to render) страницу — standards mode (режим соответствия стандартам) или quirks mode (режим совместимости).

Единственно правильной во втором десятилетии XXI века для всех вновь создаваемых сайтов является краткая конструкция вида <!DOCTYPE html> или <!DOCTYPE HTML>, описанная в спецификации HTML5. Эта конструкция не является SGML-декларацией и преследует единственную цель — переключение браузеров в режим соответствия стандартам.

Общую картину распространенности тех или иных видов объявлений <!DOCTYPE …> отражают диаграммы блока «Объявления <!DOCTYPE …>». Разительных различий между тремя исследованными выборками не наблюдается. Хочется отметить повышенную распространенность объявления <!DOCTYPE …>, рекомендованного спецификацией HTML5, на качественных сайтах из верхушки рейтинга Alexa. В то же время нельзя не отметить общую консервативность этой выборки — почти половину ее составляют сайты, использующие наиболее распространенный в данный момент вид объявления <!DOCTYPE …>, соответствующий типу документов XHTML 1.0 Transitional.

Объявления <!DOCTYPE …>, RU

Объявления <!DOCTYPE …>, COM

Объявления <!DOCTYPE …>, Alexa

Обнадеживает то, что в целом большинство индексных страниц веб-узлов использует какие-либо объявления <!DOCTYPE …> и, в особенности, то, что в большинстве — те их разновидности, которые переключают браузеры в режим соответствия стандартам.

Несмотря на то, что краткое объявление <!DOCTYPE …> в стиле HTML5 используется относительно редко, степень его распространенности стремительно растет. Наблюдения в динамике для веб-узлов в доменах второго уровня зоны RU за время жизни проекта иллюстрирует соответствующий график блока «Новые веяния, RU».

Новые веяния, RU

Распространенность объявления <!DOCTYPE …> в стиле HTML5 — один из самых динамично изменяющихся показателей из всего множества исследуемых. (Прирост в абсолютных цифрах составил более 100 тысяч веб-узлов, в относительных — почти 4 процентных пункта.)

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

Веб-стандарты

Обсуждение диаграмм наиболее насыщенного информацией блока, «Веб-стандарты», потребует относительно подробных пояснений, поэтому этот раздел будет разбит на несколько подразделов.

Веб-стандарты, RU

Веб-стандарты, COM

Веб-стандарты, Alexa

Кодировка UTF-8

В настоящее время практически отсутствуют технические препятствия, мешающие повсеместному распространению Unicode, поэтому видится, что единственно верным выбором кодировки для представления данных на веб-страницах является UTF-8. Ее используют около половины исследованных веб-узлов.

Условные комментарии

Microsoft Internet Explorer, в особенности устаревших к настоящему моменту версий, славится в среде веб-разработчиков клиентской стороны многими, мягко говоря, индивидуальными особенностями, идущими вразрез с общепринятыми отраслевыми стандартами. Условные комментарии (conditional comments) — механизм, предусмотренный в браузере Internet Explorer и упраздненный в последней, 10-й его версии, — позволяют изолировать специфичный для браузера Internet Explorer HTML-код от обработки другими браузерами. Классическое использование:

<link rel="stylesheet" href="all.css">

<!--[if IE]><link rel="stylesheet" href="ie.css"><![endif]-->

<!--[if lt IE 8]><link rel="stylesheet" href="old-ie.css"><![endif]-->

Вышеприведенный пример иллюстрирует фрагмент HTML-кода, в котором подключаются внешние файлы таблиц стилей. Файл all.css применяется для всех браузеров без исключения. Две следующие строки кода, имеющие синтаксис HTML-комментария, будут закономерно проигнорированы всеми браузерами, кроме Internet Explorer. Файл ie.css будет применен в дополнение к файлу all.css любыми версиями Internet Explorer, поддерживающими условные комментарии, а файл old-ie.css, в дополнение к двум вышеупомянутым файлам, будет применен в Internet Explorer устаревших версий (c номером меньше 8).

Наличие в HTML-коде веб-страниц условных комментариев говорит, с одной стороны, об использовании специфичных «костылей» и «хаков» для Internet Explorer, а, с другой стороны, о том, что веб-разработчики проявляют определенную аккуратность и не смешивают эти «хаки» с кодом более высокого качества, предназначающимся для обработки браузерами, альтернативными по отношению к Internet Explorer и более уважительно относящимися к духу и букве современных веб-стандартов.

Проблемные элементы и атрибуты HTML

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

  1. элемент или атрибут объявлен как deprecated (не рекомендованный к использованию) в спецификации HTML 4.01 и упразднен в HTML5;
  2. элемент или атрибут не объявлен как deprecated, но в итоге все же упразднен в HTML5;
  3. элемент или атрибут объявлен как deprecated, но в итоге «реабилитирован» в HTML5 в каком-либо новом качестве;
  4. элемент или атрибут актуален только в документах типа Frameset; не используется в HTML5;
  5. нестандартный элемент или атрибут, не описанный ни в одной из официальных спецификаций HTML;
  6. изначально нестандартный элемент или атрибут, легитимизированный в HTML5.

К категории 1 относятся:

К категории 2 относятся:

К категории 3 относятся:

К категории 4 относятся:

К категории 5 относятся:

К категории 6 относятся элементы: <embed>, <wbr>.

Описанная классификация призвана проконтролировать использование популярных в разное время конструкций HTML, упраздненных или, напротив, узаконенных в спецификации HTML5 либо всегда являвшихся и поныне остающихся нестандартными. Речь идет именно о широко применявшихся когда-либо на практике конструкциях HTML. Формально, конечно же, почти любую строку символов можно записать в нестандартные элементы или атрибуты.

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

Очевидное замечание на всякий случай. Данные в диаграммах блока «Веб-стандарты» отражают, разумеется, не совокупное количество зарегистрированных вхождений тех или иных HTML-конструкций, а численность веб-узлов, в HTML-коде индексных страниц которых встретилось хотя бы по одному соответствующему вхождению.

Новые структурные элементы HTML5

Спецификация HTML5 обогатила словарь языка разметки гипертекста десятками новых элементов и атрибутов.

В системе мониторинга реализован подсчет общего количества вхождений в исследуемый HTML-код 30 новых структурных элементов HTML5: <article>, <aside>, <audio>, <bdi>, <canvas>, <command>, <datalist>, <details>, <figcaption>, <figure>, <footer>, <header>, <hgroup>, <keygen>, <mark>, <math>, <meter>, <nav>, <output>, <progress>, <rp>, <rt>, <ruby>, <section>, <source>, <summary>, <svg>, <time>, <track>, <video>. Подсчет количества вхождений каждого из перечисленных элементов в отдельности в текущей версии системы мониторинга не осуществляется.

Количество веб-узлов, на индексных страницах которых используются новые структурные элементы HTML5 — еще один из наиболее быстро растущих показателей. График иллюстрирует динамику для веб-узлов в доменах второго уровня зоны RU.

Новые типы полей ввода HTML-форм

Спецификация HTML5 увеличила разнообразие полей ввода HTML-форм за счет расширения множества допустимых атрибутов и значений атрибутов элемента <input>.

Так, описаны следующие новые атрибуты данного элемента: autocomplete, dirname, list, max, min, multiple, pattern, placeholder, step. Введены дополнительные разрешенные значения атрибута type: color, date, datetime, datetime-local, email, month, number, range, search, tel, time, url, week.

Элементы <input>, содержащие перечисленные выше нововведения, классифицируются системой мониторинга как новые типы полей HTML-форм.

Весьма интересным представляется тот факт, что на индексных страницах веб-узлов в доменах второго уровня зоны COM и веб-ресурсов из верхушки рейтинга Alexa такие элементы распространены в существенно большей степени, чем на заглавных страницах сайтов в доменах второго уровня зоны RU.

Причина явления не изучалась в деталях. Гипотезы:

Использование CSS

Авторы проекта решили проследить, как часто и в каких формах используется CSS на сайтах. Под связанными таблицами стилей понимаются внешние по отношению к HTML-коду CSS-файлы; под внедренными — CSS-код, фигурирующий непосредственно внутри HTML-кода в виде содержимого элементов <style>; под inline-стилями подразумеваются стилевые правила в атрибутах style. Злоупотребление inline-стилями считается плохой практикой вследствие того, что такой подход отдаляет код разметки от идеалов принципа разделения содержания и представления.

Метатеги viewport

Элемент <meta> со значением viewport атрибута name — предложенный фирмой Apple механизм, ставший прообразом спецификации CSS Device Adaptation. В настоящее время метатег viewport является насущной необходимостью для любого сайта, в отношении которого веб-разработчик подумал, как этот сайт будет отображаться на мобильных устройствах.

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

Классы, поименованные в стиле БЭМ

БЭМ — методология и инструментарий, разрабатываемые компанией «Яндекс». Использование БЭМ, как правило, говорит о высокой квалификации веб-разработчика, поскольку философией этой методологии не каждому дано проникнуться.

Для БЭМ характерно своеобразное именование классов. Описываемая в статье система мониторинга учитывает как БЭМ-классы имена классов, удовлетворяющие следующему регулярному выражению: /^(b|i)-\S+__\S+$/. На практике множество БЭМ-классов шире. Так, часто опускается префикс b-, а помимо классических префиксов b- и i- используется ряд других. Так что цифры, фигурирующие в статистике, следует воспринимать как весьма осторожную оценку снизу.

Потенциально идеальные сайты

Предпринята попытка осуществить выборку «потенциально идеальных» с точки зрения веб-стандартов индексных страниц, отвечающих всем нижеперечисленным требованиям одновременно:

Веб-узлов, удовлетворяющих всем этим условиям — доли процента от общего количества.