Уменьшить HTTP-запросы или нет? - PullRequest
21 голосов
/ 24 июня 2010

Теоретический вопрос:
Мы все знаем о преимуществах минимизации и объединения файлов javascript для сокращения HTTP-запросов для ускорения работы сайта.Но когда используются популярные библиотеки javascript (например, jQuery), не слишком глупо предполагать, что они уже были загружены на клиентский компьютер с другой страницы.

Так что же предпочтительнее? Как крупные парни в отрасли справляются с этим?

A) Объединять и минимизировать каждый сценарий в массивный и обслуживать его из моего собственного CDN.

B) Объедините все «самописные» сценарии в один файл и по возможности используйте доступные CDN библиотек.

Спасибо!

Ответы [ 7 ]

13 голосов
/ 29 июня 2010
  • "Объедините и уменьшите каждый сценарий в массивный и подайте его из моего собственного CDN "

    Если у вас есть CDN, о чем мы говорим?:) Вы имеете в виду сервер, верно?

  • «Как крупные парни в отрасли справляются с этим?»

    Большие парни всегда используютих собственные серверы.

  • "... не слишком глупо предполагать, что они уже были загружены на клиентский компьютер с другой страницы."

    К сожалению, это так.Факты:

    • 40-60% пользователей имеют пустой кеш
    • браузеров ограничения кешамалы
    • используются разные версии библиотек , кеширование происходит только в том случае, если они соответствуют
    • ресурс из нового домена создает Поиск DNS , который медленный
    • + вам нужно управлять зависимостями
6 голосов
/ 24 июня 2010

Я думаю, это зависит от вашего сайта:

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

Лучший способ действительно знать, что делать, это проверить, какая комбинация методов сэкономит вам больше всего трафика / соединений.

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

4 голосов
/ 29 июня 2010

Я думаю, что лучший подход - использовать минимизированный файл application.js (содержащий все специфичные для приложения javascript), а затем использовать сервис, такой как Google AJAX Libraries API (найден здесь ), для загрузки jQuery , Прототип и др.

3 голосов
/ 30 июня 2010

Омар аль-Забир управляет сайтом под названием pageflakes и имеет множество статей о том, как повысить производительность. Один из них , в частности, объясняет, как сжимать и комбинировать все виды вещей на стороне сервера перед отправкой клиенту.

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

* У меня, конечно, нет огромной производственной площадки, но эти вещи определенно помогли сэкономить на пропускной способности.

3 голосов
/ 29 июня 2010

Я думаю, что это сводится к нескольким вещам:

  1. Сколько страниц используют код на вашем сайте
  2. Качество CDN
  3. Какмного кода это

Существует также разница между использованием популярных пакетов Javascript, таких как jQuery, и персональным пакетом, который будут иметь только посетители, посетившие ваш сайт.

Повышение производительности может происходить из двух мест: 1) кэш браузера и 2) кэш DNS, который, даже если файл не хранится локально, у сервера DNS есть маршрут, который минимизирует время запроса или даже временно обслуживает файл.

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

Кроме того, напомните, что некоторые пользователи предпочитают отключать кэш браузера.Так что минимизация вашего JS - это всегда плюс.Вы должны разделить ваш JS на два файла: 1) Необходим при загрузке и 2) Не нужен при загрузке.В основном, сначала получите необходимый код, чтобы улучшить воспринимаемое время загрузки.Затем загрузите все остальные дополнения (например, слайд-шоу, смены цвета и т. Д.).

Последнее, что нужно сделать, это использовать заголовки Expires, поскольку ничего из этого не важно, если вы не оптимизируете это.Это то, что действительно уменьшит скорость для возвращенных посетителей с включенным кэшем. YSlow - это хорошее дополнение к Firefox, которое поможет оценить производительность загрузки.


Чтобы ответить на ваш вопрос: Сократите HTTP-запросы, но сделайте свою собственную оценку наразмер файла JS.

(Быть экстремальным) Вам не нужен один JS-файл 10 МБ, иначе загрузка вашего сайта займет слишком много времени.Вы также не хотите 1000 файлов 10 КБ, из-за HTTP-издержек.Опять же, используйте это, чтобы проиллюстрировать тот факт, что вам нужен баланс между размером и количеством файлов - и, как я уже говорил ранее, упакуйте их в требуемую производительность против требуемой.

2 голосов
/ 30 июня 2010

Нет особой причины, по которой получение одного сценария будет быстрее, чем его разбиение. Это происходит потому, что количество одновременных загрузок в браузере ограничено, но не одним.

Я думаю, что идея должна заключаться в том, чтобы сначала обрабатывать синхронные сценарии пользовательского интерфейса, а затем сценарии "ответа пользователя на действия" (такие как проверка и т. Д.)

При прочих равных вариант B выглядит наилучшим.

2 голосов
/ 29 июня 2010

В частности, на ваш вопрос о том, как крупные парни в отрасли работают со сценариями на стороне клиента, вы всегда можете посмотреть и увидеть. Stackoverflow.com выглядит хорошо, полагаясь на версию jquery lib от Google. Другие решительно не делают ....

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...