Клиентская оптимизация популярных проектов Рунета 1

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

vkontakte.ru

В Контакте ( http://vkontakte.ru/ ) является на данный момент (по числу просмотров страниц) наиболее посещаемым сайтом. Диаграмма загрузки внутренней страницы профиля выглядит примерно следующим образом:

SpeedUpYourWebsite.v1.2_img_55

Рис. 55. Результаты анализа загрузки внутренней страницы сайта vkontakte.ru

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

Двигаемся дальше: gzip. Для всех текстовых файлов (HTML, CSS, JavaScript) он включен. Это не может не радовать. Однако никакой минимизации для них не производилось. С точки зрения производительности это минорная оплошность: при самой лучшей минимизации выиграть больше 5% от уже имеющегося сжатия крайне сложно. Для пользователей же это отразится в 10-50 мс загрузки.

Объединение файлов. После применения сжатия CSS- и JavaScript-файлы стали занимать 2-5 Кб в размере, поэтому загружать их по отдельности особого смысла не имеет. Объединение наиболее используемых стилевых правил в основной файл (пусть даже размером в 15-20 Кб) позволило бы сократить время загрузки на 100 мс (в данном случае). Стоит также отметить, что для пользователей IE загружается дополнительный файл стилей (крайне маленький в размере), который, естественно, можно было бы включить в основной.

Пост-загрузка для JavaScript-компонентов. На странице уже используются данные методы: в частности, рекламные баннеры загружаются как раз через динамическое создание изображений в заранее определенных блоках шаблона страницы. Однако вынесение всей клиентской логики в загрузку по комбинированному событию window.onload позволило бы отрисовать страницу на экране на 300 мс быстрее (в данном случае это 40% от стадии предзагрузки). Хотя, возможно, это потребовало бы достаточно существенной переработки текущего функционирования отдельных частей портала.

Кэширование. На данный момент с этим все замечательно: выставляется как max-age для статических файлов, так и Last-Modified. Предполагается, что большинство пользователей заходят на vkontakte.ru постоянно, поэтому большая часть файлов берется браузером сразу из кэша. Именно поэтому наличие стилей и скриптов внутри HTML-файла сведено к минимуму: это позволяет уменьшить объем последнего при наличии в кэше всех необходимых файлов. Также стоит отметить, что в качестве внешнего сервера используется nginx.

 

SpeedUpYourWebsite.v1.2_img_56

Рис. 56. Заголовки ответа для статического файла с vkontakte.ru

 

На странице присутствует некоторое количество (5-10) небольших фоновых картинок, которые могли бы быть успешно объединены в CSS Sprites или даже добавлены в соответствующий CSS-файл. Однако данное действие не сильно спасло бы ситуацию: основная нагрузка приходится на пользовательские картинки. А почти все они расположены на различных хостах (на диаграмме загрузки присутствует несколько десятков хостов). Это хорошо для уменьшения времени ожидания ответа, но плохо с точки зрения DNS Lookup. В качестве дополнительного минуса можно назвать то, что средний размер картинки – 2 Кб.

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

В качестве возможного решения данной проблемы стоит рассматривать создание Image Map (или CSS Sprites) с наиболее часто используемыми изображениями для данной страницы. Для страницы пользователя – это список написавших на стене: он меняется относительно редко, а объединение иконок пользователей в группы по 5-7 (размер итогового файла 10-15 Кб) позволит несколько сократить время загрузки страницы. В общем случае (рассматривая параллельные загрузки) это будет DNS Lookup + время соединения. Хотя vkontakte.ru уже и так использует своего рода CDN (время соединения сведено к минимуму), но выигрыш все равно составит порядка 200-300 мс даже для широкополосного доступа.

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

odnoklassniki.ru

 

SpeedUpYourWebsite.v1.2_img_57

Рис. 57. Результаты анализа загрузки внутренней страницы сайта odnoklassniki.ru

 

Давайте рассмотрим прямого конкурента vkontakte.ru – odnoklassniki.ru. Для этого сайта ситуация, очевидно, еще хуже. Во-первых, значительная часть декоративных картинок не внесена в число фоновых изображений, что заставляет IE старых версий опрашивать их в обычном порядке. Во-вторых, рекламные баннеры не вынесены в пост-загрузку и сильно мешаются в общем процессе отображения страницы (часть страницы с баннером «зависает» в ожидании ответа рекламного сервера). Обилие счетчиков статистики только усугубляет ситуацию.

Как с этим можно бороться? Естественно, что все файлы скриптов можно и нужно объединить в один, и его вынести в пост-загрузку. Фоновые картинки достаточно объединить в 2-3 файла, что позволит загружать иконки других пользователей (а именно они составляют наиболее значительную часть) быстрее.

 

SpeedUpYourWebsite.v1.2_img_58

Рис. 58. Результаты ответа для статического файла с odnoklassniki.ru

 

В остальном почти все меры уже приняты: текстовые файлы отдаются сжатыми, для статики устанавливается срок кэширования в далекое будущее. Однако, как видно из рис. 58, с кэшированием произошел небольшой перебор: наличие и ETag, и Last-Modified заголовка является избыточным. Для корректной проверки файла на существование новой версии достаточно только одного из них.

Естественно, что для odnoklassniki.ru проблема распределения различных изображений по нескольким хостам так же актуальна, как и для vkontakte.ru. И на данный момент она решается точно так же. Поскольку статические блоки с большим количеством изображений на странице практически отсутствуют, то более корректное решение указанной проблемы может и не существовать.

yandex.ru

Давайте вслед за самыми популярными социальными сетями рассмотрим наиболее посещаемые поисковые и почтовые порталы Рунета. Начнем с Яндекса.

 

SpeedUpYourWebsite.v1.2_img_59

Рис. 59. Результаты анализа загрузки главной страницы www.yandex.ru

 

Как можно видеть, эта страница уже сильно оптимизирована. При всем объеме информации и внутренней логики используется всего 19 запросов к серверу, общий объем передаваемых данных 49 Кб. В качестве характерного шага оптимизации часто посещаемых главных страниц таких порталов можно назвать то, что CSS-файл внесен внутрь HTML и вся JavaScript-логика располагается там же (не учитывая, конечно, какие-то непостоянные явления, вроде блока авторизации или сезонной рекламы).

Естественно, что для текстовых файлов применяется сжатие, причем даже сам HTML-код минимизирован почти по максимуму: убраны переводы строк и лишние пробелы. В качестве спорного момента можно отметить отсутствие кэширования для главной страницы. Раньше его включали на 5 минут, чтобы уменьшить число повторных запросов. На данный момент (наверное, в связи с блоком почтовой авторизации) всякое кэширование отключено. Однако, корректная настройка Last-Modified (в зависимости от переменных окружения, связанных с конкретным пользователем) могла бы уменьшить число передаваемых данных (сервер мог бы ответить статус-кодом 304 и не передавать всех данных).

 

SpeedUpYourWebsite.v1.2_img_60

Рис. 60. Результаты ответа для HTML-файла с yandex.ru

 

rambler.ru

SpeedUpYourWebsite.v1.2_img_61

Рис. 61. Результаты анализа загрузки главной страницы www.rambler.ru

В случае в Рамблером ситуация несколько другая: на главной странице портала представлено достаточно большое количество информации, в связи с чем число внешних объектов значительно больше – уже 46.

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

CSS Sprites довольно активно используются на странице, но и тут не обошлось без очевидных промахов. Например, иконки для состояний погоды можно было с легкостью объединить в один файл, однако, это не было сделано. Использование .png формата вместо .gif для фоновых изображений также способно уменьшить размер конечного файла. Применение же скрипта patch_script.js размером в 185 байтов (по сравнению с HTML в 20 Кб) крайне неосмотрительно.

Для загрузки большинства изображений (как хорошо видно из диаграммы загрузки) используется всего 2 хоста (rambler.ru и i.rl0.ru). Увеличение их числа до 4 позволило бы существенно ускорить процесс загрузки многочисленных картинок. Поскольку картинки занимают около 60% от общего времени, то добавление двух хостов для них позволило бы ускорить загрузку страницы на треть. Дополнительно: большинство jpeg изображений сгенерированы не оптимальным образом, и их размер можно уменьшить на 20-30%.

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

mail.ru

SpeedUpYourWebsite.v1.2_img_62

 

Рис. 62. Результаты анализа загрузки главной страницы www.mail.ru

 

Сам HTML-документ отдается через gzip, но для CSS- и JavaScript-файлов сжатие не применяется (что, естественно, плохо отражается на времени загрузки). На странице запрашивается 4 JavaScript-файла и 3 CSS. При этом JavaScript подключается, в основном, в head страницы. Это все крайне негативно влияет на скорость отображения страницы. Однако, как видно из рис. 63, кэширование для файлов стилей и скриптов включено при помощи Expires и Last-Modified. Это не может не радовать.

 

SpeedUpYourWebsite.v1.2_img_63

Рис. 63. Результаты ответа для статического файла с mail.ru

 

Фоновые картинки уже объединены в спрайты (хотя, есть еще возможности для объединения), однако, дополнительное уменьшение размера возможно за счет использование .png. Также большинство .jpg картинок можно существенно уменьшить в размере. Можно рассмотреть кэширование и объединение нескольких картинок (из блоков «Фото» или «Видео») в Image Map, чтобы уменьшить число запросов к серверу.

Для статических файлов используется всего 2 хоста (r1.mail.ru и img.mail.ru). Добавление еще двух (вместе с уже описанными методами уменьшения размера графики) способно ускорить загрузку примерно в два раза. В целом же, у разработчиков mail.ru есть еще большой простор для творчества в области клиентской оптимизации.

Mail.ru является, пожалуй, наиболее крупным почтовым порталом в Рунете. Все остальные сервисы на нем появились именно благодаря почте и базе держателей почтовых адресов.  Во всем остальном соблюдены почти все рекомендации: наиболее часто используемые картинки объединены в CSS Sprites, при загрузке статических файлов задействуется несколько хостов (в том числе те, на которые не передаются cookie). Однако, как видно из диаграммы загрузки, на странице еще есть некоторое количество небольших изображений, которые также можно объединить в одно или же даже внести в сам документ (для всех браузеров, кроме IE) в виде data:URI.

Материалы близкой тематики:

Posted in Разгони свой сайт.