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

Определение необходимости оптимизации

Прежде чем начать данную процедуру необходимо понять — нужно ли что-то менять? Для получения ответа на этот вопрос проверьте западающие стороны приложения. Например, проседает ли FPSна «средних» настройках и если да, то в каких ситуациях? В случае с сайтом можно рассматривать проблему скорости открытия вашего ресурса у других пользователей. Если промежуток прогрузки будет равняться секундам, то посетители будут более активны.

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

Профилирование

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

Одним из вариантов анализа является узкоспециализированный профайлинг. У метода достаточно много плюсов, тем не менее минусов тоже много. Из недостатков стоит отметить такие, как:

Замедление работы приложения;

Необходимость в задействовании отдельных утилит для просмотра результатов анализа;

Использование существенного объёма памяти для хранения данных профилирования.

За счет этого многие используют другой способ, а именно встраивание дебаг-панели в development-версии разработки. Как мы уже сказали, они встраиваются прямо в код, их функционал позволяет составлять сводку различных измерений с разъяснением деталей. Зачастую это анализ количества или времени исполнения SQL-запросов. Наряду с этим проверяется время отклика собственного приложения/сайта со сторонними сервисами, количество потребляемой памяти. В играх такая процедура является частым явлением.

В случае с веб-разработкой основное время тратится на связь с базой данных или коннект со сторонними сервисами. Если вы еще не встроили в код какой-либо фреймворк или дебаг-панель, то начните с чего-то подобного:

Разность показателей

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

Бывают и такие ситуации, когда с вашей стороны время отдачи с сервера безупречное, а пользователи жалуются на то, что страницы открываются долго. В таком случае попробуйте изменить размер передаваемого объёма информации и характеристики счетчиков производительности. Причин тут может быть несколько, одной из которых является необходимость установки CDNдля работы со статикой. С другой стороны, все может исходить от провайдера, и после его смены все заработает, как и должно было.

Прописывайте исключения только при необходимости

Часто можно проследить в коде такую тенденцию, когда webразработчик старается на одно действия прописать сотню возможных исключений, при этом не думая, что сервер просто рухнет. Советуем просмотреть и свой код на наличие подобных ненужных операций. Возможно, не все из них бесполезны, но они все равно нагружают сервер. В таком случае заверните их в if, чтобы данные исключения использовались только при необходимости.

Еще одним примером являются одинаковые фрагменты сайта. Например, headerи footerостаются практически неизменными при переходе на другую страницу. Что мешает нам поместить их в кэш или заранее сгенерировать, а не каждый раз прописывать все заново? Очевидно, что данный способ решения проблемы будет наиболее оптимальным и сможет сэкономить вам время.

Асинхронная пакетная обработка

Еще одной распространённой ошибкой webкодеров является обработка запросов по одному, несмотря на то, что общее их количество переходит за сотню. Почему бы не обрабатывать их все единым запросом? Если говорить о связи с базой данных в этом случае, то разницы в задержке практически не будет. Зачастую нужно провести небольшое количество изменений, чтобы добавить пакетную обработку, зато скорость отклика увеличиться в разы. То же относится и к другим запросам, ведь обращение куда-либо тоже требует времени, потому советуем уменьшать количество запросов до минимума.

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

Подведение итогов

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