Загрузка, перетаскивание и масштабирование файлов в 3 раза быстрее

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

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

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

Мы хотим, чтобы Figma стала продолжением вашего творческого мышления.

Ранее в этом году мы выяснили, что реструктуризация нашего средства визуализации документов и устранение ошибок WebAssembly может сделать Figma значительно быстрее. Мы работали над этой оптимизацией месяцами. Наградой стали значительные улучшения в масштабировании, перетаскивании и скорости загрузки файлов (в 3 раза быстрее!) В плотных файлах.

Мы внедрили эти изменения для всей пользовательской базы за последние несколько недель. Читайте дальше, чтобы узнать больше о том, что изменилось, как мы измерили этот прирост и что дальше с производительностью в Figma.

Загрузка файлов - до 3 раз быстрее

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

Команда разработчиков Fluent Design в Microsoft, например, перестроила каждый собственный элемент управления Windows в один документ Figma, зафиксировав компоненты во всех возможных состояниях и перестановках. Эти, казалось бы, простые операции добавляют много вычислительной сложности и сокращают время загрузки.

«Мы проверяли пределы возможностей Figma, прежде чем приняли его в качестве основного инструмента нашей команды», - сказал нам Кайл Андерсон, старший дизайнер продукта в команде Fluent.

К счастью, за последние 2 месяца оптимизация WebAssembly и ряд других изменений помогли нам сократить время загрузки большого реалистичного документа с 29 до менее 8 секунд.

«Он значительно легче и производительнее». - Кайл Андерсон, Microsoft

WebAssembly теперь включен во всех местах, где наши пользователи работают в Figma [1]. Сюда входят настольные приложения, Chrome, Firefox и Safari как для macOS, так и для Windows. Влияние этого огромно по всем направлениям.

«Он намного легче и производительнее», - сказал Кайл. «Скорость, с которой ваша команда исправляет исправления, действительно обнадеживает, и мы очень довольны продуктом».

Непрерывное взаимодействие

Конечно, важность производительности не заканчивается, когда ваш файл загружен. Две из наиболее распространенных операций, при которых пользователям Figma нужна скорость, - это увеличение / уменьшение масштаба и перетаскивание слоев.

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

Масштабирование теперь в 3 раза быстрее.

Перетаскивание теперь в 3 раза быстрее.

N3TWORK, компания, занимающаяся компьютерными играми и медиа, особенно оценила эти улучшения. Их файлы плотны и заполнены растровыми изображениями, поэтому их директор по UX-дизайну Адам Донкин лично пришел поговорить о производительности. «Это одна из лучших особенностей Figma - я чувствую, что наладил там отношения с людьми, и мы вместе решаем проблемы», - сказал он. «Создается впечатление, что Figma - это мой продукт».

После нескольких минут диагностики проблемы с Адамом лично, мы включили наш новый модуль рендеринга для N3TWORK. Они увидели мгновенный всплеск скорости публикации компонентов и загрузки файлов. «Вам не нужно было его измерять, это было совершенно очевидно», - сказал Адам. «Я вернулся в офис, и несколько человек проверили его и увидели улучшения во всех случаях. Это было супер захватывающе ».

Почему мы измеряем как среднее время кадра, так и максимальное время кадра

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

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

Один из руководящих принципов нашей команды дизайнеров - «отдавайте предпочтение прямым манипуляциям».

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

Более высокое максимальное время кадра вызывает резкий эффект «заминки», как будто ваша парусная лодка внезапно ударяется о скалу. Для сравнения, более высокое среднее время вызывает волнение, как при езде по булыжнику.

Приведенные ниже примеры показывают это различие между ними на практике.

В этом примере с уменьшением максимального времени кадра все три гифки имеют среднюю частоту кадров 15 кадров в секунду. В крайней левой анимации каждый кадр составляет 67 мс. В центральной анимации длина большинства кадров составляет 33 мс, но каждый шестой кадр имеет длину 200 мс. В правой анимации длина большинства кадров составляет 33 мс, но каждый одиннадцатый кадр имеет длину 367 мс.

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

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

Все три из них имеют максимальное время кадра 167 мс, при этом большинство кадров занимает 33 мс. Однако в левой анимации заминки 167 мс происходят каждый 28-й кадр. В центре анимации каждый 10-й кадр. В правой анимации каждый 4-й кадр.

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

Отслеживание среднего и максимального времени кадра в Figma

Мы измерили наш прогресс за последние 3 месяца в масштабировании и перетаскивании сложного документа с точки зрения среднего и максимального времени кадра.

Как видно из диаграмм ниже, время масштабирования и перетаскивания уменьшилось. Для увеличения нашего эталонного документа мы сохранили необходимое среднее время кадра для 60 кадров в секунду и уменьшили максимальное время кадра настолько, чтобы не пропустить какие-либо кадры. Для перетаскивания мы улучшили средний кадр с 30 до 60 кадров в секунду и уменьшили заминки со 120 мс до 30 мс, пропуская один кадр вместо шести во время заминки.

За кадром: подробности для скептиков

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

Чтобы создать последовательные и реалистичные тесты, мы запускаем версию нашего приложения в Electron (по сути, причудливую оболочку для Chrome) и имитируем взаимодействия пользователя, такие как перетаскивание, панорамирование, масштабирование, выбор и некоторые другие ключевые взаимодействия. Мы измеряем, сколько времени мы тратим на ключевые части кода (обработка событий, рендеринг, обновление пользовательского интерфейса и т. Д.), И отслеживаем их с течением времени.

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

Что дальше: копирование, вставка, удаление, отмена, улучшение зеркального отображения и многое другое

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

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

Мы также недавно внесли изменения, чтобы помочь нам отслеживать операции, которые приводят к блокировке Figma более чем на 100 мс, и определили несколько важных областей для начала: копирование, вставка, удаление, отмена, повтор и экспорт.

Будьте на связи!

Сноски

[1]: Мы объявили об этой победе в прошлом году, но по-настоящему осознавая, что это был путь, включающий обсуждение с командой Chrome WebAssembly, погружение в исходный код их компилятора, поиск обходных путей для избежания взаимоблокировок компилятора и внесение исправлений в Electron для резервного копирования Chrome Исправления ошибок GPU.