Оптимизация проекта Figma на примере большого банковского приложения

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

Оптимизация проекта Figma на примере большого банковского приложения

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

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

Мы студия Mish, преимущественно сфокусированы на дизайне сайтов и мобильных приложений. За время работы мы много сталкивались с крупными проектами, в частности, в банковской сфере. В рассматриваемом случае клиент поставил нам задачу разработать дизайн двух мобильных приложений для SBI: банкинг «для взрослых» и отдельное банковское приложение «для детей», в котором есть полноценный счет, можно выполнять задания родителей, получать награды и копить на мечты. Разработка приложений осуществлялась для двух платформ.

Через полгода работы только во «взрослом» приложении появилось свыше шести сотен экранов для каждой платформы. Тогда мы столкнулись с проблемой: люди, задействованные на проекте, — разработчики, аналитики, тестировщики, заметили, что файлы Figma стали работать медленнее. А именно: долго открывались, тормозили при зуме и порой даже вылетали. Даже дизайнеры, работающие на MacBook Pro, испытывали трудности. Например, десять фреймов могли копироваться около минуты: к примеру, выделил их, нажал Cmd+C и ждешь — Figma все это время не двигается. Потом, если не повезет, выскакивало сообщение «You run out of memory». После этого приходилось перезапускать Figma и копировать фреймы по одному.

Оптимизация проекта Figma на примере большого банковского приложения

Поискав информацию в Интернете и на сайте Figma, мы нашли причину и поняли, как решить проблему. Статья, которая нам помогла🇬🇧.

Две основные причины тормозов:

  1. В одном файле расположено слишком много макетов;
  2. Основные мастер-компоненты собраны с большим количеством скрытых слоев.

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

Расскажем подробнее о каждом пункте:

Оптимизация проекта Figma на примере большого банковского приложения

Причина 1. В одном файле расположено слишком много макетов

Дизайн в«взрослого» приложения состоит из трех файлов:

  • файл с макетами и компонентами iOS;
  • файл с макетами и компонентами Android;
  • файл с компонентами общих для платформ иконок и графики.

Есть еще два файла с «детским» приложением, но мы не стали их оптимизировать, так как эти файлы работают быстро: в них меньше пяти сотен макетов.

Оптимизация проекта Figma на примере большого банковского приложения

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

Способ 1. Продублировать файл нужное количество раз и в каждом дубликате удалить лишние макеты или страницы.

Оптимизация проекта Figma на примере большого банковского приложения

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

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

Оптимизация проекта Figma на примере большого банковского приложения

Данный способ выглядит вполне жизнеспособным. Во всяком случае, не противоречит каким-либо очевидным правилам поведения программы. Но мы не знали о том, что в Figma есть серьезная скрытая проблема: при переносе макета в новый файл многие дочерние компоненты, находящиеся в нем, теряют связь с мастер-компонентом, т.е. часть скопированных дочерних компонентов при вставке превращается в обычные фреймы. Это та самая фундаментальная бага, о которой ребята из Figma в курсе и с которой они воюют уже года два. Подробнее о проблеме тут 🇬🇧.

Подобные баги могут происходить даже при копировании и вставке макета внутри одного файла, если делать это через «Cmd+C ⟶ Cmd+V» или «Копировать ⟶ Вставить». Нам показалось, что часто это происходит на сложных компонентах, а также если компонент уже копировался и вставлялся неоднократно. Чтобы избежать этого бага, нужно сложные многосоставные компоненты копировать через зажатый Opt или Alt. Если вы сталкивались с подобной проблемой, поделитесь в комментариях своими наблюдениями.

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

Причина 2. Основные компоненты собраны с большим количеством скрытых слоев

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

Оптимизация проекта Figma на примере большого банковского приложения

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

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

Вариант 1. Создать один компонент и расположить в нем все состояния в виде скрытых слоев.

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

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

Вариант 2. Создать отдельный мастер-компонент под каждый случай.

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

Изначально мы пошли по первому варианту — сделали «супер-компоненты», внутри которых учитывались все возможные состояния в виде скрытых слоев. Это привело к увеличению количества слоев и размера файла. Лучшим решением оказался второй вариант, при котором для каждого состояния элемента создается отдельный компонент.

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

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

Процесс работы

Работали на «живом» проекте, на котором параллельно присутствовали разработчики, аналитики, тестировщики и представители заказчика. Задачей занимался один дизайнер, параллельно разрабатывая новые фичи и занимаясь поддержкой разработки. На переработку двух платформ ушло около месяца. Мы вели лог основных показателей файла и скринили табличку используемых Figma ресурсов (View > Resource use) при закрытии каждого раздела. Итак, что получилось?

Объективные показатели по платформам

iOS:

  • Количество слоев уменьшилось в 3 раза с 750 тыс. до 250 тыс.
  • Вес файла уменьшился в 2,3 раза с 0,89 ГБ до 0,39 ГБ.

Android:

  • Количество слоев уменьшилось в 4 раза с 940 тыс. до 230 тыс.
  • Вес файла уменьшился в 4 раза с 1,4 ГБ до 0,35 ГБ.
Оптимизация проекта Figma на примере большого банковского приложения

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

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

Кстати, если ваш файл займет 2GB, он может перестать открываться, так что не доводите до такого и вовремя проводите оптимизацию. Следить за показателями тут View > Resource use.

Выводы:

  1. Если в проекте предполагается свыше тысячи экранов — храните компоненты в отдельном файле.
  2. Сразу закладывайте возможность дробления одного файла на несколько.
  3. Заранее продумайте структуру библиотеки.
  4. Если размер файла больше 700–800 МВ, следует планировать оптимизацию. Больше 1,5 GB — проводить оптимизацию немедленно, иначе есть риск на какое-то время остаться без доступа к файлу и ждать помощи от службы поддержки.
  5. Если нужно провести оптимизацию, обсудите это с заказчиком, объясните, почему это важно, договоритесь о сроках и бюджете заранее.
  6. Периодически проводите тестирование скорости работы файлов на слабом железе.
  7. Изучайте матчасть, читайте статьи на английском. Это расширит ваш кругозор и поможет лучше понять особенности работы с вашим рабочим инструментом.
9494
58 комментариев

Даже дизайнеры, работающие на MacBook Pro, испытывали трудности

16
Ответить

По опыту, на относительно мощных маках в основном работают дизайнеры и iOS-разработчики. У большинства людей в команде стандартные офисные ПК. Команды на таких проектах большие — 30–50 человек: дизайнеры, тестировщики, бизнес-аналитики, проджект-менеджеры, представители заказчика, разработчики, редакторы, юристы и тд. Если проект начинает тормозить на прошке, это значит, что бОльшая часть команды страдает в разы сильнее.

1
Ответить

Взял некоторые советы, благодарочка

6
Ответить

Хорошая статья, молодцы! 

PS: что-то не так с логотипом московской биржи - у нее будто строук не удалили или пикселёк не дотравили:

3
Ответить
Автор

Да знаем, спасибо, бага от SVG уже в следующем релизе поправим, новый сайт пока в бетте.

Ответить

"Также мы получили возможность поделить файл" – так вам удалось поделить файл таким образом, чтобы сохранить связь инстансов с мастер-компонентами в файлах дупликатах?

2
Ответить

Мы не стали пока этого делить файл, так как скорость работы системы и так выросла в ходе оптимизации. Мы вынесли мастер-компоненты в отдельные файлы и теперь сможем поделить файл с макетами на любое количество частей. Тестировали эту возможность, при необходимости — сделаем это за 5–10 минут. 

Ответить