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

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

3 голосов
/ 28 апреля 2010

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

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

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

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

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

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

Ответы [ 3 ]

4 голосов
/ 28 апреля 2010

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

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

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

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

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

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

4 голосов
/ 28 апреля 2010

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

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

0 голосов
/ 28 апреля 2010

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

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

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

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

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

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

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

...