Ускорение загрузки сайта: от браузера до сервера

Статья написана в рамках статейного конкурса Serpstat и SEOnews.

Условия конкурса

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

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

Итак, нашей целью является передать контент страницы от сервера клиенту (браузеру, поисковой системе или даже парсеру) с наибольшей скоростью. Для этого нужно ответить на 4 вопроса, каждый из которых определяет отдельную сторону процесса загрузки страницы:

1. Где находится сервер (или сервера) с которых загружается контент? Здесь подразумеваем географическое расстояние между сервером и клиентом.
2. Какой контент передает сайт? HTML-код, изображения, CSS, JavaScript и прочее. Это так называемый Front-end сайта.
3. Как идет передача контента страницы? Существует ряд распространенных методов ускорения передачи контента в сети Интернет, их мы также непременно рассмотрим.
4. Каким способом этот контент генерируется? Время статичных сайтов, работающих на одних лишь HTML и CSS практически ушло. На современном сайте используется гораздо больше технологий - это, по крайней мере, базы данных и серверные языки программирования, такие как PHP и ASP. Эту область сайта называют Back-end’ом.

Рассмотрим вкратце, как можно улучшить производительность по каждому из этих процессов.

Удаленность сервера от клиента

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

Географическая удаленность

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

Помимо непосредственно расстояния, на ping влияет загруженность канала передачи данных и ее маршрут.

DNS

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

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

К счастью, описанные выше «детские» проблемы Интернета сейчас стоят не так остро, как раньше. Если DNS-сервера работают нормально, процесс обращения и подключения к серверам редко занимает более 1-2% времени полной загрузки страницы.

Контент страницы

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

Изображения

Самой распространенной, явной и легко устраняемой ошибкой является использование изображений большого объема. Самые распространенные случаи:

• Изображение имеет очень большой размер (в пикселях). На странице оно масштабируется при помощи CSS-стилей, но файл все равно загружается браузером полностью.
• Нерационально используется формат изображения. Например, объем изображения в формате PNG-24 в несколько раз больше, чем в JPEG.
• Разрешение изображения значительно больше, чем требуется. Большинство современных мониторов одинаково отображают изображения разрешением выше 96 dpi (120 dpi на передовых моделях). На сайты же порой попадают файлы разрешения 300 dpi - макеты для печати и более, например, необработанные фото с цифрой камеры.

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

Узнать объем уже размещенных изображений не сложно. Если их количество невелико, и вы знаете где они расположены, достаточно подключиться к серверу по FTP и посмотреть статистику файлов. Если же изображений много, и все они находятся в разных папках, используйте программное обеспечение. При помощи бесплатной Xenu Link Sleuth можно просканировать сайт и собрать статистику с адресами, форматами и объемом изображений. Отобрать «тяжелые» изображения легко при помощи отчета Xenu, а скачать «оптом» можно, к примеру, утилитой wget.

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

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

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

Стили и программный код

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

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

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

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

На помощь приходит технология по оптимизации размера и количества файлов JavaScript и CSS, получившая обобщенное название “Minify” (минификация). По этому названию вы сможете найти множество онлайн-сервисов, способных автоматически сжимать и объединять js- и css-файлы для обеспечения наилучшей производительности.

К сожалению, разработчики подобных сервисов не несут ответственности за результаты их работы. Так что не забудьте сделать резервную копию всех изменяемых файлов перед экспериментами!

Оптимизация передачи контента

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

Компрессия текстовых данных

Широко распространенный метод, регламентированный в стандарте HTTP1.1, и поддерживаемый фактически всеми серверами и клиентами. Как правило, используется алгоритм сжатия Gzip, являющийся стандартными для всех Unix-систем.

Браузер обращается к серверу со списком поддерживаемых технологий сжатия (запросом Accept-Encoding), сервер возвращает заголовок Content-Encoding: gzip, что означает что контент страницы будет передан в сжатом gzip архиве. Сам метод сжатия близок с стандартным Zip-архивам.

Технология подходит для сжатия только текстовой информации (HTML, CSS, программного кода), но малополезна для передачи изображений и файлов сложных форматов.

Gzip-сжатие широко распространено и по умолчанию работает на большинстве сайтов. Проверить, отдает ли ваш сайт контент в сжатом таким образом виде можно практически любым из инструментов, проверяющих ответ сервера, например, «Проверка ответа сервера» в Яндекс.Вебмастере. Если сжатие включено, в отчете вы увидите вышеупомянутый Content-Encoding: gzip.

Если все же компрессия не работает, в большинстве случаев вы сможете самостоятельно активировать ее при помощи файла .htaccess. Для этого нужно добавить в него инструкции AddOutputFilterByType DEFLATE с типами данных, которые нужно сжимать. Например, для HTML, CSS и JavaScript инструкции будут выглядеть следующим образом:

AddOutputFilterByType DEFLATE text/html

AddOutputFilterByType DEFLATE text/css

AddOutputFilterByType DEFLATE application/javascript

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

Браузерное кэширование

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

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

Главные из них:

● Expires – содержит дату и время (по Гринвичу), до достижения которой контент можно считать контент актуальным. Например, Expires: Fri, 13 Oct 2017 13:59:58 GMT означает что браузер может использовать кэш страницы, не запрашивая ее у сервера, до пятницы 13-го октября 2017 года.

● Cache-Control – позволяет задавать время актуальности кэша в секундах, относительно времени запроса, а также ограничивать кэширование, например, на публичных proxy-серверах или непосредственно в браузерах. Также кэширование можно и вовсе запретить.

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

● Last-Modified – хранит время последнего изменения страницы. Клиент сохранит дату и при следующем посещении добавит запрос If-Modified-Since, содержащий сохраненное значение. Если страница с этого времени не изменилась, сервер возвращает ответ 304 Not Modified, то есть страница не изменилась, и ее еще можно загружать из кэша.

● Etag можно считать гораздо более удобным, чем предыдущий вариант. Данный заголовок проводит валидацию кэша не по времени, а на основе произвольного алгоритма. При каждом обращении сервер должен генерировать Etag на основе заданного ему алгоритма, от которого и зависит правильность обработки.
Например, на странице интернет-магазина размещено 10 товаров, алгоритм может объединить артикулы этих товаров в единую строку, рассчитывать ее хэш-сумму и выводить эти данные в Etag. Таким образом, пока на странице находятся именно эти 10 товаров, заголовок всегда будет иметь одно и то же содержимое и страница будет загружаться из кэша.
Недостатком Etag, вернее, алгоритма его генерации, можно считать вероятность коллизии – ситуации, когда на основе разного контента получается одинаковая строка. Устойчивость к коллизиям нужно предусмотреть на стадии проектирования алгоритма генерации значений.

Проверки актуальности кэша можно упрощенно описать так:

• Браузер проверяет, разрешено ли ему кэширование в Cache-Control.
• Если оно разрешено, и страница уже есть в кэше, проверяется достигнута ли дата, указанная в заголовке Expires. Если дата не достигнута, можно взять страницу из кэша.
• Если дата достигнута, нужно обратиться к заголовку валидации, например, Etag. Если сохраненный Etag и значение с сервера совпадают, страница не изменилась, можно взять контент из кэша. Если заголовки различаются или отсутствуют, страницу нужно запросить контент с сервера.

При отсутствии всех заголовков, страница не будет кэшироваться вовсе.

Возможностей настройки отдачи описанных выше заголовков три:

1. Генерировать на стадии создания страницы при помощи php или другого серверного языка программирования.
2. Настроить отдачу сервером при помощи файла .htaccess.
3. Скорректировать данные непосредственно на сервере.

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

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

HTML-кэш на жестком диске

Еще одним вариантом является размещение на жестком диске HTML-кэша динамических страниц. При первом обращении к странице, сервер генерирует ее, включая все запросы к базе данных, исполнение php-кода и другие действия на сервере. Копия страницы сохраняется на жестком диске и выдается клиентам при последующих обращениях (от любого посетителя).

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

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

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

Асинхронная загрузка JavaScript

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

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

Рассмотрим природу и отличия свойств на примерах. Допустим, у нас есть два файла JavaScript, «1.js» и «2.js». Добавим для них атрибут async:

[script async src="1.js"][/script]

[script async src="2.js"][/script]

Этим мы скажем браузеру, что файлы могут быть загружены параллельно с остальным контентом страницы и в произвольном порядке. То есть, второй файл может быть обработан раньше первого. Такая конструкция не подойдет если «2.js» использует результаты работы «1.js». Именно в этом случае вместо async используется атрибут defer – он указывает браузеру, что файлы могут быть обработаны параллельно остальному контенту страницы, но должны быть загружены в той последовательности, в которой размещены в исходном коде.

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

Параллельная загрузка статичных файлов и CDN-технология

Как упоминалось выше, стандарт HTTP1.1, применяемый повсеместно, предполагает параллельную загрузку строго ограниченного количества файлов с одного домена, то есть не дает полной параллельности.

Наиболее прямолинейный способ улучшить ситуацию – перенести часть контента на другой домен. В теории современные браузеры способны параллельно обрабатывать до 5-6 файлов с хоста. То есть, в качестве экстремального решения можно расположить каждые 5 файлов на отдельном домене. На практике, конечно, так поступают редко. Чаще всего, как самые «тяжеловесные» составляющие, переносят изображения и видео – к примеру, создают поддомен (для site.ru он может иметь название img.site.ru или любое другое), с него и происходит загрузка файлов.

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

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

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

Выбирая провайдера услуг CDN следует руководствоваться двумя факторами – заявленным расположением и количеством серверов…, а также отзывами клиентов. Не все CDN-провайдеры одинаково надежны!

HTTP/2

HTTP/2 – новый протокол передачи данных, представленный общественности в 2014, и утвержденный 2015 году. По сравнению с HTTP1.1 для нас он имеет одно заметное преимущество – он не создает отдельно соединение для загрузки каждого файла, а загружает все их параллельно, одним потоком. Благодаря этому, нет необходимости в создании CSS-спрайтов, минификации JavaScript и переносе изображений на другие домены.

Кроме того, обмен заголовками здесь происходит в сжатом виде, а сервер, поддерживающий HTTP/2, может отправлять данные, которые еще не были запрошены клиентом, например, изображения из тела страницы еще до того, как полностью обработаны CSS-стили и JavaScript из раздела head. Вместе эти методы способны значительно ускорить загрузку Front-end составляющей страницы.

Проверить, поддерживает ли сайт HTTP/2 можно при помощи сервиса от KeyCDN. Если же вы хотите проверить поддержку протокола вашим браузером и наглядно оценить ускорение загрузки контентом, воспользуйтесь demo от Akami.

Но у HTTP/2 есть также и недостатки:

• На данный момент поддержка осуществляется только поверх TLS. Это означает, что вы не сможете использовать преимущества протокола, если на сайте не установлен SSL-сертификат, и страницы не загружаются через HTTPS.
• Внедрение подразумевает серьезные изменения на сервере. К сожалению, не все конфигурации поддерживают необходимые технологии, может понадобится обновление ОС и другого программного обеспечения сервера. Соответственно, на виртуальном хостинге подобные изменения сделать вряд ли удастся.

На начало 2017 года около 12% сайтов по всему миру поддерживают HTTP/2 и, учитывая все преимущества, в ближайшие годы можно ожидать значительный рост этого показателя.

Как генерируется контент

В данном пункте мы рассмотрим, пожалуй, самые критичные вопросы производительности сайтов – работу сервера, так называемый Back-end. Использование недостаточно производительного программного обеспечения и неправильные настройки могут очень негативно влиять на такой параметр, как время ответа сервера.

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

Поисковые системы также достаточно чувствительны ко времени ответа сервера и при достижении определенных значений страница считается неработоспособной. Яндекс.Метрика, например, рассылает уведомления о неработоспособности сайта, если не может получить ответ сервера в течение 10 секунд. Такие страницы не будут проиндексированы, а если они уже были в индексе, растет вероятность их выпадения.

Рассмотрим три важных момента, которые помогут увеличить скорость сервера.

Установленный сервер и его настройки

Apache и Nginx – два наиболее распространенных web-сервера, каждый со своей спецификой. Apache получил популярность благодаря производительности при обработке динамического контента, но в высоконагруженных системах он не всегда может обеспечить оперативную работу.

Nginx же способен обрабатывать только статичный контент, а динамический – отдавать другим обработчикам, например, тому же Apache. Тем не менее, Nginx может параллельно обрабатывать большое количество запросов. На самом деле, Apache также способен параллельно обрабатывать обращения, но его масштабируемость меньше. Это связано с различиями в механизме так называемых работников (воркеров), каждый из которых и обрабатывает обращения.

В наиболее распространенной сейчас архитектуре, Nginx + Apache, первый используется для сортировки запросов и передачи, второй - только тех из них, которые не способны обработать воркеры Nginx.

Если в конфигурации сервера все же нет Nginx, его следует непременно подключить.

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

Режим работы PHP

CGI – спецификация обработки прикладных программ сервером. Она определяет, как в программу передаются данные из HTTP-запроса, а также способ отдачи результата. Скрипты CGI могут быть написаны на любом языке, понятном серверу, например, распространенным PHP.

• PHP в режиме CGI – является старым методом, установленным по умолчанию на многих серверах. Это наименее производительный режим, и, если ваш сервер работает именно так, обязательно нужно перейти к другому.
• mod_php – модуль Apache, который позволяет ему обрабатывать PHP-код. Этот режим производительнее предыдущего, но он достаточно ресурсоемкий в плане оперативной памяти и в большинстве случаев уступает описанному далее режиму PHP-FPM.
• PHP в режиме FastCGI (PHP-FPM) – более продвинутая архитектура, рассчитанная на высоконагруженные сайты. В этом режиме веб-сервер Apache не участвует в обработке PHP-кода и фактически полностью исчезает из процесса выполнения скриптов сайта. Мы устраняем посредника Apache между Nginx и PHP. PHP-FPM по умолчанию включен в дистрибутивы начиная с PHP 5.3.

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

PHP имеет огромное количество настроек, которые следует привести в соответствие с рекомендациями технической поддержки CMS сайта.

Базы данных

Львиную долю длинного ответа сервера, как правило, составляют именно запросы к базам данных. За редким исключением, на современных серверах используются реляционные БД SQL, а самой распространенной является система управления базами данных MySQL.

В работе базы данных можно выделить два важных параметра – скорость обработки запросов, количество и время блокировок (т.н. «локов»). Если происходит длительная блокировка, БД не может обрабатывать другие запросы, до завершения блокирующего, и может образоваться большая очередь.

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

1) Для таблицы неправильно выбрана система хранения данных (движок). Самые распространенные из них – MyISAM и InnoDB.
MyISAM хорошо обрабатывает запросы на выборку данных (SELECT) и подходит для таблиц, из которых осуществляются поиск, но не включаются новые записи. Попытка включить новые данные в такую таблицу наверняка вызовет долгую блокировку БД.
InnoDB гораздо лучше обрабатывает запросы на добавление данных, благодаря чему является стандартом для реализаций баз данных на сайтах. Тем не менее, если важен быстрый полнотекстовый поиск по таблице, стоит обратить внимание на MyISAM.

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

3) Установлена стандартная СУБД MySQL. Если 10-15 лет назад стандартной сборки MySQL было достаточно даже для самых нагруженных сайтов, применяя стандартные решения сейчас, вы значительно теряете в производительности. Улучшить этот показатель может установка форков MariaDB или Percona Server. По сравнению с продукцией Oracle, эти решения более производительны и надежны, а Percona Server уже стал негласным стандартом для замещения стандартной MySQL.

4) Если после решения предыдущих 3-х задач, не удалось достигнуть повышения производительности, следует проверить настройки MySQL. Здесь, как и в предыдущих пунктах, я рекомендую обратиться к документации CMS. Но нужно иметь в виду, что главным образом, проблемы встречаются в следующих узких местах:

a) количество допустимых одновременных подключений (max_connections);

b) объем кэша запросов и его эффективность;

c) недостаток памяти на сервере (в процессе работы БД может занимать огромный объем физической памяти сервера);

d) большое количество временных таблиц, которые были созданы на жестком диске.

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

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

Вместо послесловия

Три дополнительных метода оптимизации скорости для перфекционистов:

1. data: URL - технология, которая позволяет встраивать файлы прямо в исходный код страницы, при этом для загрузки этих файлов браузеру не требуется создавать дополнительные подключения. При этом нужно указать тип файла, а также бинарный код файла, перекодированный в base_64.

2. Google AMP - ускоренные мобильные страницы, которые Google кэширует и отображает в некоторых собственных сервисах.

3. Varnish способен кэшировать запросы на сервере и работать как дополнительный маршрутизатор запросов. Он применяется на высоконагруженных контентных проектах, таких как Википедия и Facebook.