Дизайн
Mish
11 703

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

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

В закладки
Аудио

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

К примеру, вариаций блока списка высотой 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 ГБ.

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

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

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

Выводы:

  1. Если в проекте предполагается свыше тысячи экранов — храните компоненты в отдельном файле.
  2. Сразу закладывайте возможность дробления одного файла на несколько.
  3. Заранее продумайте структуру библиотеки.
  4. Если размер файла больше 700–800 МВ, следует планировать оптимизацию. Больше 1,5 GB — проводить оптимизацию немедленно, иначе есть риск на какое-то время остаться без доступа к файлу и ждать помощи от службы поддержки.
  5. Если нужно провести оптимизацию, обсудите это с заказчиком, объясните, почему это важно, договоритесь о сроках и бюджете заранее.
  6. Периодически проводите тестирование скорости работы файлов на слабом железе.
  7. Изучайте матчасть, читайте статьи на английском. Это расширит ваш кругозор и поможет лучше понять особенности работы с вашим рабочим инструментом.
{ "author_name": "Mish", "author_type": "self", "tags": ["figma"], "comments": 57, "likes": 79, "favorites": 310, "is_advertisement": false, "subsite_label": "design", "id": 120754, "is_wide": false, "is_ugc": true, "date": "Thu, 16 Apr 2020 15:06:34 +0300", "is_special": false }
Онлайн-интенсив «10 секретов эффективного маркетинга e-commerce»
23 июня Онлайн Бесплатно
Объявление на vc.ru
0
57 комментариев
Популярные
По порядку
Написать комментарий...
12

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

Ответить
1

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

Ответить
1

Последнее, по моему мнению, значит то, что макбук про не самый мощный компьютер.

Ответить
0

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

Ответить
2

на порядок? за счёт чего? свяжут синей изолентой 10 интеловских процов?

Ответить
0

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

Ответить
2

Это еще и во многом проблема Фигмы. Именно из за технологий на которых она сделана. Веб-стек посто не приспособлен (да и изначально он формировался для других потребностей) для этого.

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

Ответить
0

По-моему, уложить не оптимизированным ПО можно любую конфигурацию. Яркий тому пример — продукты Adobe

Ответить
0

У Адоб немело проблем, конечно. Но больше удивляет, что какой нибудь GMAIL (вкладка в браузере) может потреблять больше ресурсов чем Illustrator, например (от этого, конечно, не тормозит, но сам факт).

Ответить
5

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

Ответить
3

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

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

Ответить
0

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

Ответить
0

Нужно ждать следующего релиза, чтобы заменить одну картинку? 🤔

Ответить
0

Мы специализируемся на дизайне и фронте, и ребята которые занимаются деплоем у нас наемные - у нас с ними согласовывается время деплоя по графику :) 

Ответить
1

Ещё ашыбочка - когда у вас там деплой-то? :)

Ответить
0

Глаз-алмаз :) Долго вычитывал мелкий текст на твоём скрине, полез проверять сам на сайт.
И только в движущемся варианте заметил RESE_RCH на фоне.

Ответить
4

Глаз-то алмаз, а словил минус от автора 😁

Ответить
0

Может, он просто промазал по плюсу?)

Автор, статья классная и полезная, спасибо вам!
Да и бесплатный аудит сайта от других дизайнеров – не повод ставить минуса.

Ответить
2

Правда промахнулись:) Сами не знаем как так вышло... Аудит на бетте всегда полезен :)

Ответить
2

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

Ответить
0

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

Ответить
1

Спасибо, отличная статья!

Ответить
1

Как раз сегодня столкнулся с этим. Благодарочка в виде апвоута!

Ответить
1

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

Ответить
1

Спасибо за статью, у меня 3 вопроса:
1. Итак, вы решили не делить один большой файл с макетами приложения на несколько файлов. Не боитесь наступить на те же грабли, на которые наступили при создании UI-кита в одном файле с макетами? Насколько понял, у вас проект рос, растёт и будет расти. Собственно, сколько оптимизацией одного файла не занимайся, макетов будет всё больше и больше. В итоге у вас просто закончится место в файле и вы вынуждены будете дробить всё на несколько файлов. Вы специально ждёте этого момента? :) 
2. Что с бэкапами? Если что-то критичное случится (тьфу-тьфу) на конкретной страничке файла, то бэкапить придётся весь файл со всеми страницами. А если придётся бэкапиться на несколько недель, а то и на месяц назад, то в трубу улетает весь труд за несколько недель/месяц. От этой мысли страшно не становится?) 
3. Что там у вас по autolayout? Уже юзаете его в компонентах или ждёте пока фигма доведёт его до ума?

peace 🙌🏻

Ответить
0

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

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

Ответить
0

Все верно. Спустя несколько релизов, работа обычно переходит на продуктовую стадию — это когда приложение хорошо работает и уже не нужно разрабатывать кучу новых разделов в короткий промежуток времени. В этот момент необходимость в поддержке всех старых макетов отпадает. Собственно, зачем, если приложение сверстано, протестировано, проревьюировано, «отфидбечено» и отшлифовано :—) В такой момент происходит медленная разработка новых фич и шлифовка старых. Ни дизайнерам, ни разработчикам не нужно уже видеть в одном месте все макеты, тем более старые версии типа MVP. Отдавать макеты разработке можно частями. Если нужно кардинально изменить все элементы, которые встречаются на каждом экране — можно просто отдать один макет с пометкой «поменять везде». 

Ответить
0

Отвечу от Mish, так как я принимал участие в процессе.

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

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

 3. Autolayout очень любим и активно пользуемся на каждом проекте. При помощи пары лайфхаков можно делать удобные штуки. Например такие:

Ответить
1

ребят, огромное спасибо за статью, добавил в закладки

Ответить
0

Пункт меню View >  Resource use.
Почему-то у меня такого пункта нет, версия фигмы Release 85

Ответить
2

Смотри не системное меню, а меню фигмы :)

Ответить
1

Классно ) получилось включить.
Странно, что меню называются одинаково, и пункты в них почти одни и те же. Кроме Resource Use и Toggle full screen

Ответить
1

Не в том View ищите.
Вам надо нажать на гамбургер меню Фигмы -> View -> Resource Use

Ответить
0

Да, спасибо, там и нашёл. Просто странно, что в разных меню View почти все пункты совпадают, кроме двух. 

Ответить
0

Может какие-то системные ограничения MacOS или банально ребята из Figma не досмотрели

Ответить
0

Я решаю проблему тормозов так: в одном файле создаю несколько page и раскидываю по ним все макеты сайта. 

Ответить
1

Когда макетов 300–400 это действительно может отсрочить возникновение проблем. Но когда одних page уже штук 20 и в каждом из них макетов по 50–100, нужны более радикальные меры :—)

Ответить
1

У меня вот так)

Ответить
0

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

Ответить
0

Не понял тебя. Дай пример скрином

Ответить
5

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

Ответить
1

С эмоджи ты грамотно придумал. А как делать вторым уровнем страницы?

Ответить
0

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

Ответить
1

Ну молоток. Грамотно.

Ответить
0

Пасиб)

Ответить
0

При 500 макетах и работает быстро?  Что-то мой дизайнер делает не так.

Ответить
1

Мы всегда рады подсказать и помочь! Пусть обращается!

Ответить
1

Может быть там растровых картинок много? Из за этого может тормозить даже если сам файл не очень большой. 

Ответить
0

Ребят, у вас «Разлел» на скринах

Ответить
1

🙄 Никто ничего не видел! Фотошоп! Нас подставили!

Ответить
0

Была такая проблема. Мы просто расфигачили файл на несколько файлов и стало проще)))

Ответить
0

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

Ответить
0

"Кстати, если ваш файл займет 2GB, он может перестать открываться, так что не доводите до такого и вовремя проводите оптимизацию." :)

Ответить
0

Не спорю, просто у меня проблемы начались только на 2,7 гб

Ответить
0

Да у вас мощный комп :—) фигма пишет, что до 2GB еще можно открыть файл, а вот после — может быть больно. По-хорошему, 1GB — это уже многовато. Я вообще раньше думал, что фигма практически «бесконечна». 

Ответить
0

Тоже так думал, пока не столкнулся с этой проблемой). На англоговорящих форумах и сказали, что лимит 3гб.

Ответить
0

Кстати, в статье есть ссылка на блог фигмы, где они пишут про 2Гб, так что вам повезло с 2,7 )) я бы на вашем месте больше так не рисковал ))

Ответить

Прямой эфир