Фигма, по-бързо 🏎

Зареждането на файла, плъзгането и мащабирането е до 3 пъти по-бързо

За да бъдат ефективни инструментите за проектиране, скоростта е от съществено значение. Ако има закъснения на грешни места, това напълно разрушава илюзията, че инструментът е продължение на ума и тялото ви. Представете си безсилието да се опитвате да удряте в пирон, когато чукът върви зад ръката ви с половин секунда.

Искаме Figma да бъде продължение на вашия творчески ум. За да постигнем тази цел, трябва да премахнем възможно най-много триене от процеса на поставяне на вашите идеи във визуално пространство за обсъждане, сътрудничество и превръщане в работещ софтуер. За да намалим това триене, се нуждаем от постоянен фокус върху производителността на Figma.

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

Искаме Figma да бъде продължение на вашия творчески ум.

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

През последните няколко седмици внесехме тези промени в цялата потребителска база. Прочетете, за да научите повече за промените, как измерваме тези печалби и какво следва за работата по производителността на Фигма.

Зареждане на файлове - до 3 пъти по-бързо

Скорост на зареждане на файловете в действие, върху истински документ за дизайн

Тъй като продуктът ни отлежава, забелязахме екипи от големи организации, създаващи все по-сложни дизайнерски документи на Фигма. Потребителите натискат нашия инструмент до неговите граници, влагайки компоненти много слоеве в дълбочина, за да им даде гъвкавост и сила в техните дизайнерски системи.

Fluent Design Team в Microsoft, например, преустройва всеки нативен елемент на Windows в един документ Figma, улавяйки компоненти във всички възможни състояния и пермутации. Тези на пръв поглед прости операции добавят много изчислителна сложност и претърпяно време на натоварване.

„Тествахме стрес за границите на това, което Фигма можеше да направи, преди да го приемем като основен инструмент на нашия екип“, ни каза Кайл Андерсън, старши продуктов дизайнер в екипа на Fluent.

За щастие, през последните 2 месеца оптимизациите на WebAssembly и колекцията от други промени ни помогнаха да намалим времето за зареждане на голям реалистичен документ от 29 секунди до под 8 секунди.

„Тя е значително по-лека и много по-ефективна.“ - Кайл Андерсън, Microsoft

WebAssembly вече е активиран на всички общи места, които нашите потребители работят в Figma [1]. Това включва настолното приложение, Chrome, Firefox и Safari както в macOS, така и в Windows. Въздействието на това е огромно навсякъде.

„Тя е значително по-лека и много по-ефективна“, каза Кайл. „Скоростта, с която вашият екип прави актуални корекции, е наистина обнадеждаваща и не бихме могли да бъдем по-щастливи с продукта.“

Непрекъснати взаимодействия

Разбира се, важността на ефективността не приключва, когато файлът ви се зареди. Две от най-често срещаните операции, при които потребителите на Figma се нуждаят от скорост, са увеличаване / намаляване и влачене на слоеве.

Обновихме фокуса си върху подобряването на плавността на тези често срещани поведения и от началото на годината намалихме „стопките“, които виждате при увеличаване или плъзгане.

Мащабирането вече е до 3 пъти по-бързо.

Мащабирането сега всъщност е zoooooms

Плъзгането вече е до 3 пъти по-бързо.

Плъзгането се усеща като по-малко влачене

N3TWORK, игрална и медийна компания за 100 души, особено оцени тези подобрения. Техните файлове са плътни и пълни с растерни изображения, така че техният директор на UX Design Адам Донкин дойде лично, за да говори с представянето. „Това е едно от най-хубавите неща във Фигма - имам чувството, че съм изградил връзка с хората там и заедно работим чрез проблеми“, каза той. „Прави впечатление, че Figma е мой продукт.“

След няколко минути диагностициране на проблема с Адам лично, ние активирахме новия ни представител за N3TWORK. Те видяха моментална крачка в скоростта на публикуване на компоненти и зареждане на файлове. „Не е нужно да го измервате, беше напълно очевидно“, каза Адам. „Върнах се в офиса и няколко души го тестваха и виждаха подобрения във всички случаи. Това беше супер вълнуващо. "

Защо измерваме както средното, така и максималното време на кадъра

При непрекъснати операции като увеличение и плъзгане, за нас е грижата, а не продължителността. Има голям опит в пропастта между плъзгането, което отнема 500 мс, и получаването на обратна връзка, докато не завърши спрямо драгването, което прави 500 мс, където получавате пълна визуална обратна връзка при 60 кадъра в секунда.

Един от водещите принципи на нашия дизайнерски екип е „благоприятствайте директната манипулация“ и нищо не нарушава илюзията за директна манипулация като забавена и рядка обратна връзка.

Един от водещите принципи на нашия дизайнерски екип е „благоприятствайте директната манипулация.“

За да измерваме качеството на тази обратна връзка, проследяваме две ключови показатели: средно време на кадър и максимално време на кадър. Всеки от тях допринася за гладкостта на влаченето, така че и двамата трябва да бъдат наблюдавани, за да се разбере въздействието на оптимизацията.

По-високите максимални времена на рамката създават ефект на „бъркане“, като ветроходството ви внезапно удари скала. За сравнение, по-високите средни пъти произвеждат щастие, като шофиране на кола над калдъръмени камъни.

По-долу примерите показват тази разлика между двете на практика.

Максималното време за кадър се увеличава (отляво надясно), докато средното време за кадър остава същото

С този пример за разграждане на максимално време на кадъра и трите GIF имат средна честота на кадрите от 15 кадъра в секунда. В най-лявата анимация всеки кадър е 67ms. В централната анимация повечето кадри са 33 мс, но всеки шести кадър е дълъг 200 мс. В правилната анимация повечето кадри са 33 ms, но всеки единадесети кадър е дълъг 367 ms.

Въпреки, че единият метричен остане постоянен, другият се влошава достатъчно, за да изглежда пътеката на топката да изглежда неподвижна.

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

Средното време за кадър се увеличава (отляво надясно), докато максималните времена на кадър остават същите

И трите имат максимално време за кадър от 167 ms, като повечето кадри заемат 33 ms. В лявата анимация, обаче, 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, за да подкрепи грешката в GPU на Chrome грешки.