Figma, nopeampi ūüŹé

Tiedoston lataaminen, vetäminen ja zoomaaminen on jopa 3x nopeampi

Jotta suunnittelutyökalut olisivat tehokkaita, nopeus on välttämätöntä. Jos väärissä paikoissa on viiveitä, se pilaa täysin illuusion, että työkalu on mielen ja kehon jatke. Kuvittele turhautumista, kun yrität naulata kynsiin, kun vasara kulkee käden taakse puolessa sekunnissa.

Haluamme, että Figma on luovan mielen jatke. Tämän tavoitteen saavuttamiseksi meidän on poistettava niin paljon kitkaa prosessista, jossa ideasi sijoitetaan visuaaliseen tilaan keskustelemaan, tekemään yhteistyötä ja muuttamaan toimiviksi ohjelmistoiksi. Tämän kitkan vähentämiseksi tarvitsemme jatkuvaa keskittymistä Figman suorituskykyyn.

Alusta lähtien olemme yrittäneet suunnitella jokaisen ominaisuuden suorituskykyä ajatellen. Kun havaitsemme kohdennetun suorituskyvyn voitot analysoimalla koodiamme huolellisesti (ajamalla oikeita asiakirjoja, jotka käyttäjät jakavat kanssamme), otamme ne. Toisinaan mahdollisuudet saada suuria voittoja kuitenkin esiintyvät.

Haluamme, että Figma on luovan mielen jatke.

Aikaisemmin tänä vuonna huomasimme, että asiakirjatoimittajamme uudelleenjärjestely ja WebAssembly-virheiden tasoitus voivat tehdä Figmasta huomattavasti nopeamman. Työskentelimme näiden optimointien parissa kuukausia. Palkkio oli massiivisia parannuksia tiheissä tiedostoissa zoomaamisessa, vetämisessä ja tiedostojen lataamisessa (jopa 3x nopeammin!).

Vedimme nämä muutokset koko käyttäjäkuntaan viimeisten viikkojen aikana. Lue lisää siitä, mikä muuttui, kuinka mittasimme näitä voittoja ja mitä seuraavaksi suoritetaan Figman suorituskykytyössä.

Tiedostojen lataus - jopa 3x nopeampi

Tiedoston latausnopeus käytännössä oikealla suunnitteludokumentilla

Tuotteemme kypsyessä olemme huomanneet suurten organisaatioiden ryhmiä, jotka luovat Figmassa entistä monimutkaisempia suunnitteluasiakirjoja. Käyttäjät työntävät työkalumme rajoihinsa, pesivät komponentteja moniin kerroksiin syvälle, jotta heille annettaisiin joustavuutta ja voimaa suunnittelujärjestelmissä.

Esimerkiksi Microsoftin sujuva suunnittelutiimi rakensi uudelleen jokaisen Windowsin natiiviohjaimen yhdessä Figma-dokumentissa, sieppaamalla komponentit kaikissa mahdollisissa tiloissa ja permutaatioissa. Nämä näennäisesti yksinkertaiset toiminnot lisäävät paljon laskennallista monimutkaisuutta ja kärsivät kuormitusajat.

"Testasimme stressimahdollisuuksia siihen, mitä Figma voisi tehdä, ennen kuin otimme sen joukkueemme ensisijaiseksi työkaluksi", kertoi Fluent-tiimin vanhempi tuotesuunnittelija Kyle Anderson.

Onneksi viimeisen kahden kuukauden aikana WebAssembly-optimoinnit ja kokoelma muita muutoksia auttoivat meitä lyhentämään suuren realistisen asiakirjan latausaikaa 29 sekunnista alle 8 sekuntiin.

"Se on huomattavasti kevyempi ja suorittavampi." - Kyle Anderson, Microsoft

WebAssembly on nyt käytössä kaikissa yleisissä paikoissa, joissa käyttäjät työskentelevät Figmassa [1]. Tämä sisältää työpöytäsovelluksen, Chromen, Firefoxin ja Safarin sekä macOS: ssä että Windowsissa. Tämän vaikutus on valtava kaikkialla.

"Se on huomattavasti kevyempi ja paljon suorituskykyisempi", Kyle sanoi. "Nopeus, jolla joukkueesi kuuma korjaa tavaroita, on todella rohkaisevaa, emmekä voi olla tyytyväisempi tuotteeseen."

Jatkuva vuorovaikutus

Suorituksen tärkeys ei tietenkään lopu tiedostoosi latautuessa. Kaksi yleisintä toimintaa, jossa Figman käyttäjät tarvitsevat nopeutta, ovat lähentäminen / loitontaminen ja tasojen vetäminen.

Uudistimme keskittymistämme parantaa näiden yleisten käyttäytymisten sujuvuutta ja olemme vähentäneet vuoden alusta lähtien "kiinnittimiä", joita näet zoomaamalla tai vetäessäsi.

Zoomaus on nyt jopa 3x nopeampi.

Zoomaus on nyt eläintarha

Vedäminen on nyt jopa 3x nopeampi.

Vedäminen tuntuu vähemmän vetävältä

100 hengen peli- ja mediayhtiö N3TWORK arvosti erityisesti näitä parannuksia. Heidän tiedostot ovat tiheitä ja täynnä bittikarttakuvia, joten heidän UX-suunnittelija Adam Donkin tuli henkilökohtaisesti puhumaan esityksen kautta. "Se on yksi Figman parhaimmista asioista - minusta tuntuu, että olen luonut suhteen ihmisiin siellä ja työskentelemme yhdessä ongelmien läpi", hän sanoi. "Se saa tuntemaan, että Figma on minun tuotteeni."

Muutaman minuutin kuluttua diagnoosin ongelmasta Adamin kanssa henkil√∂kohtaisesti, otimme k√§ytt√∂√∂n uuden renderatorimme N3TWORK: lle. He n√§kiv√§t hetkellisen korotuksen komponenttien julkaisun ja tiedostojen lataamisen nopeudessa. "Sinun ei tarvinnut mitata sit√§, se oli t√§ysin selv√§√§", Adam sanoi. ‚ÄúK√§velin takaisin toimistolle ja useat ihmiset olivat testanneet sit√§ ja n√§hneet parannuksia kaikissa tapauksissa. Se oli eritt√§in j√§nnitt√§v√§√§. ‚ÄĚ

Miksi mitataan sekä keskimääräinen kehysaika että enimmäiskuvausaika

Jatkuvien toimintojen, kuten zoomauksen ja vetämisen, avulla meistä välittyvä sileys ei ole kestoa. 500 ms: n vetämisen ja ilman palautteen saamisen välillä on valtava kokemuksellinen kuilu, kunnes se on valmis, ja 500 ms: n vetämisen välillä, jossa saat täydellisen visuaalisen palautteen nopeudella 60 kuvaa sekunnissa.

Yksi suunnittelutiimimme p√§√§periaatteista on ‚ÄĚsuosia suoraa manipulointia‚ÄĚ, eik√§ mik√§√§n riko suoraa manipulointia koskevaa harhaa, kuten viiv√§stynytt√§ ja harvoin tapahtuvaa palautetta.

Yksi suunnittelutiimimme p√§√§periaatteista on ‚ÄĚsuosia suoraa manipulointia‚ÄĚ.

Tämän palautteen laadun mittaamiseksi seuraamme kahta avainmittaa: keskimääräinen kehysaika ja enimmäiskuvausaika. Kumpikin edistää vetämisen sujuvuutta, joten niitä molempia on tarkkailtava optimoinnin vaikutusten ymmärtämiseksi.

Suuremmat enimm√§iskehysajat tuottavat jarring ‚ÄĚkiinnitystehosteen‚ÄĚ, kuten purjeveneesi ly√∂ √§kki√§ kallioon. Vertailun vuoksi korkeammat keskim√§√§r√§iset ajat tuottavat pilkkomista, kuten autolla ajaminen mukulakivill√§.

Alla olevat esimerkit osoittavat tämän eron näiden kahden välillä käytännössä.

Enimmäiskuvausajat kasvavat (vasemmalta oikealle), kun taas keskimääräiset kehysajat pysyvät samana

Tässä esimerkissä suurimmasta kehysajasta heikentyvästä kaikista kolmesta gifistä keskimääräinen kuvanopeus on 15 kuvaa sekunnissa. Vasemmassa animaatiossa jokainen kehys on 67 ms. Keskianimaatiossa useimmat ruudut ovat 33 ms, mutta joka kuudes kehys on 200ms pitkä. Oikeassa animaatiossa useimmat kehykset ovat 33 ms, mutta joka toinentoista kehys on 367 ms pitkä.

Huolimatta siitä, että yksi metriikka pysyy vakiona, toinen huononee tarpeeksi, jotta pallon polku tuntuu räjähtävältä.

Seuraavassa esimerkissä keskimääräinen kehysaika pienenee vasemmalta oikealle. Sen sijaan, että siirryttäisiin tasaisuuden ja kiinnityksen välillä, alhainen keskimääräinen kuvanopeus tuottaa katkovan ilmeen.

Keskimääräiset kehysajat kasvavat (vasemmalta oikealle), kun taas enimmäiskuvausajat pysyvät samana

Kaikkien näiden kolmen enimmäiskuvausaika on 167 ms, useimpien kehysten ollessa 33 ms. Vasemmassa animaatiossa 167 ms: n kiinnitys tapahtuu kuitenkin joka 28. kehys. Keskianimaatiossa joka 10. kehys. Oikeassa animaatiossa joka 4. kehys.

Ihanteellisessa maailmassa sovellukset eivät koskaan pudota alle 60 kuvaa sekunnissa. Kun siirrymme kohti maailmaa, on kuitenkin hyödyllistä seurata näitä molempia muuttujia ajan myötä. Voisimme sen sijaan tarkastella koko histogrammia kehysaikoja, mutta olisi vaikea kartoittaa kehitystämme ajan myötä niin monilla muuttujilla.

Seuraa Figman keskimääräistä ja enimmäiskuvausaikaa

Mittasimme viimeisen 3 kuukauden edistymistä monimutkaisessa asiakirjassa zoomaamisessa ja vetämisessä keskimääräisen ja enimmäiskuvausajan perusteella.

Kuten alla olevista kaavioista voidaan nähdä, sekä zoomauksen että vetämisen kehykset vähenivät. Vertailuasiakirjamme zoomaamiseksi olemme ylläpitäneet tarvittavan keskimääräisen kehysajan 60 kuvaa sekunnissa ja lyhentäneet enimmäiskuvausaikaa tarpeeksi välttääksesi kehyksen pudottamisen. Vedämistä varten paransimme keskimääräistä kehystä 30 fps: stä 60 fps: iin ja vähensimme kiinnityksiä 120 ms: stä 30 ms: iin, pudottamalla yhden kehyksen kuuden sijaan kiinnityksen aikana.

Kulissien takana: yksityiskohdat skeptikoille

Figman optimoimiseksi tarvitsemme vertailukokeita, jotka ovat johdonmukaisia, mutta myös realistisia. Jotta luettaisiin yhtenäiseksi, niiden on tehtävä joka kerta täsmälleen sama asia, joten voimme kertoa, milloin suorituskyvyn parannukset johtuvat koodin vaihdosta verrattuna muuttuvaan käyttötapaan. Jotta ne olisivat realistisia, meidän on testattava todellisia suunnittelutiedostoja, ei vain tiedostoja, jotka sisältävät 1000 harmaan suorakaiteen ristikkoa. Figman tekeminen todella nopeaksi epärealistisissa käyttötapauksissa ei ole kovin hyödyllistä kenellekään .

Jotta voidaan luoda johdonmukaisia ‚Äč‚Äčja realistisia vertailuarvoja, suoritamme version sovelluksestamme Electronissa (pohjimmiltaan hieno k√§√§re Chromen ymp√§rille) ja simuloimme k√§ytt√§jien vuorovaikutuksia, kuten vet√§mist√§, panorointia, zoomaamista, valitsemista ja muutamaa muuta keskeist√§ vuorovaikutusta. Mittaa, kuinka kauan viet√§mme koodin keskeisiss√§ osissa (tapahtumien k√§sittely, renderointi, k√§ytt√∂liittym√§n p√§ivitys jne.), Ja seuraamme niit√§ ajan my√∂t√§.

Kun vertailuarvot ovat valmistuneet, tulokset ilmoitetaan Datadogille, missä me asetamme hälytykset. Nämä vertailuarvot toimivat jokaisessa sitoutumisessa, joten kun suorituskyky taantuu, saamme sähköposti-ilmoituksia ja voimme sitoa regression tiettyihin koodimuutoksiin. Kun olemme selvittäneet regression lähteen, joko korjaamme regression tai peruutamme muutoksen, kunnes voimme keksiä tavan toimittaa sama toiminnallisuus ilman suoritusosumaa.

Mitä seuraavaksi tulee: kopioi, liitä, poista, kumoa, peilausparannukset ja paljon muuta

Tietysti meitä ei ole tehty täällä. Olemme sitoutuneet tekemään Figman käytöstä mahdollisimman nopean kokemuksen ja haluamme keskittyä alueisiin, jotka vaikuttavat ihmisiin syvimmin.

Vaikka olemme askelneet latausajan suhteen, tehtävää on vielä paljon. Meillä on käynnissä muutama merkittävä arkkitehtuurimuutos, joiden pitäisi tuottaa valtavia etuja lastausaikaan. Edut korostuvat erityisesti prototyyppien lataamisessa ja Figma Mirror -sovelluksessa työskentelystä.

Olemme myös hiljattain ottaneet käyttöön muutoksia, joiden avulla voimme seurata toimintoja, jotka johtavat Figman lukitsemiseen yli 100 ms: n ajan, ja olemme yksilöineet muutamia merkittäviä alueita, joista aloittaa: kopioi, liitä, poista, kumoa, tee uudelleen ja vie.

Pysy kanavalla!

alaviitteet

[1]: Julistimme tämän voiton viime vuonna, mutta todella ymmärtäessämme, että se on ollut keskustelu Chromen WebAssembly -tiimin kanssa, sukeltaminen heidän kääntäjälähteensä, keinojen löytäminen kääntölaitteiden umpikujaan välttämiseksi ja korjauspaikkojen lisääminen Electroniin Chrome GPU -virheen tueksi. korjauksia.