Как Google так быстро?

Как Google так быстро?

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

Результаты поиска Google быстрые

Главная страница Google известна своей скоростью, но отчасти это связано с тем, насколько она разрежена. Вместо этого давайте сосредоточимся на странице результатов поиска Google. Там гораздо больше функций и контента, и он по-прежнему загружается невероятно быстро. Здесь мы ищем «метрики запроса» с мобильного телефона.

Результаты поиска Google по запросу «Показатели запроса»

Ух ты. Это почти мгновенно. Если мы сравним скорость результатов поиска Google с нашим профилем веб-производительности Nike.com, то не возникнет вопроса, какой опыт предпочтительнее. Но как Google так быстро загружает эти результаты?

Статистика страницы результатов поиска

Давайте посмотрим на статистику загрузки этой страницы (собранную на вкладке «Сеть» в инструментах разработчика Chrome).

• Всего 130 запросов на загрузку результатов поиска.
• 707 КБ ресурсов по сети (сжатых с помощью gzip)
• 9 файлов JS
• 104 файла изображений
• 0 файлов CSS

По сравнению со многими сайтами, это «легкая» загрузка страницы, но запросов по-прежнему больше ста. И по сети отправляется три четверти мегабайта активов.

Интересно, что Google использует для сжатия gzip вместо собственного алгоритма Бротли, хотя мой браузер принимает и то, и другое. В бенчмарках Brotli можно настроить на увеличение сжатия и производительности по сравнению с gzip, поэтому непонятно, почему они делают такой выбор.

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

Откуда берутся стили?

Браузер не запросил ни одного CSS-файла, и тем не менее страница оформлена красиво. Давайте посмотрим на HTML-код, который мы получили от Google, чтобы понять, откуда берутся стили.

Они встроенные! Google встраивает CSS и отправляет его вместе с ответом страницы. Это позволяет браузеру отображать стилизованное содержимое, не дожидаясь возвращения внешнего ресурса. Но Google не просто встраивает CSS.

Встроить каждый статический ресурс

Google серьезно относится к встраиванию. Они не только встраивают стили, они встраивают свой JavaScript!

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

Мы видим, что из всех скриптов и стилей на странице все встроено, кроме 2 внешних файлов JavaScript. ( Примечание: эти два внешних скрипта динамически загружают дополнительные JS-файлы, поэтому мы получаем 9 всего при загрузке страницы).

Что, если мы не будем загружать какие-либо внешние активы?

Чтобы проиллюстрировать, насколько далеко Google продвинулся в концепции встраивания статических ресурсов, давайте только загрузим HTML. Других внешних ресурсов нет. Никакого внешнего JavaScript, никаких внешних изображений, ничего внешнего. Я сохранил HTML-ответ от Google и открыл его, отключив сеть. Как это выглядит?

Только исходный HTML. Никаких внешних активов.

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

Ранее мы видели, что 104 файлов изображений загружались во время загрузки реальной страницы. И тем не менее, мы видим, что большинство изображений работает здесь. Что дает?

Встраивание изображений с URI данных

Google использует умную оптимизацию для большинства изображений. Если мы посмотрим на изображение фавиконки Request Metrics в инспекторе, то увидим, что изображение имеет специальный src URI — URI данных! Содержимое двоичного изображения закодировано в Base64 и помещено непосредственно в атрибут src.

Использование Data URI — это еще один способ, которым Google демонстрирует свою приверженность встраиванию активов. Это идеальная техника для использования, когда нужно отобразить много маленьких изображений. Подход Data URI имеет убывающую отдачу для больших изображений, поскольку он увеличивает размер страницы. Вот почему карусель «Изображения» пуста — они все еще используют изображения из внешних источников для заполнения этого раздела.

Важно! Стоит отметить, что каждое из этих изображений в кодировке Base64 считается «запросом» на вкладке «Сеть» в инструментах разработчика Chrome. Это объясняет, почему так много «запрошенных» изображений, но страница работает так быстро. Браузер никогда не выходит из сети, чтобы получить их! Вот как они выглядят в инструментах разработчика:

Встраивание для скорости

Приверженность Google встраиванию JS, CSS и изображений показывает, насколько это важно для максимальной производительности. Каждый внешний запрос, который делает браузер, представляет собой проблему производительности, ожидающую своего возникновения.

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

Конечно, важно также быстро получить первый ответ пользователю. И 90 % — это не 100 % — есть другие запросы, необходимые для полнофункционального взаимодействия. Встраивание — не единственное, что делает Google, чтобы быть быстрым.

Сеть Fast Edge от Google

Оптимизация содержимого страницы важна, но, возможно, не менее важна быстрая доставка этой страницы и связанных с ней ресурсов по сети.

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

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

Трудно объективно измерить производительность сети Google с помощью традиционных инструментов, таких как ping, но мы можем посмотреть, как все работает в нашем браузере.

Первоначальный ответ результатов поиска

Вот что говорят инструменты разработчика о времени загрузки результатов поиска:

Первоначальный запрос в Google имел время до первого байта (TTFB) 145 мс (синяя рамка). То есть браузер начал получать ответ от Google через 145 миллисекунд. Это довольно быстро. Общее время завершения чтения ответа составило 880 мс (оранжевый прямоугольник). Это включает в себя время на загрузку всего ответа из Google.

Помните, что из-за агрессивного встраивания статического контента Google 90% пользовательского интерфейса могут быть отображены пользователю после завершения ответа.

Статический контент еще быстрее

При загрузке страницы извлекаются несколько внешних файлов JavaScript.

Все эти файлы имеют среднее значение TTFB ~30 мс. Это говорит о том, что сервер находится рядом с минимальными переходами между моими браузерами. Учитывая, что я загрузил эту страницу через интернет-соединение Comcast, это хорошее время отклика.

Протокол имеет значение

Мало того, что серверы Google находятся поблизости, они также обслуживают файлы по новому протоколу. Вы могли заметить значение h3-Q050 на снимках экрана выше. Это потому, что браузер общается с Google через HTTP/3.

Это все еще черновик стандарта, но основное различие между HTTP/3 и HTTP/2 заключается в том, что TCP больше не является базовым протоколом соединения. Они приняли QUIC вместо TCP, потому что это повышает производительность:

[QUIC] делает это, устанавливая несколько мультиплексных соединений между двумя конечными точками по протоколу пользовательских дейтаграмм (UDP). Это работает рука об руку с мультиплексными подключениями HTTP/2, позволяя нескольким потокам данных достигать всех конечных точек независимо и, следовательно, независимо от потери пакетов, связанных с другими потоками.

Как быть быстрым, как Google

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

Делайте меньше запросов

Google выводит это на новый уровень, но избегание сетевых запросов является основным фактором повышения производительности в Интернете. Даже с более новыми HTTP-протоколами объединение ресурсов для объединения статического контента по-прежнему является хорошей идеей. Если вы можете встроить некоторый JavaScript или CSS, это даже лучше. Также может помочь использование URI данных для передачи небольших изображений. Сети ненадежны, и каждый запрос браузера может завершиться ошибкой или быть отложенным.

Webpack является одним из основных инструментов в современных интерфейсных цепочках инструментов, и есть несколько плагинов, которые могут помочь, если вы хотите пойти по пути встраивания:

Используйте CDN и современные протоколы

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

Размещение статического контента в CDN — это простой способ получить некоторые сетевые преимущества, которыми пользуется Google, включая поддержку HTTP/2 или HTTP/3. А использование DNS-решения с учетом геолокации позволяет вывести локализацию данных на новый уровень, если это важно для вашего варианта использования или клиентской базы.

Даже если вы не используете облако, сторонние поставщики, такие как MaxCDN и Fastly, упрощают доставку статического контента со всего мира. И есть провайдеры DNS, такие как easyDNS, предлагающие полную маршрутизацию GeoDNS.

Google — одна из ведущих веб-компаний в Интернете, и компания внедряет множество новых веб-стандартов. Неудивительно, что их сайт является одним из самых быстрых. Для всех остальных мы построили Метрики запроса. Теперь вы можете увидеть, как ваши пользователи на самом деле воспринимают ваш сайт.

Первоначально опубликовано на https://requestmetrics.com.