Обслуживание js-библиотек: лучшая производительность из кода Google или с помощью компоновщика ресурсов?

Question

Я работаю над приложением rails, которое использует большие библиотеки javascript (например, jquery UI), и у меня также есть несколько моих собственных файлов javascript. Я использую пакет активатора, чтобы упаковать свой собственный JavaScript. Я рассматриваю два способа обслуживания этих файлов:

1. Связывайтесь с библиотеками jQuery из Google Code, как описано на http://code.google.com/apis/ajaxlibs/documentation/, и отдельно упаковывайте и обслуживайте мои файлы javascript, используя упаковщик ресурсов.

2. Разместите библиотеки jquery самостоятельно и упакуйте их вместе с моим собственным javascript в один большой объединенный файл javascript.

Мое хостинговое решение, конечно, не превзойдет сеть доставки контента Google, поэтому сначала я предположил, что конечные пользователи будут быстрее загружать страницы с помощью опции #1.

Однако мне также пришло в голову, что если я буду обслуживать их самостоятельно, пользователям потребуется всего лишь один запрос для получения объединенного JavaScript (в отличие от одного для моего объединенного JavaScript и другого для библиотек, обслуживаемых Google).

Какой подход обеспечит наилучшее взаимодействие с конечным пользователем (предположительно в форме более быстрого времени загрузки?)

Answer 1

Я бы сказал "это зависит", но в большинстве случаев я бы выбрал вариант № 1 (хостинг Google) для интернет-сайта. Для интрасети я бы разместил все внутри по ряду причин, но это выходит за рамки вашего вопроса, похоже.

Есть несколько вещей, которые следует учитывать в целом:

• Ваши пользователи не загружают файл, кроме случаев принудительного обновления, если он правильно кешируется.
• У Google больше серверов, чем у вас:) намного больше, и они географически расположены, чтобы наилучшим образом удовлетворить любой запрос, я думаю, что ваш хостинг из одного или нескольких местоположений.
• Браузер распараллеливает загрузки, даже если он выполняет сценарий последовательно, поэтому он будет загружаться от вас и от Google одновременно, увеличивая пропускную способность.
• Другие сайты используют Google для хостинга jQuery (вы сейчас на нем), если у пользователя был какой-либо из них, у него уже был кеширован файл, то есть запрос не был сделан.

Вы можете разместить все файлы в одном файле, но вы должны учитывать вес нескольких вещей с этим:

• Насколько большим будет этот файл, вам нужно, чтобы пользователи снова скачивали все это, когда вы что-то изменили в своем скрипте?
• Несколько запросов (и поиск DNS) дешевле, чем время загрузки для этого файла
• Вы платите за пропускную способность?:)

В зависимости от того, какой процент кода является пользовательским и какой является фреймворком, Google CDN может забрать значительную часть вашего статического js-трафика с вашего сервера, оставляя его доступным для обслуживания и выполнения других задач (это огромное преимущество для сайта с высоким трафиком)), и когда вы меняете свой сценарий (гораздо более распространенный, чем новый выпуск фреймворка)... клиент загружает только это, а не весь фреймворк снова.

Answer 2

Хорошая вещь о Google состоит в том, что, поскольку он используется многими веб-сайтами, есть вероятность, что пользователь уже просматривал сайт, который использовал библиотеки Google JS, в этом случае он уже был бы кэширован на их компьютере, и они могли бы этого не делать. нужно скачать файл вообще.

Лично я бы придерживался использования Google (через google.load()) вместо того, чтобы пытаться объединить файлы и загрузить их с моего собственного сервера. (Вы также можете использовать загрузчик Google для отложенной загрузки файлов и загружать их только тогда, когда они вам нужны, а не загружать все ваши библиотеки и использовать только одну из них.)

Answer 3

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

Когда вы используете CDN от Google (или кого-то еще), передается заголовок реферера, содержащий адрес страницы, а также файл cookie для отслеживания. Упс! Теперь Google знает, на какой сайт смотрели ваши пользователи, когда загружали свои js. Это несколько смягчается за счет кэширования в браузере, так как если вы уже получили его, вы не будете загружать его повторно, и они используют довольно агрессивные элементы управления кэшем.

Однако, если вы опубликовали политику конфиденциальности, в которой говорится, что вы не будете передавать информацию об отслеживании третьим сторонам, то теперь вы лжете своим пользователям. Если вам необходимо включить такое требование конфиденциальности, потому что, например, вы разрабатываете правительственный веб-сайт, то вы нарушаете законодательство.

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

Для конкретного случая Google они прямо заявляют в условиях обслуживания для googleapis:

• 7.2. Вы соглашаетесь на использование своих данных в соответствии с политикой конфиденциальности Google.

... который включает в себя хранение уникально идентифицируемых файлов cookie отслеживания на компьютерах ваших пользователей.

---

Обратите внимание, что даже в политике конфиденциальности Stackru никогда не упоминается о том, что Google может получить запрос, чтобы сообщить им о том, что вы посетили их сайт, или о том, что на сайте есть встроенное изображение отслеживания QuantServe. В нем упоминается "Мы" делаем то и это, но, по-видимому, "Мы" не предназначены для включения QuantServe или Google. Уединение может быть волосатым.