Оригинальный адрес: http://www.smashed.by/perf-checklist Автор | Виталий Фридман Переводчик | Разработчик OpenWeb Сансан
Как мы все знаем, производительность очень важна. Однако знаем ли мы на самом деле конкретное узкое место в производительности? Реализация сложного JavaScript, медленная загрузка веб-шрифтов, огромные картинки или рендеринг Caton? Исследования встряхнули дерево (Tree Shaking), чтобы расширить масштаб (Scope Hoisting), или с помощью различных IntersectionObserver, Clients Hints, CSS-сдерживания, великолепного режима загрузки HTTP/2 и Service Worker, чтобы работать вместе, действительно стоит ли это? самое главное,С чего начать оптимизацию производительности, и как мы создаем долгосрочную культуру производительности?
Раньше производительность часто была просто запоздалой мыслью. Обычно это не рассматривается до самого конца проекта, а затем сводится к минификации, слиянию, статической оптимизации ресурсов или каким-то мелким изменениям в файлах конфигурации сервера. Оглядываясь назад, кажется, что многое изменилось.
Производительность — это не просто технический вопрос: она важна, и когда она вводится в рабочий процесс, проектные решения должны приниматься с точки зрения ее влияния на производительность.Мы должны постоянно измерять, отслеживать и повышать производительность, а растущая сложность Интернета создает новые проблемы, которые затрудняют отслеживание показателей производительности, поскольку показатели производительности будут различаться в зависимости от устройства, браузера, протокола, типа сети и задержки (CDN, оператора связи, кэша, прокси-сервера, брандмауэра, балансировщиков нагрузки и серверы играют роль) и сильно различаются.
Поэтому обзор по всем вопросам, если мы создаем обязательство помнить, когда увеличиваем производительность - окончательный выпуск процесса с самого начала на сайте - этот список будет выглядеть? Вот контрольный список производительности передней работы 2018 года (надеюсь, беспристрастным и объективным и объективным) - проблема, которую вы можете захотеть рассмотреть возможность обеспечения вашего сайта быстрого времени отклика, пользовательское взаимодействие гладко, и пользователь не будет заканчиваться пропускной способностью.
Вот что вы можете рассмотретьПроблемы с производительностью интерфейсаОбзор, чтобы обеспечить быстрое и плавное время отклика.
(Аннотация: исходный текст подробно описывает принципы, а также все тонкости всех стратегий оптимизации, задействованных в тексте. Здесь переведен только файл контрольного списка в формате PDF, прикрепленный к исходному тексту, чтобы предоставить быстрый и краткий список оптимизаций производительности.)
1. Подготовка: планирование и показатели
01 Создайте культуру производительности
Пока нет сотрудничества между командами, высокая производительность не может поддерживаться в долгосрочной перспективе. Изучите распространенные жалобы в отзывах пользователей, чтобы узнать, поможет ли улучшение производительности решить некоторые из этих проблем. Используйте реальные данные для создания собственных кейсов и моделей. Начните планировать последовательности нагрузок и компромиссы в процессе проектирования.
02 Выберите правильные показатели эффективности
Не все показатели одинаково важны. Исследуйте наиболее важную метрику: вообще говоря, она связана с тем, как быстро вы можете начать рендеринг самых важных пикселей и как быстро вы можете предоставлять входные ответы. Расставляйте приоритеты загрузки страниц в зависимости от того, что чувствуют клиенты. Обычно важны время интерактивности, время рендеринга элементов заголовка страницы, время первой эффективной отрисовки (FMP), индекс скорости (Speed Index).
03 Будьте как минимум на 20% быстрее своих конкурентов
Собирайте данные об устройствах, представляющих вашу аудиторию. С точки зрения источников данных реальные устройства лучше, чем смоделированные данные. Выберите хорошее устройство среднего класса, например Moto G4, устройство Samsung среднего класса или Nexus 5X. Кроме того, вы можете имитировать мобильную работу, установив ограничение скорости сети (например, RTT 150 мс, загрузка 1,5 Мбит/с, загрузка 0,7 Мбит/с) и ограничение скорости процессора (в 5 раз медленнее) на вашем компьютере. Наконец, переключайтесь между обычным 3G, 4G и Wi-Fi. Собирайте данные, настраивайте электронные таблицы, увеличивайте показатели на 20% и ставьте цели (например, «бюджеты производительности»).
04 Поделитесь этим контрольным списком со своими коллегами
Убедитесь, что все в команде знакомы с контрольным списком. Каждое решение влияет на производительность, и ваш проект значительно выиграет от активного участия фронтенд-разработчиков. Сопоставьте свой бюджет производительности с проектными решениями.
Во-вторых, развивать реалистичную цель
05 Время отклика 100 мс + 60 кадров в секунду
Каждый кадр анимации должен выполняться менее чем за 16 миллисекунд (в идеале 10 миллисекунд), что дает 60 кадров в секунду (1 секунда ÷ 60 = 16,6 миллисекунд). Сохраняйте оптимизм и используйте свое свободное время с умом. Для точек высокого давления, таких как анимация, не делайте ничего другого, если можете. Расчетная задержка ввода должна быть менее 50 мс.
06 Индекс скорости (SpeedIndex) меньше 1250, время до взаимодействия (Time-To-Interactive) меньше 5 секунд на 3G
Цель состоит в том, чтобы завершить первую отрисовку (FMP) в течение 1 секунды (в высокоскоростной сети) со значением SpeedIndex (SpeedIndex) ниже 1250 мс. Учитывая, что базовой скоростью является телефон Android с сетью 3G, а цена составляет около 200 долларов США, вы можете выполнить моделирование сети с RTT 400 мс и скоростью передачи 400 кбит/с для достижения интерактивности. Время (время до взаимодействия) меньше, чем 5 секунд, а скорость второго открытия менее 2 секунд. Снижайте эти показатели настолько, насколько это возможно.
07 Основные блоки = 15 КБ, критические файлы
Первые 14–15 КБ HTML являются наиболее важным основным блоком (фрагментом) и единственной частью всего файла, которую можно загрузить в первом RTT. Для достижения вышеуказанных целей установите максимальный размер «бюджета» для ключевых файлов. Gzip-файл размером 170 КБ (исходный размер файла 0,8 ~ 1 МБ) может занять 1 секунду для анализа и компиляции на обычном мобильном телефоне.
3. Определите среду
08 Выберите и настройте инструменты сборки
Не обращайте слишком много внимания на так называемое «круто». Это нормально, если вы можете быстро получить результаты и не иметь проблем с поддержанием процесса сборки.
09 Прогрессивное улучшение
Сначала спроектируйте и создайте базовую функциональность, а затем используйте ее, чтобы улучшить расширенные функции мощных браузеров, чтобы обеспечить отказоустойчивость. Если ваш веб-сайт работает относительно быстро на машине с низкой производительностью и плохой сетью, он будет работать быстрее только на машине с хорошей производительностью и сетевым адаптером.
10. Установите жесткие критерии производительности
Реализация интерактивных эффектов в JavaScript стоит дорого. Бюджет размером 170 КБ уже включает в себя базовый HTML/CSS/JavaScript, маршрутизацию, управление состоянием, служебные функции, фреймворки и производственную логику, поэтому, пожалуйста, тщательно проверьте стоимость передачи по сети, время синтаксического анализа/компиляции и время выполнения выбранных нами фреймворков.
11 Holy war заканчивается мудрым: Angular, React или Ember
Не каждому проекту нужен фреймворк. Но если для вашего проекта требуется фреймворк, то лучше использовать фреймворк, поддерживающий рендеринг на стороне сервера (SSR). Перед использованием фреймворка обязательно оцените время запуска фреймворка как в режимах рендеринга на стороне сервера, так и в режимах рендеринга на стороне клиента на мобильных устройствах. Узнайте особенности платформы, на которую вы будете полагаться. Узнайте о шаблоне PRPL и модели App Shell.
12 Будете ли вы использовать AMP или Instant Articles
(Аннотация: AMP — это проект Google с открытым исходным кодом, целью которого является повышение скорости доступа мобильных устройств к веб-сайту в виде компонентов; Instant Articles — это протокол Facebook, целью которого является повышение производительности страницы в приложении Facebook путем рендеринга упрощенная версия страницы. Включите скорость. В Китае MIP — это решение, аналогичное AMP.)
Вы также можете получить хорошую производительность без них. Но AMP обеспечивает надежную основу производительности с бесплатной CDN, а Instant Articles повысит вашу видимость и производительность на Facebook. Вы также можете создать прогрессивный AMP.
13 Выберите правильный CDN
Вы можете передать части контента на аутсорсинг генератору статических сайтов, передать их в CDN и обслуживать статическую версию из CDN, избегая запросов к базе данных (например, JAMStack). Конечно, это зависит от количества имеющихся у вас динамических данных. Дважды проверьте, выполняет ли CDN сжатие и преобразование контента, интеллектуальный HTTP/2 и пограничные включения (ESI) за вас.
В-четвертых, оптимизировать конструкцию
14. Правильно расставляйте приоритеты
Составьте таблицу всех ваших статических ресурсов (JavaScript, изображения, шрифты, сторонние скрипты, большие модули) и разделите их на три группы по приоритету: базовые основные функции (основной контент, который можно просматривать в старых браузерах)), улучшения опыта ( мощные и богатые возможности, разработанные для современных браузеров), дополнительные функции (ресурсы, которые не обязательно требуются и могут загружаться лениво, такие как шрифты, сценарии каруселей, видеоплееры, кнопки общего доступа и т. д.).
15 Используйте методы, соответствующие стандартам
(Аннотация:"Техника разрезания горчицы"В блоге разработчиков BBC News предлагается технология, которая определяет уровень поддержки на основе характеристик браузера и выбирает, какие функции загружать. )
Для старых браузеров выводится только основной код функции, для современных браузеров выводится расширенный код функции. Загружайте статические ресурсы строго в соответствии со стандартом: загружайте основной код напрямую, загружайте код расширения в событии DOMContentLoaded и загружайте остальную часть кода в событии загрузки. Примечание. Недорогие телефоны Android, хотя и находятся на должном уровне, имеют ограниченную память и производительность процессора. Поэтому вам может потребоваться использовать API JavaScript, который считывает размер памяти устройства для определения производительности устройства, и следовать методу «соответствия стандартам», только если он не поддерживается.
16. Уменьшение размера JavaScript
Поскольку синтаксический анализ JavaScript занимает много времени, постарайтесь максимально уменьшить размер JavaScript. При создании SPA может потребоваться некоторое время для инициализации приложения перед отрисовкой страниц. Ищите модули и методы, которые могут ускорить начальное событие рендеринга (на недорогих мобильных устройствах это может быть в 2-5 раз быстрее). Тщательно проверьте каждую зависимость JavaScript, чтобы выяснить, кто тратит драгоценное время на инициализацию.
17 Используйте микрооптимизацию и инкрементный запуск
Используйте рендеринг на стороне сервера, чтобы получить быстрое время до первой отрисовки (FMP), но также выводите на страницу минимально функциональный JavaScript, чтобы время до взаимодействия (TTI) было близко к времени до первой отрисовки (FMP). Затем запускайте несущественные части приложения только при необходимости или при наличии дополнительного времени. Показывать каркасный экран во время загрузки вместо анимации «загрузки».
18 Использование встряхивания дерева и разделения кода
Используйте Tree Shake и Code Splitting, чтобы уменьшить размер кода.
Tree Shake — это метод очистки кода в процессе сборки путем удаления неиспользуемого кода. Технология разделения кода разбивает ваш код на «фрагменты», которые загружаются по требованию. Технология Scope Hoisting позволяет плавно преобразовывать связанные зависимости во встроенные функции. Используйте описанные выше методы для своего кода с помощью WebPack. Используйте компилятор AOT (аннотация: например, компилятор Closure), чтобы перенести некоторые клиентские вычисления на сервер.
19 Загружать JavaScript асинхронно
Как разработчики, мы должны явно использоватьdeferа такжеasyncАтрибут, указывающий браузеру не ждать загрузки скрипта, а начать отрисовку страницы. Если вам не нужны внимание и следующие версии браузера IE 9, то используйтеdeferЛучше; в противном случае используйтеasyncлучше. Используйте статические кнопки общего доступа, статически связывайте интерактивные карты вместо использования сторонних библиотек.
20 Установлен ли заголовок кэша HTTP?
Еще раз проверьте правильность установки заголовков ответов Expires, Cache-Control, Max-Age HTTP Cache-Control. Как правило, ресурс либо кэшируется на короткий период времени (например, ресурс, который часто изменяется), либо постоянно (например, ресурс, который не изменяется). Используйте заголовки ответов, предназначенные для статических файлов с хэш-отпечатками.Cache-Control: imuutableчтобы браузер не запрашивал файл повторно.
5. Статическая оптимизация ресурсов
21 Используется ли сжатие Brotli или Zopfli
Brotli — это новый формат сжатия без потерь. Теперь все современные браузеры поддерживают его. Он сжимает сильнее, чем Gzip и Deflate, сжимает очень медленно, но распаковывает очень быстро. Предварительно сжимайте статические файлы с помощью Brotli+Gzip с максимальной степенью сжатия и сжимайте динамический контент в режиме реального времени с помощью Brotli уровней 1–4. Также проверьте, поддерживает ли CDN Brotli. В качестве альтернативы вы можете попробовать использовать Zopfli на редко меняющихся ресурсах — он сжимает данные в форматах Deflate, Gzip и Zlib и рассчитан на одно сжатие, загрузку много раз.
22 Правильно ли оптимизировано изображение?
использовать как можно большеsrcset,sizesа также<picture>Отзывчивое изображение, реализованное элементом. Используйте изображения в формате WebP; это можно сделать через<picutre>тег с запасным вариантом JPEG или черезAcceptЗапрос до достижения. Для основных изображений используйте прогрессивный JPEG и размывайте несущественные части фильтром Гаусса.
23 Правильно ли оптимизированы веб-шрифты?
Веб-шрифт, который вы используете, скорее всего, содержит реализации и дополнительные функции, которые на самом деле не используются. Создайте подмножество шрифтов. Отдайте предпочтение WOFF2 и используйте WOFF в качестве запасного варианта. Немедленно отобразите текст с резервным шрифтом, загрузите шрифт асинхронно (например, с помощью loadCSS), а затем переключите шрифт. Также учитываются шрифты, уже установленные в локальной операционной системе. Не забудьте написать в CSSfont-display: optional; если вы не можете загружать шрифты с вашего сервера, не забудьте использовать события загрузки шрифтов.
6. Оптимизация дистрибуции
24 Быстрый пуш основной CSS
Соберите вместе весь CSS, необходимый для рендеринга верхней части сгиба, и тогда метод готов.<head>в этикетке. Рассмотрим встроенный выбранный метод. Или используйте push-сервер HTTP/2, но для этого вам может потребоваться создать механизм push-сервера HTTP/2 с поддержкой кеша.
25 Используйте babel-preset-env для переноса только функций ES2015+
Поскольку ES2015 широко поддерживается, вы можете рассмотреть возможность использованияbabel-preset-envДля переноса только функций ES2015+, которые не поддерживаются современными браузерами. Затем вы можете скомпилировать две копии, одну для ES6 и одну для ES5. использовать<script type="module">Заставляет браузеры с поддержкой ESM загружать новые файлы, а остальные старые браузеры могут использовать<script nomodule>для загрузки старых файлов.
26 Улучшить производительность рендеринга
使用 CSS 包含（CSS Containment）隔离渲染十分耗时的组件。请保证在滑动页面或者元素动画的时候，页面不会卡顿，而且你的页面能持续以 60fps 的速度渲染。如果那不可能，那么至少也要把 fps 控制在 15~60 之间。 с помощью CSSwill-changeАтрибут сообщает браузеру, какой элемент будет изменен.
27 ленивых загрузок больших скриптов с помощью Intersection Observer
Intersection Observer API предоставляет возможность асинхронно прослушивать изменения в пересечении целевого элемента с элементом-предком или окном просмотра документа верхнего уровня. Поддержка браузера? Поддерживаются браузеры Chrome, Firefox, Edge и Samsung. WebKit все еще находится в стадии разработки. Браузер не поддерживается? Ленивая загрузка полифилла.
28 Оптимизирован ли процесс рендеринга
Не стоит недооценивать силу воспринимаемой производительности. Старайтесь всегда быть на шаг впереди пользователя при загрузке статических файлов, чтобы процесс работал быстро, когда в фоновом режиме происходит множество вещей. Например, чтобы пользователи не отвлекались от вашей страницы, используйте скелетный экран вместо анимации загрузки.
29 Разогрейте соединение для более быстрого распространения
Используйте экран-скелет и лениво загружайте все большие компоненты, такие как шрифты, JavaScript, карусели, видео, фреймы и т. д. Используйте подсказки ресурсов, такие какdns-prefetch,preconnect,prefetchа такжеpreloadсэкономить время.
7. HTTP/2
30 для подготовки к HTTP/2
Поддержка HTTP/2 очень хороша, но также обеспечивает большой прирост производительности. Недостатком является то, что вы должны перейти на HTTPS, вы не поддерживаете группы пользователей в зависимости от размера HTTP/2, вы можете захотеть вернуть разные версии кода для пользователя HTTP/1.1 и HTTP/2, что требует от вас для настройки инструментов компилятора.
31 Правильное развертывание HTTP/2
Вам нужно найти хороший баланс между пакетированием модулей и параллельной загрузкой множества небольших модулей. Разбейте весь интерфейс на множество небольших модулей, затем сгруппируйте, сожмите и упакуйте. Разделение всего сайта примерно на 6-10 пакетов должно быть хорошим компромиссом (и неплохим для устаревших браузеров). Найдите правильный баланс для своего веб-сайта с помощью экспериментов и мониторинга данных.
32 Вы сохранили трафик данных для заголовка Save-Data?
Заголовок запроса Save-Data позволяет нам предоставить персонализированный ответ пользователям, обеспокоенным стоимостью трафика и производительностью. Например, вы можете изменить все изображения высокой четкости на изображения низкой четкости, без веб-шрифтов и великолепных анимаций, отключить автовоспроизведение видео и отправку на сервер и даже изменить интерфейс вашего приложения.
34 Убедитесь, что безопасность вашего сервера безупречна
Дважды проверьте правильность установки заголовков безопасности, устраните известные уязвимости и проверьте SSL-сертификаты. Убедитесь, что все внешние подключаемые модули и сценарии отслеживания загружаются через HTTPS, не имеют XSS и что заголовки ответов HSTS и Content Security Policy (CSP) настроены правильно.
35 Поддерживает ли ваш сервер и CDN протокол HTTP/2?
Разные серверы и CDN могут по-разному поддерживать HTTP/2. использоватьIs TLS Fast Yet?чтобы проверить свои настройки или просто посмотреть, как работает ваш сервер и какие функции поддерживаются.
36 Включено ли сшивание OCSP?
Включение сшивания OCSP на сервере может помочь ускорить рукопожатие TLS. Протокол OCSP сокращает время рукопожатия, избавляя браузеры от необходимости загружать и извлекать информацию о сертификате.
37 Вы используете IPv6?
Исследования показали, что обнаружение соседей IPv6 (NDP) и оптимизация маршрутов могут ускорить работу веб-сайтов на 10-15%. Перейдите на DNS с поддержкой IPv6, чтобы подготовиться к будущему. Просто убедитесь, что сеть с двойным стеком работает — это позволяет IPv6 и IPv4 работать одновременно. В конце концов, IPv6 не имеет обратной совместимости.
38 Включено ли сжатие HPACK?
Если вы используете HTTP/2, дважды проверьте, поддерживает ли ваш сервер сжатие HPACK. Сжатие HPACK сжимает заголовки ответов HTTP, чтобы уменьшить ненужные накладные расходы. Поскольку серверы HTTP/2 в наши дни появились совсем недавно, они могут не полностью поддерживать все стандарты, включая сжатие HPACK. H2spec — очень хороший инструмент для проверки уровня поддержки стандарта.
39 Используете ли вы Service Worker для кэширования или обслуживания автономного контента?
Какой бы оптимизированной ни была сеть, она никогда не будет быстрее, чем локальный кеш. Если ваш веб-сайт использует HTTPS, вы можете поместить статические ресурсы в кеш Service Worker, не запрашивая сеть.
8. Тестирование и мониторинг
40 Предупреждение о смешанном содержании монитора
Если вы недавно переведены с HTTP в HTTPS, обязательно используйте аналогичные услуги Report-uri.io такой строгий мониторинг смешанного контента или пассивной тревоги. Вы также можете использоватьMixed Content Scanдля сканирования вашего HTTPS-сайта на наличие смешанного контента, отличного от HTTPS.
41 Оптимизирован ли рабочий процесс разработки с помощью DevTools?
Выберите инструмент отладки и попробуйте нажать каждую кнопку. Убедитесь, что вы понимаете, как анализировать производительность рендеринга, вывод консоли, отлаживать JavaScript и редактировать стили CSS.
42 Тестировалось ли оно на прокси-браузерах и старых браузерах?
Тестирования в Chrome и Firefox недостаточно. Пожалуйста, посмотрите, как выглядит ваш веб-сайт в прокси-браузерах и устаревших браузерах (включая браузер UC, Opera Mini и т. д. Примечание переводчика: здесь прокси-браузер относится к функции облачного ускорения, обычно встречающейся в отечественных браузерах). Подсчитайте среднюю скорость сети в стране вашей аудитории, чтобы избежать серьезных сюрпризов. Используйте дросселирование сети и имитируйте устройства с высоким разрешением. Хотя BrowserStack великолепен, его нужно протестировать на реальной машине.
43 Установлен ли непрерывный мониторинг
Хорошим показателем эффективности является сочетание пассивных и активных инструментов мониторинга. Наличие частного экземпляра WebPagetest и использование Lighthouse действительно хорошо подходит для быстрого тестирования, но также требует создания системы непрерывного мониторинга с использованием инструментов RUM, таких как Calibre, speedscurve и т. д. Настройте собственные пользовательские таймеры для отслеживания определенных показателей скорости бизнеса.
Девять, быстрое решение
Этот список довольно полный, и для завершения всех оптимизаций может потребоваться некоторое время. Что делать, если у вас есть всего час, а вы хотите получить значительный прирост? Мы выбрали 10 самых простых способов сделать это. Очевидно, что перед тем, как вы начнете, и после того, как вы закончите, подсчитайте результаты, включая время начала рендеринга и SpeedIndex на 3G и проводных соединениях.
- Учитывайте реальный пользовательский опыт и ставьте приемлемые цели. Хорошая цель примерно: FMP
- Подготовьте основной CSS для вашего основного шаблона и поместите его в
<head>tab (ваш бюджет 14 КБ). Для CSS/JS убедитесь, что размер основного файла не превышает 170 КБ (размер в сжатом виде; 0,8–1 МБ до сжатия). - Откладывайте или лениво загружайте как можно больше сценариев, собственных или сторонних, особенно кнопок общего доступа, видеоплееров и других сложных модулей.
- Добавлены подсказки по ресурсам, в том числе
dns-lookup,preconnect,prefetchа такжеpreload. - Создавайте подмножества для веб-шрифтов и загружайте их асинхронно (или не используйте их вообще).
- Оптимизируйте изображения. Рассмотрите возможность использования WebP для ключевых страниц (например, целевых страниц).
- Убедитесь, что заголовки кэша HTTP и заголовки безопасности установлены правильно.
- Включите сжатие Brotli или Zopfli на сервере. Если он не поддерживается, не забудьте включить gzip.
- Если присутствует HTTP/2, включите сжатие HPACK и сообщайте о предупреждениях о смешанном содержимом. Если используется LTS, включите сшивание OCSP.
- Если возможно, кэшируйте как можно больше статических ресурсов (включая шрифты, стили, скрипты, изображения и т. д.) в сервис-воркере.
Huge thanks to Yoav Weiss, Addy Osmani, Artem Denysov, Denys Mishunov, Ilya Pukhalski, Jeremy Wagner, Colin Bendell, Mark Zeman, Patrick Meenan, Leonardo Losoviz, Guy Podjarny, Andy Davies, Rachel Andrew, Anselm Hannemann, Patrick Hamann, Andy Davies, Tim Kadlec, Rey Bango, Matthias Ott, Mariana Peralta, Philipp Tellis, Ryan Townsend, Mohamed Hussain S H, Jacob Groß, Tim Swalling, Bob Visser, Kev Adamson and Rodney Rehm for reviewing this article, as well as our fantastic community, which has shared techniques and lessons learned from its work in performance optimization for everybody to use. You are truly smashing!
Brilliant Open Web
Команда BOW (Brilliant Open Web) — это специальная группа разработчиков веб-технологий, занимающаяся продвижением разработки технологии Open Web и превращением Интернета в лучший выбор для разработчиков. BOW фокусируется на интерфейсе и Интернете, анализирует технологии, делится практикой, рассказывает об обучении и управлении. Подпишитесь на официальный аккаунт разработчика OpenWeb (ID: BrilliantOpenWeb), ответьте «Добавить группу», давайте вместе способствовать развитию технологии OpenWeb!