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

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

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

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

Объяснение я нашел в книге Рэймонда Иммельмана «BOSS: Бесподобный или Бесполезный». В этой книге в формате бизнес-романа рассказывается о том, что поведением людей управляет контекст. И зная этот контекст, можно с высокой вероятностью предсказать, как человек себя поведет в той или иной ситуации.

Что я подразумеваю под «контекстом», я расскажу вам под катом.

Привет Хабр! В предыдущих частях цикла (раз, два) мы рассматривали тайловую архитектуру мобильных GPU, а также классифицировали различные семейства GPU, представленные у пользователей. В этой части мы рассмотрим приемы, которые помогут писать быстрые шейдеры для мобильных GPU.

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

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

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

Загрузка CSS на страницу — блокирующая операция. Если асинхронная загрузка JavaScript может быть незаметна пользователю, то медленное появление стилей может прогнать нетерпеливого гостя с сайта. Как загружать CSS максимально производительно и незаметно для пользователей? Разобраться пробует Никита Дубко DarkMeFoDy из группы поисковых интерфейсов Яндекса в Минске.


— Всем привет. Расскажу про стили. Все сегодня говорят про TypeScript да TypeScript. А я про Cascade style script буду рассказывать.

Казалось бы, померил время от HTTP-запроса браузера до загрузки последнего байта страницы — и готово. Not so fast! У Google, например, целых 6 метрик для оценки скорости работы сайта. Под катом НЕ будет перевода документации Lighthouse и НЕ будет советов по написанию SEO текстов, зато вы узнаете:

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

Улучшаем компрессию бандлов на 40% от размера файла, путём замены стандартного хеширования на однобуквенный префикс + хеш пути файла.

Всем привет! Меня зовут Артур, я работаю frontend-разработчиком в Exness. Не так давно мы перевели один из наших проектов на веб-компоненты. Расскажу, с какими проблемами пришлось столкнуться, и о том, как многие концепции, к которым мы привыкли при работе с фреймворками, легко перекладываются на веб-компоненты.

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

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

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

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

К счастью, я недавно исправил трассировку кольцевого буфера UIforETW, сделав его надёжным, поэтому я запустил его и начал ждать следующего случая задержки. Долго ожидать мне не пришлось.

Мне потребовалось несколько раз, чтобы получить полностью устраивающую меня трассировку ETW. И поскольку эта территория была для меня незнакомой, на выяснение происходящего потребовалось какое-то время. Я по-прежнему не полностью разобрался в проблеме, но на 90% понял причины её возникновения. Мне удалось многое узнать, в том числе некоторые новые подробности о Windows-планировщике, а также я обнаружил абсолютно эффективное решение.

Идеальная трассировка, которую я в конце концов записал, при загрузке в Microsoft Windows Performance Analyzer (WPA) выглядит так:


Стандартные события, окна в фокусе и использование ЦП

Эта таблица и два графика содержат кучу информации. Верхняя таблица (Generic Events) показывает записанные UIforETW нажатия клавиш. Я пытался нажимать клавишу (код виртуальной клавиши 162) раз в секунду, пока не появится поле ввода пароля. Так как эти 17 нажатий клавиши выбраны, в графике ниже они показаны вертикальными синими линиями для упрощённой визуализации времени выполнения критически важных событий. По оси x отложено время в секундах.

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

В этой статье мы узнаем, как профилировать сборку в Xcode и получать метрики. В следующей статье я расскажу о методах устранения узких мест и ускорения сборки проекта. Следует также упомянуть, что мы будем использовать проект Kickstarter iOS, который можно найти на Github. Так что давайте начнем!

Что мы измеряем?

Первое, что мы должны сделать, — определить, что мы пытаемся измерить и оптимизировать. Можно рассмотреть два варианта:

• Clean build — clean и сборки проекта. Часто clean сборка выполняется на CI для проверки нового pull request и выполнения юнит тестов.
• Incremental build — сборки проекта после значительных правок исходного кода. Эта сборка создается разработчиком во время работы над новой функциональностью.

В большинстве случаев уменьшение времени при Clean сборке должно также ускорить Incremental сборку. Оптимальным вариантом было бы создание метрик для обоих типов сборок и отслеживание их. Мы будем измерять время сборки, используя Debug конфигурацию только потому, что она используются большую часть времени и оказывают большее влияние на разработку.

Материал, перевод которого мы сегодня публикуем, посвящён поиску узких мест в производительности серверов, исправлению проблем, улучшению производительности систем и предотвращению падения производительности. Здесь, на пути к решению проблем перегруженного сервера, предлагается сделать следующие 4 шага:

1. Оценка ситуации: определение узкого места производительности сервера.
2. Стабилизация сервера: применение срочных мер по улучшению ситуации.
3. Улучшение системы: расширение и оптимизация возможностей системы.
4. Мониторинг сервера: использование автоматизированных средств, позволяющих предотвращать возникновение проблем.

Рендеринг диаграмм может серьёзно нагрузить работой браузер. Особенно если речь идёт о выводе в интерфейсе сложного приложения множества элементов, представляющих диаграммы. Попытаться улучшить ситуацию можно с помощью интерфейса OffscreenCanvas, уровень поддержки которого браузерами постепенно растёт. Он позволяет, задействовав веб-воркер, переложить на него задачи по формированию изображения, выводимого в видимый элемент <canvas>.



Статья, перевод которой мы сегодня публикуем, посвящена использованию интерфейса OffscreenCanvas. Здесь речь пойдёт о том, зачем может понадобиться этот интерфейс, о том, чего реально ожидать от его применения, и о том, какие сложности могут возникнуть при работе с ним.

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

• Количество запросов на загрузку файлов шрифтов.
• Размеры файлов шрифтов.
• Время до первого рендеринга страницы.

Мне захотелось узнать о том, как на эти показатели влияет применение вариативных шрифтов. Поэтому я сравнила их с обычными шрифтами. Вот что у меня получилось.

Эдди Османи, в статье «Цена JavaScript в 2018 году», озвучил одну ценную мысль: время, необходимое на обработку скрипта размером 200 Кб, и на обработку изображения, имеющего такой же размер, серьёзно различается. Дело в том, что при обработке кода браузеру нужно проделать более масштабную работу, чем при подготовке к использованию изображений. Вот что об этом говорится в статье:

JPEG-изображение нужно декодировать, растеризовать и вывести на экран. А JS-бандл надо, если рассматривать это упрощённо, загрузить, распарсить, скомпилировать, выполнить. На самом же деле движку приходится решать и другие задачи в процессе обработки JS-кода. В целом, стоит учитывать, что на обработку JavaScript-кода, размеры которого, в байтах, сопоставимы с размерами других материалов, тратится гораздо больше системных ресурсов.

Эти слова были написаны в 2018 году, но они до сих пор более чем справедливы. Правда, учитывая текущую обстановку, высказанная здесь мысль сегодня воспринимается немного иначе.

Привет, Хабр.

Сегодня мы предлагаем вам перевод статьи, затрагивающей не самую обсуждаемую тему: компиляцию кода в Python, а именно: работу с абстрактным синтаксическим деревом (AST) и байт-кодом. Притом, что Python является интерпретируемым языком, такие возможности в нем чрезвычайно важны с точки зрения оптимизации. О них мы сегодня и поговорим.

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

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

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

Процесс загрузки разделим на три этапа. Для каждого этапа сформулируем общие стратегии повышения производительности:

1. Начальная отрисовка: сколько времени требуется, чтобы пользователь увидел хоть что-то
   
   • Сократить запросы, блокирующие рендеринг
     
   • Избегать последовательных цепочек
     
   • Повторно использовать соединения с сервером
     
   • Сервис-воркеры для мгновенного рендеринга
2. Загрузка приложения: сколько времени требуется, чтобы пользователь смог использовать приложение
   
   • Разбить пакет приложения на части. Загружать только необходимые ресурсы. Максимизация попаданий в кэш
     
   • Проверить, что хэши частей пакета не меняются без необходимости
     
   • Запрашивать данные для страницы до загрузки всего приложения
     
   • Не блокировать рендеринг загрузкой второстепенных данных
     
   • Рассмотреть рендеринг на стороне сервера
3. Следующая страница: сколько времени требуется для перехода на следующую страницу
   
   • Запрашивать дополнительный код до того, как он понадобится
     
   • Кэшировать и повторно использовать данные на клиенте

Привет всем, меня зовут Илья. В ИТ я работаю около 6 лет, последние 2 года — в компании «Яндекс.Деньги» фронтенд-разработчиком. В обязанности входит поддерживать/развивать части приложений, в данный момент проект «Личный кабинет» (и нет, это не просто «в ие неправильные отступы поправить», «кнопке цвет поменять» или «быстро форму сошлепать»).

В отделе разработки у нас есть внутренний проект Challenges — так мы называем задачи, не связанные напрямую с основными продуктами. Это задачки, которые будут общественно полезны, помогут улучшить инфраструктуру, CI/CD и другое. Например, доработать бота, оповещающего о релизах, сделать плагин для IDEA по автогенерации assert по объекту и провести рефакторинг старой UI-библиотеки. Такие «вызовы» можно брать по желанию — они прекрасно подходят для разбавления бизнес-задач.

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

Естественно, итогом стала не просто конкретная реализованная задача, а библиотека с правилами и общими функциями (ядро/core) для реализации любых чекеров (я надеюсь). В процессе решения задачки были набиты шишки, о которых тоже хочется рассказать.

Итак, есть Jenkins, Bitbucket, почта (или Telegram, Slack — что понадобится) и необходимость проверять размер бандла. Надо это всё подружить.

Приглашаем вас 13 февраля на митап Growth Teams, чтобы поделиться крутыми докладами: узнаем, как диагностировать продукт и искать возможности роста в воронке. Ответим на вопросы, как и зачем автоматизировать закупку трафика и работу с инфлюенсерами. Команда сайта Raiffeisenbank расскажет, как им удалось оптимизировать сайт для поисковых систем, упаковать продукт и повысить конверсию в заказы.

Ждём вас в офисе Райффайзенбанка в Нагатино!

Привет, Хабр! Представляю вашему вниманию перевод «Salesforce administrator responsibilities: What needs to be done and when» автора David Taber.

Что администратор Salesforce делает весь день, неделю или месяц? Вот общее краткое изложение.

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

Начнем с самого начала: то, что Salesforce находится в облаке, не означает, что он не является основным ИТ-активом. У вас нет аппаратного или программного обеспечения, но данные, которые вы храните в Salesforce, обычно гораздо более ценные, нежели ваши сборы с Salesforce.com (SFDC). Кроме того, производительность увеличивается благодаря продажам, маркетингу и поддержке, что снижает ценность ваших данных CRM, поэтому в первую очередь стоило инвестировать так много в SFDC. Счастливые, продуктивные пользователи зависят от инфраструктуры системы и качества данных, а это означает, что системные администраторы не могут быть случайными.

Давайте рассмотрим тему передового опыта с двух сторон: что должно быть сделано и как это должно быть сделано.

Около двух лет назад наша команда поведала Хабру о своём проекте по оптимизации ОС Windows с помощью технологии нейросетей.

За прошедшие два года многое изменилось, но самое главное осталось неизменным. И в этой статье мы хотим поделиться теми открытиями и теми выводами, которые сделали за эти два года.



Если вам интересно, как в 2020ом обстоят дела по независимому продакшену софта для ПК, добро пожаловать под кат.