Aš nuoru, kad web aplikacija greičiau veiktų!

Sveiki,

Nesenai publikavau savo straisnį web optimizacijos tema, anglų kalba.

Manau, jog nuodėmė būtų nepasidalinti juo kartu su Jumis, juo labiau, jog turiu jo draft'ą lt kalba :)

Tikrojo straipsnio adresas: http://bit.ly/1mLtvj9

Visais laikais žmones žavėjo greitis. Greičiausia mašina, greičiausias bėgikas, greičiausias žveris, greičiausias procesorius... Greitis, tai magija, kuri iš pradžių atrodo vulgari ir paprasta, tačiau, kad taptum tikrai greitu, visose srityse turi įdėti nemažai darbo. Kaip ir vaikinas, laisvalaikiu paspardantis kamuolį su draugais futbolo stadione netaps profesionaliu futbolininku, uždirbančiu milijonus, taip ir Jūsų programinė įranga netaps ypatingai greita be tam tikrų optimizacijos procesų.

Jau tampa aišku, jog web technologijų srityje responsive dizainas yra „must have“. Ir ne be reikalo, nes mobiliųjų įrenginių skaičius, kurie naudojasi mobiliu internetu, pasaulyje jau pasiekė penktadalį visos populiacijos, tad web‘ui tenka taikytis prie įvairių įrenginių (šaltinis: http://www.dekh.com/blog/post/the-mobile-web-will-it-replace-desktop-use). Prisitaikymas kainuoja. Daugiausia kenčia našumas, kurį galėčiau išskirti į tris dalis: „loado“ (krovos), grafinį (rendering) ir nematomoji dalis – programavimo našumas (executing). Apie našumo svarbą verslui plačiau galite pasiskaityti čia: http://www.tagman.com/mdp-blog/2012/03/just-one-second-delay-in-page-load-can-cause-7-loss-in-customer-conversions/ . Rezultatai gana įdomūs – 1 papildoma sekundė kainuos Jums 7% konversijų.

Šiame straipsnyje pabandysiu aptarti pagrindines klaidas ir duoti gerų patarimų, kaip svetainę padaryti greitesnę, tačiau prieš pradedant, norėčiau supažindinti su nerašytomis taisyklėmis, kada web aplikacija gali būti laikoma „greita“:

• Time To First Byte: 200ms - 350ms

• DOM Content Loaded: 1000ms - 2000ms

• JS Load Event Fired: 900ms - 2200ms

• Total Download Size: 1MB - 2MB

• DNS Lookup: 10ms - 20ms

• HTTP Requests per page: 50 - 75

Tad, pradedam:

Sulieknėk greitai arba kai reklama tampa realybe

Tikriausia esate matę tas reklamas, kuriose moteris numeta 15 kilogramų per tris dienas naudodama stebuklingus patarimus? Ši reklama gali būti teisinga web optimizacijos atveju. Jūs galite turėti didelę aplikaciją, su daug įvairiausio kodo, tačiau dažniausia turėsite bėdų su paveiksliukais, kurie kels krovos laiką, o jeigu naudosite dar ir transparent png – tai bus didelis galvos skausmas... iki tol, kol naudosite reikiamus įrankius ir mokėsite juos organizuoti.

• Visų pirma rekomenduočiau tinkamai paruošti paveiksliukus. Dažniausia girdžiu, jog png optimizuoti beprasmiška, nes labai kenčia kokybė, tačiau geresnio įrankio, nei daug kam nežinomas, kuklus ir nemokamas „Color quantizer“ (http://www.softpedia.com/get/Multimedia/Graphic/Graphic-Others/Color-quantizer.shtml) – neteko sutikti, o ir problemas jis sprendžia puikiai. Yra tekę matyti pavyzdžių, kai transparent png neoptimizavusios svetainės, turėjo vieną, riebų paveikslėlį, kurio dydis viršijo pusę megabaito. Su šiuo įrankiu tokį paveikslėlį nesunkiai sumažinsite bent kelis kartus, o kokybės skirtumas bus sunkiai įžvelgiamas. Tiesa, gradient paveikslėlių optimizuoti nepatariu.

Keletas PNG optimizacijos pavyzdžių:

1. http://www.htc.com/www/smartphones/ - atvaizduojama 12 telefonų paveiksliukų ir nuo kiekvieno vidutiniškai galima sutaupyti 20KB. 12 * 20KB = 140KB

2. Vienas iš awwwards nugalėtojų: http://epic.net/mmxiv/

Suoptimizavus titulinio puslapio png laimima ~75KB.

3. Neabejotinas nugalėtojas: http://www.olympicstory.com/ - 190KB loss nuo vieno paveiksliuko.

• Sprite‘ai – naudokite sprite‘us krauti paveikslėliams. Tai kardinaliai sumažins requestų skaičių, kas žymiai pagreitins bendrą svetainės krovimasi. Automatizuotam sprite‘ų generavimui mano kolega, Paul Gabronis yra parašęs SASS biblioteką (https://github.com/paulgabronis/Easy-Sprites ), kuri leis pilnai automatizuoti sprite‘ų generavimą ir pagreitins ne tik krovimosi laiką, bet kartu ir leis pagreitinti gamybos procesą.

Drąsiausieji gali pabandyti netgi SVG sprite‘us: http://css-tricks.com/svg-sprites-use-better-icon-fonts/

• Labai dideliems background images naudokite jpg progressive arba preloaderius, tai leis neturėti didelių pokyčių svetainėje ir neprivers vartotojo ilgai laukti.

• Jei dėl vienokių ar kitokių priežasčių negalite naudoti sprite paveiksliukų, galite naudoti inline base64 paveiksliukus. Sumažinsite request skaičių, tačiau patys paveiksliukai gali būti šiek tiek didesni, nei įprasto formato (prieš versdami į base64 formatą, patariu juos optimizuoti).

Jeigu naudojate SASS + Compass, tai padaryti galite labai lengvai:

.test-class  {
background:inline-image("test-image.png") no-repeat 0 0;
}

Jeigu naudojate CSS ir koduojate su Visual Studio, Jums padės šis papildinys:

http://visualstudiogallery.msdn.microsoft.com/a56eddd3-d79b-48ac-8c8f-2db06ade77c3

CSS optimizacija

1. Magiškasis Transform:translateZ(0). Naršyklių kurėjai dažnai nesutaria įvairiausiais klausimais, tad nieko nuostabaus, jog nuomonės dėl gpu akseleracijos naršyklėse skirtingos stovyklose išsiskyrė. Jeigu FireFox kūrėjai akseleruoja viską, kas pasitaikė po ranka, webkit varikliuko kurėjai davė laisvę pasirinkti. Ir tai yra gana logiška, nes:

a) Suteikiama resursų skirstymo laisvė

b) Leidžia taupyti įrenginio bateriją

Būtent minėtasis translateZ(0) leis „paforsinti“ gpu akseleraciją elementui, tačiau būkite atsargūs, kadangi tai nėra galutinis sprendimas ir ateityje planuojama įvesti tam dedikuotą css property: „will-change“. Daugiau pasiskaityti galite čia: http://tabatkins.github.io/specs/css-will-change/ .

2. CSS animacijos/tranzicijos. Stenkitės kiek įmanoma daugiau javascript animacijų pakeisti css animacijomis/tranzicijomis, ypač kai Jūs turite animuoti kelis elementus vienu metu.

Paskaityti apie tai ir pajusti skirtumą galite čia: http://css3.bradshawenterprises.com/blog/jquery-vs-css3-transitions/

Tik nepamirškite, jog FireFox naršyklė sunkiai susitvarko su css animacijomis/tranzicijomis, kai vienu metu animuojama daugiau nei 150 elementų.

3. Stenkitės optimizuoti „brangius“ css properties. Tokie stiliai kaip box-shadow, gradient, border-radius, outline, opacity turi įdomių savybių renderinant ir gali žymiai sulėtinti Jūsų UI.

Keli pavyzdžiai, kaip renderinamas box shadow:

Imkime tris scenarijus (A, B ir C), kai:

A - elementas turi tik box shadow.

B - kai turi tik border radius

C - kai turi abu šiuos stilius.

Kaip pasikeis renderinimo laikas?

A renderinimo laikas 0,19ms

B renderinimo laikas – 0,16ms

C renderinimo laikas – 0,73ms

Dar vienas įdomus testas palyginimui, box-shadow reikšmės

box-shadow: 1px 1px = 0.28ms

box-shadow:1px 2px 3px red = 0.16ms

box-shadow: 1px 2px 3px 4px = 0.76ms

Tai jokiu būdų nereiškia, jog reikia atsisakyti šių stilių naudojimo, tačiau jei iškyla tam tikros bėdos su UI greičiu, šią informaciją svarbu žinoti.

Plačiau šia tema: http://nerds.airbnb.com/box-shadows-are-expensive-to-paint/

4. Naudokite automatizuotus testus, kad aptiktumėte blogiausiai performinančius selectorius. Vienas naudingesnių testų, kuris leis nustatyti blogiausiai peforminančias klases scrollinant:

http://andy.edinborough.org/CSS-Stress-Testing-and-Performance-Profiling

Keep things simple

• Kurkite gracefully degrading tinklalapius. Galbūt metas atsisakyti javascript select‘o librario, o checkbox‘us ir radio buttonus sustailinti su plain css‘u? Taikydamiesi prie mažumos browserių, tokių kaip ie8 ar žemiau, palaikydami 2 metų senumo opera naršykles Jūs tiesiog apsunkinate tiek savo darbą, tiek svetainės performance, o lopomos vietos vis sunkėja, kol tampa nebepakeliamos ir tampa visiškai nebenaudojamos. Taip, IE8 dar gana plačiai naudojamas, tačiau 1-5% vartotojų tikrai nenusimins, jog tam tikri elementai tiesiog turi defaultinį stilių, o tinkalapis veikia nepalyginamai greičiau.

Custom select: http://jsfiddle.net/TKE6g/

Custom checkbox and radio: http://jsfiddle.net/t7jCL/

• Nepersistenkite su Web font‘ų įvairove. Pasirinkite tik būtinus fontus ir jų variacijas ir nekraukite nenaudojamų, tai leis pastebimai sumažinti krovos laiką.

Optimization Essentials

Jeigu norite, jog web aplikacija veiktų greitai, Jūs tiesiog privalote:

1. Minifikuokite CSS failus ir sumažinkite jų kiekį iki minimumo.

2. Jokiu būdu nenaudokite @import css failuose, juo labiau, kai dabar galite lengvai failus importuoti SASS pagalba.

3. Javascript failus krauti tik prieš užsidarant body tag‘ui ir šios taisyklės galima nepaisyti tik labai išskirtiniais atvejais

4. Minifikuokite javascript failus ( Automatizuotam minifikavimui galite naudoti: https://www.npmjs.org/package/grunt-contrib-uglify )

5. Naudokite „up to date“ jquery versiją kartu su jquery migrate, tai leis sėkmingai palaikyti kodą, rašytą su senomis jquery versijomis, tačiau kartu veiks sparčiau ir pati biblioteka užims žymiai mažiau vietos.

6. Kraukite pakopinius stilius tik head dalyje ir kaip įmanoma anksčiau

7. Naudokite resursus iš CDN (Content Delivery Network). Jei naudojate require.js, cdn naudoti galite taip:

requirejs.config({
   baseUrl: "Scripts",
   paths: { 
       /* Load jquery from google cdn. On fail, load local file. */
       'jquery': ['//ajax.googleapis.com/ajax/libs/jquery/2.0.3/jquery.min', 'libs/jquery-min'],
   }
});

8.

MISC optimizacija

• Dažnai socialinių tinklų ikonos tinklalapyje nugrūdamos į footer dalį. Ar jos tikrai vertos savo vietos po saule? Spręsti Jums, o perskaityti ką galite sutaupyti jų atsisakydami, galite čia:

http://zurb.com/article/883/small-painful-buttons-why-social-media-bu

http://lastdropofink.co.uk/market-places/the-true-cost-of-adding-social-buttons/

• Vietoje strandatinio „on resize” jquery event’o, naudokite šį: http://www.paulirish.com/2009/throttled-smartresize-jquery-event-handler/

Praktinis pavyzdys: http://jsfiddle.net/c9Dfm/

• Iframe – didelis galvos skausmas, jeigu jame pateikinėjate informaciją iš nutolusių šaltinių. Tokių iframe krovimas kaip youtube, vimeo, gali kardinaliai pakeisti Jūsų krovos laikus ir window loaded, bei js first event fire eventų gali tekti laukti labai ilgai. Pateiktas snippet‘as padės Jums išvengti šių bėdų:

<iframe width="780" height="440" data-src="//player.vimeo.com/video/54638896" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen class="vimeo-video"></iframe>

 $(document).ready(function () {
   $('iframe').each(function() {
                    $(this).attr('src', $(this).data('src'));
});
});

• Tiems kam patinka skaičiai – neprošal perskaityti šį straipsnį: https://developers.google.com/speed/articles/web-metrics

Pabaigai – palyginimas

Pabaigai - tiesiog norėčiau palyginti dvi visiškai paprastas aplikcijas. Viena aplikacija bus be optimizacijos, kita – su ir palyginsime jų performance.

Parašius tik labai paprastutę aplikaciją ir pritaikius paprasčiausius optimizacijos veiksmus, mes gavome tokius rezultatus (testuota esant prisijungus prie mobilaus interneto ir išvestas vidurkis iš 10 kartų):

1. Neoptimizuota versija:

Užklausų skaičius: 88

Dom ready event fire: 2,24sec

Window loaded event: 8,21sec

Data transfered: 3,2MB

2. Minimaliai optimizuota versija

Užklausų skaičius: 74

Dom ready event fire: 1,07sec

Window loaded event: 6,63sec

Data transfered: 2,2MB

Tai tiek :) tikiuosi, jog patiko :)