Kaip pagreitinti SASS kompiliavimą arba “Kai kiekviena sekundė yra svarbi”...

Sveiki, teko parašyti straipsnį anglų kalba, tačiau noriu juo pasidalinti ir su lietuvių Front-ender'ių community.

Originalu straipsnį rasite čia:

https://www.devbridge.com/articles/increasing-sass-compiling-performance-or-when-every-second-counts/

Ar daug yra sekundė? O dvi, trys? Dešimt? Tokie klausimai man kilo nuo tada, kai pradėjome naudoti CSS preprocesorių SASS.

Įrankis, kurio pagalba turėjome palengvinti ir pagreitinti savo darbą, kartais jį netgi prailgindavo, dėl savo compile’o greičio. Taip, įrankis mums leido suvienodinti savo kodą tarp kelių komandos narių, leido automatizuoti kodo rašymo, spritinimo ir kitus procesus, tačiau kelis mėnesius developinamas projektas, pasiekdavo 7-12 sec. ar net didesnes compile’o laiko ribas. Galbūt tai neatrodo daug, tačiau paskaičiuokime: tarkime, jog buildiname failą vieną kartą kas minutę, vidutinis build time 6-10sec = 8sec. Tai reiškia, jog nemaža dalis mūsų darbo laiko (1/7.5, kas yra 40/7.5 ~ 5.3 valandos) yra ne kas kita, kaip laukimas, kol SASS susicompilins. Tad ką mes galime padaryti?

SASS su steroidais

Logika čia gana artima automotibilių sportui - jei automobilis važiuoja labai lėtai, vadinasi kaltas jo variklis. Būtent tai mes ir padarysime, pakeisim variklį. SASS buildinimui panaudosime libsass, tai SASS port‘as C kalba. Libsass kūrėjai jau senai pastebėjo, jog Ruby tikai nėra gerai performinanti kalba ir SASS variklį reikia perkelti ant kalbos, kurią galėtum paleisti tiek įvairiose aplinkose ir kurios greitis tenkintų.

Tolumoje jau girdžiu žmones, kurie sako „Palauk, palauk, o kaip compass? Kaip native ruby funkcijų naudojimas libuose? Pamiršai?“.

Karalius mirė? Tegyvuoja karalius!

Taip, pasirinkus libsass aš turėjau atsisakyti dviejų visų mėgiamų sass frameworkų: „Compass“ ir grid‘o sistemos „Susy“. Jei susy atsirado dar visai nesenai, tai compass buvo labai didelė SASS populiarumo priežastis ir jo atsisakymas daug kam pasirodys neadekvatus, tačiau mes jį visai nesunkiai pakeisime. Susipažinkite – „Bourbon“.

Bourbon – tai tik SASS paremta mixinų biblioteka, kuri yra beveik identiška „Compass“, tačiau „Bourbon“, mano nuomone turi didesnį išpildymą, nepriklausomumą, greitį ir dokumentaciją.

Pavyzdiniame projekte, pakeitus „Compass“ į „Bourbon“, su kiekvienu importo pakeitimu compile time sumažėdavo 0,6~ sekundės (visas compile time apie 10sec).

Tad ką mes laimėjome ir ką praradome iškeitę „Compass“ į „Bourbon“?

Laimėta:

a) Greitis (build time, net nepakeitus buildinimo engine tapo greitesnis)

b) Didesnis išpildymas – papildomai gausite tikrai kokybišką grido sistemą - „Neat“, ir ne tokią svarbią componentų ir add’ons bibliotekas.

c) Dokumentacijos stilius yra pesonalinis dalykas, tačiau „Bourbon“ dokumentacija man žymiai aiškesnė.

d) Bourbon yra „pure“ SASS, jį galima naudoti tiek su libsass tiek su ruby sass compileriu.

f) Jau integruotas CSS animacijų paketas (keyframes, animation ir t.t.)

g) Compass iš esmės stengiasi padaryti viską, bet kaip žinoma, įrankiai skirti viskam, dažniausia nėra tinkami geriausiems ir sparčiausiems sprendimams. Netgi visų mėgstamas spritinimo helperis compasse nėra optimaliai parašytas, nes sprite’ai yra pertikrinami kas kiekvieną sass failo modifikaciją, kai tuo tarpu, logiška būtų juos tikrinti tik tuomet, jei grafiniai failai buvo pridėti į sprite.

h) Compass labiau mėgsta įsibrauti į jūsų sistemą ir turi kelis erzinančius dependencies.

Prarasta:

a) Compass Inline-image funkcija, kuri buvo patogi, tačiau galima gyventi ir be jos.

b) Sprite‘ų generavimas (kaip mes tai pakeisime – apie tai, vėliau)

Grido sistema gali kelti performance bėdų? Really?

Mano atveju, teko keisti ir grid sistemą. Naudotas susy, jau pusę metų neišsprendžia savo bėdų performance srityje https://github.com/ericam/susy/issues/325, taip pat, jis priklauso nuo ruby, tad teko jo atsisakyti.

Žinoma, skaitydami šias eilutes, galvojate, jog vėl sutaupysime vidutiniškai puę sekundės, tačiau, norėčiau atkreipti Jūsų dėmesį į šį grid‘o sistemų palyginimą: http://jeffreydegraaf.nl/2014/07/04/performance-of-sass-grid-systems/

Kaip matote, Neat ir Susy performance skirtumas yra gana didelis (0.3~1,2 sec versus 7~8sec.). Gana įspūdinga?

Būtent todėl ir pasirinkau „Neat“, nes jis panašus į „Susy“, LABAI greitas, nepriklausomas nuo Ruby ir labai gerai dokumentuotas.

Užteks kalbėti, rodyk skaičius.

Gerai, tad tarkime, jog turime seną projektą, kiek mes galime sutaupyti?

Generation of average project file (240KB size)

Compass + susy + sprites – empty cache: 16-17s.

Compass + susy + cache + sprites: 10-12sec.

Libsass + neat + bourbon + sprites + grunt-watch: 1.6 sec.

Libsass + neat + bourbon + sprites + grunt watch with (spawn:false): 0.6 sec.

Kaip matote, skirtumas yra milžiniškas.

Įtikinai, tik kaip visa tai efektyviai sujungti? Ir kaip dėl sprite’ų?

Turbūt ne paslaptis, jog didelė dalis front-end developerių laikosi įsikandę compass tik dėl sprite’ų generavimo.

Libsass ir automatizuotas spritinimas? Taip, tai įmanoma, kaip ir minėjau, sprite‘ų automatizavimo atsisakyti nereikės, tačiau tam, jog viskas veiktų, reikės grunt arba gulp. Jei dar nesate susipažinę su šiuo įrankiu, tai pasiskaitykite čia (asmeniškai, pirmenybę teikiu Grunt, todėl instrukcijas pateiksiu tik jam): http://gruntjs.com/

Jums eikės:

Node naujausios versijos:

http://nodejs.org/download/

Parsisiųskite sample libsass projektą: https://github.com/devbridge/Front-End-Toolkit/tree/master/starter-template-libsass

kai susiinstaliuosite Node, įsijunkite node command line ir nueikite į projekto direktoriją:

įveskite komandą: npm install

Ir viskas, galite pradėti dirbti :)

Pirmam paleidimui duokite komandą „grunt“, bus sugeneruoti pradiniai failai, sprite‘ai. Dirbant naudokite task‘ą grunt watch, jis stebės scss failus ir img failus ir jiem pakitus, atitinkamai reaguos.

Jei kažkas nepavyko – rašykite komentaruose, pabandysiu pagelbėti.

Faster!

Tam, jog taupyti laiką ir tik atsinaujinus CSS failui, vaizdas būtų perpieštas, esu pasirašęs mažą chrome extensioną, galbūt pravers ir Jums:

https://chrome.google.com/webstore/detail/prototool-css-auto-refres/kobijmefblkndpicohiondpdnpojebjd

Final thoughts

Tiesą sakant, šis research‘as davė man labai daug patirties apie tai, kaip aš ateityje rinksiuosi įrankius. Tai padėjo man suvokti, jog sass plugins‘ai, extension‘ai negali savyje turėti kitos kalbos panaudojimo kaip SASS. Tai leidžia vėliau išvengti suderinamumo ir palaikomumo problemų ir esant dideliems pokyčiams, leidžia greitai daryti pakeitimus esant poreikiui.

Taip pat, developinant didelius projektus, kritiškai svarbu atsižvelgti į įrankio spartą.

Tikiuosi mano postas Jums padės atsikratyti beverčio laukimo ir leis atsilaisvinusį laiką panaudoti geresniems tikslams.

Galbūt turite įdėjų kaip visa tai dar labiau pagreitinti, o gal turite pastabų ar pastebėjimų? Rašykite komentarų skiltyje! Ačiū!