Комментарии 93
Как то на хабре уже была статья, о том как же обстоят рабочие дела в гугле. Автор сетовал на том, что фикс багов и рефакторинг никому не нужен, и тебе как разработчику это не принесёт баллов на ревью. Думаю, то что описано в этой статье доказывает вышесказанное.
Не очень понятно как автор перепрыгнул от минифицированного кода к UI компонентам closure library и решил, что именно они и есть проблема. По опыту дебага минифицированного closure compiler'ом кода даже при наличии исходников не сильно просто сопоставить минифицированный код оригинальному, потому что closure compiler практически все переименовывает, инлайнит функции, передвигает куски функций. А когда дело идет о таком большом приложении как гмейл, то вообще должно быть очень сложно определить что ж конкретно делает код.
И кстати полифилы при максимальных настройках оптимизации занимают около 10-15кб не gzip'нутого кода. Это конечно не классно, но если говорить о 6мб ресурсов и предположить, что полифилы загружены только в одном js файле (ну или в паре-тройке), то вряд ли они являются большой проблемой.
И кстати полифилы при максимальных настройках оптимизации занимают около 10-15кб не gzip'нутого кода. Это конечно не классно, но если говорить о 6мб ресурсов и предположить, что полифилы загружены только в одном js файле (ну или в паре-тройке), то вряд ли они являются большой проблемой.
Выйти на Closure Library помогли строковые константы, которые сохраняются при минификации, например, вот такой фрагмент: lCa = "closure_uid_" + ((1e9 * Math.random()) >>> 0), который соответствует вот этой строчке. Ну а дальше уже обладая каким-то подобием исходников можно представить, как выглядел этот код до минификации.
Про полифилы соглашусь, в таких объемах кода это экономия на спичках. Но сам факт того, что браузер тратит ресурсы на то чтобы загрузить код, по факту завернутый в if(false) {...} очень огорчает.
Да, строковые константы — это один из основных способов распутать код. Но uid — это очень общая утилитная функциональность. Она используется во многих не ui-ных классах closure library и вполне может использоваться в кастомных классах самого гмейла, особенно учитывая что скорее всего в гмейле свой фремворк и есть какие-то базовые классы, которые могут этот uid использовать. Наверное более точным будет наличие вот этих констант.
Как ни странно, но вот эти константы оказались обфусцированы. Но есть вот такой код
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".
Пересматривайте свои исходники и избавляйтесь от тех вещей, которые стали уже неактуальными.
Это не сложно делать в действительно своих исходниках либо в исходниках, от и до покрытых тестами. Но в реальности, ковыряясь в чужом коде, написанном пару лет назад, и натыкаясь на костыль, — очень страшно его удалять, потому что не знаешь, всё ли после этого будет хорошо сейчас… через неделю… через месяц.
Когда делается редизайн продукта, есть возможность переписать весь код с нуля. Так можно выкинуть все эти грабли, полудоделанные фичи, спрятанные под флагами, костыли под старые форматы API, которых давно уже нет в природе и т.д.
есть возможность переписать весь код с нуля
Возможность — безусловно есть. Денег и человеко-часов? Далеко не факт.
Переписывание с нуля не добавляет ничего к стоимости продукта здесь и сейчас, и владельцы бизнеса на это смотрят очень косо (и с их точки зрения в общем-то правильно).
Ну что же, теперь у нас есть живой пример Gmail. Можно показать его «бизнесу», пусть решают, сойдет им старый продукт с новыми костылями, или все-таки переписать по-нормальному
Нет, ну как только гмаил помрёт и уступит место чему-нибудь еще, так они там все наверное сразу поймут, как они были неправы со своим 6.9Мб гмейлом.
Только есть у меня опасения, что этот сценарий не случится…
Только есть у меня опасения, что этот сценарий не случится…
Тормозит же адски, 5-10 секунд загрузки интерфейса для чтения текстовых писем в 2018 году на современнейшем железе это ад, трэш и издевательство над здравым смыслом.
gmail как почта и десктоп-интерфейс gmail все же разные вещи.
На десктопе, например, именно из-за тяжеловесности gmail перешли на «оффлайн» клиентов и работу по imap (стряхнули пыль с thebat), а так же иногда используем «легкую хтмл версию» ( mail.google.com/mail/u/0/h/1pq68r75kzvdr/?v%3Dlui ), задумываемся о подключении какого-нибудь альтернативного веб-сервиса работающего по imap с gmail.
Вряд ли гмылу от этого жарко или холодно, но тем не менее именно так «варят лягушку». Сначала имап, потом альтернативные веб-сервисы для доступа к имап, потом параллельно другие почтовые сервисы. Проблемы не возникают мгновенно, но зато имеют огромный запас инерции.
gmail как почта и десктоп-интерфейс gmail все же разные вещи.
На десктопе, например, именно из-за тяжеловесности gmail перешли на «оффлайн» клиентов и работу по imap (стряхнули пыль с thebat), а так же иногда используем «легкую хтмл версию» ( mail.google.com/mail/u/0/h/1pq68r75kzvdr/?v%3Dlui ), задумываемся о подключении какого-нибудь альтернативного веб-сервиса работающего по imap с gmail.
Вряд ли гмылу от этого жарко или холодно, но тем не менее именно так «варят лягушку». Сначала имап, потом альтернативные веб-сервисы для доступа к имап, потом параллельно другие почтовые сервисы. Проблемы не возникают мгновенно, но зато имеют огромный запас инерции.
Да я это всё понимаю, что вы мне рассказываете. Но опять же вот, гмейл всегда можно открыть на любом соединении — именно потому что «легкая версия»-то на месте (и она реально очень легкая).
ну в этом случае, потратив в два раза больше человека часов гуглеров, можно было бы сократить огромное количество человеко часов обычных юзеров ожидающих пока загрузится почта. и бизнес от этого бы только выиграл
натыкаясь на костыль, — очень страшно его удалятьОчень помогает хорошее покрытие регрессионными тестами.
Помогает только если весь проект под вашим контролем. А вот если вы меняете либу от которой зависит 10к проектов, то лучше либу вообще не трогать.
Если говорить о либе, то давайте для начала разделим изменение API и рефакторинг (т.е. изменение функциональности без изменения API). Для изменения API есть вполне работающие механизмы (сначала объявляем некоторые элементы API устаревшими, потом выжидаем некоторое время, потом выпиливаем). А что касается рефакторинга — см. выше про регрессионные тесты.
Ну как же гугл мог так сильно опозориться?
Команде Гмыла не привыкать. Новый интерфейс гуглдоков в разы хуже старого даже спустя 2 года, восьмой андроид жрёт 12 гиг и замусорен хэнгаутсами по 300 метров каждый. Да и ютуб иногда падает на Сафари, лечится сменой агента.
В общем, гугл уже не первый год считает, что у всех пользователей мира гигабитная сеть и 10 ядерные ксеоны.
В общем, гугл уже не первый год считает, что у всех пользователей мира гигабитная сеть и 10 ядерные ксеоны.
… двойку за производительность (из максимальных 100 баллов!
Зато дали замечательный пример, чтобы отбиваться от заказчиков, требующих вылизывать page speed до 100
До совсем недавнего времени там был жуткий красный рейтинг у Amazon.com, который на самом деле очень даже быстрый. Починили это где-то весной с.г., но до тех пор очень помогало с тем, о чем Вы пишете.
Да, полировать до достижения 100 баллов может и не стоит, но если у вас околонулевой результат – это сигнал каких-то проблем.
у меня на проекте Lighthouse по производительности показывает сотню, и это с сотней запросов к бекенду. Каких-то специальных оптимизаций не делалось
Ладно, Первоначальная загрузка это еще половина беды. У меня порой письма не открываются. Заходишь в какую-нибудь табу, кликаешь на письмо и… ничего. А на верху висит «Загрузка...»
НЛО прилетело и опубликовало эту надпись здесь
Раз есть ie10, значит нет вебкомпонентов.
Странное дело. Смотрел я тут на кануне запись с недавнего NgConf, где товарищ рассказывает, что 600+ приложений гугл используют Angular. Неужели GMail до сих пор не в этом списке?..
Да всё нормально. Youtube в браузере уже на слабых компах не посмотришь, скоро и Gmail нельзя будет открыть без 8-ми ядерного камня, 16ГБ ОЗУ, и графического ускорителя класса GTX 1080TI
А YouTube вообще у меня последнее время весело багует- нажимаешь на одно видео справа, а подгружаться начинает какое-либо другое. Если нажимать Ctrl+r открывается то на которое первоначально кликал
Это не совсем «youtube багует», это РКН багует, объявляя локальные гугловые CDN-сервера «шпионским оборудованием». Некоторые провайдеры отключили у себя гугловые кешеры, а по публичным каналам до ютуба частенько достучаться не выходит, канал забит.
Еще интересный баг наблюдаю-при быстром переходе между страницами начинает играть видео, которое было на предыдущей.
Пример, зашел на страницу канала, на котором видео с автоплеем, переходишь на главную-видео с канала начинает играть фоном.
Пример, зашел на страницу канала, на котором видео с автоплеем, переходишь на главную-видео с канала начинает играть фоном.
Я как-то проапгрейдился со среднего пятого айкора/6Гб на десятиядерный зеон/16Гб. И неожиданно обнаружил, что единственное, что значительно прибавило в производительности — это браузер (Хром, ессно). Причем реально стало круче!
Разработка и остальное укомфортились совсем не так сильно, а вот на серфинге теперь нервов значительно меньше тратится.
Разработка и остальное укомфортились совсем не так сильно, а вот на серфинге теперь нервов значительно меньше тратится.
Вы очень близки к истине, примерно на такой конфигурации большинства поделок погромистов начинают быстро загружаться и что-то быстро делать. Даже сильно кривые сайты можно переварить, хотя есть нюанс, в хроме еще не пробовал, но вот в лисе 60 вкладок одноглазников или иных открытых страничек от погромистов меил.ру приводит к зависанию и краху браузера.
6/16/1050
6/16/1050
GMAIL раньше для меня ассоциировалося с прогрессом. Потом когда начал замечать тормоза, понял, что надо искать альтернативу, т.к. именно из-за слабых систем было все труднее использовать его. После того как полностью перешел и настроил свои сервера, мои проблемы были решены. Но не все же пользователи могут позволить себе такое. Проблема гигантов в том, что они думают, что их пользователи должны принимать на веру все, что они делают, и мнение пользователей можно не учитывать.
Гиганты просто максимизируют свою прибыль. Они не думают о пользователях ничего.
Я вот думаю как свалить...(да хоть на synology mail station) но одна из проблем в том что G Suite. И на эти аккаунты куча всего куплено.
Вот можно ли грохнуть G Suite для mydomain.com и при этом НЕ грохнуть сами гуглоаккаунты вида user@mydomain.com?
Вот можно ли грохнуть G Suite для mydomain.com и при этом НЕ грохнуть сами гуглоаккаунты вида user@mydomain.com?
Насколько я понимаю — учетки гугла живут независимо — у меня есть на одну почту G suite учетка и обычная (в которую я не могу попасть, но гугл регулярно присылает письма что злые хакеры туда заходят)
я просто настраивал в свое время переадресацию на новую почту. со временем все мои клиенты и друзья перешли на новую, а старые емайлы живут до сих пор.
Красиво ткнули нагадившую собачку Google носом в ее дерьмо.
Gmail.com открываю раз в квартал. Для всего остального есть десктопный/мобильный клиент.
Gmail.com открываю раз в квартал. Для всего остального есть десктопный/мобильный клиент.
Как-то всё это не укладывается в моей голове вместе с непроходимыми гугловскими собеседованиями, о которых здесь постоянно пишут
Побуду кэпом. Из знания передовых технологий ведь можно строить как изящные и простые решения, а можно хтонические нагромождения smartass-кода. Причем первое делать сильно сложнее.
Так что сложные собесы просто обеспечивают пул разработчиков только лучшими стрелками, да вот менеджмент — менеджмент как обычно…
Так что сложные собесы просто обеспечивают пул разработчиков только лучшими стрелками, да вот менеджмент — менеджмент как обычно…
Неплохо ускоряет работу отключение «Действия, доступные при наведении указателя на письмо» и «Значки персональных писем»
Как человек 5 лет проработавший с closure library/compiler, не могу сказать, что там всё хорошо. Но и винить его в том, что из-за чьих то кривых рук гмэйл не грузится тоже излишне. С инструментами надо уметь работать.
И обратная совместимость не вина библиотеки, которую использует не только гугл. Если ActiveX не нужен — пожалуйста:
И обратная совместимость не вина библиотеки, которую использует не только гугл. Если ActiveX не нужен — пожалуйста:
--define goog.net.XmlHttpDefines.ASSUME_NATIVE_XHR=true, и компилятор автоматом уберёт лишее.Про флаги компиляции интересно. Нашел, что в коде Gmail еще подключается и код для эмуляции addEventListener через attachEvent, для IE8, который тоже можно выключить флагом.
Возникает вопрос: а зачем в 2018 году включать все это по дефолту? Разумнее было бы наоборот, с возможностью включить тем, кому всё еще это нужно. А идеальнее всего вообще использовать конфигурацию вроде browserlist, где пользователи бы просто указывали нужные им браузеры, а полифилы сами конфигурировались исходя из этой настройки, без жонглирования разными флагами.
Пользуюсь гуглопочтой исключительно по IMAP/SNMP с локально установленным клиентом.
И, судя по этому факапу с тормозящим веб интерфейсом (кстати, на гугловой же page speed tool — сколько попугаев показывает?), разработчики gmail тоже им не пользуются.
И, судя по этому факапу с тормозящим веб интерфейсом (кстати, на гугловой же page speed tool — сколько попугаев показывает?), разработчики gmail тоже им не пользуются.
Ага, а если еще учесть что и по IMAP иногда бывают глюки (в последнее время редко) или неочевидные костыли вещи, вроде Gmail IMAP – Solving the [Gmail] separation
То каждый раз задумываешься: чем эти люди там занимаются? Пользуются ли они своим продуктом?
То каждый раз задумываешься: чем эти люди там занимаются? Пользуются ли они своим продуктом?
Попугаев ровно 100 из 100 в десктопной версии и всего 53 в мобильной. Хотя по моим ощущениям все с точностью до наоборот, и мобильная версия вполне быстро грузится и работает
вот да. Я понимаю, сценарии разные бывают. Но на своем ПК вижу смысл только в использовании почтовых клиентов. Больше настроек, меньше тормозов, возможность читать почту в оффлайн.
Я решил вопрос так:
Мало кто помнит, что есть web-версии gmail для смартфонов и планшетов.
Меняем UserAgent на современный планшет, Ctrl+F5.
Вообще не тормозит.
Вот так вот выглядит:
Мало кто помнит, что есть web-версии gmail для смартфонов и планшетов.
Меняем UserAgent на современный планшет, Ctrl+F5.
Вообще не тормозит.
Вот так вот выглядит:
del
При загрузке Gmail'а внизу всегда была ссылка для старых/медленных компьютеров, которая загружает html-версию почтового ящика.
Поэтому не нужно ничего менять, при входе нужно нажать внизу ссылку и Вы попадёте в почтовый ящик почти моментально.
Поэтому не нужно ничего менять, при входе нужно нажать внизу ссылку и Вы попадёте в почтовый ящик почти моментально.
Моментально-не знаю, у меня страница сначала полностью загружается, потом переходит на базовую версию.
И минус, что эта ссылка присутствует только при загрузке страницы.
И минус, что эта ссылка присутствует только при загрузке страницы.
Это будет basic html версия, которая страшненькая и куцая. В ней, например в ней нет автоматического раскладывания на Рекламу, Соц-сети и собственно почту.
Я имею ввиду вполне современную SPA версию gmail, только сделанную для планшетов/смартфонов и гораздо более легкую чем десктопный gmail. Немного отличается лейаутом.
Я имею ввиду вполне современную SPA версию gmail, только сделанную для планшетов/смартфонов и гораздо более легкую чем десктопный gmail. Немного отличается лейаутом.
Хорошо объяснять тормоза легаси-кодом и поддержкой IE6, но почему тогда этот же Gmail в эпоху IE6 совсем не тормозил?
Из моего опыта: если в текущем Gmail-е выключить чат (Настройки — чат — отключить чат), то прекращается дикий memory leak таба гмыла (Chromium 70).
Пару лет назад кто-то в комментариях к какой-то статье злорадно ехидничал о том, что скоро сайты будут грузиться дольше чем ОС… в принципе ожидаемо, но не думал что это случится так скоро.
Возможно ноут с 16 гигами — это очень круто, но каждая очередная загрузка гмейла — менее секунды. Успеваю увидеть, что конвертик хлопнул дверью и сразу письма.
Я не пользователь gmail, но мне все равно интересно — а зачем они сделали это обновление? В чем реальное преимущество для пользователя, и в чем могут быть плюсы для самого google? (Может это часть далеко идущих планов?) Но вообще, как пользователю только мобильного интернета (а ранее и с помегабайтной оплатой), мне грустно от этого тренда :(
Ну, software bloat обычное дело, не вчера появился. Я думаю это особенности менеджмента большой корпорации. Кто-то должен выдавать результат, и результат должен быть не «ну всё, старый gmail оптимизирован, давайте теперь уволим половину разработчиков и сэкономим миллион в год» а «мы запустили новый gmail, потратили 50 миллионов, смотрите сколько в нём фич!».
использую thunderbird и не знаю таких проблем
Когда читаешь в новостях "… за этим стоят такие гиганты, как Гугл....", хочется прыснуть — да уж, «маленькие гиганты большого кода»! Позорнее разработок ещё не видел (после Windows Millenium).
У знакомых на новом слабеньком ноутбуке слабеньком с двухядерным N30601.6Ghz Gmail грузился почти 40 секунд, окно создания нового письма открывалось… 30 секунд! Было такое ощущение, что gmail попутно майнит биткойн.
На 6 ядерном Xeon прокрутка списка сообщений не плавная, и это ухудшилось именно в последний год. 10 лет назад даже на одноядерном CPU всё было как-то быстрее и плавнее в Gmail.
На 6 ядерном Xeon прокрутка списка сообщений не плавная, и это ухудшилось именно в последний год. 10 лет назад даже на одноядерном CPU всё было как-то быстрее и плавнее в Gmail.
Уже давно пользуюсь google inbox. Он понравился больше, интерфейс проще и чище, плюс очень понравился функционал откладывания писем и создания напоминаний (с интеграцией с календарем). А сегодня появилось сообщение «Поддержка Inbox от Gmail заканчивается в конце марта 2019 г. В новой версии Gmail обновлен дизайн и сохранены лучшие функции Inbox, такие как откладывание писем, напоминания и другие.». Решил глянуть на новый интерфейс gmail — выглядит ужасно. Из плюсов вижу только интеграцию календаря и keep. Если в inbox у меня на виду с десяток писем/напоминаний, то в gmail куча старых писем. Нету функционала напоминаний, а он был очень удобен для создания простых напоминалок, не надо было лезть календарь.
НЛО прилетело и опубликовало эту надпись здесь
Ничего не понял. У меня на ноуте и дектопе в Хроме всегда открыты необходимые табы, в том числе гмэйл. Хром всегда запущен. ОС тоже всегда загружена (на ночь компы уходят в спячку). На дектопе и ноуте памяти 8, оба процессора i3. Таким образом все всегда готово к работе и что такое ждать загрузки я не знаю. Что я делаю не так или не правильно?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Заглядываем под капот нового Gmail