Секция о клиентском программировании на HighLoad++

от автора


Не знаю, как вы, но я застал время, когда фронтенда еще не было. Большинство макетов программисты могли сверстать самостоятельно, ну что там сложного: <table>, <table> и <table>

Потом появилась блочная верстка, верстальщики выделились в отдельную профессию, но остались на второстепенных ролях. На команду из нескольких серверных программистов приходился один верстальщик, самый бесправный член коллектива — он иногда даже сам внедрить-то свой код не мог, обычно в шаблон HTML-верстку превращали программисты.
 
Прошло еще несколько лет, и ситуация изменилась в корне! Не каждый PHP-программист поймет, как устроен и работает Angular или React. Страницы стали интерактивными, в ходу концепции толстого клиента и Single Side Application, Игорь Сысоев выпускает nginScript, компилятор JavaScript для nginx, а профессия верстальщика конвертировалась в профессию фронтенд-разработчика. Кстати, как работодатель скажу, что фронтендеров гораздо тяжелее найти, чем бекендеров.
 


Посмотрите на современный фронтенд — это настоящая большая программа на JavaScript, со своей архитектурой, модульным разбиением, объектно-ориентированным программированием, кешированием и так далее. Зачастую это не менее, а более сложный код, чем серверный. На клиенте все больше бизнес-логики, а сервер превращается в простое хранилище данных.
 
Но браузер, который интерпретирует JavaScript на клиенте, это не сервер. У него меньше возможностей, скорости, памяти, у него, как правило, есть батарейка. Возникает целый пласт задач, связанных с производительностью фронтенда: как написать не тормозящий JS, как не сожрать всю память в ноутбуке клиента, как не посадить батарейку за час работы с вашим сайтом, как, в конце концов, обеспечить быструю загрузку страницы (или сделать вид, что она загружается быстро).
 
Решению именно этих задач посвящена новая секция ПРОИЗВОДИТЕЛЬНОСТЬ ФРОНТЕНДА. Что в ней будет, расскажет её куратор — представитель компании Opera в России, руководитель сообщества веб-стандартистов, Председатель Программного комитета конференции для фронтенд-разработчиков FrontendConf Вадим Макеев.

— Вадим, начиналось всё с таблиц, затем блочная вёрстка – что будет дальше?

Таблицы, флоаты и другие попытки приспособить для сложной вёрстки не предназначенные для этого возможности — это была довольно интересная эпоха — мы каждый день экспериментировали и придумывали новые трюки. Сегодня вёрстка повзрослела и обросла десятком новых спецификаций, которые позволяют делать те же раскладки страниц гораздо проще. Что самое интересное: спустя год после появления нового черновика в недрах Рабочей группы CSS, вечнозелёные браузеры уже начинают его поддерживать, и всё самое прогрессивное и новое уже сразу можно использовать.

С другой стороны, людей, которые хорошо разбираются во флексбоксе или начинают пробовать гриды — не так и много. И нет-нет, да включишь флоат, знакомый с детства, вместо того, чтобы разбираться в нюансах флексбокса, поэтому инерция сохраняется. Уж не говоря про ошибки реализации, которые записывает во [Flexbugs] Филип Уолтон.

Флексбокс, каким бы он ни был крутым, это всё та же коробочка, внутри которой просто появились новые удивительные возможности (боже, вертикальное выравнивание!), то грид — это штука в духе «забудьте всё, что вы знали». Она уже есть за флагами в большинстве последних браузеров, кроме Safari и не терпится уже прыгнуть с головой в эту новую эпоху вёрстки.

Дальше будет только круче, например, LG уже [работает над черновиком] адаптации блочной модели под круглые экраны.

— Какие новые технологии появились для увеличения производительности?

Я сейчас скажу крамольную вещь, но самый правильный способ улучшать производительность в вебе — это браузерам быстрее рендерить и выполнять. То есть, по сути, докупить серверов и обновить ПО — если говорить языком, понятным на конференции HighLoad. Всё потому, что веб — это самая гибкая и совместимая платформа из всех существующих. И поэтому веб состоит из кучи старого кода, который написан плохо, но от этого содержимое этого сайта не становится менее ценным.

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

Помимо инструментария, который позволяет правильно измерять эту производительность — не только браузерных отладчиков, но и API для доступа к такой информации — у нас появляется всё больше низкоуровневых API для доступа в те части браузера, куда нас раньше не пускали. Тот же requestAnimationFrame позволяет правильно планировать действия вместе с браузером, чтобы быть с ним на одной волне, сервис-воркеры позволяют прописываться в браузере и управлять кэшем и сетевыми запросами даже при закрытой странице.

Это вообще новая интересная тенденция — браузер для нас становится всё меньше просто чёрной коробкой, в которой происходит что-то неведомое. Мы всё больше получаем к ней доступ и начинаем управлять его поведением всё тоньше. Погуглите «CSS Houdini».

— Ты работаешь в Opera, Opera мониторит тренды? Как реагирует на них?

У нас появилась команда R&D (Research and Development), которая как раз и занимается сбором новинок и планами нашего развития в быстро меняющейся отрасли и экспериментирует с ними. До сих пор у нас получалось изобретать новое в браузерной отрасли, что теперь видно в интерфейсах всех браузеров. Шутка «Opera сделала это первой» до сих пор нет-нет, да всплывает. И мы продолжаем: недавно мы запустили [экспериментальную сборку Opera для Android] с поддержкой биконов — небольших маломощных устройств на местности, которые транслируют URL и позволяют взаимодействовать с физическим миром прямо из браузера. Такой вот интернет вещей: подходите к автобусной остановке — и видите уведомление в браузере с расписанием движения. И это не фантазии — это уже работает в Осло, [в статье] есть фотографии и подробности работы.

О докладах новой секции

Understanding Page Load
Маленький сайт грузится быстро, большой долго — так? Не так. Правильно сделанный сайт и грузится, и работает быстро. Чтобы сделать его правильно, нужно понимать, что на самом деле происходит с сетью и браузером на каждом их этапов, разобраться в «холодной» и «горячей» загрузке и научиться пользоваться инструментами. Опытом создания, профилирования и ускорения фронтенда для YouTube делится Зилин Жао из Google.

От Request до DOMContentLoaded на примере главной страницы Mail.ru
Можно сделать быстрый сервер, можно оптимизировать работу с сетью, а можно ускорить отрисовку в браузере — и каждый из вариантов добавит вам немного скорости. А если оптимизировать и объединить всю цепочку: от запроса на сервер до последнего события в браузере? C++, V8 и JS на сервере, отложенная загрузка и тонкая организация блоков на клиенте и Keep-Alive между ними — Павел Минеев расскажет о быстрой главной Mail.Ru.

From nothing to a video under 2 seconds
В тонкую психологическую разницу между «ещё грузится» и «всё зависло» важно попасть, чтобы пользователь не ушёл. Хороший способ — поставить бюджет времени и не выходить за его рамки. Как YouTube, одному из тройки самых больших сайтов в мире, удаётся показывать видео за 2 секунды и даже быстрее, какие бывают типы загрузки и что делать с каждым и как вообще устроена страница просмотра видео — Михаил Сычёв из команды YouTube Desktop.

Производительность WebGL-приложений
Даже быстрый WebGL на видеокарте можно нагрузить так, что станет медленно. Яндекс.Карты придумали хороший способ нагрузить WebGL с помощью интерактивных панорам. Какие проблемы вылезли и как от них получилось разгрузить движок панорам — в докладе Кирилла Дмитренко.

Скорость на клиенте
Записка «страничка сформирована за X секунд» с сервера не говорит вообще ни о чём — когда пользователь увидит это в браузере, вот что важно. Почему вообще бывает медленно, как с этим бороться и чем здесь поможет Navigation Timing API и HTTPS расскажет Анатолий Орлов, уже не из Яндекса.

Это ещё не всё!

Как видите, получилась очень представительная секция: Google, YouTube, Mail.ru, Яндекс. И это — только половина от всех докладов, представленных в новой секции «Производительность фронтенда».

Прошлые года

А вот здесь нам показать-то особенно нечего – секции-то такой не было ещё год назад. Но были доклады на других наших конференциях, в частности, на конференции «Российские интернет-технологии». Несколько докладов оттуда ниже. А с этой страницы можно скачать несколько книжек, в том числе с расшифровкой лучших докладов по клиентскому программированию с наших конференций.





И последнее: Для пользователей «Хабрахабра» конференция предлагает специальную скидку в 15%, всё что нужно сделать — это воспользоваться кодом "IAmHabr" при бронировании билетов.

И совсем последнее: Конференция уже на следующей неделе и мы станем писать реже — будем отсыпаться и отдыхать. Но потом мы вернёмся, новые публикации вы сможете найти в блоге на Хабре и в наших бесплатных рассылках. Будем рады оставаться на связи!

ссылка на оригинал статьи http://habrahabr.ru/post/269447/


Комментарии

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *