Полгода назад Google представила обновленную версию своего почтового сервиса. Несмотря на то что многие пользователи были недовольны редизайном, в том числе и на Хабре, это теперь основной интерфейс для пользователей.
Среди прочих недостатков, люди жалуются на ухудшение производительности новой версии, особенно на слабых компьютерах. Давайте же посмотрим, почему так происходит и что может быть такого тяжелого в почтовом интерфейсе. В этой статье мы будем пользоваться инструментами разработчика в Google Chrome, так что эта статья будет еще и напоминанием о том, какие возможности там имеются.
Исходные данные
Для начала, нужно понять, с чем мы имеем дело. В Google Chrome Devtools встроен инструмент Lighthouse, который строит простой и понятный отчет о производительности вашего сайта. В нем Gmail получает двойку за производительность (из максимальных 100 баллов!)
Если честно, это не тот результат, который ожидаешь от продукта Google. Тем не менее, посмотрим на эту ситуацию детальнее. Отключим кеш, и загрузим интерфейс Gmail с включенными devtools. На вкладке Network будут показаны все запросы, сделанные для загрузки этой страницы. Получилось 6.9 Мб. Это внушительный размер, учитывая, что даже Youtube, еще один недавно обновленный сервис, загружает всего 2 Мб ресурсов.
Здесь еще стоить заметить, что современные сервисы, и Gmail в их числе, используют Service Workers для улучшенного кеширования ресурсов. Поэтому для точных замеров холодного старта одного отключения кеша недостаточно, нужно еще сбросить Service Workers, которые тоже держат ресурсы. Только после этого цифра загрузки с нуля будет настоящей.
Теперь попробуем посмотреть на загрузку страницы в замедленной съемке. В документации Google Chrome, объясняется, как это сделать. Получим набор скриншотов с разных этапов загрузки страницы:
Здесь видно, что более-менее загруженной страница оказывается к 9й секунде.
С повторной загрузкой при использовании кеша ситуация получше. Страница делает всего 250 Кб запросов, однако это не делает ее быстрее, мы все так же видим заставку в течение почти 10 секунд. Дело явно не в количестве запросов, что-то другое делает страницу медленнее.
Блокируем ресурсы
Теперь посмотрим на список загружаемых скриптов:
Возможно, некоторые из них не так уж нужны для нормальной работы интерфейса? Попробуем поотключать их по очереди и тестировать работу страницы без них. Это легко делается при помощи встроенной в devtools функциональности.
Опытным путем выяснилось, что запросы на https://mail.google.com/_/scs/* являются критичными для работы интерфейса, а вот следующие запросы можно заблокировать:
www.gstatic.com/og/*— Google API Сlient Library, билиотека для запросов к сервисам Googlessl.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-часть Closure основывается на иерархии классов в "лучших" традициях GWT – подходе, c большим количеством многословных абстракций, которые, очевидно, влияют на производительность рендеринга. Современные UI-фреймворки (React или Vue, например) предлагают намного более легковесные абстракции – компоненты – которые намного дешевле в рендеринге.
Отсюда и долгая инициализация: в коде создаются тысячи классов и инициализируется много абстракций, перед тем как собственно начать рендерить нам интерфейс Gmail.
Таким образом, несмотря на обновленный внешний вид, Gmail тянет в себе легаси старых технологий, тяжесть которых не скрыть за внешней оболочкой.
Выводы
Надеюсь, после этого обзора станет немного понятнее, почему именно тормозит Gmail. К сожалению, не в наших силах заставить Google ускорить работу их сервиса, но можно хотя бы извлечь несколько уроков для своих приложений:
- В легаси проектах обычно встречается ненужный код, например, хаки для устаревших браузеров. Пересматривайте свои исходники и избавляйтесь от тех вещей, которые стали уже неактуальными.
- Абстракции не бесплатны. Если вы хотите решить задачу, используя изящный архитектурный паттерн, сначала подумайте, а не будет ли это слишком тяжелым инструментом, может есть вариант попроще.
- Не загружайте второстепенные элементы на страницу изначально. В данном случае, виджет Hangouts мог бы не блокировать канал, мешая загрузке основных ресурсов Gmail, а загружаться в фоне, уже после отрисовки основной функциональности.
- Не стоит пренебрегать современными технологиями. В них могут быть принципиально новые решения для ваших задач, более производительные и удобные. Странно увидеть в 2018 году редизайн сервиса от Google, в котором не используются веб-компоненты, за которые Google так активно топит на конференциях.
- Ну и не забывайте уделять внимание измерениям производительности для своих проектов. Для этого сейчас имеется много удобных инструментов, как браузерные, так и для запуска в CI.
Комментарии (89)
Nikelandjelo
12.11.2018 00:58+3Не очень понятно как автор перепрыгнул от минифицированного кода к UI компонентам closure library и решил, что именно они и есть проблема. По опыту дебага минифицированного closure compiler'ом кода даже при наличии исходников не сильно просто сопоставить минифицированный код оригинальному, потому что closure compiler практически все переименовывает, инлайнит функции, передвигает куски функций. А когда дело идет о таком большом приложении как гмейл, то вообще должно быть очень сложно определить что ж конкретно делает код.
И кстати полифилы при максимальных настройках оптимизации занимают около 10-15кб не gzip'нутого кода. Это конечно не классно, но если говорить о 6мб ресурсов и предположить, что полифилы загружены только в одном js файле (ну или в паре-тройке), то вряд ли они являются большой проблемой.justboris Автор
12.11.2018 01:33+1Выйти на Closure Library помогли строковые константы, которые сохраняются при минификации, например, вот такой фрагмент:
lCa = "closure_uid_" + ((1e9 * Math.random()) >>> 0), который соответствует вот этой строчке. Ну а дальше уже обладая каким-то подобием исходников можно представить, как выглядел этот код до минификации.
Про полифилы соглашусь, в таких объемах кода это экономия на спичках. Но сам факт того, что браузер тратит ресурсы на то чтобы загрузить код, по факту завернутый в
if(false) {...}очень огорчает.Nikelandjelo
12.11.2018 20:18Да, строковые константы — это один из основных способов распутать код. Но uid — это очень общая утилитная функциональность. Она используется во многих не ui-ных классах closure library и вполне может использоваться в кастомных классах самого гмейла, особенно учитывая что скорее всего в гмейле свой фремворк и есть какие-то базовые классы, которые могут этот uid использовать. Наверное более точным будет наличие вот этих констант.
justboris Автор
13.11.2018 01:07Как ни странно, но вот эти константы оказались обфусцированы. Но есть вот такой код
w.Xg = function(b) { if (this == b) throw Error(Qh); if (b && this.Lg && this.Id && this.Lg.Xc(this.Id) && this.Lg != b) throw Error(Qh); this.Lg = b; px.Ia.Zg.call(this, b); };
Соответствует вот этому исходнику:
goog.ui.Component.prototype.setParent = function(parent) { if (this == parent) { // Attempting to add a child to itself is an error. throw new Error(goog.ui.Component.Error.PARENT_UNABLE_TO_BE_SET); } if (parent && this.parent_ && this.id_ && this.parent_.getChild(this.id_) && this.parent_ != parent) { // This component is already the child of some parent, so it should be // removed using removeChild/removeChildAt first. throw new Error(goog.ui.Component.Error.PARENT_UNABLE_TO_BE_SET); } this.parent_ = parent; goog.ui.Component.superClass_.setParentEventTarget.call(this, parent); };
Здесь видно, что константа
goog.ui.Component.Error.PARENT_UNABLE_TO_BE_SETсжалась доQh, который инициализируется какQh = "eb".
KevlarBeaver
12.11.2018 01:22+1Пересматривайте свои исходники и избавляйтесь от тех вещей, которые стали уже неактуальными.
Это не сложно делать в действительно своих исходниках либо в исходниках, от и до покрытых тестами. Но в реальности, ковыряясь в чужом коде, написанном пару лет назад, и натыкаясь на костыль, — очень страшно его удалять, потому что не знаешь, всё ли после этого будет хорошо сейчас… через неделю… через месяц.justboris Автор
12.11.2018 01:40Когда делается редизайн продукта, есть возможность переписать весь код с нуля. Так можно выкинуть все эти грабли, полудоделанные фичи, спрятанные под флагами, костыли под старые форматы API, которых давно уже нет в природе и т.д.
JustDont
12.11.2018 02:11есть возможность переписать весь код с нуля
Возможность — безусловно есть. Денег и человеко-часов? Далеко не факт.
Переписывание с нуля не добавляет ничего к стоимости продукта здесь и сейчас, и владельцы бизнеса на это смотрят очень косо (и с их точки зрения в общем-то правильно).justboris Автор
12.11.2018 02:28Ну что же, теперь у нас есть живой пример Gmail. Можно показать его «бизнесу», пусть решают, сойдет им старый продукт с новыми костылями, или все-таки переписать по-нормальному
JustDont
12.11.2018 02:36+1Нет, ну как только гмаил помрёт и уступит место чему-нибудь еще, так они там все наверное сразу поймут, как они были неправы со своим 6.9Мб гмейлом.
Только есть у меня опасения, что этот сценарий не случится…edogs
12.11.2018 03:06+1Тормозит же адски, 5-10 секунд загрузки интерфейса для чтения текстовых писем в 2018 году на современнейшем железе это ад, трэш и издевательство над здравым смыслом.
gmail как почта и десктоп-интерфейс gmail все же разные вещи.
На десктопе, например, именно из-за тяжеловесности gmail перешли на «оффлайн» клиентов и работу по imap (стряхнули пыль с thebat), а так же иногда используем «легкую хтмл версию» ( mail.google.com/mail/u/0/h/1pq68r75kzvdr/?v%3Dlui ), задумываемся о подключении какого-нибудь альтернативного веб-сервиса работающего по imap с gmail.
Вряд ли гмылу от этого жарко или холодно, но тем не менее именно так «варят лягушку». Сначала имап, потом альтернативные веб-сервисы для доступа к имап, потом параллельно другие почтовые сервисы. Проблемы не возникают мгновенно, но зато имеют огромный запас инерции.JustDont
12.11.2018 03:22Да я это всё понимаю, что вы мне рассказываете. Но опять же вот, гмейл всегда можно открыть на любом соединении — именно потому что «легкая версия»-то на месте (и она реально очень легкая).
Nova_Logic
12.11.2018 11:08и она реально очень легкая
Она-то лёгкая, её я бы и открывал на обычном соединении. Только вот не нахожу варианта использовать её по-умолчанию. Это ад и угар, когда на i7-8700k+16gb ram+nvme почта открывается по 5-6 секунд.Mad__Max
13.11.2018 05:16Что характерно, но на Phenom 2 + 4gb ram + HDD она открывается примерно столько же (5-7 сек от самого начала — клика по ярлыку).
Тут дело уже не столько в доступных ресурсах — тут «всю систему надо менять!» (с)
nafgne
12.11.2018 17:17Она тоже тормозит. 3-5 секунд до открытия страницы проходит, несмотря на общую убогость.
worldxaker
12.11.2018 10:38ну в этом случае, потратив в два раза больше человека часов гуглеров, можно было бы сократить огромное количество человеко часов обычных юзеров ожидающих пока загрузится почта. и бизнес от этого бы только выиграл
eugenius_nsk
12.11.2018 08:02натыкаясь на костыль, — очень страшно его удалять
Очень помогает хорошее покрытие регрессионными тестами.ankh1989
12.11.2018 09:04Помогает только если весь проект под вашим контролем. А вот если вы меняете либу от которой зависит 10к проектов, то лучше либу вообще не трогать.
AirLight
12.11.2018 04:23Ну как же гугл мог так сильно опозориться?
batyrmastyr
12.11.2018 08:33Команде Гмыла не привыкать. Новый интерфейс гуглдоков в разы хуже старого даже спустя 2 года, восьмой андроид жрёт 12 гиг и замусорен хэнгаутсами по 300 метров каждый. Да и ютуб иногда падает на Сафари, лечится сменой агента.
В общем, гугл уже не первый год считает, что у всех пользователей мира гигабитная сеть и 10 ядерные ксеоны.SurfCalavera
12.11.2018 13:35падает на Сафари, лечится сменой агента.
извините за оффтоп — а на какой агент лучше поменять?
а то достает иногда это безобразие.batyrmastyr
12.11.2018 16:57Простите, уже не скажу — за последние полгода вроде не нарывался, редко ютуб открываю.
SDKiller
12.11.2018 05:11… двойку за производительность (из максимальных 100 баллов!
Зато дали замечательный пример, чтобы отбиваться от заказчиков, требующих вылизывать page speed до 100
hillbilly
12.11.2018 09:49До совсем недавнего времени там был жуткий красный рейтинг у Amazon.com, который на самом деле очень даже быстрый. Починили это где-то весной с.г., но до тех пор очень помогало с тем, о чем Вы пишете.
justboris Автор
12.11.2018 12:13+1Да, полировать до достижения 100 баллов может и не стоит, но если у вас околонулевой результат – это сигнал каких-то проблем.
Moxa
12.11.2018 15:23у меня на проекте Lighthouse по производительности показывает сотню, и это с сотней запросов к бекенду. Каких-то специальных оптимизаций не делалось
konchok
12.11.2018 07:39У какого-нибудь RoundCube загрузка и работа молниеносная. Не сказать что функционал как-то принципиально отличается от Gmail.
inkvizitor68sl
12.11.2018 15:00Есть ещё afterlogic, он лучше =)
Но функциональность отличается, такого количества шпионских блобов ни в RC, ни в AL не завезли.
ru5l4n
12.11.2018 10:56Странное дело. Смотрел я тут на кануне запись с недавнего NgConf, где товарищ рассказывает, что 600+ приложений гугл используют Angular. Неужели GMail до сих пор не в этом списке?..
justboris Автор
12.11.2018 11:38Гугл такой гугл. Компания большая, проектов много. Цифра в 600+ приложений может быть очень маленькой в процентном отношении.
Vikonrob
12.11.2018 10:56+2Да всё нормально. Youtube в браузере уже на слабых компах не посмотришь, скоро и Gmail нельзя будет открыть без 8-ми ядерного камня, 16ГБ ОЗУ, и графического ускорителя класса GTX 1080TI
Nova_Logic
12.11.2018 12:59А YouTube вообще у меня последнее время весело багует- нажимаешь на одно видео справа, а подгружаться начинает какое-либо другое. Если нажимать Ctrl+r открывается то на которое первоначально кликал
inkvizitor68sl
12.11.2018 15:02Это не совсем «youtube багует», это РКН багует, объявляя локальные гугловые CDN-сервера «шпионским оборудованием». Некоторые провайдеры отключили у себя гугловые кешеры, а по публичным каналам до ютуба частенько достучаться не выходит, канал забит.
altrus
12.11.2018 13:05Я как-то проапгрейдился со среднего пятого айкора/6Гб на десятиядерный зеон/16Гб. И неожиданно обнаружил, что единственное, что значительно прибавило в производительности — это браузер (Хром, ессно). Причем реально стало круче!
Разработка и остальное укомфортились совсем не так сильно, а вот на серфинге теперь нервов значительно меньше тратится.springimport
12.11.2018 17:03Что i5, что xeon являются слабыми для десктопа в плане скорости ядер у которых частота недалеко ушла от 3.0ггц. Для комфортной и быстрой работы нужно 4-5.
Поэтому после 6-8 ядер остальные не добавляют смысла для обычных задач.
OnelaW
12.11.2018 16:37Вы очень близки к истине, примерно на такой конфигурации большинства поделок погромистов начинают быстро загружаться и что-то быстро делать. Даже сильно кривые сайты можно переварить, хотя есть нюанс, в хроме еще не пробовал, но вот в лисе 60 вкладок одноглазников или иных открытых страничек от погромистов меил.ру приводит к зависанию и краху браузера.
6/16/1050
AGARTY
12.11.2018 12:50+1GMAIL раньше для меня ассоциировалося с прогрессом. Потом когда начал замечать тормоза, понял, что надо искать альтернативу, т.к. именно из-за слабых систем было все труднее использовать его. После того как полностью перешел и настроил свои сервера, мои проблемы были решены. Но не все же пользователи могут позволить себе такое. Проблема гигантов в том, что они думают, что их пользователи должны принимать на веру все, что они делают, и мнение пользователей можно не учитывать.
altrus
12.11.2018 13:02Гиганты просто максимизируют свою прибыль. Они не думают о пользователях ничего.
vikarti
13.11.2018 09:04Я вот думаю как свалить...(да хоть на synology mail station) но одна из проблем в том что G Suite. И на эти аккаунты куча всего куплено.
Вот можно ли грохнуть G Suite для mydomain.com и при этом НЕ грохнуть сами гуглоаккаунты вида user@mydomain.com?Daemon_Hell
13.11.2018 11:18Насколько я понимаю — учетки гугла живут независимо — у меня есть на одну почту G suite учетка и обычная (в которую я не могу попасть, но гугл регулярно присылает письма что злые хакеры туда заходят)
AGARTY
13.11.2018 13:14я просто настраивал в свое время переадресацию на новую почту. со временем все мои клиенты и друзья перешли на новую, а старые емайлы живут до сих пор.
tamtakoe
12.11.2018 13:09+4Как-то всё это не укладывается в моей голове вместе с непроходимыми гугловскими собеседованиями, о которых здесь постоянно пишут
UberSchlag
12.11.2018 14:03Побуду кэпом. Из знания передовых технологий ведь можно строить как изящные и простые решения, а можно хтонические нагромождения smartass-кода. Причем первое делать сильно сложнее.
Так что сложные собесы просто обеспечивают пул разработчиков только лучшими стрелками, да вот менеджмент — менеджмент как обычно…
stayacid
12.11.2018 13:37Неплохо ускоряет работу отключение «Действия, доступные при наведении указателя на письмо» и «Значки персональных писем»
red_led
12.11.2018 13:37+1Как человек 5 лет проработавший с closure library/compiler, не могу сказать, что там всё хорошо. Но и винить его в том, что из-за чьих то кривых рук гмэйл не грузится тоже излишне. С инструментами надо уметь работать.
И обратная совместимость не вина библиотеки, которую использует не только гугл. Если ActiveX не нужен — пожалуйста:--define goog.net.XmlHttpDefines.ASSUME_NATIVE_XHR=true, и компилятор автоматом уберёт лишее.justboris Автор
13.11.2018 00:55Про флаги компиляции интересно. Нашел, что в коде Gmail еще подключается и код для эмуляции addEventListener через attachEvent, для IE8, который тоже можно выключить флагом.
Возникает вопрос: а зачем в 2018 году включать все это по дефолту? Разумнее было бы наоборот, с возможностью включить тем, кому всё еще это нужно. А идеальнее всего вообще использовать конфигурацию вроде browserlist, где пользователи бы просто указывали нужные им браузеры, а полифилы сами конфигурировались исходя из этой настройки, без жонглирования разными флагами.
dMac
12.11.2018 13:58+1Пользуюсь гуглопочтой исключительно по IMAP/SNMP с локально установленным клиентом.
И, судя по этому факапу с тормозящим веб интерфейсом (кстати, на гугловой же page speed tool — сколько попугаев показывает?), разработчики gmail тоже им не пользуются.Dee3
12.11.2018 14:51Ага, а если еще учесть что и по IMAP иногда бывают глюки (в последнее время редко) или неочевидные костыли вещи, вроде Gmail IMAP – Solving the [Gmail] separation
То каждый раз задумываешься: чем эти люди там занимаются? Пользуются ли они своим продуктом?
Irgen
12.11.2018 15:25Попугаев ровно 100 из 100 в десктопной версии и всего 53 в мобильной. Хотя по моим ощущениям все с точностью до наоборот, и мобильная версия вполне быстро грузится и работает
Iamkaant
12.11.2018 17:53вот да. Я понимаю, сценарии разные бывают. Но на своем ПК вижу смысл только в использовании почтовых клиентов. Больше настроек, меньше тормозов, возможность читать почту в оффлайн.
saipr
12.11.2018 18:24К сожалению, не в наших силах заставить Google ускорить работу их сервиса
Не в наших силах заставить подписывать почтовые сообщения ГОСТ-овыми сертификатамию
ivangermes
12.11.2018 18:58Я решил вопрос так:
Мало кто помнит, что есть web-версии gmail для смартфонов и планшетов.
Меняем UserAgent на современный планшет, Ctrl+F5.
Вообще не тормозит.
Вот так вот выглядит:
fogx
12.11.2018 19:42+1Хорошо объяснять тормоза легаси-кодом и поддержкой IE6, но почему тогда этот же Gmail в эпоху IE6 совсем не тормозил?
justboris Автор
12.11.2018 21:02+2Потому что в эпоху IE6 продукт был моложе и там было меньше кода.
Если разработать путём только докидывания кода сверху, то мы приходим к вот такой ситуации.
Mad__Max
13.11.2018 05:21Вспомнилось откуда-то:
— я только постоянно сверху докидываю
— ты бы хоть, посмотрел, что там внизу делается
— а чего туда смотреть — там компост
stat1c_void
12.11.2018 21:43Из моего опыта: если в текущем Gmail-е выключить чат (Настройки — чат — отключить чат), то прекращается дикий memory leak таба гмыла (Chromium 70).
whyme
12.11.2018 21:43+2Пару лет назад кто-то в комментариях к какой-то статье злорадно ехидничал о том, что скоро сайты будут грузиться дольше чем ОС… в принципе ожидаемо, но не думал что это случится так скоро.
pavelkolodin
12.11.2018 22:06Возможно ноут с 16 гигами — это очень круто, но каждая очередная загрузка гмейла — менее секунды. Успеваю увидеть, что конвертик хлопнул дверью и сразу письма.
ledinhome
12.11.2018 23:25+2Я не пользователь gmail, но мне все равно интересно — а зачем они сделали это обновление? В чем реальное преимущество для пользователя, и в чем могут быть плюсы для самого google? (Может это часть далеко идущих планов?) Но вообще, как пользователю только мобильного интернета (а ранее и с помегабайтной оплатой), мне грустно от этого тренда :(
varnav
13.11.2018 00:30Ну, software bloat обычное дело, не вчера появился. Я думаю это особенности менеджмента большой корпорации. Кто-то должен выдавать результат, и результат должен быть не «ну всё, старый gmail оптимизирован, давайте теперь уволим половину разработчиков и сэкономим миллион в год» а «мы запустили новый gmail, потратили 50 миллионов, смотрите сколько в нём фич!».
geekmetwice
13.11.2018 04:29Когда читаешь в новостях "… за этим стоят такие гиганты, как Гугл....", хочется прыснуть — да уж, «маленькие гиганты большого кода»! Позорнее разработок ещё не видел (после Windows Millenium).
ThisMan
Как то на хабре уже была статья, о том как же обстоят рабочие дела в гугле. Автор сетовал на том, что фикс багов и рефакторинг никому не нужен, и тебе как разработчику это не принесёт баллов на ревью. Думаю, то что описано в этой статье доказывает вышесказанное.