Ускорение работы веб-приложений

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

От старшего поколения программистов приходилось слышать, что в конце 90х даже Google (тогда еще совсем молодой), откликался с задержкой 5-7 секунд, что сейчас трудно представить. Но на уровень Google мы замахиваться пока не будем, а просто дадим несколько наиболее общих и простых советов для веб-разработчиков.

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

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

Клиентская оптимизация подразумевает уменьшение размеров картинок и скриптов. Даже на сайтах солидных организаций часто возникает нежелательный эффект, связанный с размером изображения. Например, на страницу нужно вывести изображение размером 150х200 пикселей, а по сети передается изображение в оригинальном разрешении 750х1000. В результате скорость отрисовки страницы значительно уменьшается. Чтобы не допустить этого, необходимо оптимизировать все изображения для работы с веб. Они должны храниться и передаваться по сети в том разрешении, в котором будут выводиться на сайте. Используйте форматы jpg и png, а для анимации – gif. Если у вас галерея с изображениями в фотографическом разрешении, не загружайте изображения на страницу сразу, используйте превью с качественными, но многократно уменьшенными миниатюрами. Загрузку в полном разрешении реализуйте с помощью ajax. Данный формат поможет в тех случаях, когда пользователь захочет просмотреть отдельную фотографию. Также целесообразно воспользоваться спрайтами, то есть объединить несколько маленьких картинок в одну большую. Это уменьшит количество запросов к серверу и сократит время загрузки страницы.

Скрипты нужно загружать в минимальной по объему версии. Большинство js-библиотек поставляются в двух версиях: для разработчиков (с оформленным по всем стандартом кодом и комментариями) и собственно для загрузки на сайт (в максимально сжатом по объему кода виде). Когда работа с фронтэндом уже завершена, всегда используйте только последний вариант. Свои собственные js-скрипты, особенно большие по объему, также обязательно сжимайте, но после того, как они полностью отлажены. Для этого существует множество инструментов. Например, YUI Compressor и Closure Compiler. Конечно же, не стоит подключать на сайт один и тот же скрипт по нескольку раз. Стандартные js-библиотеки лучше грузить с серверов Google (https://developers.google.com/speed/libraries/devguide?hl=ru-RU&csw=1), а для сайтов, ориентированных на Россию, с серверов Яндекса (http://api.yandex.ru/jslibs/libs.xml). Эти серверы используют тысячи сайтов по всему миру и велика вероятность того, что библиотека оттуда уже присутствует в кэше посетителя вашего сайта, то есть загрузка произойдет едва ли не мгновенно. Если используемой вами библиотеки на серверах Google и Яндекс нет, скопируйте ее к себе на сайт и загружайте с собственного сервера, но не полагайтесь на сторонние малоизвестные источники. В случае их отказа вы получите полную или частичную неработоспособность сайта. Если ваш клиентский скрипт слишком долго выполняется, профилируйте и оптимизируйте его сразу же в процессе разработки, иначе впоследствии вы рискуете потратить на это куда больше времени, нервов да и денег тоже.

Стили СSS всегда располагайте в заголовке (секции head) страницы, большинство браузеров прорисуют страницу быстрее именно в этом случае. Согласно исследованиям сотрудника Yahoo Стива Соудерса, js-скрипты желательно размещать в конце страницы, что позволяет браузеру рендерить страницу постепенно, распараллеливая нагрузку.

Также рекомендуется пользоваться средствами для настройки сжатия, предусмотренными в протоколе HTTP. Сжатие сокращает время загрузки HTTP-ответа, уменьшая его объем. Алгоритм Content-Encoding: gzip сжимает размер ответа на 70%. Он будет эффективен в тех случаях, когда клиент разрешает сжатие.

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

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

Изначально определитесь с оптимальной технологией разработки на всех уровнях, например, для стэка LAMP при нагрузке выше 50000 посещений в сутки использовать стандартные CMS, типа Joomla, DLE, Wordepress нецелесообразно. Вероятно, вам потребуется уникальное решение на основе надежного MVC-фреймворка, например, Zend или Yii.

Максимально используйте кэширование на стороне сервера. Кэшируйте статические шаблоны и блоки страниц, результаты ресурсоемких запросов к БД, при необходимости – целые страницы, но учитывайте специфику бизнес-логики вашего приложения. Результаты работы модулей, которые должны функционировать в реальном времени, кэшироваться не должны.

Отдельный вопрос – работа с БД. Детально изучите бизнес-логику проектируемого приложения и определитесь, какая модель данных вам нужна, реляционная или нереляционная. В связи с бумом развития нереляционных БД их использование не во всех случаях оказывается целесообразным. Далее выберите оптимальную базу данных и приступайте к проектированию. При работе с реляционными БД особое внимание уделите индексам, профилируйте ваши SQL-запросы. С помощью EXPLAIN разберите по косточкам механизм работы всех ваших запросов, выберите оптимальные комбинации индексов, в том числе, составных. В отдельных случаях вам может потребоваться денормализация базы до 2НФ, но увлекаться этим не стоит. Если вы видите, что базу нужно денормализовать, то, скорее всего, либо вы изначально ее неправильно спроектировали, либо вам следует задуматься об использовании нереляционной БД. Не следует повторять один и тот же запрос несколько раз подряд без необходимости и выбирать из таблицы все столбцы, если вам нужен всего один.

 Профилируйте ваши серверные скрипты и находите узкие места. При работе с большими объемами данных не забывайте о вычислительной сложности алгоритмов, а также использовании оптимальных структур данных. Загляните на сайт местечковой конторы «Рога и копыта», затем – на портал национального масштаба типа prom.ua, а потом – на Amzon. Представьте, с какими объемами данных приходится работать каждому их них и сколько людей заходят на такие сайты ежедневно. При работе с сайтом-визиткой той самой конторы «Рога и копыта», где число записей в БД не превышает пару тысяч, а посетителей у него аж 25 в сутки, вы теоретически можете использовать какой угодно алгоритм сортировки и хранить все данные только в массивах (хоть всю БД в массив записать, если ОП сервера позволяет). Разница в скорости работы между наилучшим и наихудшим вариантом составит доли секунды. И заказчик, и пользователи будут довольны. А это очень опасно: если со временем «Рога и копыта» разрастется до уровня prom.ua (а то и до Amazon, лет через 250), вам просто придется переписывать все с нуля. Неэффективные решения для небольшого сайта выльются в его неработоспособность при попытке масштабирования.

Делайте нагрузочное тестирование веб-приложения в комплексе и профилируйте отдельные модули еще на этапе разработки, перед сдачей проекта. Оптимальная оптимизация бэкэнда – это та, которой удалось избежать. Или хотя бы свести к минимуму. Иначе вы рискуете потерять очень много времени, а клиент – денег.

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

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



Комментарии

Комментарии (0)

Ваш e-mail не будет опубликован.
Обязательные поля помечены *

ПОСЛЕДНИЕ КОММЕНТАРИИ

  • Эстония
    Tien
    : Is that really all there is to it because that'd be flaibergastbng.
  • Полезные советы новичкам WordPress
    Роман
    : В строке с "else if" в примере (на картинке) вроде не хватает одной закрывающей кавычки. И
  • Gekos красно-золотой
    Админ Блогович
    : ИЛИ выступлениями на внешних семинарах/конференциях
  • Gekos в Стамбуле: мы работаем там, где лето
    Денис
    : Очень крутая статья!
  • Как увернуться от гранаты или «Яндекс АГС – уберется все!»
    Рустем
    : Спасибо за кейс. На счёт хостингов - полностью согласен. Некоторые сайты расположены на ка
  •