Проблема с авторизацией (социальной и модераторов) в новой версии Chrome решена!

С новым релизом Chrome 80, перестала работать авторизация. Проблема была в том, что изменилась дефолтная политика cookie. Браузер автоматически выставляет значение SameSite=Lax, которое ограничивает  возможность отправки сookie на сторонние сайты и тем самым блокирует работу сторонних виджетов, которые не адаптированы к такому поведению. Наши виджеты теперь полностью готовы к работе на любых версиях Chrome. Также данный фикс частично исправил проблему на Safari.

В предыдущей статье мы разобрались с сетевыми ресурсами, выяснили что переход на http/2 позволяет быстрее загружать ресурсы, а в данной статье посмотрим на те ресурсы, что мы загружаем.

Как загружается страница в браузере

Сначала загружается html страница, далее если приоритет не указан и используется http/1, то идет загрузка ресурсов из тега head, это css, js.

После парсинга html браузер создает модель DOM, далее браузер когда видит ссылку на css приостанавливает визуализацию до тех пор пока не загрузит, распарсит css и не построит модель CSSOM.  Это блокирующий процесс в том смысле, что пользователь не увидит содержимого, пока эти ресурсы не будут загружены, спарсены и применены к странице т.е. html и css замедляют загрузку страницы.

Оптимизация CSS

При использовании css фреймворков Bootstrap/Foundation и др., которые содержат большое кол-во css необходимо:

• выбирать только необходимые компоненты
• делать  lazy загрузку только того, что необходимо для работы: например если фрейморк используется только для  desktop то убрать стили для mobile, если у вас не используются какие-то селекторы, то их также можно вырезать
• воспользоваться альтернативами: flexbox и grid.

На мобильных устройствах компиляция может доходить до 300ms. Всегда это нужно отслеживать на новых браузерах.

Оптимизация JS

Jquery cтал популярен благодаря удобным селекторами, но в настоящее время все современные браузеры поддерживают querySelector, querySelectorAll. Работа с событиями возможна через  addEventListener. Работа с классами и атрибутами элементов через classList, setAttribute, and getAttribute.

Библиотеки манипулирующие с DOM напрямую хорошо подходят для быстрого старта проектов, но сильно влияют на производительность. Современные браузеры довольно быстрые, но проблемы возникают когда идет манипуляция большого кол-ва элементов:

• чтение атрибутов, или имени классов
• получением child или sibling

Браузеру необходимо искать, проверять и парсить большое кол-во элементов для каждого узла.

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

Проверим скорость манипуляции элементами через Jquery и VanillaJS, для теста возьмем 1000 операций append, как самую частую операцию при создании страницы динамически.

for(let i = 0; i < 1000; i++) {
	$("div").append("test item "+i);
}

let c = new DocumentFragment()
for(let i = 0; i < 1000; i++) {
   const e = document.createElement('div');
   var t = document.createTextNode("text text.");   
   e.appendChild(t);  
   c.appendChild(e);
}
document.getElementById('div1').appendChild(c);

Тестировать будем на телефоне Sony Xreria XR(4core CPU, 2GB).

По данным замерам хорошо видно, что операция append во втором случае является почти бесплатной по времени, т.к построение дерева html происходит в памяти с помощью функции DocumentFragment, а процесс Layout занимает больше всего времени, т.к происходит построение сразу же всех элементов из памяти.

В react'e используется такой же принцип:  создается виртуальная модель dom, которая имеет текущее и предыдущее состояние, синхронизирует изменения и изменяет только нужные узлы DOM.  

Даже при среднем 4G(или хорошем 3G) мобильном соединении в 5-10 мбит/с  средний мобильный сайт (1896 КБ) должнен загружаться не более чем за 2 секунды. Но почему же тогда практический любой сайт, открываемый на мобильном грузится довольно долго? Наверное вы замечали, что серфинг на мобильном значительно отличается от desktop.

Для описания загрузки сайта мы воспользовались проектом HTTP Archive, который краулит миллионы (делает замеры в lighthouse) url на десктопах(4 млн.) и мобильных(5 млн.),  и построили следующую диаграмму:

Цифры на диаграмме (и ниже) усредненные: используется 3G, средний телефон  Moto G4, и данные по всем сайтам усреднены.

При загрузке сайта сначала загружается html, далее в зависимости от протокола http/1 или http/2 формируются приоритеты для загрузки других ресурсов. Загружаются css, шрифты, js, img.

Сначала пояляется первая часть  контента по которой пользователь понимает, что сайт грузится в принципе, метрика FCP(First Contentful Paint)  для среднего смартфона и 3g соединения составляет 5.7 секунд, для desktop 2.3 секунды. Но в это время мы еще пока не можем пользоваться навигацией и прочими интерактивными элементами, до тех пор пока javascript не будет спарсен, скомпилирован и исполнен.

После этого можно посмотреть на метрику TTI(Time to interactive):

Эта метрика как раз показывает когда уже можно взаимодействовать с мобильным сайтом: сейчас это 9.3 секунды, а год назад было 15 секунд.

Все дело в том, что кроме затрат на загрузку ресурсов, самым дорогим по времени является парсинг и выполнение js и именно это замедляет первичную загрузку страницы(парсинг) и TTI(js execution). Парсинг и компиляция css и построение cssdom, шрифтов, рендеринг images также занимает какое-то время(обычно от 10 до 200 мс), но  это не первое, что нужно оптимизировать.

Парсинг JS.

После загрузки js браузер производит декомпрессию(если source был сжат), парсинг кода и компиляцию. Операция parsing/compile выполняется в main thread и является блокирующей для всех других операций выполняющихся в этом потоке(до Chrome 71), в том числе рендеринг.

Данный этап может занимать от 2 до 15 секунд в зависимости от мощности процессора телефона и ресурсов сайта.

По данным наших замеров эмулятор Moto G4 с версией Chrome 61 250Kb gzipped(сжатого) кода ~ 1 Mb распакованного парсится за 2000 ms. Все замеры с пошаговой инструкцией и примерами мы выложим в след. статье посвященной парсингу JS.

Конечно в реальности нужно смотреть на google analytics, чтобы делать тесты своего сайта на девайсах ваших пользователей, а не на том смартфоне, что лежит у вас в кармане.

Возможные решения:

1) отказаться от тяжелых SPA приложений с большим кол-вом js кода, особенно на mobile.

2) Для mobile лучше всего сделать статический сайт, а если требуется функциональность SPA, то лучше сделать отдельное мобильное приложение. 3) Искать более легкие библиотеки.

Выполнение JS.

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

Для наглядной иллюстрации по скорости выполения мы замерили 1000 append операций с помощью Jquery и чистого JS. На чистом JS данная операция выполняется в 4 раза быстрее.

Данный замер проводился на macbook pro, и для среднего телефона можно умножить в 6-8 раз, а это уже 2-3 секунды.

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

Решение: по возможности использовать чистые решения с минимальным кол-вом библиотек, по максимуму искать альтернативные решения на чистом JS.

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

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

JAMStack держится на двух китах: SSG (Static Sites Generators) и Headless Cms.
SSG генерит все страницы сайта при любом изменении контента, а Headless Cms репозиторий контента, который может быть запрошен через API и основная цель которого хранить и передавать данные по запросу.

Термин Headless произошел от того, что head (например front end у сайтов) отрывается от body (например backend у сайтов).

Headless cms сохранил интерфейс(админку) для создания структур данных и добавления контента, а сам контент отдается через Restful API или GraphQL.

Headless Cms исходя из своей архитектуры не привязана ни к какому фронтенду как например другие cms: Wordpress, Drupal, Joomla, etc. Контент может быть запрошен на любой платформе.

На https://headlesscms.org располагается каталог Headless Cms систем: opensource и closesource.

Самый большой рейтинг у Strapi.

Выглядит это вот так:

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

Далее все это можно получать через api.

В следующей статье сделаем краткий обзор одного из SSG.

В прошлой статье мы поговорили про прогрессивные сайты, посмотрели кейсы как переход на pwa, а именно ускорение загрузки сайта для пользователей позволяет увеличивать конверсии и вовлеченность аудитории.

Давайте проверим как быстро грузится ваш сайт?

Проверить просто: открываем консоль хрома Command+Option+I (Mac) or Control+Shift+I (Windows, Linux), переходим на вкладку "Performance" и нажимаем кнопку "Start profiling and reload" и смотрим результат на вкладке Summary.

Для примера посмотрим на cackle.me.

У нас во время теста это 610 ms. В это время входит полная загрузка и отработка всех скриптов. Основное время занимает отработка скриптов аналитики, которые загружатся асинхронно и не влияют на то, как пользователь видит сайт.  Если ваш сайт не загрузился за 2000-3000 ms за минусом времени на работу  скриптов, влиящих на отображение страницы, то нужно проводить оптимизацию.  Также теперь попробуйте сделать замер с эмуляцией мобильных устройств с настройкой 3G и уменьшение мощности процессора в 4 раза.(шестеренка настроек справа devtools). Результат может быть в 2-3 раза хуже.

Как оптимизировать?

Процесс загрузки сайта состоит из нескольких основных этапов:

• Network - получение ресурсов по сети
• Script evaluation - выполнение скриптов на странице
• Rendering - обработка html элементов браузером
• Painting - отрисовка DOM элементов браузером

Каждый этап занимает какое-то время и мы посмотрим как его можно уменьшить.

Смотрим в отчет на Network.

На шкале Network показана загрузка всех ресурсов: html страницы, js, css, картинок. Задача уменьшить время загрузки этих ресурсов.

Какая оптимизация была раньше?

• минифицировать js и css
• убрать все скрипты в конец тега body
• сжать картинки

Новые технологии оптимизации загрузки сайта

• перейти с http/1 на http/2

На http/1 браузер имеет возможность создавать до 6 TCP соединений и внутри одного соединения идет только один запрос, в итоге браузер накапливает очередь запросов, а пользователю приходится ждать загрузки всех ресурсов. Приоритет загрузки ресурсов при http/1 определяет браузер и у каждого браузера своя стратегия определения приоритетов (какие-то сначала грузят css, шрифты, картинки, другие идут строго по html и загружают все последовательно)

Http/2 - вторая версия сетевого протокола http, при котором может передаваться множество запросов в одном соединении TCP. При HTTP/2 сервер может отправить содержимое, которое ещё не запрашивалось клиентом, выслать дополнительные файлы, которые нужны браузеру для отображения страниц, без необходимости парсинга браузером основной страницы. Также на сервере можно установить приоритет ресурсов, которые будут отдаваться сервером в первую очередь. Например, самое верхнее изображение или видео в header'e шаблона может отдаваться в первую очередь, т.к это то, что пользователь увидит в самом начале при заходе на страницу. Остальные изображения будут иметь меньший приоритет, наряду с какими-нибудь скриптами аналитики.

Поддержка браузерами: все браузеры поддерживают http/2 поверх tls. Т.е для работы http/2 сайт должен работать по https.

Поддержка серверами: практически все популярные хостинги поддерживают http/2, на выделенном сервере nginx последних версий также имеет такую поддержку. Практически все популярные сайты уже давно используют именно этот протокол.

Как проверить: Протокол запросов можно посмотреть на вкладке Network в шапке таблицы с запросами (необходимо подключить Protocol по правому клику мыши/двойному tap на маке).

Ускорение: в 2-3 раза. Можно нагуглить http/2 example и протестировать в своем браузере.

Для кого будет иметь максимальный эффект: для страниц с большим кол-вом картинок, библиотек, скриптов.

• использовать Preload и Prefetch

Приоритеты запросов можно посмотреть на вкладке Network в шапке таблицы с запросами (необходимо подключить Priority по правому клику мыши/двойному tap на маке)

<link rel="preload"> информирует браузер, что ресурс необходим как можно скорее и поднимает приоритет загрузки(на вкладке Priority highest).

<link rel="preload" as="script" href="important_for_view.js">
<link rel="preload" as="style" href="critical.css">

Данные будут отправлены в cache страницы, который существует пока открыта данная страница. Данная директива работает практически во всех браузерах и особенно эффективна на http/1. При использовании http/2 запросы кэшируются в отдельном push cache и если сервер уже прислал ресурс, то повторного запроса(от preload) не будет.

<link rel="prefetch"> позволяет сделать предварительную загрузку страницы(на вкладке Priority highest), которую пользователь скорее всего будет использовать/переходить, чтобы задействовать свободное время сети. Самый простой пример - следующая страница пагинации.

<link rel="prefetch" href="next-pagination-page.html">

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

• разделить код

Разделение кода: идея в том, чтобы загружать только те ресурсы, которые необходимы для отображения текущей страницы, а не всего сайта. Раньше при использовании http/1 все js и css соединялись в bundle и отдавались клиенту единым файлом. Это было целесообразно из-за ограничений http/1 по кол-ву запросов. Сейчас, когда у нас есть возможность использовать http/2 мы можем разделить ресурсы и загружать только то, что нужно только для текущей страницы. Для загрузки только нужных ресурсов можно воспользоваться webpack или просто разделите ваши css и js на небольшие файлы и включайте их только там, где они используются.

Ускорение загрузки сайта: данный метод позволяет в несколько раз уменьшить размер подгружаемых ресурсов, и соответственно и скорость загрузки сайта в целом.

В следующей статье мы будем оптимизировать работу ui библитек.

Ставьте лайк в ВК и делайте репост в Twitter  и FB, если вам понравилась статья, и вы хотите продолжения.

Прогрессивные веб приложения (progressive web app) это обычные веб приложения которые используя современные веб технологии добиваются следующих целей:

1) Надежность. Когда пользователь загружает приложение со своего домашнего экрана, то оно загружается сразу внезависимости от наличия сети. Это происходит благодаря Service worker, который является клиентским прокси и контролирует запросы между приложением и сервером, и приложение становится доступным даже оффлайн.

2) Быстрая загрузка. DoubleClick by Google обнаружил, что по 53% посещений мобильных сайтов были отказы если страницы грузилась дольше 3-х секунд.

3) Вовлечение. PWA может быть инсталирован на десктоп или домашний экран мобильное телефона и запускаться отдельно от браузера. Самый запоминающийся мне пример это Espruino IDE. Данная функция возможна при объявлении Web App Manifest файла в хидере приложения, который позволяет контролировать отображение и запуск приложения: задать иконки для дом.экрана, страницу для загрузки когда приложение стартует, ориентацию экрана. Также для целей вовлечения используется web push notifications, а их умное использование позволяет увеличить вовлеченность аудитории до 4х раз.

PWA позволяют получить app-like expirience (опыт использования) нативного приложения.

Итак, почему стоит все-таки разрабатывать PWA сайт?

• Стоит того, чтобы быть на домашнем экране пользователя
• Надежная работа в независимости от сети или оффлайн
• Увеличивается вовлеченность

Кейс eXtra Electronics: Web push notifications помогли eXtra Electronics увеличить вовлеченность в 4 раза и эти пользователи в 2 раза больше проводили времени на сайте.

• Увеличиение конверсии
  Кейс Aliexpress: переход на pwa улучшил конверсию на 104% на всех браузерах и  на iOS 82% .

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

Ставьте лайк в ВК и делайте репост в Twitter  и FB, если вам понравилась статья, и вы хотите продолжения.

JAMstack - современная архитектура веб-разработки. JAMstack предлагает генерировать html только один раз при изменении контента. Никакой генерации шаблонов runtime(на лету).
Размещать такой сайт можно на любом файловом хостинге, cdn. От хостинга не требуется ни баз, ни поддержки языков программирования и/или фрейморков. Остальной функционал возлагается на микросервисы.

Преимущества:

• простота и дешевизна: нет серверов, нет БД, размещение на любом файлом сервисе и даже на github pages.
• скорость загрузки страниц, т.к не тратится время на запросы к БД, генерации шаблонов на лету.
• большая устойчивость от взломов / DDOS из коробки, т.к весь контент компилируется в процессе деплоя и у хакеров нет доступа к БД или к cms
• данными для сайта могут выступать любые источники: cms, файлы, api.
  
  jamstack.org

Совершенно неважно, что мы выбирем для доставки писем свой сервер (например, postfix, haraka) или сторонний сервис (mailchimp, amazon ses). Правила доставки для всех серверов доставки одинаковые, и применяются автоматизированными системами. Есть мнение, что использование платных сервисов доставки гарантирует хороший % доставки. В большинстве случаев это так и есть. И вот почему.

Рассылки через сторонние сервисы

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

Основные приемущества по доставке писем:

• Есть автоматическая система отлова bounced писем, invalid user, user not found по всей базе, что значительно уменьшает риск бана IP
• Автоматизированный контроль черных списков
• Есть статистика отправок и переходов

Основные правила рассылки для собственного почтового сервера

1. Создаем A запись для smtp сервера. Это может быть @ или поддомен(например, smtp) в случае, если root домен занят делигирование на сайт. Данное действие полезно для:

   • Можно по названию домена соединяться по ssh
   • Понадобится для указания в mx записи, ptr

2. Настройка MX записи. Считается, что MX запись настраивается главным образом для входящей почты. На самом деле для исходящего smtp сервера эта настройка также имеет значение. Многие почтовые сервера проверяют MX запись домена и если она не указывает на A запись почтового сервера с которого происходит отправка, то письма могут быть отклонены с различными статусами ошибок либо как это происходит на gmail письмо просто уйдет в папке SPAM.
   Внимание: MX запись не может быть IP адресом сервера, всегда должна указаны на A запись.

3. ReverseDNS запись указывается на хостинге либо у вашего провайдера. Она должна указывать на A запись из пункта 1. Значение должно быть указано точно до поддомена.

4. SPF запись не является обязательным условием для всех, но gmail отправляет письма в СПАМ. Указывается как txt запись для @ домена как "v=spf1 +a mx ~all"

5. DKIM подпись с указанием DMARC

6. На smtp сервере в HELLO BANNER должен быть указана А запись домена

7. Проверить репутацию IP адреса по black lists mxtoolbox.com

Общие правила для рассылки

8. Ссылка на отписку от рассылки в заголовках письма List-Unsubscribe (для почтовых клиентов поддерживающих отписку)
9. Ссылка на отписку от рассылки в теле письма
10. Контент не должен содержать много ссылок - т.к многие почтовые сервера могут оценить данные ссылки как спам

В итоге необходимые следующие действия для успешной отправки писем: