Comments 159
Непонятно зачем в вашей статье картинки, которые тоже отжирают мегабайты, когда можно было просто написать текстом или лучше табличкой:) Ну да ладно.
Я вообще далек от современной web-разработки. Сейчас у меня есть домашний проект - веб-интерфейс к социальному графу вконтакте. Там всякое - скачивание, пагинация (классическая а не эти дурацкие бесконечные прокрутки), поиск, фильтрация, установка тегов, сортировка, но сделано все абсолютно минималистически без каких-бы то ни было фреймворков и украшательств (я их просто не знаю). js-файл к этому 12 килобайт:) и css 3 килобайта.
Могу предположить, что в современных средствах развертывания сайтов (аналоге классической компиляции) нет понятия оптимизации по использованию функций. Т.е. если код не используется, то он и не включается в релиз. Хотя возможно ли это для интерпретируемого языка, в котором код теоретически может сам по себе сгенерироваться в рантайме? Может потому так и не делают...
Могу предположить, что в современных средствах развертывания сайтов (аналоге классической компиляции) нет понятия оптимизации по использованию функций. Т.е. если код не используется, то он и не включается в релиз.
webpack, на сколько я помню, умеет в ленивую подгрузку модулей.
Или вы что-то другое имеете в виду?
13 килобайт против 10 мега.. Как мы с Вами безнадежно отстали от жизни .. делал, получал примерно такой же размерчик, но это было раньше времени этой статьи - 2010-2013гг. Помнится тогда директор уволил троих коллег только на основании того, что их странички (полностью с контентом!) весили больше 1(одного) мегабайта. Норматив помнится был "уложиться в 100к вместе со 100 строчками выборки данных".. :)
Вот ПОЭТОМУ с тех пор и "бэкендщик", хотя .. тут тоже много чудесатого уже.
P.S. Публиковал тут выдачи со Сбера и .. Хабра. Случаем не ими навеяна статья? :)
P.P.S. в 2016-2017 .. где-то там, делал толстого клиента - Смета для производства на Jquery .. не помню точно каков был размер js-кода, но меньше мегабайта - всяко. С моделями и пр. блекджеком и плюшками.. :)
Сейчас у меня есть домашний проект - веб-интерфейс к социальному графу вконтакте. Там всякое - скачивание, пагинация (классическая а не эти дурацкие бесконечные прокрутки), поиск, фильтрация, установка тегов, сортировка, но сделано все абсолютно минималистически без каких-бы то ни было фреймворков и украшательств (я их просто не знаю). js-файл к этому 12 килобайт:) и css 3 килобайта.
А у меня есть "тренировочный лендинг" с листаемой галереей (оно-же пагинация) и раскрывающимися "learn more" вообще без js :)
Сделано в качестве "гляди чё я могу" лет 10 назад для показа вместе с резюме.
Единственный коментарий, который я слышал по этому поводу, был "и нафига этот изврат? Кто-нибудь, кроме тебя, это вот поддерживать сможет?" :)
JS бандлеры вполне себе выкидывают неиспользованный код.
tree shaking ?
Вот на этом сайте всё сделано правильно:
Здесь загружается 0,1 МБ, и этого достаточно!
А потом ещё спрашивают на форумах: «Насколько стыдно использовать jQuery в 2024-м году?» (Нет, серьёзно, я не выдумываю, недавно видел такой вопрос). Стыдно! Очень стыдно! Сто килобайт — да вы выглядите просто каким-то лохом.
Невероятно!
Рекомендую сравнить в этом месте перевод с оригиналом ;)
Вспоминаю закон Мура, думаю к размеру JS он тоже будет применим: Каждые 2 года размер JS удваивается.
Очень давно видел сайт где можно было собрать JS для себя с нужными функциями, мол выбираешь там: 1) сворачивание меню 2) плавный переход по картинкам 3) отправка сообщений из формы и т.д. и потом скачиваешь минимальный размер JS только с нужными функциями. Щас уже забыл что это был за сайт. Может кто-то знает что-то похожее где можно в JS положить минимум функций самых необходимых чтобы размер был поменьше?
И это тоже просто лендинг.
Зачастую делается одно frontend-SPA сразу под все задачи. И лендинг просто одна из страниц.
И если вы, как и я, подумали, что: «Figma — это действительно сложное фронтенд-приложение, поэтому у него должен быть большой объём JS-кода», то ошиблись. Тогда получается, что Gmail почти такой же сложный, как Figma, LinkedIn сложнее него в 1,5 раза, а Slack — в 2,5 раза. ¯\_(ツ)_/¯
Во-первых, конено же есть фактор плохого кода. Выбрали "тяжелые" библиотеки, плохо настроили сборку, плохо разделили код и т.д. Иногда с финансовой точки зрения выгодно просто оставить бандл в 10Мб, чем тратить несколько десятков (или сотен) часов работы высокооплачиваемого специалиста.
Во-вторых, все зависит от функционала. Иногда кажется, что вроде ничего и нету на сайте, а там вот где-то WYSIWYG-редактор спрятался, Markdown-renderrer, Всякие code-блоки с подстветкой миллиона языков программирования, всякие там builder'ы, color-picker'ы и еще сотни разных элементов. Каждый, естественно, своя библиотка, и зачастую далеко не самая оптимальная (потому что те что были размером поменьше не имели вот конкретно той фичи которая так нужна была). Докинем сверху еще всяких интеграций с другими сервисами, и вообще караул.
Иногда с финансовой точки зрения выгодно просто оставить бандл в 10Мб, чем тратить несколько десятков (или сотен) часов работы высокооплачиваемого специалиста.
Зачем высоко платить недоразвитому программисту?
Потому что "недоразвитый" он с точки зрения эстетов или просто токсичных людей, а здесь и сейчас он делает полезные фичи, которые этому бизнесу деньги.
Недоразвитый он с точки зрения профессионалов в области, которые понимают как дорого бизнесу на самом деле обходятся такие вот "делатели фич здесь и сейчас".
Под профессионалами вы почему-то понимаете именно себя, а другие признанные профессионалы не такие профессиональные профессионалы и их мнение не котируется, ибо не совпадает с вашим?
А по поводу статьи в целом. Ну, весит сайт 60мб, так у меня и интернет быстрый, скачает и 100 и 200. Тем более что это разовое действие, потом возьмёт из кэша.
Признанные профессионалы, не способные делать свою работу хорошо, называются разбалованными дилетантами.
Кажется, тут смешивание мастерства и профессионализма. Профессионал делает так, как за это платят деньги, это его профессия. Платят, видимо, когда нет значимых огрехов. Из профессионалов можно выбирать, каждый сделает немного по-своему. А мастер сделает мастерски, уникально, недостижимо для большинства. Таких единицы. Если считать профессионалами только мастеров, тогда у нас нет ни музыкантов, ни кондитеров, ни водителей.
Я как-то на автодроме видел, как инструктор на грузовике проехал змейку задом, да ещё на не самой маленькой скорости. Если судить по этой планке, то вряд ли среди водителей грузовиков все профессионалы.
Да-да, чтобы из десятка вариантов зависимости выбрать не самую жирную - это нужно настоящее мастерство, профессионалам такое не под силу.
Возможно, сперва-то выбрали, но там не было нужного, пришлось брать другую. Мне иногда нужен кастомный <select>, но не в виде компонента для react или vue, а под чистый js, я беру некоторые из npm или просто из поиска, а там нет возможности рисовать свою стрелочку вниз-вверх или нельзя стилизовать <option>, потому что они не кастомизированы, а выводятся прямо из родного селекта. Приходится искать другие, даже целые комбайны. Часто попадаются какие-то древние штуки на jQuery с дохлым сайтом. Недавно нашёл нужную, но она не видела параметр placeholder, да и документация была от старой версии. Пришлось лезть в исходник, разбираться и добавлять всё, что мне нужно. А ещё там нельзя было сделать нормальный сброс значений через вызов customSelect.reset() или чего-то подобного, но я смог обойтись костылями.
Я бы мог написать всё сам, даже чтобы можно было стрелочками и по pgup/pgdown листать выпадашки, но мне на задачу выделено ограниченное количество времени, которого едва хватает даже на поиск и перестилизацию найденных компонентов.
А взяли бы сразу нормальный фреймворк с кастомизируемой библиотекой компонент - не пришлось бы страдать всей этой ерундой.
Если бы нужно было взять фреймворк, я бы взял vue, но мне нужно было на чистом js или максимум с jQuery, потому что он туда уже подключен.
Посмотрите в сторону веб-компонентов, например, shoelace.style. Можно взять конкретный компонент, подключить его через <script>/import и кастомизировать как нужно
У вас дихотомия. Вы видите мир в черном и белом, а серое это тоже норма и ок. Заканчиваете с радикализмом, будьте open minded
Это у вас интернет быстрый, а у меня 1 гбит/c на всю страну. В офис, к примеру, у нас подается 20 мбит/c. В офисе 30 человек.
> Тем более что это разовое действие, потом возьмёт из кэша.
Каждый раз компьютеру парсить и интерпретировать 100 МБ говнокода. И не у всех Core i9 настольный.
Какая ужасная страница. Грузится долго, зачем-то спрашивает про локальное хранение, скроллбара нет, потом тормозит на банальном скролле колесом мыши... За ссылки через якорь вместо реальных URI уготован отдельный котёл в аду, конечно.
Долго - это сколько секунд? Можно скрин без скроллбара? А лучше видео тормозящего скролла. Про адские якори можете почитать тут.
Да чего уж там далеко ходить. Страница хабра при плохом интернете не может получить какие то рантаймы и показывает мне скелетон. Либо крашится и не реагирует на кнопку Reload, потому что богомерзкий фреймворк перехватывает это действие и history.push(). В итоге я трачу время чтобы убить вкладку сафари на смартфоне и как-то заставить скрипты перезагрузиться полностью (ака force reload). В общем пиздец, я не знаю какое еще другое слово подобрать
Вы действительно считаете, что эти «профессионалы» знают как делать сайты?
Красный флаг
Профессионалы просто получают деньги за работу — в отличии от любителей. Не наделяйте их качествами сверх того.
Я конечно понимаю, что бытует мода на "настоящих" мужчин и всё такое, но в корне её — шейминг и манипуляция, к физиологии не относящиеся.
Обратная связь: если запустить видео, а потом крутануть страницу вниз, то видео останавливается, приходится возвращаться и перезапускать, а потом искать место, где воспроизведение было прервано.
Если уйти на другую страницу оно тоже останавливается. Если хочется слушать видео в фоне и продолжать бродить по сайту, то его можно открыть в отдельной вкладке.
Базовый юзкейс: хочется смотреть видео, параллельно читать описание под ним. Например, в видео упоминается ссылка, я пошел искать ее в описании под видео - ссылку нашел, но видео прервалось и пришлось искать на видео, где остановился.
Понимаю, но это всё же не видео хостинг, а место публикации статей. В стати можно встраивать видео, картинки и другие приложения, но смотреть встроенные в маленький блок видео не очень комфортно в любом случае, а фоновая работа не видимых приложений может давать излишнюю нагрузку на систему.
Если в статью за каким-то надом вставлено видео - предполагается, что читатель может его посмотреть. Если его смотреть не следует - то и вставлять не надо было. А некомфортность маленького блока может быть ещё одним недочётом сайта, но никак не оправданием для остановки видео.
Читать же статью во время просмотра видео - совершенно естественное желание пользователя.
Где же реклама божественного мола, о великий програмер?
Иногда с финансовой точки зрения выгодно просто оставить бандл в 10Мб, чем тратить несколько десятков (или сотен) часов работы высокооплачиваемого специалиста.
Здесь этот аргумент не очень проходит, потому что в статье обозреваются сайты с многомиллионными аудиториями. То есть кейсы, когда оптимизация имеет смысл. Тут скорее фактор управленческого паралича — где-то менеджменту недосуг, а где-то уже и трогать боятся.
Здесь загружается 0,1 МБ, и этого достаточно!
Для статичной-то странички? Несколько лет назад я делал свой редактор документов с синхронизацией в реальном времени, полностью кастомным рендерингом на холсте, виртуализацией, прозрачной поддержкой MarkedText, подсветкой синтаксисов и прочими плюшками, который весил всего... 80кб.
Вот и оцените, насколько Вы отстали от модно-молодежных трендов!
На месте тимлидов, я бы штрафовал разрабов за применение внешней библиотеки (доп. зависимость), если из неё применяется менее 75% функционала. За каждый "избыточный процент скажем минус 100рублей".. очень быстро отрезвит всех.
Поэтому вы и не тимлид )
Конечно, пусть лучше напишут 74% функционала библиотеки сами. Они, вообще-то, с удовольствием уйдут на пару месяцев в разработку, это будет стоить работодателю 500к и потерянного времени. Ещё и 100 руб штрафа не получит.
Начните с себя: сколько процентов функционала вашей ОС вы используете? Если меньше 75%, то пора писать свою ось, а пока не написали - штрафовать себя за каждый избыточный процент
и за велосипеды тоже штрафовать
чтобы ни один разработчик не остался не охваченным пламенной заботой
Неудивительно, ведь теперь в spa в js зашиваются все вьюхи для компонентов, сама логика из Бэка по большей части переехала во фронтенд, и если не настроена динамическая погрузка, а все зашит в один бандл, то итоговый размер js будет жирным. А ещё зависимости погоняют зависимости и очень много кода по сути не используется, или используется в крайне редких случаях. В общем современный веб во всей красе.
На заре интернета все делалось на сервере, и получали лёгкие страницы чисто с внешним видом, а сейчас из Бэкенда фактически только rest api осталось, то есть бэк почти как тупая база данных, а вся логика и представление - во frontend.
А это разве плохо? Все поместит на клиент, нежели чем на сервер. С аудиторие 1кк+ это полне логичено, пусть человек один раз грузит со свеого устройства 10мб, чем сервер будет грузить в 100 больше за тот же промежуток времени.
Типичный современный клиент это телефон. Иногда не очень новый и очень китайский телефон. Пусть лучше сервер считает, на этот телефон надежды совсем нет. Сервера стоят не так дорого.
Заблуждение. Когда у вас на сайт ходит 100 юзеров в час это действительно недорого. А когда миллион это уже совершенно другие деньги.
Как раз миллион дешевле выйдет в пересчете на каждого юзера. Фиксированных издержек почти нет все издержки на юзера, нанять дорогих разработчиков деньги есть.
А денег миллион юзеров приносит ровно в 10 тысяч раз больше чем 100.
Тут вы неправы еще и в том, что для этого нужно написать качественный бэк, а найти бэкендеров способных справиться с этим так же сложно как и найти фронта который знает чистый JS.
Ну практика показывает, что загружается это далеко не один раз, а практически каждый раз, начиная с тупо протухания кэша статики, заканчивая постоянными релизами, а следовательно обновлением бандла.
На первый взгляд так и есть, только вот неудачное api приводит к тому, что клиенту приходится делать по десятку запросов перед показом страницы, загружая в несколько раз больше данных чем выглядела бы разметка HTML...
Да там половина, если не больше - трекеры и аналитика
И ещё немного — поддержка устаревших браузеров, которые не умеют чего-нибудь, что остальные умеют.
Больше. Все инкрустированные сервисы типа социальных кнопок, рекламы, аналитики тащат с собой свои SDK-бандлы, каждый из которых запросто может превосходить сам код страницы. Благо грузятся они все асинхронно. Автор должен был это учесть.
Хм. Со статьёй в целом согласен, но в некоторых примерах реализуются довольно сложные манипуляции с содержимым страницы без перезагрузки этой самой страницы, а не просто выводится статичный контент.
Gmail может переписали уже, но раньше его JS код транслировался из Явы.
Современный фронтенд очень легковесный, потому что на этапе сборки удаляется все не используемое, делится на небольшие кусочки, и в браузере загружается ровно то, что необходимо (в разумных пределах), в автоматическом режиме.
Дикие десятки мегабайт появляются тогда, когда надо поддерживать легаси десятилетней давности, давно не поддерживаемые библиотеки, потом к этому прикрутить современный фронтенд фреймворк и наладить взаимодействие с десятками рандомных сторонних скриптов, которым что-то нужно, а так-же добавить метрики, аналитику и рекламу. И все это должно работать в IE.
есть полифиллы, и они довольно компактные
сегодня очень многие сайты работают только в Хроме, а во всех остальных браузерах говорят мы вас не поддерживаем.
Не обязательно. Когда фронт модульный и пилится одновременно несколькими командами, возникает проблема с зависимостями, когда разные команды используют либы разных версий, которые по нескольку раз включаются в финальный бандл. Поэтому некоторые переходят на монорепозиторий, где менеджить зависимости легче.
Думаю это хорошо подходит под категорию рандомных скриптов. Чтоб все хорошо работало, нужен единый инструмент, который все разруливает. А если N модулей используют по такому инструменту, то в результате бандл будет больше примерно в N раз.
Лучше переходить нa verless, тогда можно оставаться в полрепо.
Шут его знает, что там по ссылке. Она не открылась даже когда я разрешил скрипты в noscript.
Судя по домену, это опять агрессивный пиар какого-то собственного изделия? Вам такое поведение не кажется чересчур навязчивым?
Это страница в нашей базе знаний. У вас видимо расширения шалят.
eval() не ваше?
А вот теперь открылось. Я перезапускал браузер между этими событиями.
Страницу под 1920 верстали? Чуть поменьше не тестировали? У меня слева расположены вкладки, на странице появился скрол, хотя можно было просто сузить третью и четвёртую колонки. Да и первая явно имеет потенциал для сужения.
Возможно, у вас 1rem подразумевается в 16px. У меня в браузере 18px, поэтому всё впритык. Если сделать 16, то влазит.
Открыл в новой вкладке страницу со ссылки "Профиль" и опять поймал эту ошибку с CSP. Совсем оно не дружит с Firefox.
Это букленый дизайн. Одна страница влезает полностью, остальные могут обрезаться - это нормальная ситуация.
Hidden text
Это в порядке вещей? Страница была пустая, я решил заглянуть в консоль в поисках ошибок.
Думаю, не хватает прелоадера.
Да, но лучше включить custom formatters, чтобы логи были покрасивше.
В недавно сданном проекте домашняя страница занимает 500(пятьсот) мегабайт.
Фронтенд девелоперы не видят проблемы.
С картинками, но все же!
500 мегабайт, загружаемых на устройство клиента при переходе на домашнюю страницу?
Да. Сам офигел. Индийские фронтендеры, ну а че, " у нас тут куча фоток на весь 4к экран".
Оно еще потом все в кэше клиента оседает. Прикольно, да?
А, т.е. это просто вагон тяжёлых фоток?
Они на любое устройство отдают оригиналы, или это версия для 4К экранов?
Интересно, что за проект, в котором такое может понадобиться...
Аналогично было, только наши фронари. Бизнес дал фотки как есть, дизайнер в отпуске, а они, видите ли "не дизайнеры", чтобы 4К уменьшить до 200 пикселей. Самое смешное, что пришел дизайнер и оказалось, что не может рисовать, поэтому чистить и править фото он не будет. Пришлось самому все быстренько исправлять. Такие спецы - за 21 день - зато дешево!
В кэше браузера больше 40-70 Мб на сайт не оседает
> Сравните это с ресурсами, реально обеспокоенными производительностью — Po...
Забавно, что они отправляют петрабайты видео, но минимизируют js... Avito - слыхали?
Это время на загрузку страницы до начала показа видео, а человеку, у которого рука уже начала действовать (возможно, с предыдущей страницы) на причинном месте, ждать некогда - такое раздражает гораздо больше медленного сёрфинга обычных сайтов в обычном состоянии. Т.е. человек может психануть и уйти на другой сайт аналогичной тематики. И зачем оно им?
Чаты проще TODO листов? Ну, может быть чат на каком-нибудь форуме, где можно писать текстовые сообщения в общую колонку текстовых сообщений - да. Дискорд - это махина из миллиона самых разных фич, это весьма сложное приложение с точки зрения бизнес-логики. Я не говорю, что каждый байт из js, который он скачивает, необходим, но и нельзя просто сказать, что размер бандла раздут на ровном месте.
а где российские ресурсы?
яндекс, вк, мейл..
ну например, зум есть, телемоста и гугл мита нету. Плохо ?
Ну напишите про них, кто мешает
мне кажется тут в одну таблицу все уложить можно. На статью прям не тянет.
Жаль конечно, что вы тока негатив везде видите. Мой поинт был в том, на русском ресурсе ни одного русского сайта в подборке ?.
Проблема в том, что весь т. н. Веб сегодня фундаментально поломан.
Поначалу была только статика и это всех устраивало. Потом придумали JS, но как опциональную штуку для небольших улучшений. Но потом кто-то додумался использовать JS для написания по сути приложений в среде браузера. Эти приложения стали популярны, ибо браузер, это по сути универсальная платформа для распространения кроссплатформенных приложений.
В альтернативной истории всё могло бы сложиться иначе. Браузер бы остался программой для просмотра статичных страниц, а для кросплатформенных приложений существовало бы что-то иное, возможно с чем-то более подходящим вместо JS, вроде Java-машины или WASM. Всякие Википедии и сайты вроде Хабра остались бы статичными, а приложения вроде Youtube или Discord были бы внутри этой второй технологии. Более низкоуровневое кросплатформенное представление программ, вместо JS, способствовало бы уменьшению размеров приложений.
а для кросплатформенных приложений существовало бы что-то иное
*кашляет* Flash.
Альтернативной истории не случилось, т.к. приложение надо доставить пользователю ещё вчера, браузер уже есть сейчас, а "иное" появится только послезавтра.
WASM
Вполне себе пилится, но только это всё ещё "завтра".
Flash - это ж редактор векторной графики, к которому прикрутили поверх немного скриптов. Делать на нём приложения ещё тяжелее чем в браузере же...
Вы точно не в теме
Flash это виртуальная машина оптимизированная для работы с анимацией и графикой, она запускалась в браузере через плагин Flash Player, на десктопе и мобилах через обертку Adobe Air. Для флеша была куча инструментов и фреймворков для формошлепства, игр, анимаций. Adobe Flex, который вышел 20 лет назад до сих пор во многом превосходит современные JS фреймворки, с точки зрения удобства для разработчика и полноты возможностей (декларативное описание ui, анимаций, данных, качественная ui библиотека, нормально сделанные формы, односторонний и двухсторонний биндинг, разделение логики и представления, компилируемый язык и как следствие компактные размеры приложения, разделяемые библиотеки, ленивая подгрузка модулей, бинарный протокол общения с сервером, встроенная поддержка e2e тестов, локализаций, xml и json и так далее).
Silverlight еще был.
Я даже видел предложение (от @netch80 емнип) как это могло бы быть - виртуальная машина VAX/VMS, мертвое железо, но простой ассемблер, бинари в котором могли бы быть таким общим знаменателем для всех.
Веб не сегодня фундаментально поломан. Он в принципе такой. Вот посмотрите, статья [“Forgiving” Browsers Considered Harmful](https://alistapart.com/article/forgiving/) (из https://habr.com/ru/companies/ruvds/articles/793906/) была права - именно вот это всепрощение с низким порогом входа и привело к тому раздутому кошмару со сложностями на ровном месте, которое мы имеем сейчас. А ведь тогда вопроса приложений на JS в среде браузера еще даже не стояло!
Можно рыться и глубже в историю, когда Веб "сломали". Технически это прослеживают на момент где-то после введения тега img, примерно в 1994. А астрологически он таков прям от рождения - ему на роду написано быть раздутым с кривыми черезжопными решениями и костылями.
Теперь проще всё выкинуть, уничтожить Web и начать что-то новое, чем исправить горбатого.
На самом деле концептуальная проблема, отсутствие tree shaking как опции по умолчанию и помойка в npm, печальные тренды, ну и плюсом часто в js улетает контент стили картинки и много другого.
А вот вопрос - ведь многие в приведённых примерах, используют всякие библиотеки, React, Angular и прочую лабуду. Заметил, что многие клиентские интерфейсы буть то почта, интернет-банк, всякие интернет магазины, в последнее время намного тормознутее стали. А если глянуть консоль, мама дорогая, как правило куча ошибок, предупреждений и т.д.
Если разработчики не утруждаться, чтобы убрать хотя бы ошибки, то уж точно не "надорвутся", оптимизируя вес и быстродействия своих говноподелий
Как правило, разработчик никак не может повлиять на сторонние скрипты, которые встраиваются в сайт. Это метрики, аналитика, реклама, капчи и тд. Так-же не может повлиять на установленные в браузер расширения и блокировщики. Все это пишется непонятно кем, непонятно как. Но по итогу, каким бы ни был вылизан твой код, в консоли будет насрано.
И так сойдёт! Лозунг ИТ и программирования в частности:)
Колхозный фронтенд все ближе)
Двести метров джаваскрипта грузят текста триста байт
Колхозный фронтенд все ближе)
Двести метров джаваскрипта грузят текста триста байт
Windows 95 занимает около 50 мб. Что то явно во фронтенда странные дела творятся. Если js настолько много.
Да и мобильные приложения недалеко ушли.
"Помидорный таймер", которым я пока пользуюсь, весит 20 мегабайт (это размер только приложения, ещё 300 МБ "пользовательские данные", как будто я сотни лет уже с ним работаю) и иногда тормозит на 10-20 секунд при старте (возможно, роется в этих данных каждый раз?).
Более простой опенсорсный -- 180 килобайт o_O (да, на два порядка меньше).
Просто js стал высокодетализированным.
4К 120fps
Не удивлен учитывая желание помещать в JS и стили и иконки и логику с бэка
У меня игра, довольно сложная, написана на JS. Строим деревеньку, генерируем карты а-ля King's Bounty, ходим в походы, бьемся за сундуки с золотом.
Общий размер кодовой базы, включая плагин выбранной локали, составляет 500 кБ.
Общий размер, с картинками, SFX, кодом, и всем остальным меньше 4,5 МБ.
Сколько времени уйдёт у нового разработчика, чтобы вникнуть в код и начать его дорабатывать?
Периферийные модули - неделю, core - ну, недели три. Это если вечером ковырять после работы.
«После работы»? А разве погружение в проект не является работой?
Вы, если обратили внимание на картинку, могли понять, что это хобби проект.
Работа - то, за что вам платят и где у вас есть обязательства.
Мне за это не платят, обязательств у меня нет, поэтому это хобби.
Это же я говорю и всем тем людям, которые когда-либо проходили через этот проект.
Если нормализовать на рабочее время - через 3 рабочих дня можно выполнять задачи на периферийных модулях, через 7 рабочих дней можно начинать контрибьютить в core
Стремление автора следить за весом скриптов очень похвально. Но удивило, почему Senior Software Developer в статье об оптимизации забыл позаботиться о весе картинок к ней. Если пропустить все картинки оригинальной статьи через TinyPNG — что, кстати, заняло 5 минут, а не "десятки часов работы дорогого специалиста" — то получаем экономию минус 56.7% (9.974 MiB => 4.318 MiB)
Я "придралась" не из-за ЧСВ, а потому, что скрины оригинальной статьи загрузились раздражающе медленно у меня на Йоте (да, параллельно качались музыка и кино, но всё же).
Вы слишком многое ожидаете от автора статьи. Человек ткнул в известный факт и сделал из этого целую статью, но не объяснил в чем конкретно присутствуют проблемы и как мы в этом оказались. Не объяснил про трекеры, рекламу, аналитику, лишние библиотеки, стили в js и медленное перетекание логики сервера на фронт, а также многое другое. Исходя из этого можно сделать вывод, что автор возможно сам не имеет представления о происходящем и в оптимизации особых знаний не имеет.
Но картинки оригинальной статьи в webp, и они раза в 2 меньше по объёму, чем PNG из перевода.
Полностью согласен с автором — выглядит это всё страшно и будто бы глупо. Но, думаю, причины вполне логичны. И заключаются в том, что накопилось очень много legacy-кода. Разработчики приходят и уходят, вынужденные поддерживать старьё, часто не сильно оптимальное, написанное предыдущими разработчиками, которые попали на это место как дети друзей владельцев компании, а не как толковые кодеры. И далее всё движется по принципу «работает — не трожь», который заставляет для уже написанных костылей писать новые. И ни у кого не хватает смелости, чтобы не потерять место, просто переписать всё с нуля и оптимально, потому что в Джире висит ещё 50+ задач и хотелок от руководства, которые надо срочно реализовать ко вчера. Плюс накладывается работа в команде, когда у каждого свой участок кода, своя кодовая база и все видят всё по-своему.
Когда над проектом работает один человек и когда нет большой ответственности, оптимизировать в разы проще — ты видишь весь код, понимаешь что куда и полностью всё контролируешь и время у тебя есть. Поэтому проекты одиночек и небольших и постоянных команд куда более оптимальны и эффективны. Взять же ответственность за большого колосса, создаваемого большой командой, которой платят кучу денег, и заставить всё переписать только потому, что бандл великоват, мало у кого хватает.
Это плата за быструю и удобную разработку. Например google может заниматься оптимизациями силами пары программистов и при этом экономить, а для остальных это прямые затраты. Вообщем как говорится рыночек порешал
Для меня примером является веб клиент телеграма. 152кб :)
Тем временем Google использует оценку Lighthouse в качестве одного из важных критериев ранжирования сайтов в поисковой выдаче. Поэтому когда создаются сайты для продвижения через поисковую выдачу, разработчиков сильно дрючат за производительность.
LCP is a common optimization target because it's presented as one of the primary metrics in Google PageSpeed Insights, a "Core Web Vital" metric. There's an asterisk next to LCP as used in this document because, LCP as measured by Chrome is about painting a large fraction of the screen, as opposed to the definition above, which is about content. As sites have optimized for LCP, it's not uncommon to have a large paint (update) that's completely useless to the user, with the actual content of the page appearing well after the LCP.
In the more blatant cases, developers will deliberately flash a very large change on the page as soon as possible, generally a loading screen that has no value to the user (actually negative value because doing this increases the total amount of work done and the total time it takes to load the page)
Оптимизация под Lighthouse всеми правдами и неправдами https://danluu.com/slow-device/ хорошая статья
Так а потолстел то насколько? Так и не нашел ответа, потолстел относительно чего, относительно какого времени и на сколько :)
Так и 15 лет назад аналогичная проблема была. Когда jQuery подключали только ради того чтобы одну строчку кода написать.
Насколько потолстел JavaScript к 2024 году?