ugrás a tartalomhoz

Php css, és js összfűzés

therest · 2012. Már. 19. (H), 16.15
Mostanság arról olvasgattam, hogy célszerű a javascript és css fájlokat összefűzni egy-egy fájlba, hogy minél kevesebb kérés legyen a kliens és s szerver között.
Mivel egy MVC rendszeren dolgozom, ahol a controllerben kerül meghatározásra a model alapján, hogy milyen javascript illetve css fájlokat kell használni, arra gondoltam, hogy célszerűbb lenne egy php szkript ami összevágná a kért css fájlokat egy fájlba, és azzal térne vissza.
Mivel a kapcsolt fájlok nem mindig ugyanazok egy adott oldalnál, a manuális megoldás nem jöhet szóba.
A kérdés, hogy mi a gazdaságosabb: szerver oldalon megcsinálni a fenti összefűzést, és esetleg van plusz htacces szabály is, vagy ez túl nehézkes ahhoz képest, amit a több css/js fájlból fakadó kérés növekedés jelent?
 
1

Összefűzés kezelése

orionstar · 2012. Már. 19. (H), 17.09
Én ezt úgy oldottam meg anno, hogy van egy embed metódusa a sablonkezelő osztályomnak, amivel a controllerben meg tudom adni, hogy melyik CSS, JS fájlokat használja az adott oldal előállításához és meg tudom mondani (pl. $this->template->embed('css', 'cssfájlnév', 'body') ezt annyiszor meghívom ahány css kell az adott oldalhoz és hasonlóan JS esetében), hogy a headerbe vagy a body tag lezárása elé tegye az adott fájlt, a két hely alapján két külön összefűzött CSS és JS fájl keletkezik és az azokra mutató linkekkel kerül be a style és script elem a végül előálló oldalba. Ez azért fontos mert, pl a Modernizer-t nem tehetem hátulra.
Mivel élesben sehol nem használom ezt a keretrendszert még, ezért nincs cache-elés, különben el kellene cache-elni az összefűzött fájlokat és azokat kiszolgálni ha nincs változás a forrásfájlokban, ha van változás akkor újra összefűzni őket és frissíteni a cache-t, így nem nő lényegesen az oldal előállításának ideje.
2

Magad, uram, ha szolgád nincsen

Hidvégi Gábor · 2012. Már. 19. (H), 17.15
A legegyszerűbb, ha kézzel összemásolod a fájlokat egybe, és kész. Azzal nem vagy előrébb, ha mondjuk minden oldaltípushoz saját css/js fájlokat generálsz.
4

Azert az konnyen elo tud

Ajnasz · 2012. Már. 19. (H), 18.29
Azert az konnyen elo tud fordulni, hogy ha ezt megteszed, akkor par szaz Kb-val tobbet tolt le az a user is, aki csak jon a fooldalra es mar megy is.
Nekem eddig a legkenyelmesebb az volt, amikor egy config file-ban lehetett definialni a js/css modulokat, amik kepesek voltak fuggosegeket kezelni. Tehat pl egy modulba egy masik modult is be lehetett agyazni.
Ezutan minden actionnek meg lehetett mondani, hogy melyik modulokra van szukseg. Itt gyakorlatilag egy action is megfelel egy sima modulnak, csak azokbol a build script generalt minden actionnek egy osszefuzott file-t, amit utana be lehetett illeszteni az oldalba.
Esetleg olyan dolgokat, amik biztosan kellenek a website osszes oldalan (pl. JS framework), azokat erdemes kulon letoltetni.

Az osszefuzes szuksegessege es modja meg leginkabb attol fugg, hogy mekkora file-okrol van szo. Par 10 vagy mondjuk 100 Kb eseten mehet egybe, de par 100 utan mar erdemes lehet elgondolkodni, hogy valoban kell-e minden oldalra minden file.
6

Igazad van

Hidvégi Gábor · 2012. Már. 19. (H), 18.53
Emellett az oldaltól/alkalmazástól is függ, utóbbi esetében úgyis legtöbbször csak egyszer töltünk be mindent az elején, ott annyira nem számít, hogy hány darabból áll (max. a fejlesztésnél).
3

több dologtól is függ.

rrd · 2012. Már. 19. (H), 17.52
több dologtól is függ. Például, hogy hányféle verzióban állítódnak elő a css, js file-ok. Kliens oldalon úgy is jó eséllyel a cache-ből leszek kiszolgálva, szóval egy kisebb rendszernél elképzelhető, hogy azzal jársz jobban ha van 1 darab nagyonbbacska css és js fileod.
Benchmarkolj és az alapján nézd meg, hogy érdemes-e ezzel ügyködnöd és merre mozogj.
7

Azért azt hozzá kell tenni,

Hidvégi Gábor · 2012. Már. 19. (H), 19.07
Azért azt hozzá kell tenni, hogy ha nem adsz meg Expires fejlécet, akkor is érkezik kérés a szerver felé, sok fájl esetén ez is észrevehetően lassítja a betöltést, még akkor is, ha csak "nem változott" választ kapsz.
5

Amíg nincs túl sok fájl

inf · 2012. Már. 19. (H), 18.51
Amíg nincs túl sok fájl (mondjuk több, mint 10), vagy nem hatalmas az adatforgalom, addig nincs értelme ezzel foglalkoznod. Ha nem nagyon nagyok a css és js fájlok, akkor összefűzheted egy-egy (esetleg több) fájllá őket, a többi oldalon meg úgyis cacheből fogja használni őket a böngésző.

Egyébként meg annyira nem bonyolult, van két Set-ed amikben felsorolod a használt fájlokat, a View Helper-ekben letárolod, hogy milyen css-re és js-re van szükségük, és amikor használsz egy helper-t, akkor hozzácsapod az adott set-hez a függőséget. Utána el lehet dönteni, hogy egybefűzöd őket, vagy egyesével szúrod be, az összefűzött nevet meg lehet generálni, ha tömbre alakítod a set-et, rendezed, string-re alakítod (implode vagy serialize), és fájlnévként használható formára alakítod (crc32 vgy md5).
8

Drupal megoldása az, hogy van

pp · 2012. Már. 20. (K), 09.18
Drupal megoldása az, hogy van két függvény(drupal_add_css és drupal_add_js) amivel js és css fájlokat adhatnak hozzá a modulok(kiegészítők, pluginek stb.) a kimenethez. Amiket aztán (ha be van kapcsolva) a rendszer automatikusan aggregál (css és js).
Természetesen nem csak a modulok(működési logika) adhat hozzá js és css fájlokat, hanem a smink(megjelenítési logika) is. Az egyik hozzászólásban említett dependencia kérdésekre is kínál megoldást a rendszer, de az már egy másik történet. :)
9

Kösz a hozzászólásokat. A

therest · 2012. Már. 20. (K), 13.03
Kösz a hozzászólásokat. A kézi összemásolás kizárt mint írtam, mert az oldal struktúrája is adatbázis vezérelt, tehát a kapott adatok alapján építi fel (egy komplexebb személyre szabható felület).
A szerver várhatóan elég komoly terhelésnek lesz kitéve, a css fájlok nem nagyok a legkisebb jelenleg 1kb, a legnagyobb meg 8kb, ennél várhatóan nem lesznek nagyobbak, de akár 15-20 darab is kellhet, egy lap legeneráláshoz.
Ami engem rémiszt pl a drupalos linkek kapcsán, hogy masszív kód van mögötte.
Ilyenkor nem veszíti el kapott előnyt a kliens, a szerver oldali munka hossza miatt?
10

20 darab 8k-s fájl 160k,

Hidvégi Gábor · 2012. Már. 20. (K), 15.38
20 darab 8k-s fájl 160k, mindenki jobban jár, ha egybefűzöd, első betöltéskor egy tizedmásodperccel többet kell várni, aztán viszont nem.

Az szerintem nem túl optimális helyzet, ha legenerálsz n darab JS és CSS fájlt, amelyekben lévő kódoknak nagy a metszete, azaz egy-egy függvény vagy stílusdefiníció több helyen is megvan.
11

Az azért hozzátartozik, hogy

pp · 2012. Már. 20. (K), 15.43
Az azért hozzátartozik, hogy maga az oldal is gyorstárazva van, tehát jóval kevesebb generálás lesz mint gondolnád.

pp
12

Ilyenkor nem veszíti el

inf · 2012. Már. 21. (Sze), 03.57
Ilyenkor nem veszíti el kapott előnyt a kliens, a szerver oldali munka hossza miatt?

Ha kesseled az összefűzött fájlt, akkor nem.
13

Akkor talán az lenne az

therest · 2012. Már. 21. (Sze), 15.57
Akkor talán az lenne az ideális, hogyha egyszer összefűzöm az egészet, és lemegy kliens oldalra. Mi a tippetek arra, hogy ezek után ne történjen meg ismét az összefűzés(mivel már cachelve van )? Le kellene tenni session-be státuszként, és ezt vizsgálni?
14

hash

Poetro · 2012. Már. 21. (Sze), 16.02
A fájlok elérési útjából csinálsz egy hash-t (md5/sha1 stb.), majd az ilyen nevű fájlba mented az összefűzött fájlokat. Ezek után könnyű megnézni, hogy a fájl létezik-e, mivel a hash-t könnyű előállítani. Ezek után nincs is szükség további cachelésre. Természetesen az alkalmazáshoz kell készíteni egy metódust, amivel ezeket az aggregált fájlokat le lehet törölni.