ASP.NET MVC 4

ASP.NET MVC 4

Адам Фриман

Управление скриптами и таблицами стилей

Представление, которое мы создали в листинге 24-3, является типичным для реальных проектов MVC. Оно содержит набор библиотек из папки Scripts, таблицы стилей CSS из папки Content, локальные элементы script и, конечно, разметку HTML и Razor.

Разработчики обычно пишут файлы представлений так же, как бы они писали страницы HTML; это нормальный подход, но не самый эффективный. Как мы покажем вам в следующих разделах, в представлении MakeBooking.cshtml есть скрытые проблемы. Можно сделать ряд улучшений относительно того, как мы управляем скриптами и таблицами стилей.

Измеряем время загрузки скриптов и таблиц стилей

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

Для проблем, которые мы рассмотрим в этой главе, мы будем выполнять измерения с помощью утилит F12 из Internet Explorer 10 (называемых так потому, что к ним можно получить доступ, нажав клавишу F12). Загрузите приложение, перейдите по ссылке /Home/MakeBooking и нажмите клавишу F12. Когда откроется окно утилит, перейдите на вкладку Network и нажмите кнопку Start Capturing. Обновите содержимое вкладки браузера (щелкните правой кнопкой мыши в окне браузера и выберите Refresh), и вы увидите результаты, показанные на рисунке 24-2.

Рисунок 24-2: Измеряем время загрузки скриптов и таблиц стилей для примера приложения

Утилиты F12 в IE10 позволяют измерять производительность для сетевых запросов, которые отправляет ваше приложение. (Если вы не используете Internet Explorer, можно найти и другие инструменты. Наш любимый - Fiddler, который вы можете скачать бесплатно с www.fiddler2.com.)

Чтобы сравнивать результаты оптимизации, которую мы проведем в этой главе, мы будем использовать данные, приведенные на рисунке 24-2, как отправную точку. Вот ключевые цифры:

  • Браузер сделал 9 запросов по ссылке /Home/MakeBooking
  • Было отправлено 2 запроса к файлам CSS.
  • Было отправлено 6 запросов к файлам JavaScript.
  • В общей сложности 2,978 байт было отправлены от браузера к серверу.
  • В общей сложности 470,417 байт было отправлено от сервера к браузеру.

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

Если мы перезагрузим страницу /Home/MakeBooking без очистки кэша, то мы получим следующие результаты:

  • Браузер сделал 9 запросов по ссылке /Home/MakeBooking
  • Было отправлено 2 запроса к файлам CSS.
  • Было отправлено 6 запросов к файлам JavaScript.
  • В общей сложности 2,722 байт было отправлены от браузера к серверу.
  • В общей сложности 6,302 байт было отправлено от сервера к браузеру.

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

Примечание

В реальном проекте мы бы остановились и начали разбираться, есть ли здесь проблема, которую можно оптимизировать. Может показаться, что 470K – слишком много пропускной способности для простой веб-страницы, но все зависит от условий. Мы могли бы разрабатывать приложение для Интранет, где канал дешевый и широкий, и любая оптимизаций будет неоправданна из-за стоимости труда разработчика, который мог бы работать над более важным проектом. Равным образом, мы могли бы быть писать приложение, которое работает через интернет с важными для нас клиентами, у которых низкая скорость соединения; в этом случае стоит потратить время на оптимизацию каждого аспекта приложения. Важно то, что вы не должны автоматически оптимизировать в приложении все, что можно – чаще всего вы сможете найти себе более полезное занятие. (Особенно если вы украдкой проводите оптимизацию приложения, никому ничего не сказав. Скрытая оптимизация - это плохая идея, и конечном счете она только навредит вашей работе.)

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

Второй проблемой является то, что мы загружаем и минимизированные, и обычные версии библиотек jQuery. Так происходит потому, что макет тоже загружает файлы JavaScript и CSS, и из-за отсутствия координации браузеру приходится загружать код, который у него уже есть.

Эти проблемы встречаются довольно часто. Далее мы рассмотрим функции MVC Framework, с помощью которых можно контролировать файлы скриптов и CSS. Мы также покажем вам, как сократить количество запросов, которое браузер должен отправить к серверу, и объем данных, который он должен загрузить.

или RSS канал: Что новенького на smarly.net