Клиентская оптимизация *

Всем привет!

За время моей работы с вебпаком у меня накопилась пара интересных советов, которые помогут вам приготовить отлично оптимизированное приложение. Приступим!

Ключевой задачей высоконагруженных WEB-систем является способность обработать большое число запросов. Решить эту проблему можно по-разному. В этой статье я предлагаю рассмотреть необычный метод оптимизации запросов к backend через технологию content-range (range). А именно — сократить их количество без потери качества системы путем эффективного кеширования.

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

1. REST-интерфес;
2. WEBSocket broadcast subscription.

Метод REST зачастую используется для получения исторических данных, в то время, как по WEBSocket рассылается актуальная информация в режиме online. В некоторых случаях WEBSocket вообще не используется, а обновление происходит регулярными запросами через REST.

И вроде все довольны. Но, при более детальном рассмотрении, становится очевидными огромные накладные расходы на такую концепцию. Их основная масса ложится на REST. Для обеспечения функционирования REST-интерфейса мы должны создать backend отвечающий требованиям высоконагруженных систем. Естественно, тут можно выбирать различные варианты решения от PHP до нынче модного Golang.

Также требуется создать высокодоступную инфраструктуру, реализовать такие мелочи как CI/CD для сервисов, обеспечить все это нужными спецами по разработке, сопровождению, и т.д., и т.п.

Новые направления развития уже знакомой платформы — это всегда интересно. С одной стороны, вы расширяете клиентскую базу, с другой — не вкладываетесь в создание софта с нуля, а используете существующие наработки. Но если направление действительно новое, со своей спецификой, то совсем малой кровью обойтись не удастся. На очередной встрече сообщества Mosdroid в нашем офисе разработчик Артур Василов Arturka рассказал об адаптации приложения «Яндекс» под систему Android Go.

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

В этой статье я расскажу о различных подходах в дизайне, которые помогут создать у пользователя впечатление, что сайт (или приложение) работает быстрее.

ПРИМЕЧАНИЕ. Статья вдохновлена беседой с Адой Кэннон, которая защищает интересы разработчиков в проекте интернет-браузера Samsung Internet и в серии наших роликов Google Chrome Developers YouTube «Дизайнер и разработчик». Прослушать более полную запись разговора можно, скачав ее или подписавшись на наш подкаст на платформе iTunes или  Google Play Музыка.

Никогда не задумывались, почему когда вы звоните куда-нибудь в поддержку, вам на время ожидания включают музыку? А вы представьте свои ощущения, если бы вместо музыки была бы мертвая тишина. Канал CNN провел опрос, который показал, что если вызов абонента поставить на удержание, то в 70 процентов случаев звонящий положит трубку в первые 60 секунд тишины: ему может показаться, что вызов оборвался, да и само ожидание кажется дольше. Поэтому смысл «музыки» в том, чтобы заполнить чем-то ожидание и занять время абонента.

В аэропорте Хьюстона была похожая проблема: пассажиры жаловались, что приходится долго ждать багажа. После приземления самолета у терминала пассажиры довольно быстро добирались до карусели, и поэтому им приходилось ждать своего багажа в среднем семь минут — причем жаловаться не перестали, даже когда аэропорт расширил штат. Поэтому было решено отвести самолеты дальше от терминала, чтобы пассажирам приходилось идти дольше — и жалобы упали почти до нуля.

Переведено в Alconost

Это Славик — обычный ПХП-программист. Не джуниор и не сеньор, а парень из тех, кого раньше называли «веб-мастерами». Славик может и ЦМС поковырять, и свою написать, и шаблон сверстать, и сервер поадминить.

В этом году Славик завязал со всем этим и решил устроиться на стабильную работу. Знакомые подкинули неплохой вариант — транспортной компании «N-лайнз» нужен разработчик на поддержку готовой системы бронирования.

Славик обрадовался. Оплата неплохая, стабильная, всегда есть что делать. А главное, наконец-то будет явная польза для людей. Славику всегда хотелось понимать, как его работа кому-то принесёт пользу. Так он туда и устроился.

Однажды утром Славик увидел в Джире новую задачу:

В последнее время набирает популярность тренд «исчезающих фреймворков», локомотивом которого, без сомнения, можно считать SvelteJS — buildtime-фреймворк и компилятор в ванильный javascript.

Несмотря на то, что концептуально Svelte весьма прост, а в использовании еще проще, многие разработчики задаются вопросом, в чем же killer-фича данного фреймворка, да и подхода в целом? Почему это не «yet another javascript framework»?

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

Давайте разберемся, но сначала я расскажу вам одну легенду…

Продолжаем изучение Progressive Web Applications. После теоретической первой части и простого практического примера Hello Habr второй части попробуем перевести в PWA веб сайт на CMS Joomla.

Тип серверного фреймворка не важен. Задача данной статьи — показать перевод обычного сайта в PWA как концепцию, применимую к произвольным сайтам на любых фреймворках.

Продолжаем знакомство с Progressive Web Applications. После теоретической прошлой части самое время перейти к практике.

Сегодня мы построим простое, но полноценное PWA «Hello Habr».




Приложение доступно по адресу https://altrusl.github.io/habr-pwa/hello-habr/. При открытии в браузере на мобильном устройстве возможно добавление ярлыка на домашний экран и запуск в полноэкранном режиме.

Библиотека JQuery была создана в 2006 году для восполнения недостающей функциональности Javascript. С тех пор последний достаточно продвинулся в своем развитии, чтобы разработчики могли обходиться без JQuery, основная проблема которой — производительность.

Процесс работы пользователей с интерактивными веб-сайтами может включать в себя шаг отправки им JavaScript-кода. Часто — слишком большого объёма такого кода. Если на сайте используется очень много JavaScript, это особенно сильно сказывается на мобильных пользователях. Например, вам случалось бывать на мобильных веб-страницах, которые, вроде бы, выглядят как уже готовые к работе, но не реагируют на щелчки по ссылкам или на попытки прокрутить страницу?


JavaScript-код, который попадает в мобильные браузеры, всё ещё остаётся самым дорогостоящим ресурсом, так как он, многими способами, может задержать переход страниц в состояние, в котором с ними можно взаимодействовать. Какую нагрузку на системы создаёт JavaScript в наши дни? Как анализировать сайты? Как ускорить загрузку и обработку браузерами интерактивных веб-страниц? Эдди Османи, перевод материала которого мы сегодня публикуем, решил найти ответы на эти и на многие другие вопросы, встающие перед теми, кто пользуется JavaScript для разработки веб-сайтов в 2018 году.

Beacon API — это основанный на JavaScript интерфейс для:

отправки небольшого количества данных на сервер с браузера, без ожидания ответа. В этой статье, мы рассмотрим в каких случаях будет полезен Beacon API, чем он отличается от использования XMLHTTPRequest (Ajax) для тех же целей и как его использовать.

Для чего нам очередной API?

Beacon API используется для отправки небольших по объему данных на сервер без ожидания ответа. Последняя часть утверждения является наиболее интересной. Beacon API разработан специально для того, что бы можно было отправить данные и забыть о них. Не нужно ожидать ответ, так как его и не будет.

Понятие Progressive Web Applications (PWA) на слуху давно, с весны 2018 года приложения этого класса поддерживаются всеми основными браузерами, однако распространенность технологий PWA несмотря на очевидные их «плюсы» пока очень низка.

Специалисты Google (в том числе и на Хабре) очень информативно и компетентно пишут о PWA, но их рекомендации полезны больше тем, кто уже знаком с предметом. Данная статья призвана показать, что Progressive Web Apps — это не сложно, и использовать эти технологии можно и нужно уже сейчас разработчикам любых сайтов.

До того, как написанный нами код будет исполнен, он проходит довольно долгий путь. Андрей Мелихов в своем докладе на РИТ++ 2018 разобрал каждый шаг на этом пути на примере движка V8. Заходите под кат, чтобы выяснить, что даёт нам глубокое понимание принципов работы компилятора и как сделать JavaScript код производительнее.



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

Спойлер: «Преждевременная оптимизация — корень всех бед», Дональд Кнут.



О спикере: Андрей Мелихов работает в компании Яндекс.Деньги, активно пишет на Node.js, а в браузере — меньше, поэтому ему ближе серверный JavaScript. Андрей поддерживает и развивает сообщество devShacht, заходите познакомиться на GitHub или Medium.

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



Тема производительности интересует меня уже давно. Помню, всё началось со знакомства с «жадными» алгоритмами и алгоритмами типа «разделяй и властвуй». Было что-то особенно приятное в том, чтобы взять код, на выполнение которого требовалось несколько минут, переделать его и заставить выполнять задачу за пару секунд.

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

Переведено в Alconost

Мы попробуем разобраться — как можно снизить нагрузку на серверное железо, обеспечив при этом максимальную производительность Web-приложения.

В разработке больших высоконагруженных проектов с огромным онлайном часто приходится думать, как снизить нагрузку на сервера, особенно при работе в webSocket'ами и динамически изменяемыми интерфейсами. К нам приходит 100500 пользователей и мы имеем 100500 открытых соединений по сокетам. А если каждый из них откроет по 2 вкладки — это уже *201000 соединений. А если пять?

Этот пятничный пост посвящен переводу интересной статьи, вышедшей вчера на Medium. Решил осваивать для себя новый жанр переводов, поэтому прошу сильно не пинать, если где-то что-то не так. А по возможности даже уведомлять об ошибках и опечатках в личку.

Спасибо и хорошего прочтения!

На уровне могут находиться тысячи врагов.

У игры Defender's Quest: Valley of the Forgotten DX всегда были давние проблемы со скоростью, и мне наконец удалось их решить. Основным стимулом к масштабному повышению скорости стал наш порт на PlayStation Vita. Игра уже вышла на PC и хорошо, если не идеально, работала на Xbox One с PS4. Но без серьёзного усовершенствования игры нам ни за что бы не удалось запустить её на Vita.

Когда игра тормозит, комментаторы в Интернете обычно винят язык программирования или движок. Справедливо то, что языки наподобие C# и Java связаны с большими издержками, чем C и C++, а у инструментов наподобие Unity есть не решаемые проблемы, например со сборкой мусора. На самом деле люди придумывают такие объяснения потому, что язык и движок являются наиболее явными свойствами ПО. Но истинными убийцами производительности могут оказаться глупые крошечные детали, никак не связанные с архитектурой.

Service Workes как технология для создания offline приложений очень хорошо подходит для кэширования различных ресурсов. Разнообразные тактики работы в сервис воркере с локальным кэшем подробно описаны в Интернете.

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

Буквально вчера вышла 2-я версия молодого, но весьма многообещающего фреймворка SvelteJS. Версия мажорная, а значит содержит не только новые фичи и исправленные баги, но и соответствующие «breaking changes». Что новенького предлагает разработчикам новая версия и почему Svelte стал еще лучше, читайте под катом.