ugrás a tartalomhoz

CSS tömörítés YUI Compressorral

Török Gábor · 2008. Jan. 15. (K), 12.59
Sasvári József CSS strukturálási jegyzetéhez érkezett hozzászólások között igen jól körvonalazódott az a felismerés, hogy sokan – noha a közösség nem feltétlenül hű reprezentációja az aktív webfejlesztőknek – még mindig úgy törekednek a stíluslapok szerkesztésére, hogy az kompakt legyen, módszertanukban nem tesznek különbséget a forrásfájlok írása és azok későbbi felhasználásra szánt formátuma között. Egyszerűen csak lehet, hogy nem ismerik a YUI Compressort.

A CSS kód szerkezeti felépítése leginkább a szerző szájízére hagyatik, mindazonáltal a későbbi munka végett érdemes azt úgy tagolni, hogy könnyű legyen benne a módosítás, alkalomadtán áttekinthető legyen egy külső fejlesztő számára is. Az utóbbi hónapokban én odáig merészkedtem, hogy noha az elnevezési konvenció nagyban segíti a kód megértését, rendre bőséges széljegyzetekkel, kommentekkel fűszerezem a forrást, hogy támpontot adjak a későbbiek számára magamnak, hogy mit miért, és miért úgy alkalmaztam. Már-már rendszeres bevált gyakorlat nálam, hogy a helykitöltés (padding) és keret (border) értékekkel csökkentett szélesség mellett megjegyzésben meghagyom az eredeti width-et is.
#elem {
    width: /*720*/698px;
    padding: 10px;
    border: 1px solid #abc;
}
Mindezek persze olyan információk, amelyekre nincs szüksége a böngészőnek ahhoz, hogy az elvárásainknak megfelelő megjelenést produkálja, hovatovább szűk sávszélesség mellett, mondd, nem is akarod, hogy felesleges strófákkal terheljem a vonalad.

A YUI Compressor a Yahoo mérnökeitől származó, hagyományosan a JavaScript forrás zsugorítás problematikájára született eszköz, a 2.0-s verziótól kezdve azonban CSS tömörítési képességgel is felvértezték. Természetesen nem veszi fel és nem is akarja felvenni a versenyt a gzippelt tartalmakkal, mindazonáltal semmi okunk sincs rá, hogy felesleges adatokat küldjünk a kliens felé, ráadásul a Compressorral tömörített CSS gzippelve lényegesebb kisebb fájlméretű.

A példa kedvéért lássuk a Weblabor egyik CSS állományát önmagában, YUI Compressorral tömörítve, majd mindkét esetben gzippelve:

YUI Compressor nélkülYUI Compressorral
Gzip nélkül 35K25K
Gzippelve7,2K5,7K

Az eszköz erőssége (amely egyben a korlátja is lehet), hogy helyi gépen fut, és kitűnően összeköthető az általunk használt fejlesztői környezet CSS publikálási funkciójával.
 ■
1

régóta

deejayy · 2008. Jan. 16. (Sze), 08.33
Én már régóta használok css kompresszálást, de csak saját magam által készítettet:

$buffer = preg_replace('!/\*[^*]*\*+([^/][^*]*\*+)*/!', '', $buffer);
$buffer = preg_replace('![\n\r\t]!', "", $buffer);
$buffer = preg_replace('! *([\{\};,:]) *!', "$1", $buffer);
$buffer = preg_replace('!\}!', "}\n", $buffer);
Ezzel a következőből:

body {
    /*background          : transparent url(images/pattern01.png) fixed;*/
    background          : transparent;
    font-size           : 10px;
    font-family         : Tahoma;
    color               : #333;
    margin              : 0px;
    padding             : 0px;
}
ez lesz:

body{background:transparent;font-size:10px;font-family:Tahoma;color:#333;margin:0px;padding:0px;}
2

0px

Heilig Szabolcs · 2008. Jan. 16. (Sze), 15.05
4 byte így is felesleges, lásd hozzászólás téma. :)
3

nincsbenne :P

deejayy · 2008. Jan. 16. (Sze), 19.17
Hát értelmező, és mesterséges intelligencia még nincs benne :P
4

A ludas

Heilig Szabolcs · 2008. Jan. 16. (Sze), 19.40
Jó igaz, itt az eredeti hozott anyag volt pazarló.
5

csstidy

gonoszcsiga · 2008. Jan. 18. (P), 19.06
van ilyen online is.

[szerkesztve]
a bejegyzesben szereplo css fajlt maximumra optimizalva vele:
Input: 36.727KB, Output:23.315KB, Compression Ratio: 36.5% (-13412 Bytes)
6

Amiben a csstidy más

Török Gábor · 2008. Jan. 19. (Szo), 11.24
Kiváncsiságból futottam egy kört a csstidy offline változatával, és az alábbiakban működik eltérően a YUI-hoz képest:
  • A font-weight tulajdonságok értékeit számban vett megfelelőikre cseréli (nem is tudtam, hogy van ilyen). Ez valóban ügyes, néhány bájtot spórol rajta.

  • Shorthand jelöléssel megadott margin/padding tulajdonság negyedik értékét szükség esetén lecsapja. Még régebben néztem ezt az eszközt, és akkor ha jól emlékszem, ennek kapcsán jelentkeztek problémáim -- és most is produkált egy furcsát.
    Optimised number: Changed "0!important" to "0"

    Ebből:
    h1 {margin: 1em 0 2em 0 !important; margin: 0;}
    Legmagasabb tömörítés mellett ez lett:
    h1{margin:0;}
    Ha jól tudom, ez a kettő pedig nem ekvivalens felírásai egymásnak. Független a kompresszálás mértékétől, egy ilyen eszköz erőssége abban jelentkezik, ha nyugodtan hagyatkozhatok rá, nem kell attól tartanom, hogy egy tömörített kód hibás megjelenést okozhat.

  • Szükség esetén a hexában megadott színkódot visszaváltja az angol kifejezésre, ha az rövidebb (#f00 -> red). Egy bájt megspórolva.
7

Azert

zmb · 2008. Jan. 20. (V), 11.43
megkerdeznem, hogy mit nyer ezzel az ember? Elvegre ma mar eleg nagy savszelesseggel rendelkezik egy atlagos felhasznalo, es egy-egy oldalon siman nagyobb mennyiseget tolt le ahhoz, hogy az az +/- 10k ne rugjon labdaba.
8

nagyon is számít

Hodicska Gergely · 2008. Jan. 20. (V), 12.24
Bármilyen furcsa is, de az amit PHP-ből szolgálsz ki, az kb. a betöltődés 20-30%-a, a többi kliens oldalon dől el, ezért nagyon fontos, hogy a frontend is megfelelően optimalizálva legyen. Ezzel a fajta tömörítéssel 20-30%-ot is lehet nyerni, és a mai webloldalak elég nagy JS és CSS-eket tartalmaznak.


Üdv,
Felhő
10

Persze,

zmb · 2008. Jan. 20. (V), 14.24
ertem en, h nagy fileoknal jobban kidomborodik ez a kulonbseg (foleg js eseten), de altalaban a bongeszok cacheelik ezeket, nem kell mindig ezeket lerantani.
9

Eletkeptelen felteves

Török Gábor · 2008. Jan. 20. (V), 14.12
Te csak nagy savszelesegen csak egyedul te internetezel, es semmi masra nem hasznalod, mint hogy egyidejuleg csak egyetlen egy weboldalt nezel?
11

Nem

zmb · 2008. Jan. 20. (V), 14.28
Te csak nagy savszelesegen

Nem hasznalok semmilyen mobil kapcsolatot, nem nagyon fordulok elo 64kbit kapcsolat elott.

csak egyedul te internetezel,

Termeszetesen munkahelyen tobbedmagammal hasznaljuk a netet (100 - 150 ember)

emmi masra nem hasznalod, mint hogy egyidejuleg csak egyetlen egy weboldalt nezel?

Termeszetesen masra is hasznalom.

Ahogy a masik hozzaszolasmban irtam, a statikus elemeket - altalaban - cacheeli a bongeszo (esetleg proxy), igy ezeknek a letoltese nem okoz nagy mertekeu plussz terhelestm, ezert vettettem fel a felvetesem.
12

első benyomás

Hodicska Gergely · 2008. Jan. 20. (V), 15.13
a statikus elemeket - altalaban - cacheeli a bongeszo (esetleg proxy), igy ezeknek a letoltese nem okoz nagy mertekeu plussz terhelestm
Az is fontos, hogy amikor először beesik a látogató az oldaladra, akkor mi az első benyomása. Ha bejön gyorsan az oldal, akkor az tetszik neki, ha nem, akkor nem, és ha épp nem olyan fontos, akkor már ejti is az oldalt.


Üdv,
Felhő
19

cache

lolcode · 2008. Feb. 9. (Szo), 13.01
ezt azert te is tudod valamien szinten kontrolalni szerveroldalon
13

css és js késleltet mindent

Jano · 2008. Jan. 20. (V), 16.10
A CSS és JS fájlokat a HEAD részben tölteted be a böngészővel és amíg ezek le nem jöttek addig nem is kezd el kirakni mást. Sőt, mivel minden böngészőben limitálva van (általában kettőre) az egy domainról, párhuzamosan tölthető fájlok száma, érdemes a css-eket és js-eket összefüzni is!
A több fájl összefűzése a cachelt esetre is jó hatással van, ugyanis cache esetén és megy minden lekeréskor egy ellenőrzés a szerver felé.
14

@import

toxin · 2008. Jan. 20. (V), 18.00
ezért is kell arra ügyelni, hogy a 

<style>
@import url("styles.css");
</style>
használatát mellőzni kell, mert ennek betöltése az oldal teljes letöltése után következik be, ergo megakdályozza lap progresszív renderelését, és létrehozza a blank-page effektust (azaz a stíluslap letöltéséig egy fehér képernyő látszódik, kivéve ie/url,bookmark,link-katt esetén ahol a böngésző elindítja a render-t előidézve a FOUC (the flash of unstyled content) -t

http://weblogs.mozillazine.org/hyatt/archives/2004_05.html#005496
http://developer.yahoo.net/blog/archives/2007/07/high_performanc_4.html
ill. High Performance Web Sites by Steve Souders Rule-5

üdv Csaba
15

a JS-t inkább alulra

Hodicska Gergely · 2008. Jan. 20. (V), 19.25
A JS-t pont ezért érdemes a lap alján behúzni (már ha amúgy is onloadra lefutó valami lenne, de általában erről van szó). Amíg a JS-t szedi a böngésző, addig a másik szálat sem használja, szóval duplán rossz. A CSS-re ugyanez nem áll, mert ha lentre teszi az ember (mert pl. egy hidden részhez tartozik), akkor IE esetén nem működik a progresszív renderelés, ami miatt végeredményben lassabban kap a user életjelet az oldaltól.


Üdv,
Felhő
16

szkriptbeszúrás

toxin · 2008. Jan. 20. (V), 19.49
mi egy rövid onDomReady() -ra kötött loader js-t alkalmaztunk, ami az esemény bekövetkezte, az-az a statikus részek megjelenítése után, szkriptbeszúrással adja hozzá az előzőleg YUI tömörített, egyfájlbagyúrt core js-t

Csaba
17

defer

vbence · 2008. Jan. 20. (V), 22.06
Nemtom, hogy a gyakrolatban működik-e, a defer paraméter, de ha igen, akkor ennyire azért nem húsbavágó a dolog...
18

csak IE alatt, de ott se jól

toxin · 2008. Jan. 20. (V), 22.55
At the time of this writing, Internet Explorer is the only browser that uses the defer attribute. It does this when it is combined with the src attribute. It does not implement it quite correctly, however, because deferred scripts are always deferred until the end of the document, instead of simply being deferred until the next nondeferred script is encountered. This means that deferred scripts in IE are executed out of order and must not define any functions or set any variables that are required by the nondeferred scripts that follow.
JavaScript: The Definitive Guide, Fifth Edition 13.2.4. The defer Attribute

üdv Csaba