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

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


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


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


    Выводы


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


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

    Похожие публикации

    Комментарии 91
      +19
      Как то на хабре уже была статья, о том как же обстоят рабочие дела в гугле. Автор сетовал на том, что фикс багов и рефакторинг никому не нужен, и тебе как разработчику это не принесёт баллов на ревью. Думаю, то что описано в этой статье доказывает вышесказанное.
        +1
        А почему нужно давать баллы за фикс багов?
        Получается справедливо: меньше багов — больше реальных фич — больше баллов
        +4
        Не очень понятно как автор перепрыгнул от минифицированного кода к UI компонентам closure library и решил, что именно они и есть проблема. По опыту дебага минифицированного closure compiler'ом кода даже при наличии исходников не сильно просто сопоставить минифицированный код оригинальному, потому что closure compiler практически все переименовывает, инлайнит функции, передвигает куски функций. А когда дело идет о таком большом приложении как гмейл, то вообще должно быть очень сложно определить что ж конкретно делает код.

        И кстати полифилы при максимальных настройках оптимизации занимают около 10-15кб не gzip'нутого кода. Это конечно не классно, но если говорить о 6мб ресурсов и предположить, что полифилы загружены только в одном js файле (ну или в паре-тройке), то вряд ли они являются большой проблемой.
          +11

          Выйти на Closure Library помогли строковые константы, которые сохраняются при минификации, например, вот такой фрагмент: lCa = "closure_uid_" + ((1e9 * Math.random()) >>> 0), который соответствует вот этой строчке. Ну а дальше уже обладая каким-то подобием исходников можно представить, как выглядел этот код до минификации.


          Про полифилы соглашусь, в таких объемах кода это экономия на спичках. Но сам факт того, что браузер тратит ресурсы на то чтобы загрузить код, по факту завернутый в if(false) {...} очень огорчает.

            0
            Да, строковые константы — это один из основных способов распутать код. Но uid — это очень общая утилитная функциональность. Она используется во многих не ui-ных классах closure library и вполне может использоваться в кастомных классах самого гмейла, особенно учитывая что скорее всего в гмейле свой фремворк и есть какие-то базовые классы, которые могут этот uid использовать. Наверное более точным будет наличие вот этих констант.
              +1

              Как ни странно, но вот эти константы оказались обфусцированы. Но есть вот такой код


              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".

          0
            +9
            Пересматривайте свои исходники и избавляйтесь от тех вещей, которые стали уже неактуальными.

            Это не сложно делать в действительно своих исходниках либо в исходниках, от и до покрытых тестами. Но в реальности, ковыряясь в чужом коде, написанном пару лет назад, и натыкаясь на костыль, — очень страшно его удалять, потому что не знаешь, всё ли после этого будет хорошо сейчас… через неделю… через месяц.
              +2
              Когда делается редизайн продукта, есть возможность переписать весь код с нуля. Так можно выкинуть все эти грабли, полудоделанные фичи, спрятанные под флагами, костыли под старые форматы API, которых давно уже нет в природе и т.д.
                +1
                есть возможность переписать весь код с нуля

                Возможность — безусловно есть. Денег и человеко-часов? Далеко не факт.

                Переписывание с нуля не добавляет ничего к стоимости продукта здесь и сейчас, и владельцы бизнеса на это смотрят очень косо (и с их точки зрения в общем-то правильно).
                  +5
                  Ну что же, теперь у нас есть живой пример Gmail. Можно показать его «бизнесу», пусть решают, сойдет им старый продукт с новыми костылями, или все-таки переписать по-нормальному
                    +3
                    Нет, ну как только гмаил помрёт и уступит место чему-нибудь еще, так они там все наверное сразу поймут, как они были неправы со своим 6.9Мб гмейлом.

                    Только есть у меня опасения, что этот сценарий не случится…
                      +5
                      Тормозит же адски, 5-10 секунд загрузки интерфейса для чтения текстовых писем в 2018 году на современнейшем железе это ад, трэш и издевательство над здравым смыслом.
                      gmail как почта и десктоп-интерфейс gmail все же разные вещи.
                      На десктопе, например, именно из-за тяжеловесности gmail перешли на «оффлайн» клиентов и работу по imap (стряхнули пыль с thebat), а так же иногда используем «легкую хтмл версию» ( mail.google.com/mail/u/0/h/1pq68r75kzvdr/?v%3Dlui ), задумываемся о подключении какого-нибудь альтернативного веб-сервиса работающего по imap с gmail.
                      Вряд ли гмылу от этого жарко или холодно, но тем не менее именно так «варят лягушку». Сначала имап, потом альтернативные веб-сервисы для доступа к имап, потом параллельно другие почтовые сервисы. Проблемы не возникают мгновенно, но зато имеют огромный запас инерции.
                        0
                        Да я это всё понимаю, что вы мне рассказываете. Но опять же вот, гмейл всегда можно открыть на любом соединении — именно потому что «легкая версия»-то на месте (и она реально очень легкая).
                          0
                          и она реально очень легкая

                          Она-то лёгкая, её я бы и открывал на обычном соединении. Только вот не нахожу варианта использовать её по-умолчанию. Это ад и угар, когда на i7-8700k+16gb ram+nvme почта открывается по 5-6 секунд.
                            0
                            При переходе из стандартного в базовый один раз спрашивают
                              0
                              Что характерно, но на Phenom 2 + 4gb ram + HDD она открывается примерно столько же (5-7 сек от самого начала — клика по ярлыку).
                              Тут дело уже не столько в доступных ресурсах — тут «всю систему надо менять!» (с)
                            • НЛО прилетело и опубликовало эту надпись здесь
                        +1
                        ну в этом случае, потратив в два раза больше человека часов гуглеров, можно было бы сократить огромное количество человеко часов обычных юзеров ожидающих пока загрузится почта. и бизнес от этого бы только выиграл
                      0
                      натыкаясь на костыль, — очень страшно его удалять
                      Очень помогает хорошее покрытие регрессионными тестами.
                        +1
                        Помогает только если весь проект под вашим контролем. А вот если вы меняете либу от которой зависит 10к проектов, то лучше либу вообще не трогать.
                          0
                          Если говорить о либе, то давайте для начала разделим изменение API и рефакторинг (т.е. изменение функциональности без изменения API). Для изменения API есть вполне работающие механизмы (сначала объявляем некоторые элементы API устаревшими, потом выжидаем некоторое время, потом выпиливаем). А что касается рефакторинга — см. выше про регрессионные тесты.
                      0
                      Ну как же гугл мог так сильно опозориться?
                        +8
                        Команде Гмыла не привыкать. Новый интерфейс гуглдоков в разы хуже старого даже спустя 2 года, восьмой андроид жрёт 12 гиг и замусорен хэнгаутсами по 300 метров каждый. Да и ютуб иногда падает на Сафари, лечится сменой агента.
                        В общем, гугл уже не первый год считает, что у всех пользователей мира гигабитная сеть и 10 ядерные ксеоны.
                          0
                          падает на Сафари, лечится сменой агента.

                          извините за оффтоп — а на какой агент лучше поменять?
                          а то достает иногда это безобразие.
                            0
                            Простите, уже не скажу — за последние полгода вроде не нарывался, редко ютуб открываю.
                            0

                            да нет же, они ранжируют выдачу поиска по скорости загрузки сайта.

                          +5
                          … двойку за производительность (из максимальных 100 баллов!

                          Зато дали замечательный пример, чтобы отбиваться от заказчиков, требующих вылизывать page speed до 100

                            0
                            До совсем недавнего времени там был жуткий красный рейтинг у Amazon.com, который на самом деле очень даже быстрый. Починили это где-то весной с.г., но до тех пор очень помогало с тем, о чем Вы пишете.
                              +1

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

                                0
                                у меня на проекте Lighthouse по производительности показывает сотню, и это с сотней запросов к бекенду. Каких-то специальных оптимизаций не делалось
                                +8
                                Ладно, Первоначальная загрузка это еще половина беды. У меня порой письма не открываются. Заходишь в какую-нибудь табу, кликаешь на письмо и… ничего. А на верху висит «Загрузка...»
                                  +1
                                  Как знакомо…
                                    +1
                                    Вот с письмами полная фигня. Пишет в списке папок: входящие — 1. Жму на входяшие «писем нет». Еще раз жму на входящие — ладно, вот тебе письмо.
                                    +4

                                    У какого-нибудь RoundCube загрузка и работа молниеносная. Не сказать что функционал как-то принципиально отличается от Gmail.

                                      +1
                                      Есть ещё afterlogic, он лучше =)
                                      Но функциональность отличается, такого количества шпионских блобов ни в RC, ни в AL не завезли.
                                      +1

                                      Раз есть ie10, значит нет вебкомпонентов.

                                        0
                                        Странное дело. Смотрел я тут на кануне запись с недавнего NgConf, где товарищ рассказывает, что 600+ приложений гугл используют Angular. Неужели GMail до сих пор не в этом списке?..
                                          0
                                          Гугл такой гугл. Компания большая, проектов много. Цифра в 600+ приложений может быть очень маленькой в процентном отношении.
                                          +6
                                          Да всё нормально. Youtube в браузере уже на слабых компах не посмотришь, скоро и Gmail нельзя будет открыть без 8-ми ядерного камня, 16ГБ ОЗУ, и графического ускорителя класса GTX 1080TI
                                            +1

                                            А YouTube вообще у меня последнее время весело багует- нажимаешь на одно видео справа, а подгружаться начинает какое-либо другое. Если нажимать Ctrl+r открывается то на которое первоначально кликал

                                              –1
                                              Это не совсем «youtube багует», это РКН багует, объявляя локальные гугловые CDN-сервера «шпионским оборудованием». Некоторые провайдеры отключили у себя гугловые кешеры, а по публичным каналам до ютуба частенько достучаться не выходит, канал забит.
                                                +1
                                                Нет, багует youtube. С Украины есть такие же проблемы.
                                                0
                                                Еще интересный баг наблюдаю-при быстром переходе между страницами начинает играть видео, которое было на предыдущей.
                                                Пример, зашел на страницу канала, на котором видео с автоплеем, переходишь на главную-видео с канала начинает играть фоном.
                                                0
                                                Я как-то проапгрейдился со среднего пятого айкора/6Гб на десятиядерный зеон/16Гб. И неожиданно обнаружил, что единственное, что значительно прибавило в производительности — это браузер (Хром, ессно). Причем реально стало круче!
                                                Разработка и остальное укомфортились совсем не так сильно, а вот на серфинге теперь нервов значительно меньше тратится.
                                                  0
                                                  Что i5, что xeon являются слабыми для десктопа в плане скорости ядер у которых частота недалеко ушла от 3.0ггц. Для комфортной и быстрой работы нужно 4-5.
                                                  Поэтому после 6-8 ядер остальные не добавляют смысла для обычных задач.
                                                    +3
                                                    Для комфортной и быстрой работы нужно 4-5

                                                    Вы из Google Inc?
                                                      +1
                                                      Нет. Их тяжелый gmail не относится к вопросу. Его не спасают даже 5ггц.
                                                  0
                                                  Вы очень близки к истине, примерно на такой конфигурации большинства поделок погромистов начинают быстро загружаться и что-то быстро делать. Даже сильно кривые сайты можно переварить, хотя есть нюанс, в хроме еще не пробовал, но вот в лисе 60 вкладок одноглазников или иных открытых страничек от погромистов меил.ру приводит к зависанию и краху браузера.
                                                  6/16/1050
                                                  +2
                                                  GMAIL раньше для меня ассоциировалося с прогрессом. Потом когда начал замечать тормоза, понял, что надо искать альтернативу, т.к. именно из-за слабых систем было все труднее использовать его. После того как полностью перешел и настроил свои сервера, мои проблемы были решены. Но не все же пользователи могут позволить себе такое. Проблема гигантов в том, что они думают, что их пользователи должны принимать на веру все, что они делают, и мнение пользователей можно не учитывать.
                                                    +1
                                                    Гиганты просто максимизируют свою прибыль. Они не думают о пользователях ничего.
                                                      0
                                                      Я вот думаю как свалить...(да хоть на synology mail station) но одна из проблем в том что G Suite. И на эти аккаунты куча всего куплено.
                                                      Вот можно ли грохнуть G Suite для mydomain.com и при этом НЕ грохнуть сами гуглоаккаунты вида user@mydomain.com?
                                                        0
                                                        Насколько я понимаю — учетки гугла живут независимо — у меня есть на одну почту G suite учетка и обычная (в которую я не могу попасть, но гугл регулярно присылает письма что злые хакеры туда заходят)
                                                          0
                                                          я просто настраивал в свое время переадресацию на новую почту. со временем все мои клиенты и друзья перешли на новую, а старые емайлы живут до сих пор.
                                                            0
                                                            Как раз получение почты проблемой не будет (свой ж домен). Просто на аккаунты user@mydomain.com куплены приложения/фильмы/музыка в Google Play, причем несколькими юзерами. И что с этим будет при закрытии G Suite?
                                                        +4
                                                        Красиво ткнули нагадившую собачку Google носом в ее дерьмо.

                                                        Gmail.com открываю раз в квартал. Для всего остального есть десктопный/мобильный клиент.
                                                          0
                                                          Не открываю гмайл совсем. Чяднт?
                                                          +5
                                                          Как-то всё это не укладывается в моей голове вместе с непроходимыми гугловскими собеседованиями, о которых здесь постоянно пишут
                                                            0
                                                            Побуду кэпом. Из знания передовых технологий ведь можно строить как изящные и простые решения, а можно хтонические нагромождения smartass-кода. Причем первое делать сильно сложнее.
                                                            Так что сложные собесы просто обеспечивают пул разработчиков только лучшими стрелками, да вот менеджмент — менеджмент как обычно…
                                                            0
                                                            Неплохо ускоряет работу отключение «Действия, доступные при наведении указателя на письмо» и «Значки персональных писем»
                                                              +1
                                                              Как человек 5 лет проработавший с closure library/compiler, не могу сказать, что там всё хорошо. Но и винить его в том, что из-за чьих то кривых рук гмэйл не грузится тоже излишне. С инструментами надо уметь работать.

                                                              И обратная совместимость не вина библиотеки, которую использует не только гугл. Если ActiveX не нужен — пожалуйста: --define goog.net.XmlHttpDefines.ASSUME_NATIVE_XHR=true, и компилятор автоматом уберёт лишее.
                                                                0

                                                                Про флаги компиляции интересно. Нашел, что в коде Gmail еще подключается и код для эмуляции addEventListener через attachEvent, для IE8, который тоже можно выключить флагом.


                                                                Возникает вопрос: а зачем в 2018 году включать все это по дефолту? Разумнее было бы наоборот, с возможностью включить тем, кому всё еще это нужно. А идеальнее всего вообще использовать конфигурацию вроде browserlist, где пользователи бы просто указывали нужные им браузеры, а полифилы сами конфигурировались исходя из этой настройки, без жонглирования разными флагами.

                                                                  0
                                                                  Помимо прочих проблем в closure library отсутствует semver, и подозреваю, никто не знает, когда уже можно сломать обратную совместимость.
                                                                  А так никто не мешает собрать несколько версий с разными флагами и отдавать нужную.
                                                                +2
                                                                Пользуюсь гуглопочтой исключительно по IMAP/SNMP с локально установленным клиентом.
                                                                И, судя по этому факапу с тормозящим веб интерфейсом (кстати, на гугловой же page speed tool — сколько попугаев показывает?), разработчики gmail тоже им не пользуются.
                                                                  +1
                                                                  Ага, а если еще учесть что и по IMAP иногда бывают глюки (в последнее время редко) или неочевидные костыли вещи, вроде Gmail IMAP – Solving the [Gmail] separation

                                                                  То каждый раз задумываешься: чем эти люди там занимаются? Пользуются ли они своим продуктом?
                                                                    0

                                                                    Попугаев ровно 100 из 100 в десктопной версии и всего 53 в мобильной. Хотя по моим ощущениям все с точностью до наоборот, и мобильная версия вполне быстро грузится и работает

                                                                      0
                                                                      вот да. Я понимаю, сценарии разные бывают. Но на своем ПК вижу смысл только в использовании почтовых клиентов. Больше настроек, меньше тормозов, возможность читать почту в оффлайн.
                                                                      0
                                                                      К сожалению, не в наших силах заставить Google ускорить работу их сервиса

                                                                      Не в наших силах заставить подписывать почтовые сообщения ГОСТ-овыми сертификатамию

                                                                        +2
                                                                        Я решил вопрос так:
                                                                        Мало кто помнит, что есть web-версии gmail для смартфонов и планшетов.
                                                                        Меняем UserAgent на современный планшет, Ctrl+F5.
                                                                        Вообще не тормозит.

                                                                        Вот так вот выглядит:
                                                                          0
                                                                          del
                                                                            0
                                                                            При загрузке Gmail'а внизу всегда была ссылка для старых/медленных компьютеров, которая загружает html-версию почтового ящика.

                                                                            Поэтому не нужно ничего менять, при входе нужно нажать внизу ссылку и Вы попадёте в почтовый ящик почти моментально.
                                                                              0
                                                                              Моментально-не знаю, у меня страница сначала полностью загружается, потом переходит на базовую версию.
                                                                              И минус, что эта ссылка присутствует только при загрузке страницы.
                                                                                0
                                                                                Моментально после нажатия на ссылку.
                                                                                Да, в начале всё равно ждешь, пока начинается загрузка, прежде чем переключишься.
                                                                                Это я к тому, что для совсем медленных машин, гугл предусмотрели облегчённую версию, но это никоим образом не оправдывает 7-ми секундную загрузку обычного режима.
                                                                                0
                                                                                Это будет basic html версия, которая страшненькая и куцая. В ней, например в ней нет автоматического раскладывания на Рекламу, Соц-сети и собственно почту.

                                                                                Я имею ввиду вполне современную SPA версию gmail, только сделанную для планшетов/смартфонов и гораздо более легкую чем десктопный gmail. Немного отличается лейаутом.

                                                                                  0
                                                                                  Так Вам полный функционал нужен был, я подумал о том, чтобы быстрее зайти в почту.
                                                                                  На компьютере я использую почтовый клиент, редко захожу через браузерную версию.
                                                                              +1
                                                                              Хорошо объяснять тормоза легаси-кодом и поддержкой IE6, но почему тогда этот же Gmail в эпоху IE6 совсем не тормозил?
                                                                                +2
                                                                                потому что тогда в нем не было поддержки ИЕ11
                                                                                  +2

                                                                                  Потому что в эпоху IE6 продукт был моложе и там было меньше кода.


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

                                                                                    0
                                                                                    Вспомнилось откуда-то:
                                                                                    — я только постоянно сверху докидываю
                                                                                    — ты бы хоть, посмотрел, что там внизу делается
                                                                                    — а чего туда смотреть — там компост
                                                                                  +2
                                                                                  Из моего опыта: если в текущем Gmail-е выключить чат (Настройки — чат — отключить чат), то прекращается дикий memory leak таба гмыла (Chromium 70).
                                                                                    +3
                                                                                    Пару лет назад кто-то в комментариях к какой-то статье злорадно ехидничал о том, что скоро сайты будут грузиться дольше чем ОС… в принципе ожидаемо, но не думал что это случится так скоро.
                                                                                      0

                                                                                      Возможно ноут с 16 гигами — это очень круто, но каждая очередная загрузка гмейла — менее секунды. Успеваю увидеть, что конвертик хлопнул дверью и сразу письма.

                                                                                        +3
                                                                                        Я не пользователь gmail, но мне все равно интересно — а зачем они сделали это обновление? В чем реальное преимущество для пользователя, и в чем могут быть плюсы для самого google? (Может это часть далеко идущих планов?) Но вообще, как пользователю только мобильного интернета (а ранее и с помегабайтной оплатой), мне грустно от этого тренда :(
                                                                                          0
                                                                                          Ну, software bloat обычное дело, не вчера появился. Я думаю это особенности менеджмента большой корпорации. Кто-то должен выдавать результат, и результат должен быть не «ну всё, старый gmail оптимизирован, давайте теперь уволим половину разработчиков и сэкономим миллион в год» а «мы запустили новый gmail, потратили 50 миллионов, смотрите сколько в нём фич!».
                                                                                          0
                                                                                          использую thunderbird и не знаю таких проблем
                                                                                            0
                                                                                            Яндекс последние 2 дня не переваривает user.js и предлагает лёгкую версию. Ушёл на protonmail.
                                                                                            +2
                                                                                            Когда читаешь в новостях "… за этим стоят такие гиганты, как Гугл....", хочется прыснуть — да уж, «маленькие гиганты большого кода»! Позорнее разработок ещё не видел (после Windows Millenium).
                                                                                              0
                                                                                              У знакомых на новом слабеньком ноутбуке слабеньком с двухядерным N30601.6Ghz Gmail грузился почти 40 секунд, окно создания нового письма открывалось… 30 секунд! Было такое ощущение, что gmail попутно майнит биткойн.
                                                                                              На 6 ядерном Xeon прокрутка списка сообщений не плавная, и это ухудшилось именно в последний год. 10 лет назад даже на одноядерном CPU всё было как-то быстрее и плавнее в Gmail.
                                                                                                0
                                                                                                Уже давно пользуюсь google inbox. Он понравился больше, интерфейс проще и чище, плюс очень понравился функционал откладывания писем и создания напоминаний (с интеграцией с календарем). А сегодня появилось сообщение «Поддержка Inbox от Gmail заканчивается в конце марта 2019 г. В новой версии Gmail обновлен дизайн и сохранены лучшие функции Inbox, такие как откладывание писем, напоминания и другие.». Решил глянуть на новый интерфейс gmail — выглядит ужасно. Из плюсов вижу только интеграцию календаря и keep. Если в inbox у меня на виду с десяток писем/напоминаний, то в gmail куча старых писем. Нету функционала напоминаний, а он был очень удобен для создания простых напоминалок, не надо было лезть календарь.
                                                                                                  +1

                                                                                                  Перестал любить аебиорды к сервисам различным. Гмыло стало раздражать.
                                                                                                  Я думал что разработка веб технологий идёт по пути оптимизации и расширения возможностей. Но в последние время понял, что нет. Идут по пути "ооо давайте сделаем круутотень!!! Что тормозит? Отвали фишка крутая!!!11".
                                                                                                  Если и дальше так пойдет, то будет печально.


                                                                                                  Недавно перешёл на оутлук. Счастлив и доволен. Загружается быстро. Есть на мобиле. Почта работает прозрачней.
                                                                                                  И что самое главное, функционал почты для работы с почтой. Удивительно. Гмыло неудобно для пользования почтой. Не удобны контакты. Неудобный поиск. На гмыле большинство функций что выведены в интерфейсе, ненужные.
                                                                                                  З.ы. мне понравились ярлыки. Идея крутая, но все зависит кем я наблюдал, используют как папки их. То есть, один ярлык на одно письмо. Весь смысл ярлыков теряется. И так по всему функционалу. Вроде крутые вещи делают, но кому они нужны? Только разработчикам.

                                                                                                    0
                                                                                                    О да! Там тормозов ещё больше. Я пол года не мог фильтры настроить, потому что окно с ними тупо зависало. Потом в Файерфоксе стало через раз работать. Может одному ещё можно пользоваться, но в качестве корпоративной почты это полный трэш. Гугл хоть и косячит, но до Майкрософта ему ещё далеко

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

                                                                                                  Самое читаемое