15 простых советов по оптимизации производительности ASP.NET / Блог компании OTUS / Хабр

[ [ad_1]


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

Существует множество способов подойти к оптимизации производительности ASP.NET в веб-приложении, давайте рассмотрим пятнадцать из них.

1. Измеряйте все

Measure app peformance
Measure app peformance

Первое, что нужно сделать — это собрать базовые показатели производительности вашего приложения. Иногда вы вносите изменения в сайт, думая, что это улучшит производительность, но на самом деле это ее снизит. Хотя тюнинг производительности ASP.NET и не черная магия, но он может давать совсем неожиданные результаты. Измерение производительности должно быть комплексной работой по измерению производительности сервера, JavaScript и загрузки. Но не спешите браться за секундомер: есть отличные инструменты для измерения производительности, такие как Prefix.

Prefix позволит вам выделить медленные запросы, большие файлы JavaScript и многое другое. Измерения должны дать вам представление о том, оптимизация чего из этого списка может принести для вас больше всего пользы. Составьте себе список и отсортируйте его от наибольшего воздействия к наименьшему. Вы часто обнаруживаете, что элементы в нижней части списка недостаточно важны, чтобы о них беспокоиться, пока вы в начале оптимизации.

2. Сначала собирайте низко висящие фрукты

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

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

3. Подключите сжатие

Протокол HTTP не является особенно эффективным протоколом, и по умолчанию сжатие содержимого у него отсутствует. Некоторые веб-ресурсы уже сжаты, особенно изображения, но HTML, CSS и JavaScript обычно передаются в виде текста. Даже самые архаичные браузеры поддерживают сжатие HTTP-контента с помощью алгоритма gzip. Экономия от использования сжатия gzip для HTML-файла составляет около двух третей; другими словами, несжатый файл размером 100 КБ будет передаваться по сети весом в 33 КБ. Это потрясающая экономия!

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

4. Уменьшите количество HTTP-запросов

Каждый раз, когда браузеру требуется открыть соединение с сервером, необходимо “уплатить налог”. Этот налог представляет собой накладные расходы на подключение TCP/IP. Эта проблема особенно заметна в сценариях с высокой задержкой, когда для установления этих новых подключений требуется много времени. Добавьте к этому тот факт, что браузеры ограничивают количество запросов, которые они будут делать к одному серверу одновременно, и становится очевидным, что уменьшение количества HTTP-запросов — отличная оптимизация.

Кроме того: задержка и пропускная способность

При оптимизации загрузки веб-страницы важно понимать разницу между задержкой и пропускной способностью. Представим, что у вас есть двадцать ослов, которых нужно переместить из Банфа в Гранд-Каньон (две популярные ослиные местности). Чтобы перемещать ослов как можно быстрее, вам нужно оптимизировать две вещи: сколько ослов вы перемещаете одновременно и сколько времени нужно, чтобы переместить осла.

Пропускная способность — это то, сколько ослов вы можете перемещать одновременно — в сценариях с высокой пропускной способностью вы можете перемещать много ослов одновременно в своем тягаче для скота. В сценариях с низкой пропускной способностью вы можете разместить только одного осла на пассажирском сиденье вашего Honda Civic 2001 года, и этот осел настаивает на том, чтобы все время играли Destiny’s Child.

Задержка — это то, насколько быстро вы едете между Банфом и Гранд-Каньоном. Высокая задержка означает, что в пути будет много остановок, что замедляет время транспортировки. Перемещение осла с малой задержкой означает, что вы едете прямо всю ночь и вообще не останавливаетесь ни на одном из излюбленных ослами туристических объектов. В идеале вы хотите переместить как можно больше ослов за один раз и избегать остановок по пути.

Инструменты

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

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

Это подводит нас к HTTP 2.

5. HTTP/2 через SSL

Новая версия HTTP, HTTP/2, вводит ряд очень полезных оптимизаций. Во-первых, сжатие, о котором мы говорили в №3, было расширено, чтобы также охватить заголовки протокола. Что еще более интересно, соединение с сервером может передавать более одного файла за раз, используя механизм, известный как «конвейерная обработка». Это означает, что уменьшение количества HTTP-запросов за счет объединения файлов практически не требуется. Разница весьма впечатляющая.

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

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

SSL является частью этого совета, потому что все браузеры, поддерживающие HTTP2, требуют, чтобы он обслуживался через HTTPS.

6. Минимизируйте файлы

Сжатие — отличный инструмент для уменьшения объема данных, передаваемых по сети, а все алгоритмы сжатия, используемые для отправки HTML, CSS и JavaScript, являются алгоритмами сжатия без потерь. Это означает, что результат выполнения compress(x) => decopress(x) всегда равен x. Имея некоторое представление о том, что именно сжимается, мы можем получить дополнительный выигрыш в уменьшении размера. Например, JavaScript

function doSomething(){ 
    var size_of_something_to_do = 55; 
    for (var counter_of_stuff = 0; 
        counter_of_stuff < size_of_something_to_do; 
        counter_of_stuff++) { 
        size_of_something_to_do--; 
    } 
}

функционально эквивалентен

function doSomething(){var a=55;for(var b=0;b<a;b++){a--;}}

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

7. Сначала загружайте CSS

Сначала загружайте содержимое CSS вашего сайта, желательно в разделе заголовка страницы.

Чтобы понять мысль, заложенную здесь, вам нужно немного разобраться, как браузеры достигают своей невероятной скорости. При загрузке страницы браузер попытается начать рендеринг приложения, как только в нем появится какой-либо контент. Часто то, что он отображает, является чем-то вроде игры в догадки, потому что браузер не знает, какой контент на странице может опровергнуть сделанные им предположения. Когда браузер понимает, что он сделал неверное предположение о том, как должна отображаться страница, тогда всю проделанную работу нужно отменить и начать заново. Одна из причин, вызывающих такие перекомпоновки, — это добавление новой таблицы стилей. Сначала загрузите таблицы стилей, чтобы избежать изменения стиля уже отрисованного элемента.

8. Загружайте JavaScript последним

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

Давайте сделаем оговорку к этому правилу: если ваш сайт интенсивно использует JavaScript, например, такой как приложение Angular или React, то вы можете обнаружить, что загрузка JavaScript последней на самом деле принесет вред. Возможно, вам стоит подумать о загрузке только того JavaScript, который необходим для начальной загрузки приложения, и загрузки большего количества в фоновом режиме. Если скорость действительно важна, вы даже можете исследовать так называемые изоморфные или универсальные приложения. Страницы в этих приложениях отображаются на стороне сервера, а затем приложение JavaScript подключается к уже отрисованному HTML и перенимает его оттуда. Эти приложения имеют то преимущество, что они быстро загружаются, не отказываясь от бесшовной природы одностраничных приложений.

9. Сжатие изображений

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

ПРИМЕР ПРИВЕТЛИВОЙ ПАНЛЫ ИЗ TINYPNG
ПРИМЕР ПРИВЕТЛИВОЙ ПАНЛЫ ИЗ TINYPNG

 

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

10. Проверяйте свои запросы

ORM (инструменты объектно-реляционного отображения данных) очень полезны для повышения производительности труда разработчиков, однако они обеспечивают уровень абстракции, который может создавать неоптимальные запросы. Prefix будет выделять моменты, когда у вас может быть n + 1 select ошибки или слишком много данных с сервера. Удивительно, насколько легко решить эти проблемы, используя активную загрузку вместо отложенной загрузки и изучая прогнозы. У Microsoft есть несколько более подробных рекомендаций по оптимизации того, как EF (Entity Framework) вызывает SQL.

11. Кэшируйте свои страницы

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

Если вы используете кэширование ASP.NET MVC, ответ от действия будет таким же простым, как добавление одного атрибута к действию.

[HandleError] public class HomeController : Controller { 
    [OutputCache(Duration=10, VaryByParam="none")] 
    public ActionResult Index() { 
        return View(); 
    } 
}

Кэширование всей страницы может оказаться не совсем тем, что вам нужно, и в этом случае совет 12 для вас.

12. Кэшируйте части ваших страниц

Вы можете захотеть кэшировать только часть вашей страницы; в просторечии это называется кэшированием дырки от бублика. Это полезный подход, когда на одной странице смешаны пользовательские данные с общими данными. Пользовательские данные различаются в зависимости от пользователя, в то время как остальная часть страницы одинакова для всех пользователей. В приложениях MVC 5 это делается с использованием частичных представлений, а в MVC Core — с помощью помощников тегов кэширования.

РАЗДЕЛЫ, ВЫДЕЛЕННЫЕ ЗЕЛЁНЫМ, ЗАКЭШИРОВАННЫ ПОСТРАНИЧНО, И ОРАНЖЕВЫЕ КЭШИРУЮТСЯ  ПО ПОЛЬЗОВАТЕЛЯМ
РАЗДЕЛЫ, ВЫДЕЛЕННЫЕ ЗЕЛЁНЫМ, ЗАКЭШИРОВАННЫ ПОСТРАНИЧНО, И ОРАНЖЕВЫЕ КЭШИРУЮТСЯ  ПО ПОЛЬЗОВАТЕЛЯМ

13. Сеть доставки контента (CDN)

Скорость света составляет 300000 км/с, что довольно быстро; но, несмотря на эту высокую скорость, на самом деле это помогает хранить ваши данные ближе к потребителям. Существует множество сетей доставки контента, граничные узлы которых расположены очень близко к тому месту, где могут находиться ваши пользователи.

Content Delivery Networks
Content Delivery Networks

14. Уменьшайте свои библиотеки

Если вы используете такие библиотеки, как jQuery, учтите, что, возможно, вы не используете все функции и можете использовать меньшую, более специализированную библиотеку. Zeptojs — это библиотека, которая поддерживает многие функции jQuery, но меньше по размеру. Другие библиотеки, такие как jQuery UI, позволяют создавать персонализированные пакеты с удаляемыми функциями. Если вы используете Angular, то производственная сборка выполняет встряхивание дерева, чтобы удалить целые фрагменты библиотеки, которые не используются для вашего проекта. Это уменьшает полезную нагрузку, передаваемую по сети, сохраняя при этом все те же функции.

15. Избегайте переадресации на стороне клиента

Последний совет — избегайте перенаправления пользователей с помощью переадресации на стороне клиента. Перенаправления добавляют дополнительное отключение сервера, что в сетях с высокой задержкой, таких как сотовые сети, нежелательно. Вместо этого используйте переадресацию на стороне сервера — она не добавляет дополнительных отключений сервера. Одно из мест, где это не сработает, — это перенаправление пользователей на SSL-версию вашей страницы. Для этого сценария HTTP Strict Transport Security вашим билетом является список предварительной загрузки. Добавление вашего сайта в этот список предварительной загрузки автоматически направит трафик на SSL-версию вашего сайта.

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


Перевод статьи подготовлен в преддверии старта курса «C# ASP.NET Core разработчик»

[ad_2]

Перейти в источник

0

Автор публикации

не в сети 23 часа

admin

500
Комментарии: 4Публикации: 1454Регистрация: 12-02-2020

Похожие статьи

О классах Program и Startup — инициализация ASP.NET приложения. Часть II: IWebHostBuilder и Startup / Хабр

[ [ad_1] Введение Это — продолжение статьи, первая часть которой была опубликована ранее. В той части был рассмотрен процесс инициализации, общий для любого приложения .NET…

0

Инвентаризация ИТ-активов штатными средствами Windows с минимальными правами доступа

[ [ad_1] Коллеги, в предыдущей статье мы обсудили принципы эффективной работы с событиями аудита ОС Windows. Однако, для построения целостной системы управления ИБ важно не…

0

Цифровая трансформация офисной печати от зарождения до современных технологий

[ [ad_1] СодержаниеГлава №1. Краткая история зарождения офисной печати1.1. Пионеры1.2. ЭнтузиастыГлава №2. От CapEx к MPS и далее к DaaS2.1. Капитальные расходы (CapEx)2.2. Управляемые сервисы…

0

Ответы

Авторизация
*
*

Забыли пароль?

Регистрация
*
*
*
Генерация пароля