Хабрахабр

Заглядываем под капот нового Gmail

Несмотря на то что многие пользователи были недовольны редизайном, в том числе и на Хабре, это теперь основной интерфейс для пользователей. Полгода назад Google представила обновленную версию своего почтового сервиса.

Давайте же посмотрим, почему так происходит и что может быть такого тяжелого в почтовом интерфейсе. Среди прочих недостатков, люди жалуются на ухудшение производительности новой версии, особенно на слабых компьютерах. В этой статье мы будем пользоваться инструментами разработчика в Google Chrome, так что эта статья будет еще и напоминанием о том, какие возможности там имеются.

Исходные данные

В Google Chrome Devtools встроен инструмент Lighthouse, который строит простой и понятный отчет о производительности вашего сайта. Для начала, нужно понять, с чем мы имеем дело. В нем Gmail получает двойку за производительность (из максимальных 100 баллов!)

Тем не менее, посмотрим на эту ситуацию детальнее. Если честно, это не тот результат, который ожидаешь от продукта Google. На вкладке Network будут показаны все запросы, сделанные для загрузки этой страницы. Отключим кеш, и загрузим интерфейс Gmail с включенными devtools. 9 Мб. Получилось 6. Это внушительный размер, учитывая, что даже Youtube, еще один недавно обновленный сервис, загружает всего 2 Мб ресурсов.

Поэтому для точных замеров холодного старта одного отключения кеша недостаточно, нужно еще сбросить Service Workers, которые тоже держат ресурсы. Здесь еще стоить заметить, что современные сервисы, и Gmail в их числе, используют Service Workers для улучшенного кеширования ресурсов. Только после этого цифра загрузки с нуля будет настоящей.

В документации Google Chrome, объясняется, как это сделать. Теперь попробуем посмотреть на загрузку страницы в замедленной съемке. Получим набор скриншотов с разных этапов загрузки страницы:

Здесь видно, что более-менее загруженной страница оказывается к 9й секунде.

Страница делает всего 250 Кб запросов, однако это не делает ее быстрее, мы все так же видим заставку в течение почти 10 секунд. С повторной загрузкой при использовании кеша ситуация получше. Дело явно не в количестве запросов, что-то другое делает страницу медленнее.

Блокируем ресурсы

Теперь посмотрим на список загружаемых скриптов:

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

Опытным путем выяснилось, что запросы на https://mail.google.com/_/scs/* являются критичными для работы интерфейса, а вот следующие запросы можно заблокировать:

  • www.gstatic.com/og/* — Google API Сlient Library, билиотека для запросов к сервисам Google
  • ssl.gstatic.com/inputtools/* – Google Input Tools – виджет экранной клавиатуры
  • hangouts.google.com — отвечает за виджет handgouts

Помимо этих запросов, установленный у меня AdBlock уже блокировал запросы на https://play.google.com/log, их мы в расчет не берем, так как они не делались и до начала экспериментов с блокировками.

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

Смотрим в профайлер

Надо посмотреть, что же происходит в течение этих 4 секунд. Итак, мы минимизировали загрузку ресурсов как могли, но страница все равно грузится долго. Он показывает нам такую картинку: Тут нам на помощь придет встроенный в Chrome профайлер.

Инстересно, что такого важного и тяжелого происходит в этом коде. Здесь видно, что на протяжении всего этого времени браузер был занят исполнением Javascript. К счастью, Javascript загружается в браузер практически без изменений, и его можно почитать.

Рассматриваем оставшийся код

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

По итогам просмотра нашлось следующее:

  • Код очень сильно обфусцирован. Скорее всего, использовался Google Closure Compiler в Advanced Mode. То есть, разработчики Gmail выжали максимум из современных технологий минификации.
  • В коде собираются метрики производительности, так что разработчики должны быть в курсе, о том, насколько медленно загружается интерфейс у пользователей.
  • Исходники содержат полифиллы для Promise, Map, Set и других современных API, которые могли бы не грузиться в современные браузеры.
  • Код Gmail написан на Google Closure Libary

Closure Library – это фреймворк для разработки интерфейсов, появившийся в 2009 году, и с тех пор мало изменился. На последнем пункте стоит остановится поподробнее. Например, там до сих пор поддерживается Ajax через ActiveXObject: который нужен только для IE6 и ниже, хотя текущий Gmail официально поддерживает только IE 10+.

Современные UI-фреймворки (React или Vue, например) предлагают намного более легковесные абстракции – компоненты – которые намного дешевле в рендеринге. Кроме того, UI-часть Closure основывается на иерархии классов в "лучших" традициях GWT – подходе, c большим количеством многословных абстракций, которые, очевидно, влияют на производительность рендеринга.

Отсюда и долгая инициализация: в коде создаются тысячи классов и инициализируется много абстракций, перед тем как собственно начать рендерить нам интерфейс Gmail.

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

Выводы

К сожалению, не в наших силах заставить Google ускорить работу их сервиса, но можно хотя бы извлечь несколько уроков для своих приложений: Надеюсь, после этого обзора станет немного понятнее, почему именно тормозит Gmail.

  • В легаси проектах обычно встречается ненужный код, например, хаки для устаревших браузеров. Пересматривайте свои исходники и избавляйтесь от тех вещей, которые стали уже неактуальными.
  • Абстракции не бесплатны. Если вы хотите решить задачу, используя изящный архитектурный паттерн, сначала подумайте, а не будет ли это слишком тяжелым инструментом, может есть вариант попроще.
  • Не загружайте второстепенные элементы на страницу изначально. В данном случае, виджет Hangouts мог бы не блокировать канал, мешая загрузке основных ресурсов Gmail, а загружаться в фоне, уже после отрисовки основной функциональности.
  • Не стоит пренебрегать современными технологиями. В них могут быть принципиально новые решения для ваших задач, более производительные и удобные. Странно увидеть в 2018 году редизайн сервиса от Google, в котором не используются веб-компоненты, за которые Google так активно топит на конференциях.
  • Ну и не забывайте уделять внимание измерениям производительности для своих проектов. Для этого сейчас имеется много удобных инструментов, как браузерные, так и для запуска в CI.
Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть