Satt och kollade över mina script bibliotek jag skrivit till ett projekt.
Dessa ligger på 155 kb.

Om jag raderar alla onödiga mellanslag, tar bort alla kommentarer, alla radbrytning osv. Alltså gör alla kod till en kodklump. Sparar jag ca 18% utrymme.

155 kb blir 127 kb.

Är detta lönt att göra?
Har sett att många script t.ex. Google utvecklar är ihop klumpade på detta viset.

På 1000 besökare bör jag spara ca 28 000 Kb då.
På 10 000 besökare bör jag spara ca 280 000 Kb då.
Alltså närmre 270 Mb. Då börjar det bli lite av det.

Gör man såhär? Är jag dum i huvudet och tänker helt fel? :lol:

Är det scriptet eller själva htmlen som skickas till klienten du menar?

Framför allt skript som inkluderas och används av sidan. Både PHP och JS.
Alltså både klient och server script.

Scripten i sig är det ju dumt att försöka minimera, däremot själva datan som du skickar till klienten kan man ju komprimera för att spara lite, webbläsarna kan ju tolka det endå...

Så ja, du tjänar lite bandbredd om du komprimerar javascript och htmlen.

Men om filen är större måste väll även servern arbeta mer?
Ett php-script på 100kb bör väll både ta bråkdelen mer tid och belasta servern lite mer än ett script på 50 kb? Eller?

Nej inte om funktionerna är desamma, visst du kanske sparar lite på själva arbetsminnet men det kan knappast vara märkbart...

Premature optimization is the root of all evil, dvs innan du har data som visar på ett problem ska du inte optimera. och PHP-filens storlek kommer under alla förhållanden vara dittminsta problem.

och vad gäller data som skickas till klienten så kan du ju ha komprimerade filer som sedan packas upp på klienten (om det är storleken påöverfört data du är orolig för). Och åter igen - gör det bara om du kan påvisa ett faktiskt problem.

Att optimera själva scriptfilerna gör dom ganska oläsbara (om man nu inte behåller okomprimerade kopior förstås). Du tjänar lite grann men knappast så det är värt besväret.

Använd gzip istället. Här står det hur du gör: gzip.se

Jag tror inte din webbläsare bryr sig om dom är läsbara eller inte (OM vi pratar om client-scripts som JS) - Det är snarare tvärtom, desto mindre saker JS parsen måste gå igenom desto snabbare blir scriptet, både att ladda ner och execute!

Han menade nog dom lokala scripten, såsom php osv

Jo, precis.

Anledningen till jag inte trodde det var att han skrev "google gör såhär" och dom enda scripten som google har tillgängliga är väl JS..

Pratar vi PHP så spelar det, precis som andra också sagt - ingen som helst roll.

Om det har stor betydelse för snabbheten vet jag inte. Men du bör ju också tänka på att koden lätt ska kunna felsökas och ändras av en människa. Det blir svårt om man har klumpat ihop allting och tagit bort alla "in-tabbningar" osv.

Jag brukar använda yui compressor för att göra koden mindre. Sedan brukar jag gzippa. Vad jag vet är det det absolut bästa sättet att få ner storleken på koden. Lägg sedan den koden som en inkluderad .js fil.

Klientside-kod tjänar du på att komprimera. Antingen gör du som radioaktivitet och kör det genom en minimizer eller så kör du enbart gzip (koden blir större med enbart gzip men lättare att jobba med). Sedan ska du se till att stänga av E-Tag för dessa filer samt sätta en Expiry-header en bit in i framtiden så att filen cachas i webbläsaren.

Ett problem med långtida Expiry-headers är om du vill göra förändringar i filen, då vill du ju också att besökarens webbläsare hämtar den senaste versionen. Detta har vi löst på Levonline genom att vi har en PHP-variabel som heter $cacheid. I denna variabel lagrar vi ett nummer som vi ökar när vi gjort förändringar i någon statisk fil (JS, CSS, bilder etc). Vi lägger på cache-id:t på sluten av filnamnet när vi länkar in filerna, till exempel så här:

<script language="JavaScript" type="text/javascript" src="/inc/jquery-1.2.6.min.js?<?php echo $cacheid;?>"></script>

Ökar vi $cacheid så kommer det alltså i webbläsarens ögon bli ett unikt filnamn och filen hämtas då inte från webbläsarens cache. Med denna metod har vi fått ner antalet HTTP-frågor för återkommande besökare till en enda utan att försvåra vårt eget arbetsflöde.

Det är bra att göra så, men sen kan man fråga sig om det blir värt besväret mot filer som frekvent uppdateras. Men har du ett gäng script-bibliotek som sällan uppdateras finns ingen anledning att inte minimera. Ett litet tips är att spara den som <namn>.min.js så du inte råkar göra dig av med icke-minifierade versionen tills den dagen det ska uppdateras.

Det finns ett gäng pack-tekniker också för att ytterligare minska storleken men de har två saker gemensamt; det tar längre tid att exekvera (oftast ingen större skillnad) och är något osäker att köra om man inte är 100% på att man har kompatibel kod.

Ett annat tips är att kombinera småscript som inkluderas till en fil för att slippa onödigt många requests (samma skäl som css sprites blivit populära).

PHP:
http://blog.digitalstruct.com/2008/02/27/p...ing-techniques/

ASP:
http://www.asp101.com/lessons/caching.asp

CSS:
http://www.cleancss.com/

Javascript:
http://dean.edwards.name/packer/

Använd inte http://dean.edwards.name/packer/. YUI Compressor är mycket bättre.

Källa http://blog.jquery.com/2009/01/21/jquery-131-released/

Tanken var att minimera filer som ej skall arbetas med längre. Självklart behålla en icke komprimerad fil för framtida arbete och felsökning.

Som sagt gäller det typ scriptbibliotek som enbart skall användas, inte ändras i.

gsoc: Tack för de fina länkarna!
Clarence & emilv: Tack för de välfyllda svaren.
radioaktivitet: Även tack till dig såklart!

Och alla andra såklart :P Tack för alla inputs.

Jag gjorde en liten implementation med PHP för ett tag sedan...

"A tool for compressing JavaScript and CSS without disrupting your workflow. Reducing file size and the number of HTTP requests."

http://webcloud.se/article/PHPCompressAssets_02

Kör du t.ex. Java finns det möjlighet att automatiskt komprimera JS-filer m.h.a. jsmin och ett Ant-skript som körs när man bygger projektet för deployment. Ganska trevligt sätt att slippa tänka på det när man fått det att rulla.