Comments 26
Это очень похоже на CommonJS модуль. Однако в современных проектах рекомендуется использовать ES-модули
Ну нет, CommonJS модуль выглядит по-другому. То, что вы смотрите — это уже сбандленный модуль, и он выглядит для CommonJS и ES одинаково.
Почему вы так считаете? t.exports – это минифицированная версия module.exports. А для es-модулей webpack генерирует совсем другое. Например, для export default { value: 42 }; получится:
__webpack_require__.r(__webpack_exports__);
/* harmony default export */ __webpack_exports__["default"] = ({ value: 42 });После минификации t.exports там быть по определению не может.
Sentry — трекинг пользователя? Это система для сбора ошибок как с фронта, так и с бекенда и мобильных приложений
А в чем принципиальная разница? Sentry тоже собирает какие-то данные о пользователях в целях аналитики.
Строго говоря, error.log сервера тоже «собирает какие-то данные о пользователях в целях аналитики». Мне кажется, в вашей формулировке сместился смысл, и незнакомому с предметом читателю может показаться, что Sentry — это просто какой-то более другой Google Analytics. Было бы полезно исправить этот момент.
Так мое мнение такое и есть, что Sentry – это система аналитики, просто с фокусом на сбор информации об ошибках. Однако стандартным набором – идентификацией пользователей и записью их действий – они тоже занимаются. IANAL, но вроде бы с точки зрения какого-нибудь GDPR разницы между Google Analytics и Sentry нет никакой.
Почитал немного матчасти по этому поводу. В интернете есть много списков хостов для использования блокировщиками рекламы, и там нет однозначного мнения по поводу Sentry. Тема довольно холиварная, есть мнения за и против:
- https://github.com/StevenBlack/hosts/issues/568
- https://github.com/lightswitch05/hosts/issues/58
- https://github.com/anudeepND/blacklist/issues/61
Я понимаю, что это сервис для разработчиков, и он не занимается рекламным маркетингом. Однако, технически им ничего не мешает переобуться в воздухе, и начать продавать данные пользователей на сторону, на серверах-то они имеются.
В статье этот момент оставлю как есть. Можете считать это авторским личным мнением.
Но все же будет честным отметить, что Sentry не «передает в свою систему для анализа о любом посетителе» ни байта — до тех пор, пока у посетителя не произошла ошибка. Такое поведение — следствие ее основного предназначения, и этим Sentry и аналоги принципиально отличаются от Google Analytics и какого-нибудь Amplitude сотоварищи.
А если вы задумываетесь о переходе на Svelte ради уменьшения размера своего проекта – советую обратить внимание на пункты выше, возможно, если их исправить, то никуда переходить и не понадобится.
Я правильно понимаю, что тут говорится «оптимизированный vue/react меньше неоптимизированного svelte», ну для честности надо оба оптимизированные или неоптимизированные сравнивать то.
Тем более если трафик в основном идет на картинки и шрифты.
Ради интереса проверил сколько весит js у первых попавшихся сайтов:
habr — 200k, google поиск — 400kb, youtube — 1.8Mb, gmail — 3.2Mb
Если светила it не сильно обеспокоены оптимизациями, стоит ли нам?
Если важно показать контент до обработки js — используйте next.js, прекрасная и очень простая штука.
Если светила it не сильно обеспокоены оптимизациями, стоит ли нам?
А вы точно размером с gmail, который может себе позволить грузить 6.7Мб скриптов (не 3.2, 3.2 — это только чтоб показать вам «голый» интерфейс даже без писем, потом там еще несколько мегабайт жса придёт)? Просто потому, что куда же пользователи денутся с подводной лодки?
а потом сайты не грузятся на едва живом 2g (реальный случай конца 2019 года)
ну так пользователи с едва живым 2g принесут прибыли скорее всего меньше (в десятки раз?) чем зарплата за N часов работы программистам за их работу по оптимизацию
1. В этой статье, автор говорит про пакеты, но не упоминает query-string, который в виджете также используется. Можно его тоже выкинуть и парсить строку вручную (-2кб). И Axios/Svelte/«Все, что используется для ускорения разработки» — выбросить, оно тоже место занимает.
2. Использовать sentry в cdn? Какая вероятность, что у пользователя будет закеширована версия sentry, которая используется в виджете? Какая вероятность, что origin cdn в виджете и origin cdn на других страницах интернета, будет один и тот же? Я думаю, чуть больше, чем sentry, встроенный в виджет, но не сильно.
Тут еще можно добавить, к sentry в бандле можно применить tree-shaking, а к sentry в cdn — нельзя. Если говорить про виджет, sentry там занимает 12.5 кб.
3.
сократить бандл на 20%, сбросив 14 Кб из общего размера виджета.
Тут явно видно, что не является модулем, который можно оптимизировать. Надеюсь, больше не кажется, что можно убрать 14кб.
Итого: можно сократить 10 кб на картинках, но не 46 кб.
Спасибо за предоставленный скриншот вебпака. Обновил статью с его учетом. Теперь по пунктам:
«Все, что используется для ускорения разработки» — выбросить, оно тоже место занимает.
Не выбросить, а заменить на нативные API. URLSearchParams прекрасно заменяют функциональность query string
Использовать sentry в cdn?
А почему нет? Сможет ли пользователь заказать себе такси, если sentry не загрузится? Скорее всего, да. Тогда зачем его обременять лишним кодом? Пусть он загружается асинхронно, чтобы не отнимал время загрузки у тех, у кого канал потоньше. Вы же загружаете скрипт Google Tag Manager асинхронно, тогда почему не сделать так же с Sentry?
Если говорить про виджет, sentry там занимает 12.5 кб.
А в эти 12 килобайт входит tslib? Это еще 4 килобайта сверху, если нет.
Тут явно видно, что не является модулем, который можно оптимизировать. Надеюсь, больше не кажется, что можно убрать 14кб.
- Lodash.debounce – нужно использовать lodash-es, чтобы включить оптимизации es-модулей. А лучше вообще заменить его на свой 100-байтный велосипед, польза библиотечного debounce сильно переоценена.
- Все картинки. Нужно обновить file-loader до 5 версии чтобы он начал генерировать es-модули для файлов.
В идеале, этого желтого цвета быть вообще не должно. Если какая-то библиотека не поставляет es-модули – то это первый кандидат на вылет и поиск более современной замены.
--
После добавления lodash и query-string и уменьшения sentry до 12 кб финальный результат стал на 2 килобайта меньше, но это все еще 44 кб, и с этим по-любому что-то надо делать.
Не выбросить, а заменить на нативные API. URLSearchParams прекрасно заменяют функциональность query string
Всё было в этой стате было хорошо ровно до секции Ненужный код. К сожалению, ни одна из предложенных нативных альтернатив не заменяет существующие решения, иначе бы все давно на них перешли. И дело здесь далеко не в IE, а в банальном отстутсвии паритета возможностей которые предлагают сторонние библиотеки.
Вы не можете заменить Axios на Fetch и ожидать такой же функциональности. Fetch не поддерживает прогресс загрузки в обе стороны (только на получение), поддержка отмены запросов в Fetch (AbortController) сильно отличается от поддержки самого Fetch, Axios обрабатывает 4xx\5xx коды ответа иначе чем Fetch.
URLSearchParams работает исключительно со строками, тогда как query-string с примитивами и объектами и умеет самостоятельно их преобразовывать.
Куда действительно можно посмотреть в целях оптимизации — это в исключение изображений и CSS из бандла потому что сейчас они проходят парсинг в два этапа: сначала JS парсером, затем парсером под конкретный тип данных.
Конкретно в этом проекте нативных API хватает за глаза. Собрать JSON, отправить POST на сервер – с этим Fetch справляется прекрасно. С query-string то же самое – в этом проекте только строки и нужны, сложные объекты там не используются.
Проблема в том, что эта лишняя функциональность занимает место в бандле совершенно зря. В результате пользователи страдают и пишут посты вроде такого. Хотя проблема решается очень просто – не надо тянуть сложные зависимости раньше времени.
Во многом я соглашусь с автором статьи — сторонние либы и плохо настроенный бандлер это главные причины убивания плюшек Svelte. Отчасти по этому Rollup бывает предпочтительнее из-за того что он лучше делает tree shake но конечно главное тут что вам совершенно не нужен axios для этого виджета. Я понимаю что скорее всего вы копипастили код из других своих проектов на React но все же для целей экономии тут можно было бы немного доработать.
В любом случае я рад что вы воспользовались Svelte и у вас получился хороший и работающий виджет.
Возможно, вам не нужен Svelte, чтобы уменьшить ваш JavaScript