Гугл+

Краткое содержание

Google+ становится полностью адаптивным.

Адаптивность

Google+ — это место, где люди собираются вместе по общим интересам, от «Кошек-зомби» до старинных калькуляторов. До недавнего времени у Google+ было две разные версии своего веб-сайта: одна для настольных компьютеров и одна для мобильных устройств, разработанная для старых браузеров.

Проблемы

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

По мере того, как мы добавляли функции, наш устаревший сайт для настольных компьютеров также стал медленным и раздутым. Ранее в этом году наша домашняя страница весила около 5 МБ и выдавала около 250 HTTP-запросов. Это просто не работало хорошо. Изображения на сайте были тяжелыми и неоптимизированными, что еще больше замедляло работу страницы. В результате наш поток был практически недоступен в медленных и нестабильных сетях, и впечатления этих пользователей были в лучшем случае разочаровывающими. Кроме того, требование поддержки устаревших браузеров в мобильном Интернете не позволяло нам использовать JavaScript на всем сайте и не позволяло нам реализовать высокоинтерактивные функции. Мы не могли полагаться на достижения мобильных веб-браузеров.

Решение

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

Этот набор ограничений означал, что нам приходилось тщательно изучать каждое изменение кода в дальнейшем. Для достижения этой цели мы установили правило 6^5, гарантирующее, что при начальной загрузке страницы мы не загружаем более 60 КБ HTML, 60 КБ JavaScript, 60 КБ CSS, наша анимация всегда имела частоту 60 кадров в секунду, а средняя задержка составляла 0,6. с.

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

С помощью этой новой платформы мы начали создавать прототип повторной реализации Google+ в Интернете. Мы начали запрещать «плохое» и устанавливать строгие правила развития. Одним из наших основных правил было то, что все наши страницы должны визуализироваться как на стороне сервера, так и на стороне клиента. При рендеринге на стороне сервера мы гарантируем, что пользователь сможет начать чтение сразу после загрузки HTML, и для обновления содержимого страницы не требуется запускать JavaScript. После того, как страница загружена и пользователь нажимает на ссылку, мы не хотим выполнять полный цикл обработки, чтобы отобразить все заново. Именно здесь становится важным рендеринг на стороне клиента — нам просто нужно получить данные и шаблоны и отобразить новую страницу на клиенте. Это предполагает множество компромиссов; поэтому мы использовали структуру, которая упрощает рендеринг на стороне сервера и на стороне клиента без необходимости реализовывать все дважды — на сервере и на клиенте.

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

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

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

Полученные результаты

Не жертвуя производительностью, Google+ смогла создать сложное веб-приложение с богатым пользовательским интерфейсом. Сайт теперь работает быстрее и проще, чем когда-либо прежде.