Как ускорить мобильный поиск в два раза

Краткая версия доклада:

Скорость загрузки страниц с помощью мобильного интернета зачастую ниже, чем на десктопе через кабель. Анализ времени до первой отрисовки выдачи (TTFP) в Рунете показывает, что мобильные системы (Wi-Fi и сотовая связь) отстают в полтора-два раза в зависимости от скорости соединения. Замедление загрузки порождает неудовлетворенность клиентов, которые ожидают, что мобильный интернет не будет проигрывать десктопам.

Для мобильного веба характерны большая латентность сетевых хождений (RTT), узкий канал (bandwidth), нестабильность характеристик, потери пакетов, ограничения к оборудованию (процессору, памяти, хранилищу). В ходе загрузки страницы сначала устанавливается соединение (DCP, TCP, TLS) и идет отправка запроса, который обрабатывается на сервере и происходит доставка контента (TTFB), разбор ответа и отрисовка выдачи (TTFP). При загрузке страниц через Wi-Fi наиболее продолжительным является этап TTFP, а в 3G – установка сетевого соединения. То есть, если мы хотим оптимизировать загрузку, нужно уделять особое внимание установке соединения, а также безопасного соединения.

Установка соединения (холодная загрузка) требует пяти сетевых хождений (RTT). В российских мобильных сетях у 50% пользователей одно RTT занимает около 77 миллисекунд. Однако у порядка 10% самых медленных соединений одно сетевое хождение занимает около 2 секунд, а полная установка – 10 секунд, что очень много. На скорость оказывает влияние технология сетей – у 2G и 3G она гораздо ниже по сравнению с 4G и Wi-Fi, при этом надо учитывать и перегрузки, нестабильные сигналы, физические помехи.

Самый эффективный подход оптимизации установки соединения – не устанавливать соединение на критичном пути (настраиваем на сервере keepalive и вводим директиву preconnect), не делать редиректов (изменяем ссылки в логах на прямые заходы и используем технологию HSTS по прямой установке HTTPS) и оптимизировать установку безопасного соединения TLS (применяя методы TLS Session Ticket и TLS False Start, минимизируя передаваемые данные при TLS-хэндшейке). Все эти методы дают возможность ускорить соединение на 5-7%.

После установки соединения идет загрузка контента – сервер получил запрос и обрабатывает его, что требует времени. С целью оптимизации, параллельно с тяжелыми операциями, поисковая стрелка, которая никак не влияет на результаты поиска, может быть отправлена клиенту для первой отрисовки. Кроме того, в HTTP можно установить механизм передачи данных chunked-encoding.

С получением результата поиска контент начинает подгружаться. Путь для оптимизации здесь состоит в максимально возможном сжатии данных, поэтому используется механизм сжатия статики (Zopfli/Brotli), оптимизируются картинки (WebP, SCG), все необходимые ресурсы для отрисовки располагаются в начале HTML, статика подгружается не на критическом пути отрисовки.

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

Нами был сделан вывод, что, в зависимости от скорости соединения, нужно менять выдачу, т.е. адаптировать её. Была сделана специальная лёгкая версия поисковой выдачи для медленных соединений. Чтобы сервер мог их самостоятельно определить, используются метрики ядра Linux (данные TCP_INFO) и метрики от клиентов (Save-Data), а также учитывается время установки TLS-соединения.

Вёрстка для медленных соединений гораздо меньше, чем полноразмерная, однако при этом видимых отличий у неё на первый взгляд немного. Это достигается за счет уменьшения поисковой стрелки, снижения размера HTML/CSS до менее 14 кБ и данных для первой отрисовки до 0,8 кБ, расположения стилей в HTML перед непосредственным использованием, отсутствия AJAX, использования самого лёгкого JS. Эксперимент на Яндексе показал, что использование лёгкой версии увеличивает показов страниц результатов поиска на 2,2%.

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