Оптимизация запросов JavaScript и CSS - PullRequest
Новая
       27

Оптимизация запросов JavaScript и CSS

9 голосов
/ 03 ноября 2010

Мне нужно оптимизировать скорость загрузки нескольких существующих сайтов. Одна из проблем, с которыми я сталкиваюсь, это количество запросов на страницу. Веб-сайты имеют 7 или более различных типов страниц, которые должны загружать различный набор CSS и JavaScript, потому что они содержат разные виджеты или функции. В настоящее время каждый виджет или функциональность имеет свой собственный файл JavaScript. Я планирую объединить и минимизировать файлы, чтобы иметь меньше запросов.

  1. Будет ли хорошей практикой объединять и минимизировать все javascript-скрипты, необходимые для каждого типа страниц, в один файл (и делать то же самое для css)? например
    • На домашней странице есть только один homepage.js,
    • страниц списка есть только listing.js,
    • подробные страницы имеют только detail.js,
    • и т.д.
  2. Лучше ли объединять только те файлы, которые всегда используются вместе? например
    • jquery.js + jquery.cookie.js + common.js,
    • list.js + paging.js + favorite.js,
    • detail.js + favorite.js,
    • и т.д.
  3. Как насчет наличия одного файла для всех javascript-скриптов, которые должны загружаться в заголовке, и одного файла для всех javascript-скриптов, которые должны загружаться в конце тела, например,
    • init.js переходит к <head> и do.js переходит к <body>.
  4. Как насчет наличия одного файла для общих функций и одного для административных функций, который загружается, если у пользователя есть определенные разрешения?
  5. Существуют ли какие-либо стратегии для баланса между 1., 2., 3. и 4.?
  6. Какое рекомендуемое количество запросов javascript и css для страницы?

Я рассматриваю крупные сайты, например, порталы или социальные сети.

(Кстати, есть некоторые библиотеки, запросы которых я не могу контролировать, например, TinyMCE или google maps).

Ответы [ 11 ]

10 голосов
/ 03 ноября 2010

Обычно вы можете использовать следующий шаблон:

  1. main.js - объединить здесь все скрипты, которые используются несколькими страницами на сайте.
  2. page.js - все js, специфичные для данной страницы.Это будет означать объединение js всех виджетов на странице.

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

Вы можете использовать тот же принцип и для CSS.Это эффективно, но, как уже упоминалось в другом ответе, вы можете пойти дальше и связать все только за 1 js.Это предпочтение или стиль.Мне нравится разбивать его на 2, так как для меня это логично.

Убедитесь, что следующее:

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

РЕДАКТИРОВАТЬ: Я думал, что я буду обновлять ответ, чтобы ответитьнекоторые из ваших очков.

Пункт 2: лучше ли объединять только те файлы, которые всегда используются вместе?

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

Как только ваш JS объединен и минимизирован и находится в PROD, вы не ожидаете отладки или осмысления этого.Так что связывать воедино логически связанные файлы JS - спорный вопрос.Это в вашей среде DEV, где вы хотели бы объединить все эти логически связанные файлы кода.

Точка 3. Как насчет наличия одного файла для всех javascript, который должен загружаться в заголовке, и одного файла для всехjavascripts, который должен загружаться в конце тела?

Ответ: Есть определенные случаи, когда вы как-то вынуждены вводить JS в HEAD .В идеале не стоит этого делать, поскольку теги SCRIPT по своей природе блокируют.Поэтому, если вам действительно не нужно, разместите все свои JS (1 или несколько файлов) в конце тега BODY .

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

Ответ: Это кажется разумным подходом для разделения вашего кода JS.В зависимости от привилегий пользователя вы можете разветвлять свой код JS.

Пункт 6: Какое рекомендуемое количество запросов javascript и css для страницы?

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

3 голосов
/ 08 ноября 2010

Как и некоторые другие, поместите сценарии «Используется на более чем одной странице» вместе в main.js, а затем, если есть определенные для страницы: home.js, another_page.js и т. Д.

Единственное, что я действительно хотел добавить, это то, что для таких библиотек, как jQuery, вы должны использовать что-то вроде API библиотек Google .

  • Если ваш пользователь посетил другой сайт, который также использует серверы Google для библиотек, то он прибудет с заполненным кэшем! Победа!
  • Я собираюсь выйти из строя и поспорить, что серверы Google работают быстрее, чем ваши.
  • Поскольку запросы отправляются на разные серверы, клиенты могут одновременно обрабатывать два запроса к серверам Google (например, jQuery & jQuery UI), а также два запроса к вашим серверам (main.js & main.css)

Да, и наконец - не забудьте включить gzipping на вашем сервере!

2 голосов
/ 14 ноября 2010

Я думаю, что необходимо выполнить следующие оптимизации:

  • На стороне сервера:

    1. Использовать быстрый веб-сервер, такой как nginx или lighttpd, для обслуживания jsи css файлы, если они еще не используются.
    2. Включить кэширование и gziping для файлов.

  • И на стороне клиента:

    1. Поместите все распространенные js-файлы в уменьшенный и включите хардкорное кеширование.Если ваша страница не требует их запуска перед загрузкой, вы можете добавить ее на страницу динамически.Это ускорит загрузку.
    2. Поместите постраничный код в отдельные файлы, и если нет необходимости что-то делать.перед событием onload, добавьте его динамически.
    3. Если это вообще больше, чем несколько килобайт css, просто объедините его в один.В противном случае вы должны разделить его на общие и постраничные стили.
    4. Если вам нужна лучшая производительность на стороне клиента, поместите в общий CSS-файл действительно общие стили, которые применяются ко ВСЕМ страницам.Загружайте нужные правила только на страницу, это ускорит рендеринг.
    5. Самый простой способ минимизировать js и css - это использовать YUI Compress.Если вы хотите лучшего ускорения, вы можете удалить все уловки и другой «динамический» код и использовать Google Closure Compiler.

Если это не поможет, тогда все плохо и вам нужнобольше серверов для обслуживания файлов js и css.

2 голосов
/ 09 ноября 2010

В зависимости от среды разработки, вы можете подумать об автоматизации процесса. Это довольно много работы, но я обнаружил, что в конечном итоге это того стоило. То, как вы будете это делать, во многом зависит от вашего проекта и среды. Есть несколько вариантов, но я объясню (высокий уровень), что мы сделали.

В нашем случае у нас есть несколько сайтов на базе ASP.NET. Я написал элемент управления ASP.NET, который просто содержит список статических зависимостей - CSS и JavaScript. Каждая страница перечисляет то, что ей нужно. У нас есть несколько страниц с 7 или 8 зависимостями JS и 4 или 5 зависимостями CSS, в зависимости от того, какие разделяемые библиотеки / элементы управления используются. При первой загрузке страницы я создаю новый фоновый рабочий поток, который оценивает все статические ресурсы, объединяет их в один файл (1 для CSS, 1 для JS), а затем выполняет минификацию для них с помощью Yahoo Yui Компрессор (может делать как JS, так и CSS). Затем я вывожу файл в новый «объединенный» или «оптимизированный» каталог.

В следующий раз, когда кто-то загрузит эту страницу, элемент управления ASP.NET увидит оптимизированную версию ресурса и загрузит ее вместо списка из 10-12 других ресурсов.

Кроме того, он предназначен для загрузки только оптимизированных ресурсов, когда проект работает в режиме «RELEASE» (в отличие от режима DEBUG в Visual Studio). Это фантастика, потому что мы можем хранить разные классы, страницы, элементы управления и т. Д. Отдельно для организации (и для совместного использования между проектами), но мы все равно получаем преимущество оптимизированной загрузки. Это полностью прозрачный процесс, который не требует дополнительного внимания (если он работает). Мы даже вернулись и добавили условие, при котором неоптимизированные ресурсы загружались, если в строке запроса URL было указано «debug = true» для случаев, когда вам необходимо проверять / копировать ошибки в работе.

1 голос
/ 12 ноября 2010

Одна вещь, которую вы должны сделать, это оптимизировать ваш файл .htaccess для правильного сжатия и кэширования файлов: 

# compress text, html, javascript, css, xml:  
AddOutputFilterByType DEFLATE text/plain  
AddOutputFilterByType DEFLATE text/html  
AddOutputFilterByType DEFLATE text/xml  
AddOutputFilterByType DEFLATE text/css  
AddOutputFilterByType DEFLATE application/xml  
AddOutputFilterByType DEFLATE application/xhtml+xml  
AddOutputFilterByType DEFLATE application/rss+xml  
AddOutputFilterByType DEFLATE application/javascript  
AddOutputFilterByType DEFLATE application/x-javascript

# cache media files
<FilesMatch ".(flv|gif|jpg|jpeg|png|ico|swf|js|css|pdf)$">  
Header set Cache-Control "max-age=2592000"  
</FilesMatch>
1 голос
/ 12 ноября 2010

Я работаю над действительно большим проектом в той же области, который имеет много определений стилей и различные JS-скрипты для различных задач в проекте.На сайте были те же проблемы => слишком много запросов.По сути, мы реализовали исправление следующим образом:

  • Компонент рендеринга приложения запоминает каждый необходимый js-файл включения и складывает их вместе, минимизируя в конце процесса рендеринга.полученный результат кэшируется клиентами через заголовки кэширования, а таблицы стилей HTTP ETag !
  • зависят от друг друга.Существует огромная базовая таблица стилей, которая заботится об основном форматировании и объектах страницы (размер, плавающие элементы и т. Д.), Которая расширяется с помощью базовой цветовой схемы, которая может быть расширена с помощью настраиваемой таблицы стилей для разных клиентов, чтобы включить пользовательские цвета, компоновка, значки и т. д. .... Все эти таблицы стилей, собранные вместе, могут превышать, например, 300 КБ, потому что существует множество значков в качестве фоновых изображений ... каждый значок имеет два определения - одно в виде GIF для IE6 и изображение PNGдля всех остальных браузеров.

И здесь мы подошли к Проблемы .. Сначала таблицы стилей работали с правилами @ import .Мы написали скрипт-обертку, который проанализировал все стили и объединил их в один файл.В результате все версии IE нарушили макет, когда размер таблицы стилей превышает 250-270 КБ.форматирование выглядело как дерьмо.Таким образом, мы изменили это обратно, так что наша оболочка собирает только две таблицы стилей и записывает все остальные таблицы как правила @ import вверху.Кроме того, оболочка использует заголовки кэширования и ETag.

Это решило проблемы с загрузкой для нас.

С уважением

(Пожалуйста, не ругайте меня, потому что у нас естьтаблица стилей 300 000. Поверьте мне, это просто должно быть по разным причинам.: D)

1 голос
/ 11 ноября 2010

Предполагается, что на Apache, если нет, игнорировать ответ:)

Я сам еще не пробовал, но вы можете взглянуть на mod_pagespeed от Google.

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

1 голос
/ 11 ноября 2010

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

  1. Используете ли вы CDN для обслуживания своих ресурсов.Если вы это сделаете, вы можете получить больше запросов на страницу, чем в противном случае.Крупнейшим фактором снижения производительности при нескольких загрузках является задержка.CND снизит вашу задержку.

  2. Какие у вас целевые браузеры.Если ваша аудитория в основном использует браузеры IE8 +, FF3 и WebKit, которые позволят 6+ одновременных подключений к данному поддомену, вы можете получить больше CSS-файлов (но не JS).Более того, в случае современных браузеров вы на самом деле хотели бы избежать объединения всего CSS в один большой файл, потому что, хотя общее время, затрачиваемое на загрузку 1 большого файла, будет короче, чем время, потраченное на загрузку 6 небольших файловПри одинаковом суммированном размере вы можете одновременно загружать несколько файлов, и загрузка 6 меньших файлов будет завершена до загрузки одного большого файла (поскольку ваши пользователи не будут максимально использовать свою пропускную способность при одной только загрузке файла CSS).

  3. Сколько других ресурсов вы обслуживаете из того же домена.Изображения, Flash и т. Д. Будут учитываться при ограничении количества подключений браузера для каждого субдомена.Если возможно, вы хотите переместить их в отдельный поддомен.

  4. Вы в значительной степени полагаетесь на кэширование.Решение о том, как объединять файлы, всегда является компромиссом между количеством соединений и кэшированием.Если вы объединяете все файлы на одной странице и 90% этих файлов используются на других страницах, ваши пользователи будут вынуждены повторно загружать объединенный файл на каждой странице сайта из-за постоянно меняющихся последних 10%.

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

  6. Как часто вы обновляете свой сайт по истечении срока его службы.Если вы каждые несколько дней делаете патч, который изменяет файлы CSS / JS, вы демонстративно хотите избежать объединения всего в один файл, потому что это разрушит кеширование.

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

Также еще один комментарий, не связанный с вашим вопросом, но о чем-то, что вы упомянули.Избегайте добавления файлов Javascript в заголовок документа.Загрузка, синтаксический анализ и выполнение Javascript заблокирует все остальные активации в браузере (за исключением IE9, я полагаю), поэтому вы хотите, чтобы ваш CSS был включен как можно раньше на страницу, и вы хотите, чтобы ваши скрипты JavaScript были включены как можно раньшевозможно, прямо перед закрытием тега body, если это вообще возможно.

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

1 голос
/ 03 ноября 2010

Как всегда: это зависит. Чем больше файлы для конкретной страницы, тем больше смысла хранить их отдельно. Если они невелики (представьте, что они уменьшены на 10 КБ), возможно, имеет смысл объединить, минимизировать и сжать их, чтобы можно было сохранять некоторые запросы и полагаться на кэширование.

0 голосов
/ 03 ноября 2010

Минификация и объединение JS - только часть битвы. Размещение файлов является более важным. Навязчивый javascript должен быть последним загруженным элементом на странице, так как он остановит загрузку страницы, пока не завершит загрузку.

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

Существуют инструменты, которые могут проверить скорость загрузки страницы.

Сетевая панель в Firebug , а также Yslow - это удобные инструменты, которые можно использовать для отладки скорости загрузки страницы.

Удачи и счастливого JavaScript!

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

Похожие темы

...