Сейчас мы являемся свидетелями уникального явления: накопленный опыт, практики использования и проблемы веб-производительности обретают некоторую законченную форму в виде стандарта от W3C. Это стандарт Web Performance, над которым работает выделенная, недавно созданная группа.
Но начнем сначала.
На заре Интернета, в прошлом веке, проблемы производительности веб-сайтов не было, были проблемы медленного Интернет-соединения (потому что страницы начала века выглядят почти идеально с точки зрения текущих практик высокой производительности). Обычная страница представляла собой несколько (часто не больше 5) файлов, из которых текстовых файлов было 1-2. Лучшей практикой увеличения скорости загрузки было gzip-сжатие, но в силу слабой поддержки со стороны браузеров оно применялось редко.
Чуть позже, уже в нашем веке, с развитием технологий и стандартов, проблема «медленных» стала проявляться больше. На странице уже было несколько файлов стилей и скриптов, браузеры не умели эффективно их загружать, были разработаны все основные техники оптимизации, но до широкой общественности пока не дошли.
И на том фоне Yahoo! в 2007 году выкладывают свои советы по производительности и дополнение YSlow. Это было равносильно взрыву, о веб-производительности заговорили все. Появилась Net Panel в Firebug, появился Web Inspector в Safari в 2008 году, а в следующем году появился dynaTrace для IE и Speed Tracer.
На фоне этого бума летом 2010 года была образована отдельная группа W3C, занимающаяся разработкой соответствующих стандартов.
Почему же возникла необходимость в создание такой группы? Ведь уже есть инструменты для анализа производительности и практики создания быстрых сайтов. Во-первых, сейчас достаточно сложно получить информации о производительности страницы «в общем виде». Каждый из браузеров имеет собственное API (позволяющее через JavaScript получить доступ к C-данным), но экспорт всех значений кроссбраузерно очень сложен.
Во-вторых, доступный набор значений, которые тоже не так просто получить (ниже приведен пример получения времени onLoad, наиболее простого из всех), крайне ограничен. Сказать по нему что-то конкретное о производительности сайта сложно.
<html>
<head>
<script type="text/javascript">
var start = (new Date).getTime();
</script>
</head>
<body>
<script type="text/javascript">
window.onload = function() {
pageLoad = (new Date).getTime() - start;
};
</script>
</body>
</html>В-третьих, существует масса дополнительных, околопроизводительных возможностей и интерфейсов, которые не везде можно получить, которые кое-где невозможно получить (например, времена загрузки в Opera), и поддержка которых желательна (например, формат HAR для переноса данных о времени загрузки страницы и ее составных частей).
Проблем с определением веб-производительности страницы много, и почти все их предполагается решить со вводом следующей модели загрузки страницы.
A B C D E F G H I J K L | | | |-dns-|-conn-|-req-|-resp-| | | |-dns-|-conn-|-req-|-resp-| | | | |-unload-| |--------fetch foo.com--------| |--------fetch bar.com--------| |-load-| |-------------------------------end user latency----------------------------------------| A navigationStart B unloadEventEnd C redirectStart D redirectEnd E fetchStart F domainLookupStart G domainLookupEnd+connectStart H connectEnd+requestStart I requestEnd+responseStart J responseEnd K loadEventStart L loadEventEnd
Это лишь небольшая часть тех данных, которые предполагается, что браузер сможет отдавать. Также планируется, что будут покрыты следующие области:
Когда все это планиуется выпустить? Прямо сейчас идет обсуждение стандарта выдачи информации о сетевых задержках, и осенью будут выложены первые результаты. Весной обсуждение большинства вещей уже планируется завершить и выложить публичный стандарт. Финализирован он будет через год. Замечательно, что прямо на наших глазах происходит обобщение существующего опыта веб-разработки в официальный стандарт, и происходит достаточно быстро.
Часть вещей уже в браузерах реализовано, это IE9 Preview (такой объект как window.msPerformance и его свойства ResourceTiming, requestCount, domainCount) и ночных сборки WebKit. Поэтому скорее всего, к 2012 году мы получим рабочую модель для повседневного использования.
Это открывает поистине огромные возможности для анализа производительности (собирая статистику через единое API во всех браузерах) и более удобного, подстраивающегося поведения сайтов под не только браузеры, но и мощности компьютеров и ширину каналов пользователей. Например, мы можем менять количество графики и виджетов на сайте. Мы можем переключать загрузку сайта динамически на более быстрый узел, основываясь на показателях задержек. Возможна также предзагрузке и постзагрузка «тяжелого» содержания.
Это отлично, но все ли так гладко? Существует ряд проблем уже в текущей концепции стандарта. Например, проблема безопасности доступа к данным о закэшированному содержанию сайтов: ведь по нему можно будет вычислить историю посещений пользователей. Или падение производительности в связи с «эффектом наблюдателя». Или различные уровни использования сетевой инфрасруктуры Microsoft и остальными браузерами. Но их все предполагается так или иначе решить и выпустить стандарт с учетом всех возможных подводных камней.
Спасибо за внимание. Вопросы?
© 2016 ООО ВЕБО