Как улучшить время загрузки с basket.js

Так как он загружает страницу с нуля, все скрипты загружаются через HTTP-запросы. Для загрузки 899 КБ с 27 запросами потребовалось 4,01 секунды (requireJS был пропущен и заменен на basket.js).

В этот момент, когда вы снова перезагружаете страницу, все сбрасывается из кэша браузера, но сценарии хранятся в localStorage : дельта будет измерять фактический выигрыш, обеспечиваемый сценариями кэширования.

Результат: 2,01 с для загрузки 352 КБ, необходимого с 18 запросами. Так что для страницы, которая интенсивно использует JS, у вас есть довольно хорошая экономия.

Наконец, давайте посмотрим окончательное время загрузки для нормального доступа к домашней странице:

Используя кеш браузера и basket.js , страница может быть загружена за 771 мс, и только 5,3 КБ фактически загружены (17 запросов, в основном обслуживаемых из кеша).

Выводы

Эта библиотека — хорошая идея, с одним недостатком полагаться на неидеальный API данных. Соображения, которые привели к выбору localStorage , вполне понятны. Он пытается повысить производительность, и опыт показывает, что localStorage является самым быстрым доступным решением.

С другой стороны, как любит говорить Дональд Кнут, «преждевременная оптимизация — корень всего зла»! Без тщательного и тщательного сравнения производительности трудно взвесить ограничения, вызванные ограничениями квот. К сожалению, проблемы с localStorage не исчезнут в ближайшее время, по крайней мере, для Chrome, где увеличение квоты потребует некоторой нетривиальной перезаписи .

Хорошая новость заключается в том, что авторы basket.js рассматривают несколько альтернатив, включая многоуровневое решение , которое попытается использовать лучший постоянный API, доступный в браузере: Service Workers, Cache API (в Chrome) или FileSystem API.

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

Несколько проблем, с которыми я мог столкнуться из первых рук (и сгорел) при попытке использовать его в реальном проекте:

1. Обратная связь может быть значительно улучшена: трудно сказать, что происходит, когда не удается загрузить ваши сценарии. Если вам повезет, вы можете увидеть какие-то ошибки, но сообщения далеко не значимы. Например, я передавал фактический массив методу require() : все, что я получил, это общий TypeError из кода библиотеки, поэтому мне потребовалось много проб и ошибок, чтобы понять мою ошибку.
2. Теперь, если вам не повезло: скрипт может вообще не загрузиться, потому что у вас есть опечатка (fi basker.require ) внутри обратного вызова по цепочке обещаний. Так как ваше сообщение об ошибке проглочено, вам потребуется некоторое время, чтобы понять это.
3. Если у вас есть зависимости для ваших сценариев, вы теряете понятный декларативный синтаксис, который вы используете с помощью RequireJS, где вы можете перечислить зависимости для каждого из них.
4. С другой стороны, все ваши зависимости перечислены и упорядочены в одном месте. И давайте посмотрим правде в глаза, RequireJS является немного многословным и избыточным.
5. Как только они будут кэшированы, скрипты, загруженные асинхронно, не будут отображаться на панели « Сеть» инструментов разработки Chrome (или Firefox). Более того, вы не увидите их в списке источников, даже если они загружены из удаленного источника. Это усложняет отладку, но ее можно обойти во время разработки, если вы используете basket.js только в производственной basket.js , когда необходима оптимизация.

По правде говоря, этот проект еще не вышел на первую версию, и на данный момент ясно, что это всего лишь эксперимент. И действительно, basket.js является очень многообещающей идеей, и результаты выглядят действительно хорошо — но я basket.js что для того, чтобы быть готовым к использованию для разработки сложного проекта — или для производства огромной страницы, требуется небольшой дополнительный шаг. , (Это было бы верно для любого проекта, который не достиг версии 1, из-за возможных изменений в его интерфейсе / структуре).

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