Оптимизация проекта Figma на примере большого банковского приложения
Расскажем, как мы провели оптимизацию и ускорили работу больших файлов Figma в три раза. Подтолкнули нас к этому тормозящие и не открывающиеся файлы у команды на проекте. Особенно это ощутили ребята с не самым мощным железом: файлы загружались по пять-десять минут.
В процессе поиска решения мы столкнулись с некоторыми ограничениями и багами в Figma, о которых полезно знать заранее и которые мы подробно изложим ниже.
Статья поможет избежать фундаментальных ошибок при разработке дизайн-систем. Материал будет особенно полезен дизайнерам, разработчикам и бизнесу, которые работают над проектами, где свыше пятисот макетов в дизайне.
Мы студия Mish, преимущественно сфокусированы на дизайне сайтов и мобильных приложений. За время работы мы много сталкивались с крупными проектами, в частности, в банковской сфере. В рассматриваемом случае клиент поставил нам задачу разработать дизайн двух мобильных приложений для SBI: банкинг «для взрослых» и отдельное банковское приложение «для детей», в котором есть полноценный счет, можно выполнять задания родителей, получать награды и копить на мечты. Разработка приложений осуществлялась для двух платформ.
Через полгода работы только во «взрослом» приложении появилось свыше шести сотен экранов для каждой платформы. Тогда мы столкнулись с проблемой: люди, задействованные на проекте, — разработчики, аналитики, тестировщики, заметили, что файлы Figma стали работать медленнее. А именно: долго открывались, тормозили при зуме и порой даже вылетали. Даже дизайнеры, работающие на MacBook Pro, испытывали трудности. Например, десять фреймов могли копироваться около минуты: к примеру, выделил их, нажал Cmd+C и ждешь — Figma все это время не двигается. Потом, если не повезет, выскакивало сообщение «You run out of memory». После этого приходилось перезапускать Figma и копировать фреймы по одному.
Поискав информацию в Интернете и на сайте Figma, мы нашли причину и поняли, как решить проблему. Статья, которая нам помогла🇬🇧.
Две основные причины тормозов:
- В одном файле расположено слишком много макетов;
- Основные мастер-компоненты собраны с большим количеством скрытых слоев.
И то, и другое существенно снижало основные жизненные показатели файла: занимаемую память и общее количество слоев.
Расскажем подробнее о каждом пункте:
Причина 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.
Выводы:
- Если в проекте предполагается свыше тысячи экранов — храните компоненты в отдельном файле.
- Сразу закладывайте возможность дробления одного файла на несколько.
- Заранее продумайте структуру библиотеки.
- Если размер файла больше 700–800 МВ, следует планировать оптимизацию. Больше 1,5 GB — проводить оптимизацию немедленно, иначе есть риск на какое-то время остаться без доступа к файлу и ждать помощи от службы поддержки.
- Если нужно провести оптимизацию, обсудите это с заказчиком, объясните, почему это важно, договоритесь о сроках и бюджете заранее.
- Периодически проводите тестирование скорости работы файлов на слабом железе.
- Изучайте матчасть, читайте статьи на английском. Это расширит ваш кругозор и поможет лучше понять особенности работы с вашим рабочим инструментом.
Даже дизайнеры, работающие на MacBook Pro, испытывали трудности
По опыту, на относительно мощных маках в основном работают дизайнеры и iOS-разработчики. У большинства людей в команде стандартные офисные ПК. Команды на таких проектах большие — 30–50 человек: дизайнеры, тестировщики, бизнес-аналитики, проджект-менеджеры, представители заказчика, разработчики, редакторы, юристы и тд. Если проект начинает тормозить на прошке, это значит, что бОльшая часть команды страдает в разы сильнее.
Взял некоторые советы, благодарочка
Хорошая статья, молодцы!
PS: что-то не так с логотипом московской биржи - у нее будто строук не удалили или пикселёк не дотравили:
Да знаем, спасибо, бага от SVG уже в следующем релизе поправим, новый сайт пока в бетте.
"Также мы получили возможность поделить файл" – так вам удалось поделить файл таким образом, чтобы сохранить связь инстансов с мастер-компонентами в файлах дупликатах?
Мы не стали пока этого делить файл, так как скорость работы системы и так выросла в ходе оптимизации. Мы вынесли мастер-компоненты в отдельные файлы и теперь сможем поделить файл с макетами на любое количество частей. Тестировали эту возможность, при необходимости — сделаем это за 5–10 минут.
Спасибо, отличная статья!
Как раз сегодня столкнулся с этим. Благодарочка в виде апвоута!
Спасибо, тоже пересмотрю свои проекты на работе, фронты жалуются на торможение. Очень много скрытых слоев в компонентах.
Пока лечили это переносом страниц в отдельные проекты.
Спасибо за статью, у меня 3 вопроса:
1. Итак, вы решили не делить один большой файл с макетами приложения на несколько файлов. Не боитесь наступить на те же грабли, на которые наступили при создании UI-кита в одном файле с макетами? Насколько понял, у вас проект рос, растёт и будет расти. Собственно, сколько оптимизацией одного файла не занимайся, макетов будет всё больше и больше. В итоге у вас просто закончится место в файле и вы вынуждены будете дробить всё на несколько файлов. Вы специально ждёте этого момента? :)
2. Что с бэкапами? Если что-то критичное случится (тьфу-тьфу) на конкретной страничке файла, то бэкапить придётся весь файл со всеми страницами. А если придётся бэкапиться на несколько недель, а то и на месяц назад, то в трубу улетает весь труд за несколько недель/месяц. От этой мысли страшно не становится?)
3. Что там у вас по autolayout? Уже юзаете его в компонентах или ждёте пока фигма доведёт его до ума?
peace 🙌🏻
При таких объемах (в одном проекте например) и если предположить, что это еще будет рости дальше (возможно в разы), то заниматься заниматься дизайном (в статике) уже выглядит избыточным. В какой то момент такое количество экранов (которые в итоге отличаются допустим на 2-3 элемента) будет настолько большим, что поддерживать будет нереально.
Адекватный выход, похоже, это писать код — и объем работы сократится и поддержка проще и быстрее, места меньше, навигация проще и с версиями все понятно.
При этом не обязательно дизайн-студии брать всю разработку. Если сам процесс разработки организован нормально, то UI layer можно писать отдельно от моделей. Это в любом случае хорошая практика
Отвечу от Mish, так как я принимал участие в процессе.
1. В ходе оптимизации мы вынесли мастер-компоненты в отдельные файлы. Теперь можем делить файл с макетами на любое количество частей методом дублирования и удаления лишних разделов. Мы не стали пока этого делать, так как скорость работы системы и так выросла. При необходимости поделить — сделаем это за 5–10 минут.
2. В фигме есть история версий. В день автоматически делаются десятки бэкапов. Каждый из них хранится на сервере Figma. Можно восстановить файл таким, какой он был вчера вечером или в полдень 19 декабря 2019 года.
3. Autolayout очень любим и активно пользуемся на каждом проекте. При помощи пары лайфхаков можно делать удобные штуки. Например такие:
ребят, огромное спасибо за статью, добавил в закладки
Пункт меню View > Resource use.
Почему-то у меня такого пункта нет, версия фигмы Release 85
Смотри не системное меню, а меню фигмы :)
Не в том View ищите.
Вам надо нажать на гамбургер меню Фигмы -> View -> Resource Use
Я решаю проблему тормозов так: в одном файле создаю несколько page и раскидываю по ним все макеты сайта.
Когда макетов 300–400 это действительно может отсрочить возникновение проблем. Но когда одних page уже штук 20 и в каждом из них макетов по 50–100, нужны более радикальные меры :—)
При 500 макетах и работает быстро? Что-то мой дизайнер делает не так.
Мы всегда рады подсказать и помочь! Пусть обращается!
Может быть там растровых картинок много? Из за этого может тормозить даже если сам файл не очень большой.
Ребят, у вас «Разлел» на скринах
🙄 Никто ничего не видел! Фотошоп! Нас подставили!
Была такая проблема. Мы просто расфигачили файл на несколько файлов и стало проще)))
В фигме размер файла самого проекта ограничен 3 гб. Я недавно сам себе проблем подкинул, когда решил сделать компонент для логотипов и засунул туда около 30 изображений. При копировании компонента, копировались и скрытые изображения. А на одном экране таких компонентов могло быть более десяти (делал интерфейс для инвестиционной платформы). Когда счётчик слоев приблизился к нескольким миллионам, фигма перестала открывать проект и предложила только восстановить предыдущую копию.
"Кстати, если ваш файл займет 2GB, он может перестать открываться, так что не доводите до такого и вовремя проводите оптимизацию." :)