|
Skriven av: Stefan | den 1 juli 2009 Kl 09:54
|
För dig som jagar prestanda på alla sätt och vis har jag skrivit ett par bloggpostet som tar upp hur du kan minimera både mängden data i form av CSS och JavaScript som skickas till klienten, och samtidigt minimera antalet Requests, men ändå behålla en vettig filstruktur i utvecklingsmiljön.
http://blog.crswebb.se/post/2009/06/Minimera-dina-CSS-filer.aspx
http://blog.crswebb.se/post/2009/07/Minimera-bade-CSS-och-JavaScript.aspx
Den andra bygger på den första. Jag har även en äldre post på samma tema.
http://blog.crswebb.se/post/2008/08/Minimera-mangden-HTML-kod-som-skickas-till-klienten.aspx
Redigerad av: Stefan
Nu implementerar den senaste både Cache på servern (1 timme) och på klienten (1 vecka). Dessutom tror jag att jag har gjort det kompilerat.
|
|
|
Skriven av: LordDaimos | den 1 juli 2009 Kl 10:14
|
Har själv funderat på att skriva något sånt där men har inte riktigt orkat. Ska man dessutom snacka prestanda så saknar jag två saker. För det första så vore det bättre att lägga Regex-instansen som en statisk medlem och köra med RegexOptions.Compile, för det andra så borde den komprimerade filen cachas (antingen på disk eller i Cache-objektet) för att man ska slippa köra dessa operationer vid varje request.
Redigerad av: LordDaimos
Sen vore det ju snyggare också om man implementerade det så att istället för att man skickar in en querystring till en .ashx så mappar du upp så att .css-filer körs via .net och automatiskt gör detta för alla .css-filer.
|
|
|
Skriven av: Stefan | den 1 juli 2009 Kl 10:23
|
Jag funderade på att mappa css som du säger, men jag vill ju sammanfoga filerna ifall det är flera. Som jag skrev i mitt första inlägg hade jag en fundering på att parsa den genererade html-koden efter css-länkar, och sammanfoga dem, men i den här värmen fick det bli en sån här lösning.
Du har naturligtvis rätt i att det borde cachas. Vi är bortskämda med prestanda, men har besökare med dålig uppkoppling så det här var det viktigaste. Naturligtvis kommer cache att implementeras senare.
Ska även kika på det där med Compile å grejer.
|
|
|
Skriven av: LordDaimos | den 2 juli 2009 Kl 12:41
|
Gjorde en egen version av detta baserat på Sam Colletts kod (han som du länkade till i din bloggpost). Den har en lite mer avancerad cache och fungerar som en handler för .css-filer och inte en generic handler med querystrings. Att den kommer att behöva göra flera anrop om jag har flera filer ser jag inte som något problem då overheaden blir minimal när den frågar efter en till fil i en redan öppen anslutning.
http://blog.crazybeavers.se/index.php/archive/compacting-css-on-the-fly/
|
|
|
Skriven av: Stefan | den 2 juli 2009 Kl 13:20
|
Jag ser overheaden som ett problem, när det behöver hämtas flera css-filer. Det är ganska mycket som skickas till servern i anropet.
Det är framför allt vesäntligt för besökare som betalar för datatrafiken, eller har väldigt långsamma uppkopplingar.
Jag har implementerat både cache och kompilerad RegEx i min handler.
Vilken lösning man väljer är i mångt och mycket en smaksak. Prioriterar man enkelhet att implementera så väljer man din lösning. Vill man spara ytterligare några byte trafik så väljer man min lösning.
|
|
|
Skriven av: LordDaimos | den 2 juli 2009 Kl 13:46
|
|
Jag får ca 650 bytes i headers för varje fil som hämtas, skulle inte kalla det mycket men vill man tokspara på bandbredd så visst, då är det ju en lösning att lägga ihop filer också.
|
|
|
Skriven av: Stefan | den 2 juli 2009 Kl 14:28
|
Jag vet att jag också skulle behöva anropa en separat subdomän, då skulle jag slippa problemet med att cookies skickas fram och tillbaka. Tyvärr har vi inte möjlighet till det.
Därför är det en hel del onödig data som skickas. Det är inte såå mycket, men om jag kan få 1kb headers istället för 5kb så är det ju bra.
|
|
