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



Полгода назад 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.

Вы можете помочь и перевести немного средств на развитие сайта



Комментарии (89):

  1. ThisMan
    /#19352904

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

  2. Nikelandjelo
    /#19353094 / +3

    Не очень понятно как автор перепрыгнул от минифицированного кода к UI компонентам closure library и решил, что именно они и есть проблема. По опыту дебага минифицированного closure compiler'ом кода даже при наличии исходников не сильно просто сопоставить минифицированный код оригинальному, потому что closure compiler практически все переименовывает, инлайнит функции, передвигает куски функций. А когда дело идет о таком большом приложении как гмейл, то вообще должно быть очень сложно определить что ж конкретно делает код.

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

    • justboris
      /#19353158 / +1

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


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

      • Nikelandjelo
        /#19357310

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

        • justboris
          /#19358472

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


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

  3. mbait
    /#19353116

    ?

  4. KevlarBeaver
    /#19353132 / +1

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

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

    • justboris
      /#19353170

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

      • JustDont
        /#19353200

        есть возможность переписать весь код с нуля

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

        Переписывание с нуля не добавляет ничего к стоимости продукта здесь и сейчас, и владельцы бизнеса на это смотрят очень косо (и с их точки зрения в общем-то правильно).

        • justboris
          /#19353218

          Ну что же, теперь у нас есть живой пример Gmail. Можно показать его «бизнесу», пусть решают, сойдет им старый продукт с новыми костылями, или все-таки переписать по-нормальному

          • JustDont
            /#19353230 / +1

            Нет, ну как только гмаил помрёт и уступит место чему-нибудь еще, так они там все наверное сразу поймут, как они были неправы со своим 6.9Мб гмейлом.

            Только есть у меня опасения, что этот сценарий не случится…

            • edogs
              /#19353262 / +1

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

              • JustDont
                /#19353270

                Да я это всё понимаю, что вы мне рассказываете. Но опять же вот, гмейл всегда можно открыть на любом соединении — именно потому что «легкая версия»-то на месте (и она реально очень легкая).

                • Nova_Logic
                  /#19354162

                  и она реально очень легкая

                  Она-то лёгкая, её я бы и открывал на обычном соединении. Только вот не нахожу варианта использовать её по-умолчанию. Это ад и угар, когда на i7-8700k+16gb ram+nvme почта открывается по 5-6 секунд.

                  • Taraflex
                    /#19354432

                    При переходе из стандартного в базовый один раз спрашивают

                  • Mad__Max
                    /#19358860

                    Что характерно, но на Phenom 2 + 4gb ram + HDD она открывается примерно столько же (5-7 сек от самого начала — клика по ярлыку).
                    Тут дело уже не столько в доступных ресурсах — тут «всю систему надо менять!» (с)

                • nafgne
                  /#19356332

                  Она тоже тормозит. 3-5 секунд до открытия страницы проходит, несмотря на общую убогость.

        • worldxaker
          /#19354040

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

    • eugenius_nsk
      /#19353612

      натыкаясь на костыль, — очень страшно его удалять
      Очень помогает хорошее покрытие регрессионными тестами.

      • ankh1989
        /#19353730

        Помогает только если весь проект под вашим контролем. А вот если вы меняете либу от которой зависит 10к проектов, то лучше либу вообще не трогать.

  5. AirLight
    /#19353362

    Ну как же гугл мог так сильно опозориться?

    • batyrmastyr
      /#19353668

      Команде Гмыла не привыкать. Новый интерфейс гуглдоков в разы хуже старого даже спустя 2 года, восьмой андроид жрёт 12 гиг и замусорен хэнгаутсами по 300 метров каждый. Да и ютуб иногда падает на Сафари, лечится сменой агента.
      В общем, гугл уже не первый год считает, что у всех пользователей мира гигабитная сеть и 10 ядерные ксеоны.

      • SurfCalavera
        /#19354922

        падает на Сафари, лечится сменой агента.

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

        • batyrmastyr
          /#19356206

          Простите, уже не скажу — за последние полгода вроде не нарывался, редко ютуб открываю.

      • Alexmaru
        /#19356214

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

  6. SDKiller
    /#19353426

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

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

    • hillbilly
      /#19353864

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

    • justboris
      /#19354478 / +1

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

    • Moxa
      /#19355562

      у меня на проекте Lighthouse по производительности показывает сотню, и это с сотней запросов к бекенду. Каких-то специальных оптимизаций не делалось

  7. susnake
    /#19353524

    Ладно, Первоначальная загрузка это еще половина беды. У меня порой письма не открываются. Заходишь в какую-нибудь табу, кликаешь на письмо и… ничего. А на верху висит «Загрузка...»

  8. konchok
    /#19353580

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

    • inkvizitor68sl
      /#19355402

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

  9. Elmot
    /#19353728

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

  10. ru5l4n
    /#19354104

    Странное дело. Смотрел я тут на кануне запись с недавнего NgConf, где товарищ рассказывает, что 600+ приложений гугл используют Angular. Неужели GMail до сих пор не в этом списке?..

    • justboris
      /#19354298

      Гугл такой гугл. Компания большая, проектов много. Цифра в 600+ приложений может быть очень маленькой в процентном отношении.

  11. Vikonrob
    /#19354106 / +2

    Да всё нормально. Youtube в браузере уже на слабых компах не посмотришь, скоро и Gmail нельзя будет открыть без 8-ми ядерного камня, 16ГБ ОЗУ, и графического ускорителя класса GTX 1080TI

    • Nova_Logic
      /#19354712

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

      • inkvizitor68sl
        /#19355414

        Это не совсем «youtube багует», это РКН багует, объявляя локальные гугловые CDN-сервера «шпионским оборудованием». Некоторые провайдеры отключили у себя гугловые кешеры, а по публичным каналам до ютуба частенько достучаться не выходит, канал забит.

        • riot26
          /#19356662

          Нет, багует youtube. С Украины есть такие же проблемы.

    • altrus
      /#19354758

      Я как-то проапгрейдился со среднего пятого айкора/6Гб на десятиядерный зеон/16Гб. И неожиданно обнаружил, что единственное, что значительно прибавило в производительности — это браузер (Хром, ессно). Причем реально стало круче!
      Разработка и остальное укомфортились совсем не так сильно, а вот на серфинге теперь нервов значительно меньше тратится.

      • springimport
        /#19356256

        Что i5, что xeon являются слабыми для десктопа в плане скорости ядер у которых частота недалеко ушла от 3.0ггц. Для комфортной и быстрой работы нужно 4-5.
        Поэтому после 6-8 ядер остальные не добавляют смысла для обычных задач.

        • altrus
          /#19356288 / +1

          Для комфортной и быстрой работы нужно 4-5

          Вы из Google Inc?

          • springimport
            /#19356334

            Нет. Их тяжелый gmail не относится к вопросу. Его не спасают даже 5ггц.

    • OnelaW
      /#19356086

      Вы очень близки к истине, примерно на такой конфигурации большинства поделок погромистов начинают быстро загружаться и что-то быстро делать. Даже сильно кривые сайты можно переварить, хотя есть нюанс, в хроме еще не пробовал, но вот в лисе 60 вкладок одноглазников или иных открытых страничек от погромистов меил.ру приводит к зависанию и краху браузера.
      6/16/1050

  12. AGARTY
    /#19354658 / +1

    GMAIL раньше для меня ассоциировалося с прогрессом. Потом когда начал замечать тормоза, понял, что надо искать альтернативу, т.к. именно из-за слабых систем было все труднее использовать его. После того как полностью перешел и настроил свои сервера, мои проблемы были решены. Но не все же пользователи могут позволить себе такое. Проблема гигантов в том, что они думают, что их пользователи должны принимать на веру все, что они делают, и мнение пользователей можно не учитывать.

    • altrus
      /#19354738

      Гиганты просто максимизируют свою прибыль. Они не думают о пользователях ничего.

    • vikarti
      /#19359298

      Я вот думаю как свалить...(да хоть на synology mail station) но одна из проблем в том что G Suite. И на эти аккаунты куча всего куплено.
      Вот можно ли грохнуть G Suite для mydomain.com и при этом НЕ грохнуть сами гуглоаккаунты вида user@mydomain.com?

      • Daemon_Hell
        /#19360066

        Насколько я понимаю — учетки гугла живут независимо — у меня есть на одну почту G suite учетка и обычная (в которую я не могу попасть, но гугл регулярно присылает письма что злые хакеры туда заходят)

      • AGARTY
        /#19360906

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

  13. altrus
    /#19354720 / +1

    Красиво ткнули нагадившую собачку Google носом в ее дерьмо.

    Gmail.com открываю раз в квартал. Для всего остального есть десктопный/мобильный клиент.

    • zanac
      /#19359478

      Не открываю гмайл совсем. Чяднт?

  14. tamtakoe
    /#19354780 / +4

    Как-то всё это не укладывается в моей голове вместе с непроходимыми гугловскими собеседованиями, о которых здесь постоянно пишут

    • UberSchlag
      /#19355118

      Побуду кэпом. Из знания передовых технологий ведь можно строить как изящные и простые решения, а можно хтонические нагромождения smartass-кода. Причем первое делать сильно сложнее.
      Так что сложные собесы просто обеспечивают пул разработчиков только лучшими стрелками, да вот менеджмент — менеджмент как обычно…

  15. stayacid
    /#19354936

    Неплохо ускоряет работу отключение «Действия, доступные при наведении указателя на письмо» и «Значки персональных писем»

  16. red_led
    /#19354940 / +1

    Как человек 5 лет проработавший с closure library/compiler, не могу сказать, что там всё хорошо. Но и винить его в том, что из-за чьих то кривых рук гмэйл не грузится тоже излишне. С инструментами надо уметь работать.

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

    • justboris
      /#19358446

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


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

  17. dMac
    /#19355078 / +1

    Пользуюсь гуглопочтой исключительно по IMAP/SNMP с локально установленным клиентом.
    И, судя по этому факапу с тормозящим веб интерфейсом (кстати, на гугловой же page speed tool — сколько попугаев показывает?), разработчики gmail тоже им не пользуются.

    • Dee3
      /#19355354

      Ага, а если еще учесть что и по IMAP иногда бывают глюки (в последнее время редко) или неочевидные костыли вещи, вроде Gmail IMAP – Solving the [Gmail] separation

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

    • Irgen
      /#19355570

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

    • Iamkaant
      /#19356536

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

  18. saipr
    /#19356684

    К сожалению, не в наших силах заставить Google ускорить работу их сервиса

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

  19. ivangermes
    /#19356842

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

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

  20. fogx
    /#19357100 / +1

    Хорошо объяснять тормоза легаси-кодом и поддержкой IE6, но почему тогда этот же Gmail в эпоху IE6 совсем не тормозил?

    • altrus
      /#19357484

      потому что тогда в нем не было поддержки ИЕ11

    • justboris
      /#19357540 / +2

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


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

      • Mad__Max
        /#19358864

        Вспомнилось откуда-то:
        — я только постоянно сверху докидываю
        — ты бы хоть, посмотрел, что там внизу делается
        — а чего туда смотреть — там компост

  21. stat1c_void
    /#19357718

    Из моего опыта: если в текущем Gmail-е выключить чат (Настройки — чат — отключить чат), то прекращается дикий memory leak таба гмыла (Chromium 70).

  22. whyme
    /#19357720 / +2

    Пару лет назад кто-то в комментариях к какой-то статье злорадно ехидничал о том, что скоро сайты будут грузиться дольше чем ОС… в принципе ожидаемо, но не думал что это случится так скоро.

  23. pavelkolodin
    /#19357828

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

  24. ledinhome
    /#19358150 / +2

    Я не пользователь gmail, но мне все равно интересно — а зачем они сделали это обновление? В чем реальное преимущество для пользователя, и в чем могут быть плюсы для самого google? (Может это часть далеко идущих планов?) Но вообще, как пользователю только мобильного интернета (а ранее и с помегабайтной оплатой), мне грустно от этого тренда :(

    • varnav
      /#19358394

      Ну, software bloat обычное дело, не вчера появился. Я думаю это особенности менеджмента большой корпорации. Кто-то должен выдавать результат, и результат должен быть не «ну всё, старый gmail оптимизирован, давайте теперь уволим половину разработчиков и сэкономим миллион в год» а «мы запустили новый gmail, потратили 50 миллионов, смотрите сколько в нём фич!».

  25. duff
    /#19358184

    использую thunderbird и не знаю таких проблем

  26. geekmetwice
    /#19358798

    Когда читаешь в новостях "… за этим стоят такие гиганты, как Гугл....", хочется прыснуть — да уж, «маленькие гиганты большого кода»! Позорнее разработок ещё не видел (после Windows Millenium).