Должен ли я объединить файлы js / css в один файл?


11

И надстройки YSlow, и Google Page Speed рекомендуют объединять файлы сценариев (и стилей) в один файл каждый, чтобы уменьшить количество HTTP-запросов, и я, безусловно, вижу смысл в этом, когда файлы сценариев согласованы по всему сайту, но для веб-приложения, которое предъявляет различные требования к сайту.

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

  1. Объедините все файлы, которые используются на сайте, и каждая страница получит один и тот же объединенный файл - недостатком является неиспользуемое содержимое, загромождающее скрипт (и более тяжелая первая загрузка (также перезагружается при изменении любого скрипта компонента))

  2. Объедините файлы для каждой страницы - недостатком является то, что каждая страница с разными требованиями получает разные объединенные файлы (более тяжелая первая загрузка для каждого типа страниц)

  3. Игнорируйте строгое толкование рекомендаций «только один файл» и загрузите страницу в несколько файлов соответствующим образом, при этом кэширование, как мы надеемся, сведет на нет количество запросов HTTP в общем случае - недостатком является количество запросов HTTP на каждой странице.

Мысли?


Ты делаешь это неправильно. Либо разделите части на отдельные файлы и примите удар разминки (вызванный большим числом запросов и холодным кешем), либо программно объедините исходные файлы на стороне сервера и предоставьте всего 1 js, css, html страницу на жесткую ссылку. Смешивание файлов с разными mime-типами = плохо.
Эван Плейс

И ... как сказал @Larry Smithmier в своем ответе, используйте CDN (например, Google) для доставки общих библиотек (например, jquery), чтобы полностью избежать первоначальных затрат на нагрев кеша для этих файлов.
Эван Плейс,

Ответы:


11

Вариант 2 худший; это означает, что каждая страница с различной комбинацией необходимых JS-скриптов приведет к HTTP-запросу. Это сделает производительность намного хуже.

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

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

Один совет, хотя; объединить их автоматически, если вы еще этого не сделали!


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

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

4

Обычно я объединяю «глобальный Javascript» - jQuery и обычные плагины - в один файл, а затем при необходимости добавляю дополнительные плагины в виде отдельных файлов.

Например, на одном сайте, на котором я работаю, на многих страницах есть таблицы данных, поэтому у меня есть global.jsjQuery, DataTables и SuperFish (для моего меню). На сайте есть две страницы, которые используют «лайтбокс», поэтому у меня есть отдельный скрипт для этих двух страниц.

Для CSS я просто обслуживаю один файл для всего сайта и стараюсь сделать CSS как можно более общим - большинство страниц имеют только несколько уникальных элементов CSS.


1

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

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


1

Я бы не советовал объединять их всех. Если вы используете общую библиотеку, вы можете использовать CDN для доставки своих javascripts. Затем вы можете воспользоваться преимуществами кэширования в браузере (при условии, что другие сайты используют тот же CDN) и распределенной доставкой. У Microsoft и Google есть свои решения (я тоже честно не использовал, но я определенно собираюсь начать), и могут быть другие. На связанной ноте у SO есть этот вопрос:

Когда браузер автоматически очищает кэш JavaScript?

и первый ответ - чистое золото.


2
Я уже использую размещенную в Google библиотеку jQuery, но я имел в виду этот вопрос для ссылки на файлы, специфичные для сайта (т. Е. Для сайтов обмена стека, когда при задании вопроса у вас есть скрипт для поиска похожих вопросов, скрипт для рендеринга уценка и предложения тегов, которые могут быть разработаны в отдельных файлах). Кроме того, если вы используете js, размещенный в Google jQuery, тогда как 1.4 и 1.4.2 предоставят вам одинаковое содержимое (на данный момент), 1.4.2 кэшируется в течение года, а 1.4 кэшируется только в течение часа.
Cebjyre

классный совет! спасибо за понимание продолжительности кэширования на jQuery.
Ларри Смитмиер
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.