Comments 15
Постарайтесь, чтобы ваши JS-бандлы имели бы небольшой размер.
Маленький размер ещё не означает, что в нём используется быстрый и оптимизированный код. Чаще всего под маленьким размером разработчики понимают, что код нужно чем-то сверху сжать. Маленький размер только ускорит загрузку по сети, и возможно автор это и имел ввиду, ведь он пишет про мобильные устройства:
Особенно это важно для сайтов, рассчитанных на мобильные устройства.Но вот это утверждение вовсе не обязательно будет истиной:
Использование маленьких бандлов улучшает время загрузки кода, снижает уровень использования памяти, уменьшает нагрузку на процессор.Можно написать маленький код, который выжирает все ресурсы. А можно большой, который делает то же самое, и не выжирает. Можно и наоборот. Но маленький код != быстрый код.
0
UFO just landed and posted this here
Судя по тому, как некоторые вкладки браузера жрут CPU, думаю, что некоторые разработчики действительно делают while(true).
+1
Я думаю что имелось в виду то что для конечного пользователя гораздо важнее время которое будет потрачено на исполнение задачи в целом, а не только парсинга. К примеру можно пытаться экономить каждый байтик ради маркетинговых целей как в преакте и получить в итоге тормозное решение. Нужно пытаться оптимизировать размер кода, но не стоит делать это в ущерб производительности.
0
а можно какие-нибудь ссылки на бенчмарки preact vs react? судя по krausest.github.io/js-framework-benchmark/current.html преакт работает быстрее реакта, и его размер примерно в 10 раз меньше
0
>> В 2019 году главными узкими местами производительности веб-страниц являются загрузка и выполнение скриптов
То есть в 2018-м, и далее в глубь веков, вечная проблема софта, заключающаяся в необходимости потреблять ресурсы (процессора, сети и т.д.), никаким образом не возникала?
В целом статья поясняет, что если программу написать эффективнее, то может быть она будет меньше доставать пользователей. Наконец, в 2019-м году, мы это поняли!
Но к сожалению этого не понимают рекламные сервисы, которые именно с помощью скриптов гоняют анимацию в десятках экземпляров (ибо десятки объявлений надо показать на одной странице, ведь это-же столько денег!). И пока вся эта рекламная анимация с постоянным обновлением контента будет выжирать в ноль ресурсы системы, какая-то крошечная экономия на собственно целевой функции сайта (его собственных скриптах) просто никак не скажется на общей картине.
То есть в 2018-м, и далее в глубь веков, вечная проблема софта, заключающаяся в необходимости потреблять ресурсы (процессора, сети и т.д.), никаким образом не возникала?
В целом статья поясняет, что если программу написать эффективнее, то может быть она будет меньше доставать пользователей. Наконец, в 2019-м году, мы это поняли!
Но к сожалению этого не понимают рекламные сервисы, которые именно с помощью скриптов гоняют анимацию в десятках экземпляров (ибо десятки объявлений надо показать на одной странице, ведь это-же столько денег!). И пока вся эта рекламная анимация с постоянным обновлением контента будет выжирать в ноль ресурсы системы, какая-то крошечная экономия на собственно целевой функции сайта (его собственных скриптах) просто никак не скажется на общей картине.
0
Спасибо за аналитику, надо повтыкать.
Но, мне кажется, очень странные рекомендации — если бандл получается 500кб — делить его на несколько частей… одна из причин, емнип, формирование бандла это следствие уменьшения количество файлов, что позитивно сказывается на скорости работы (меньше дескрипторов открытых файлов и пр). Ну и тем более, что минимизированный бандл еще будет (скорее всего), сжиматься при передаче. Так надо ли его делить? В чем выгода? Постараться его уменьшить — да, особенно если он разрастается до размеров более мегабайта. Но делить 300-500кб?
Но, мне кажется, очень странные рекомендации — если бандл получается 500кб — делить его на несколько частей… одна из причин, емнип, формирование бандла это следствие уменьшения количество файлов, что позитивно сказывается на скорости работы (меньше дескрипторов открытых файлов и пр). Ну и тем более, что минимизированный бандл еще будет (скорее всего), сжиматься при передаче. Так надо ли его делить? В чем выгода? Постараться его уменьшить — да, особенно если он разрастается до размеров более мегабайта. Но делить 300-500кб?
+2
У меня, наверное, какое-то искажённое восприятие мира, но я вот смотрю на BP.EXE в 499217 байт и возникает у меня вопрос: а не охренели ли вы все? Почему у вас страничка с пятью кнопками (условно) занимает больше, чем целый компилятор вместе с интегрированной средой разработки, отладчиком и кучей свистоперделок?
По-моему если у вас бандл «улетел» за 100K — то нужно задуматься: а вас точно это web-страница? Может это уже web-приложение? И его нужно уже делать как web-приложение? С однократной загрузкой и работой через DOM?
Но да, как предыдущий оратор заметил: в мире, где рекламный блок занимает 5-10MB заниматься оптимизацией чего-либо бессмысленно. Если вы хотите зарабатывать деньги, то ваши страницы приносили какой-то доход и вкрутили туда пожирателя ресурсов — то экономить «на спичках», на своих скриптах, особого смысла уже нет, а если не хотите… то у вас и так странички за 100K JS не вылазят и все эти разговоры — для вас большого смысла не имеют.
По-моему если у вас бандл «улетел» за 100K — то нужно задуматься: а вас точно это web-страница? Может это уже web-приложение? И его нужно уже делать как web-приложение? С однократной загрузкой и работой через DOM?
Но да, как предыдущий оратор заметил: в мире, где рекламный блок занимает 5-10MB заниматься оптимизацией чего-либо бессмысленно. Если вы хотите зарабатывать деньги, то ваши страницы приносили какой-то доход и вкрутили туда пожирателя ресурсов — то экономить «на спичках», на своих скриптах, особого смысла уже нет, а если не хотите… то у вас и так странички за 100K JS не вылазят и все эти разговоры — для вас большого смысла не имеют.
+2
UFO just landed and posted this here
Разбиение на части нужно для ленивой загрузки. Например, когда главная страница требует только часть код, то можно отдать ей эту часть, а другие части будут загружаться на других страницах по мере необходимости.
+2
В заголовке Javascript, а в статье V8. Реально наступает монополия. Такое до добра не доводит.
+4
Я считаю, многие сайты вполне могут обойтись без JS, ярчайший пример www.world-art.ru
+1
Очень мило, что слайд-шоу для просмотра картинок сделано без скриптов, но то, что при смене картинки явственно наблюдается переоткрытие всей странички — это, как говорилось некогда, не айс. Простые, небольшие и «лёгкие» скрипты явно придали бы сайту дополнительного удобства. «Вполне сойдёт без» всё-таки хуже, чем «можно и лучше».
P.S.
P.S.
Ещё и табличная вёрстка?!...
0
Аналиика всё-равно прикручена, да и сайт не такой легкий, много статики грузится за раз, и в отличие от SPA, это происходит при любом клике на сайте. Так что для тех же мобильных не самое производительное решение, особенно касаемо трафика.
0
Sign up to leave a comment.
Цена JavaScript в 2019 году