Статья про ремонт квартиры, про эффективное использование графических ресурсов для современных устройств. От смарт часов до телевизоров на стену.

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

Ну, что готовы поиграть ..? Тогда погнали

Те телефоны, о которых идёт речь в заголовке, по-английски называют «feature phone». Они отличаются крайне скромными возможностями. Кроме того, они весьма доступны, так как стоят в районе $20-25. Их можно сравнить с облегчёнными версиями современных смартфонов. Такие телефоны позволяют сотням миллионов человек из развивающихся стран пользоваться веб-ресурсами.


Телефон Jio

Если в основе сайта лежат технологии, ориентированные на обеспечение высокой скорости его работы, то от этого выиграют все — и владельцы простых дешёвых телефонов, и те, кто смотрит веб-страницы со свежих мощных смартфонов.

Привет, Хабр! Представляю вашему вниманию перевод статьи «How to optimize image loading on your website».

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

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

Проблема

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

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

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

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

Немного о контексте (GPU)

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

Существует множество отличных статей и туториалов о производительности в Unity. Этой статьёй мы не пытаемся заменить или улучшить их, это всего лишь краткое изложение шагов, сделанных нами после прочтения этих статей, а также шагов, позволивших решить наши проблемы. Настоятельно рекомендую вам как минимум изучить материалы на https://learn.unity.com/.

В процессе разработки своей игры мы столкнулись с проблемами, время от времени вызывавшими торможения игрового процесса. Потратив какое-то время в Unity Profiler, мы обнаружили два типа проблем:

• Неоптимизированные шейдеры
• Неоптимизированные скрипты на C#

Большинство проблем было вызвано второй группой, поэтому я решил сосредоточиться в этой статье на скриптах C# (возможно, ещё и потому, что за свою жизнь я не написал ни единого шейдера).

Поиск слабых мест

Цель этой статьи — не написать туториал по использованию профилировщика; я хотел просто рассказать о том, что нас в основном интересовало в процессе профилирования.

Unity Profiler — всегда самый лучший способ поиска причин задержек в скриптах. Настоятельно рекомендую профилировать игру непосредственно в устройстве, а не в редакторе. Поскольку наша игра создавалась для iOS, мне нужно было подключить устройство и использовать показанные на изображении Build Settings, после чего профилировщик подключался автоматически.


Build Settings (параметры сборки) для профилирования

Если вы попробуете загуглить «Random lag in Unity» или другой похожий запрос, то обнаружите, что большинство людей рекомендует сосредоточиться на сборке мусора, поэтому именно так я и поступил. Мусор генерируется каждый раз, когда вы прекращаете использовать какой-то объект (экземпляр класса), после чего время от времени запускается сборщик мусора Unity для уборки беспорядка и освобождения памяти, что требует безумного количества времени и приводит к падению частоты кадров.

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



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

1. Исправить процесс авторизации — нормально спроектировать экраны и положить мучениям пользователей конец. Это будет стоить от NNN рублей.
2. Автоматизировать саппорт — подключить виртуального ассистента, который научит клиентов пользоваться приложением. Это будет стоить от NN рублей.

Итак, вы оптимизировали самые очевидные части своей игры. Однако на самом деле это не так. Вы упустили хитрый, не совсем заметный момент: оптимизацию иерархии сцены Unity.

А что не так с иерархией? Позвольте вам кое-что показать.

Запустите Unity и откройте проект своей игры. Затем запустите игру на целевом устройстве
и подключите к ней Unity Profiler. Запишите несколько кадров во время игрового процесса.

В Unity Profiler поищите следующие неприятные маркеры профайлера:


Не нашли? Продолжайте искать, уверен, найдётся хотя бы один.

Это могут быть UpdateRendererBoundingVolumes, Physics.SyncColliderTransform или TransformChangedDispatch.

Они появятся, когда вы уже будете готовы сдаться. Они возникнут, когда вы уже наведёте курсор мыши на кнопку закрытия Profiler.

Нашли? Если да, то вам повезло. Я тоже нашёл их в одном из своих предыдущих проектов и узнал, как полностью избавиться от них. Я понял, какое зло в них скрыто…

Хотите узнать секреты производительности иерархий сцен Unity?

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

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

Добро пожаловать под кат!

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

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

Для меня очень важно подбирать хорошие заголовки для своих постов, но я сразу же вспомнил, что подходящее название «48 ядер заблокированы девятью инструкциями» уже занято [перевод на Хабре] постом, написанным меньше месяца назад. Количество заблокированных процессоров отличается, а цикл немного длиннее, но на самом деле всё это заставляет испытывать дежавю. Поэтому пока я объясняю новую найденную проблему, мне был хотелось поразмыслить над тем, почему это случается постоянно.

Почему это происходит?

Грубо говоря, такие проблемы возникают вследствие наблюдения, которое я назову Первым законом Доусона о вычислениях: O(n²) — это магнит для алгоритмов, которые плохо масштабируются: они достаточно быстры, чтобы попасть в продакшен, но достаточно медленны, чтобы всё портить, когда туда попадут.


O(n²) в действии — данные взяты из моего случая

Давным-давно мы, в деле кэширования, всецело полагались на браузеры. Разработчики в те дни почти никак не могли на это повлиять. Но потом появились прогрессивные веб-приложения (Progressive Web App, PWA), сервис-воркеры, API Cache. Внезапно случилось так, что в руках программиста оказались широкие полномочия, власть над тем, что попадает в кэш, и над тем, как оно туда попадает. Теперь мы можем кэшировать всё, что хотим… в этом-то и кроется потенциальная проблема.



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

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

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

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

В материале мы расскажем

• Чем виртуальный ассистент отличается от обычного чат-бота
• Правда ли, что виртуальные ассистенты понимают язык
• Как мы научили робота понимать контекст и написали язык lialang
• Проверка кейсами: как мы автоматизировали поддержку в трёх банках
• Создание Lia Platform и движка для интерфейсов
• Три шага: как работает платформа для сборки виртуальных ассистентов (где собрать робота может любой, даже не-программист)

Эффективная стратегия автоматизированного тестирования кода чрезвычайно важна для обеспечения быстрой и качественной работы команд программистов, занимающихся поддержкой и развитием веб-проектов. Автор статьи говорит, что в компании StackPath, в которой он работает, с тестированием сейчас всё обстоит благополучно. У них имеется множество инструментов для проверки кода. Но из такого разнообразия нужно выбрать то, что лучше всего подойдёт в каждом конкретном случае. Это — отдельная проблема. А после того, как нужные инструменты выбраны, надо ещё принять решение по поводу порядка их использования.

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

Попытаюсь коротко рассказать про черное и белое SEО. Что это такое, стоит ли пользоваться и т.д.Для начала, сама аббревиатура SEO, расшифровка которой звучит, как: «Search Engine Optimization», уже предполагает некую «серость». Слово «оптимизировать» хоть и не звучит как что-то плохое, но подразумевает под собой искусственный «подгон» под некие правила поисковой машины. В реальной жизни всё более прагматично, ведь цель одна — вывести сайт в топ и заработать денег. Но всё по порядку.


Белое SEO (это не очень интересный блок, можно пропускать:))

Вы все знаете, что подразумевает под собой «белое» SEO. Контент — король. Юзабилити — королева...? Здесь всё в соответствии с рекомендациями от Yandex и Google: размещайте хороший контент, делайте сайт удобным, и он продвинется. А если нет? Вариантов два:

а) Вы сделали плохой контент и (или) сайт неудобен по мнению поисковиков;
б) У вас хороший контент и удобный сайт, но вам просто не повезло;
в) Есть ещё третий вариант, очень популярный. Вы думаете, что у вас отличный контент и удобный сайт, но на самом деле это не так.

А в чем проблема сделать всё как надо и выйти в ТОП, например, интернет магазину?

Сегодня публикуем перевод третьей части серии материалов об ускорении instagram.com. В первой части мы говорили о предварительной загрузке данных, во второй — об отправке данных клиенту по инициативе сервера. Здесь речь пойдёт о кэшировании.

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

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

Привет! Мы тут в Playrix решили сделать свой Unity3D. А там есть Animator. В этой статье я  расскажу, как мы сделали его у себя и как он работает.

Практически в любой статье или инструменте для оптимизации скорости сайтов есть скромный пункт «используйте CDN». Вообще, CDN – это content delivery network или сеть доставки контента. Мы в компании «Метод Лаб» часто встречаемся с вопросами клиентов по этой теме, некоторые самостоятельно включают себе CDN. Цель этой статьи разобраться, что может дать CDN с точки зрения скорости загрузки сайта, какие проблемы могут возникать и в каких случаях использование CDN оправдано.



Обведённые на картинке задержки вызваны использованием CDN.

Автор материала, перевод которого мы сегодня публикуем, говорит, что он, в середине сентября 2019, наконец-то завершил проект, которым занимался уже год. Целью этого проекта было сокращение размеров манифеста, необходимого для инициализации асинхронного JavaScript-конвейера Wikipedia. А именно, размер манифеста составлял 36 Кб. Его нужно было уместить в менее чем 28 Кб, что соответствует двум 14-килобайтным фрагментам последовательности интернет-пакетов.

Результатом этого проекта стала ежедневная экономия 4.3 терабайт трафика.

Сначала размер манифеста превышал 36 Кб, а после оптимизации его размер стал меньше 28 Кб

На графике показано постепенное уменьшение размеров манифеста. Речь идёт о сжатых данных (то есть это — чистая нагрузка на сеть, которую создаёт передача этих данных с сервера в браузер).

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



Автор статьи, перевод которой мы сегодня публикуем, работает в Wix. Он хочет рассказать о том, как смог уменьшить размер одного бандла примерно на 80%, используя Webpack Analyzer и React Lazy/Suspense.