Hoever ga jij met het optimaliseren van je code?

vrijdag 6 april 2007 15:21

Es gibt keine kleinen Punkte!

Topicstarter

Creepy schreef op vrijdag 06 april 2007 @ 15:11:
Misschien dat je even een verschil moet maken tussen daadwerkelijk compileren en interpreteren.

Commentaar, uitlijning e.d. uit een file halen die toch wordt gecompileerd is mijn inziens idioot. Na de compilatie slag blijft hier als het goed is toch niks meer van over. Voor een file die nog geinterpreteerd moet worden (standaard PHP bijv) kan het nut hebben, maar je moet je afvragen of je met dat soort micro optimalisaties moet gaan beginnen als het op het moment de coede toch al soepel genoeg draait en er nog andere zaken te optimaliseren zijn.

Mijn advies zou ook zijn om zo ver niet te gaan tenzij je er erg zeker van bent dat het ook echt winst gaat opleveren en er aan andere zaken niet verder te optimaliseren valt.

De term compileren was als voorbeeld bedoeld, maar ik wist inderdaad niet zeker of mijn vraag 100% met compilen van doen had. De reactie van Flard is precies waar ik op doelde. Hoeveel tijd scheeld het de "compiler" als ik een deel van zijn werk uit handen neem.

Ik moet wel zeggen dat het kosten technisch totaal niet lonent is. Ben nu al een paar minuten zoet om alle spaties, enters enz. in een klein bestand weg te halen.

gorgi_19 schreef op vrijdag 06 april 2007 @ 15:21:
Voor een solution is hij hier 20-30 seconden bezig met compilen. Ik gok niet dat het weghalen van commentaar het significant zou beinvloeden.

Of ik moet sneller leren typen

Maar je hebt gelijk. Een stresstest toont bij mij geen significant verschil.

[ Voor 13% gewijzigd door DerKleinePunkt op 06-04-2007 15:30 ]

Ein kleiner Punkt in einer grossen Welt

Acties:

gorgi_19

Kruimeltjes zijn weer op :9

CAIRATH schreef op vrijdag 06 april 2007 @ 15:18:
Ik vermoed dat zelfs voor een interpreted taal als PHP het verschil in snelheid tussen code met newlines/comments en code zonder dat zo klein is dat je het niet eens betrouwbaar kan aantonen.

Waar het wel nuttig kan zijn als kleine optimalisatie is bijvoorbeeld bij Javascript. Je kan een JS bestand waar redelijk veel code in staat behoorlijk in grootte terugbrengen door het op die manier te comprimeren en dat komt natuurlijk de laadtijd wel wat ten goede (je ziet dit veel gedaan worden bij allerlei JS libraries).

HttpCompressie doet al meer; daarnaast kan je een stuk van de JS in een extern bestand stoppen waardoor deze maar een keer ingeladen wordt voor meerdere requests en op de client wordt gecached.

DerKleinePunkt schreef op vrijdag 06 april 2007 @ 15:20:
[De term compileren was als voorbeeld bedoeld, maar ik wist inderdaad niet zeker of mijn vraag 100% met compilen van doen had. De reactie van Flard is precies waar ik op doelde. Hoeveel tijd scheeld het de "compiler" als ik een deel van zijn werk uit handen neem.

Voor een solution is hij hier 20-30 seconden bezig met compilen. Ik gok niet dat het weghalen van commentaar het significant zou beinvloeden.

[ Voor 24% gewijzigd door gorgi_19 op 06-04-2007 15:23 ]

Digitaal onderwijsmateriaal, leermateriaal voor hbo

vrijdag 6 april 2007 15:40

Acties:

vrijdag 6 april 2007 15:48

Een compiler (of interpreter) begint altijd met een tokenizer die het bestand inleest en deze opsplitst in tokens (keywords, constants etc...), maar dit neemt echt nauwelijks tijd in beslag t.o.v. de rest van de compiler (iig < 1%) en het helpen van deze tokenizer door de opmaak kleiner te maken is echt nihil en waarschijnlijk niet eens meetbaar, laat staan merkbaar.

Als je een echte compiler wilt helpen (dit gaat niet bij een interpreter), dan helpt het opsplitsen van code in meerdere bestanden vaak wel, omdat de compiler daarna alleen nog maar de bestanden die zijn gewijzigd opnieuw hoeft te bekijken.

Het is mij echter nog steeds niet duidelijk over welke taal jij het nu hebt, want voor elke taal/platform zijn er wel (micro)optimalisaties te bedenken die wel eens kunnen helpen.

Acties:

vrijdag 6 april 2007 15:51

Es gibt keine kleinen Punkte!

Topicstarter

Marcj schreef op vrijdag 06 april 2007 @ 15:40:
Het is mij echter nog steeds niet duidelijk over welke taal jij het nu hebt, want voor elke taal/platform zijn er wel (micro)optimalisaties te bedenken die wel eens kunnen helpen.

Mijn vraag was taal/platform onafhankelijk bedoeld. Maar ben op dit moment bezig in asp.

Ein kleiner Punkt in einer grossen Welt

Acties:

Cavorka

Internet Entrepreneur

Hm, iedereen is wel heel erg sceptisch, maar als je files kleiner zijn en je include er een hoop, dan maakt het wel degelijk een hoop uit of er een zooi commentaar en enters in staat of niet.

Ik include namelijk meestal een heel framework in mijn meeste websites (database class, template class, timer class, error class etc. etc.) en heb zelf een kort scriptje wat mijn oorspronkelijke class files stript van al het onnodige en output naar een nieuwe file met Small erachter. Scheelt ongeveer 10% laadtijd ('include tijd') per file, en ik ben niet echt een commentaar freak ofzo, maar als je echt veel commentaar hebt scheelt het dus (iets/nog) meer.

Ruwe test met de include van 1 class file van 23kb (origineel) en 15kb (small):
Include tijd Origineel: 0.00220s
Include tijd Small: 0.00191s

(Kon even niet 10000 keer loopen omdat het een class include.)

Het gaat hier misschien wel om micro optimalisaties, maar het is zo weinig moeite, omdat ik mijn framework niet zo vaak aanpas en maar een enkel scriptje hoef te runnen om ze allemaal om te zetten naar 'small'.

Als je iets van 10 files include scheelt het een paar duizendste seconde... Mja, het gaat om het idee.

Compensatie voor de eigenlijke functionaliteit van het framework zullen we maar zeggen.

Edit + note: Het betreft in mijn geval PHP files... het 'small' was ter referentie naar de geoptimaliseerde files die bij mij een ClassSmall.class.php extensie krijgen.

[ Voor 8% gewijzigd door Cavorka op 06-04-2007 16:05 ]

the-blueprints.com - The largest free blueprint collection on the internet: 50000+ drawings.

vrijdag 6 april 2007 15:57

Acties:

vrijdag 6 april 2007 16:02

Bij geinterpreteerde talen zoals Small zou het inderdaad nog wel een stukje kunnen schelen, maar dan nog moet je jezelf afvragen of je daarom een groot stuk onderhoudbaarheid (is dat een woord?) wil opgeven omdat er geen commentaar of opmaak meer in zit. Voor ASP zou denk ik hetzelfde ongeveer gelden.

Wat natuurlijk wel een optie kan zijn om toch die snelheid te behalen is om een scriptje te schrijven die van de developercode productiecode maakt waar alle commentaar en overbodige whitespace uit verwijderd zijn. Maar dan nog is dit iets waarbij je moet afvragen of het de tijd waard is

Acties:

Verwijderd

_{ik wil niet de slimmerik uithangen ofzo}

Waarom word er niet gemeten? Er word gezegd 'misschien' en 'waarschijnlijk'. Waarom zou je niet meten wat het scheelt, en of het uberhaupt noodzakelijk is.

'Premature optimization is the root of all evil'

'If I say optimize, you say measure'

vrijdag 6 april 2007 16:05

Acties:

kenneth

achter de duinen

Ik wil net zeggen, HAL-9000. Misschien geeft het een 'fijn gevoel' dat het allemaal lekker compact is, maar in de huidige tijd van razendsnelle computers vind ik leesbaarheid en onderhoudbaarheid (bijna) zwaarder wegen dan snelheid. Tenzij je het echt bont maakt natuurlijk. Eerst meten, dan optimaliseren. 'n Trage functie optimaliseren heeft weinig zin als deze maar één keer wordt aangeroepen. En 'n snelle functie nog sneller maken heeft weer wél zin als deze 1.000 keer wordt aangeroepen.

Look, runners deal in discomfort. After you get past a certain point, that’s all there really is. There is no finesse here.

vrijdag 6 april 2007 16:05

Acties:

SKiLLa

Byte or nibble a bit ?

Even googlen, dergelijke benchmarks zijn allang uitgevoerd

Wel even op de gebruikte taal/scripting/platform letten uiteraard

'Political Correctness is fascism pretending to be good manners.' - George Carlin

vrijdag 6 april 2007 16:12

Acties:

vrijdag 6 april 2007 16:36

Software Architect

Werkt hier

Cavorka schreef op vrijdag 06 april 2007 @ 15:51:
Als je iets van 10 files include scheelt het een paar duizendste seconde... Mja, het gaat om het idee.

Compensatie voor de eigenlijke functionaliteit van het framework zullen we maar zeggen.

Edit + note: Het betreft in mijn geval PHP files... het 'small' was ter referentie naar de geoptimaliseerde files die bij mij een ClassSmall.class.php extensie krijgen.

Als je je zo zorgen om de include-tijd maakt bij PHP kan je beter naar caches voor de gecompileerde code kijken, zoals eAccelerator, APC en Zend Performance Suite. Een keer compileren en vervolgens het resultaat van de compilatieslag opslaan in gedeeld geheugen. En dan maakt het weer niet uit hoeveel commentaar je hebt, die initiele keer compileren is niet zo relevant.
Vziw hebben de meeste concurrerende omgevingen vergelijkbare constructies?

Acties:

vrijdag 6 april 2007 16:48

Ik heb even de java-compiler getest en zelfs in extreme gevallen kan ik maar een verschil meten van net geen 1%. Ik heb 10x achter elkaar String.java gecompileerd met alle commentaar en witregels (115.591 bytes groot) en daar 10x String.java helemaal compact (geen commentaar en zo min mogelijk witruimte, 21,569 bytes groot). De grootste deed er gemiddeld 4,34 seconden over en de compacte 4,30 seconden. Dit verschil is echt veel te klein om uberhaupt betrouwbaar te zijn

ps. Dit hele grote verschil in grootte zit voornamelijk in de javadoc, welke meestal (iig voor de library) nog een stuk uitgebreider is dan de code zelf

Acties:

Verwijderd

Marcj schreef op vrijdag 06 april 2007 @ 16:36:
Ik heb even de java-compiler getest en zelfs in extreme gevallen kan ik maar een verschil meten van net geen 1%. Ik heb 10x achter elkaar String.java gecompileerd met alle commentaar en witregels (115.591 bytes groot) en daar 10x String.java helemaal compact (geen commentaar en zo min mogelijk witruimte, 21,569 bytes groot). De grootste deed er gemiddeld 4,34 seconden over en de compacte 4,30 seconden. Dit verschil is echt veel te klein om uberhaupt betrouwbaar te zijn

ps. Dit hele grote verschil in grootte zit voornamelijk in de javadoc, welke meestal (iig voor de library) nog een stuk uitgebreider is dan de code zelf

Talking about optimizing the build-cycle

vrijdag 6 april 2007 19:22

Acties:

vrijdag 6 april 2007 19:30

Klopt, maar dat geeft wel een indicatie van het verschil in performance bij het interpreteren van een script

Ik heb hier zo geen groot PHP script om het mee te testen

Acties:

Spixo

Gezien je het over een website hebt zou je wel de output zo compact mogelijk kunnen maken.

Ik heb dat laatst getest met mijn eigen website, en sommige output is wel tot de helft kleiner geworden (in KB's) door het verwijderen van overbodige enters, spaties e.d.

Dit scheelt je op termijn natuurlijk dataverkeer.

vrijdag 6 april 2007 19:37

Acties:

Chesta

Zowizo zorgen dat je geen html-comments hebt. Soms haal ik ook alle newlines weg met replace functie. Ook belangerijk is om de css zo goed mogelijk in elkaar te zetten, dit kan op een grote pagina echt een heleboel schelen, dus niet bij elk element style="height: 10px;" doen ofzo

//edit zoals Ricardo87 hierboven zegt scheelt dit dataverkeer, ik doe dit soort optimalisatie dan ook alleen op sites waar heel veel bezoekers opkomen.

[ Voor 21% gewijzigd door Chesta op 06-04-2007 19:38 ]

End of Transmission

vrijdag 6 april 2007 19:38

Acties:

AtleX

Tyrannosaurus Lex 🦖

Creepy schreef op vrijdag 06 april 2007 @ 15:11:
Misschien dat je even een verschil moet maken tussen daadwerkelijk compileren en interpreteren.

Commentaar, uitlijning e.d. uit een file halen die toch wordt gecompileerd is mijn inziens idioot. Na de compilatie slag blijft hier als het goed is toch niks meer van over. Voor een file die nog geinterpreteerd moet worden (standaard PHP bijv) kan het nut hebben.

Ik heb ooit gemeten wat het effect is van alle classes in 1 file onderbrengen en dan de whitespace en commentaar strippen. Het is leuk voor de eerste hit (winst was ongeveer 30%, maar als de Zend engine al een gecompileerde pagina in de cache heeft scheelt het helemaal niets. Op het moment dat je site ook van zoiets afhankelijk wordt moet je serieus gaan nadenken over het vergroten van de servercapaciteit.

Wat wel veel nut heeft is het samenvoegen van alle losse classes in 1 file. Door het aantal includes in de betreffende applicatie terug te brengen van 58 naar 9 was de winst bij de eerste hit bijna 80%.

Het strippen van whitespace uit JS en HTML files is niet erg nuttig, Gzippen levert meer winst op en het compleet onleesbaar maken van je code weegt dan niet op tegen die maar bytes winst per hit.

Sole survivor of the Chicxulub asteroid impact.

vrijdag 6 april 2007 19:44

Acties:

Verwijderd

We hebben het hier over het verkleinen van de sourcefiles. De topictitel zegt 'Hoever ga jij met het optimaliseren van je code?'. Daar versta ik eigenlijk toch wat anders onder, maar dan echt code technisch. Denk dat het voor de TS ook zinniger is zich daar in te verdiepen. (als hij dat nog niet heeft gedaan)

vrijdag 6 april 2007 21:18

Acties:

Cavorka

Internet Entrepreneur

ACM schreef op vrijdag 06 april 2007 @ 16:12:
[...]Als je je zo zorgen om de include-tijd maakt bij PHP kan je beter naar caches voor de gecompileerde code kijken, zoals eAccelerator, APC en Zend Performance Suite. Een keer compileren en vervolgens het resultaat van de compilatieslag opslaan in gedeeld geheugen. En dan maakt het weer niet uit hoeveel commentaar je hebt, die initiele keer compileren is niet zo relevant.
Vziw hebben de meeste concurrerende omgevingen vergelijkbare constructies?

Ik heb iets te veel servers om zeep geholpen en ben van iets te veel hostings weggestuurd om me er geen zorgen om te maken. Grootste redenen om weggestuurd te worden waren echter populariteit van sommige van mijn websites, en dan voornamelijk op slashdot post-achtige momenten.
Ik heb ondertussen bijna alles van al mijn websites gecached en dus ook al een tijd geen problemen meer met hosting, maar along the way heb ik dus ook het verkleinen van source files toegepast omdat ik op zoek was naar alles wat ik kon vinden om mijn pagina loads lager en parse tijden korter te maken.

Verwijderd schreef op vrijdag 06 april 2007 @ 19:44:
We hebben het hier over het verkleinen van de sourcefiles. De topictitel zegt 'Hoever ga jij met het optimaliseren van je code?'. Daar versta ik eigenlijk toch wat anders onder, maar dan echt code technisch. Denk dat het voor de TS ook zinniger is zich daar in te verdiepen. (als hij dat nog niet heeft gedaan)

De TS vroeg alleen naar kleinere source files... vandaar.

the-blueprints.com - The largest free blueprint collection on the internet: 50000+ drawings.

zaterdag 7 april 2007 00:12

Acties:

Gwaihir

Tja; je hebt wel tooltjes die dat allemaal automatisch voor je strippen (in elk geval voor PHP). Dan is 't misschien een "waarom niet?". Maar je praat over zo'n aller, allerlaatste voordeeltje dat ik me eigenlijk niet kan indenken onder welke omstigheden het me de tijd nodig voor 't tool-gebruik waard zou zijn.

Zoals HAL-9000 aangeeft gaat het optimaliseren van code voornamelijk over hele andere dingen. Doe maar 'ns wat profiling op je code en probeer de trage blokken die je tegen komt maar eens efficiënter te schrijven. Dan haal je echte tijdswinst.

zaterdag 7 april 2007 01:31

Acties:

zaterdag 7 april 2007 02:15

Es gibt keine kleinen Punkte!

Topicstarter

Ricardo87 schreef op vrijdag 06 april 2007 @ 19:30:
Gezien je het over een website hebt zou je wel de output zo compact mogelijk kunnen maken.

Ik heb dat laatst getest met mijn eigen website, en sommige output is wel tot de helft kleiner geworden (in KB's) door het verwijderen van overbodige enters, spaties e.d.

Dit scheelt je op termijn natuurlijk dataverkeer.

Mocht je over asp / php praten dan denk ik niet dat een kleiner bestand minder dataverkeer oplevert, aangezien deze pagina's op de server worden uitgevoerd en dan naar de user worden gestuurd. Aangezien mijn pagina's alleen maar een variabele met de hele paginaterugsturen heb je het kleinst mogelijk wat je volgens mij kunt krijgen? Eén lange horizontale output zoals je hier bij GoT.

Als je echter doelt op html en css, dan heb je gelijk dat kleine bestanden inderdaad minder dataverkeer opleveren. Mijn grootste html output is 28Kb en het betreft de bedrijfinformatie welke om de nabij 8 a4'tjes vult.

Cavorka schreef op vrijdag 06 april 2007 @ 21:18:
[...]
Ik heb iets te veel servers om zeep geholpen en ben van iets te veel hostings weggestuurd om me er geen zorgen om te maken. Grootste redenen om weggestuurd te worden waren echter populariteit van sommige van mijn websites, en dan voornamelijk op slashdot post-achtige momenten.
Ik heb ondertussen bijna alles van al mijn websites gecached en dus ook al een tijd geen problemen meer met hosting, maar along the way heb ik dus ook het verkleinen van source files toegepast omdat ik op zoek was naar alles wat ik kon vinden om mijn pagina loads lager en parse tijden korter te maken.

[...]
De TS vroeg alleen naar kleinere source files... vandaar.

Alle informatie m.b.t. het optimaliseren van je code in ongeacht welke vorm en taal is welkom. Dit topic is niet alleen bedoeld om mij van informatie te zien.

[off-topic]
Voor mezelf sprekend. Ik vind het zeer interessant om code te zien welke efficienter is dan dat de compiler deze kan genereren. Dus super efficiente machinecode.

Als iemand nog een goed assembler voor dummies boek weet, dan hoor ik dit graag

[/off-topic]

[ Voor 21% gewijzigd door DerKleinePunkt op 07-04-2007 01:41 ]

Ein kleiner Punkt in einer grossen Welt

Acties:

zaterdag 7 april 2007 11:43

Devver

Pixelated

Voor het terugdringen van je dataverkeer kan je, zoals AtleX ook al zei, veel beter kijken naar HTTP-compressie dan naar het strippen van overbodige whitespace. Overigens is het omzetten van table-based tag-soup naar semantische HTML + CSS ook vaak goed voor een 50%+ winst (en CSS kan clientside gecached worden)

Verder versta ik onder 'optimaliseren' ook iets heel anders dan topicstarter: ik denk dan meestal toch aan dingen als cacheing, query-optimisation, taal-specifieke optimilisaties gebruiken waar mogelijk (bestaande methods in bepaalde talen die in ander talen wellicht niet standaard zijn), string-methods gebruiken waar reguliere expressies overkill zijn etcetera...

[ Voor 36% gewijzigd door crisp op 07-04-2007 02:25 ]

Intentionally left blank

Acties:

Creepy

Tactical Espionage Splatterer

AtleX schreef op vrijdag 06 april 2007 @ 19:38:
[...]

Wat wel veel nut heeft is het samenvoegen van alle losse classes in 1 file. Door het aantal includes in de betreffende applicatie terug te brengen van 58 naar 9 was de winst bij de eerste hit bijna 80%.

Je hebt hier alleen een voordeel mee als je daadwerkelijk ook (bijna) al je classes altijd gebruikt. Als je alle classes in 1 file hebt staan en je gebruikt maar de helft dan is het zonde om elke keer alles te includen.

"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have _star_ problems" --Kevlin Henney

zaterdag 7 april 2007 11:57

Acties:

DaCoTa

Voor HTML output gebruik ik alleen HTTP-compressie. Voordeel is dat dit voor een intraweb applicatie is en alle browsers hetzelfde, en ze dus allemaal HTTP-compressie ondersteunen. Als dit werkt, is iedere moeite die je doet om whitespace weg te halen overbodig. Daarnaast is - niet alleen in HTML, maar ook in source code - leesbaarheid bijna altijd belangrijker dan optimalizaties, OOK inhoudelijk.

Je kan wel hele gave unrolled loops gaan maken, maar als er net een database query uitgevoerd is, maakt dat echt geen verschil meer. Pas als ik weet dat een bepaald stuk code in de orde van duizenden keren aangeroepen zal gaan worden per request, ga ik denken over code optimalizaties boven leesbaarheid.

Het enige dat ik wel ongeveer weet is welke zaken veel tijd/resources/cpu kosten en wanneer ik moet opletten. Zoals gezegd: database queries en bijvoorbeeld complexe objecten initialiseren (java Calender). Maar op een gegeven ogenblik heb je voor de meeste problemen wel een leesbare en toch niet zo'n grote performance hog oplossing verzonnen.

Oh en verder: optimalizatie in je build? Huh?

zaterdag 7 april 2007 14:28

Acties:

Verwijderd

[...]
De TS vroeg alleen naar kleinere source files... vandaar.

Niet helemaal, hij vraagt oa om hoe ver wij zouden gaan (

) en of we nog tips en trucs hebben. Mijn tip is om meer naar code optimalisatie te gaan kijken dan naar het weghalen van ws enzo.

zondag 8 april 2007 17:59

Acties:

Saven

Administrator

als je nou een file van 200kb include, of een file van 10, maakt toch wel redelijk verschil lijkt me

zondag 8 april 2007 18:09

Acties:

DeDooieVent

als antwoord op de hoofdvraag, ik ga ontzettend ver in het optimaliseren van mijn code, soms herschrijf ik mijn hele code 2-3 keer

maar ik programmeer voor grafische rekenmachines (casio fx-9860g) met behulp van de SDK in C

ik kan dagen besteden aan de optimalisatie, elke kb winst is namelijk wel significant in deze machines. (33 mhz cpu en 1,5 mb flash geheugen)

zondag 8 april 2007 18:20

Acties:

Verwijderd

Bij gecompileerde talen zal het zoals hierboven beschreven weining uitmaken... echter bij javascript is dit toch een ander verhaal....bij flinke js documenten...zorg ik na GOED testen er vaak voor dat ik alle commentaar weghaal..en overbodige statements toch op 1 regel verwerk.

Ik ken ook alleen javascript waarbij dit voor snelheid iets uitmaakt, overigens niet de snelheid van het lezen van de JS maar puur de download er van...een 4KB js doc is eerder binnen dan 8KB ...noem me een mierenneuker...
Natuurlijk houd ik wel altijd het org MET comments enz.
Het is alleen wel een tijdreovend klusje ...zou eigenlijk is moeten zoeken of er niet een JS optimizer te downloaden is.

@LauPro
Als je een view heb met een hoop functionaliteit..zwaar leunend op JS en je JS script is te groot..dan heb ik met 15 users al gemerkt dat het toch ietsiepietsie uitmaakt. Gelukkig is dit met javascript via xmlHTTP (ik haat ajax) veel mooier op te lossen allemaal, Debuggen is idd een zwaar drama nadat je je code heb gestript.

dus advies is toch niet doen eigenlijk.

[ Voor 21% gewijzigd door Verwijderd op 08-04-2007 18:39 ]

zondag 8 april 2007 18:34

Acties:

LauPro

Prof Mierenneuke®

Meest irritante van JS code 'reformatten' is dat je regelnummering anders gaat worden. Dus mocht er ergens een fout gaan ontstaan, dan wordt het echt gissen waar dat was. Nu zijn er wel Javascript debuggers, maar leuk is anders. Zelfde met PHP e.d.. De code strippen is misschien leuk en kan een beetje effectief zijn. Maar het zou misschien hooguit op een park van 200 servers 1 server schelen qua performance. Dus waar heb je het dan nog over?

Inkoopacties - HENK terug! - Megabit
It is a war here, so be a general!

maandag 9 april 2007 11:15

Acties:

BlackWhizz

Be-lachelijk

Ik script zelf ook, maar je moet niet zo gaan optimaliseren. Hou je code helder, maar gebruik juiste functies. Hier staan wat handige optimalisatietips. Deze zorgen voor kleinere parsetimes.

maandag 9 april 2007 11:58

Acties:

Verwijderd

Verwijderd schreef op zondag 08 april 2007 @ 18:20:
Ik ken ook alleen javascript waarbij dit voor snelheid iets uitmaakt, overigens niet de snelheid van het lezen van de JS maar puur de download er van...een 4KB js doc is eerder binnen dan 8KB ...noem me een mierenneuker...

Die ene seconde die dat langer gaat duren op een 14k4 modem is nou niet echt interessant inderdaad, dit is tegenwoordig niet eens mierenneuken meer, maar meer bacterieneuken

maandag 9 april 2007 12:03

Acties:

Onbekend

...

Bij JavaScript haal ik alle lege regels en commentaar er tussen uit. Ook de haakjes zet ik niet op aparte regels.

Hierdoor is het script niet (veel) sneller, maar maakt het wat lastiger leesbaar voor andere mensen.

Speel ook Balls Connect en Repeat

maandag 9 april 2007 12:19

Acties:

Verwijderd

Verwijderd schreef op maandag 09 april 2007 @ 11:58:
Die ene seconde die dat langer gaat duren op een 14k4 modem is nou niet echt interessant inderdaad, dit is tegenwoordig niet eens mierenneuken meer, maar meer bacterieneuken .

Integendeel, dat is juist behoorlijk interessant!!!
Niet voor de eindgebruiker maar wel voor je algehele performance van je server. Connecties kunnen simpelweg 2 keer zo snel worden vrijgegeven.

maandag 9 april 2007 12:24

Acties:

Verwijderd

Verwijderd schreef op maandag 09 april 2007 @ 12:19:
[...]
Integendeel, dat is juist behoorlijk interessant!!!
Niet voor de eindgebruiker maar wel voor je algehele performance van je server. Connecties kunnen simpelweg 2 keer zo snel worden vrijgegeven.

Nee hoor, dit valt onder de nutteloze optimalisaties. Apache en IIS, load balancers etc.. vangen dat allemaal prima af, daar hoef jij niet onleesbare code voor te maken. Performance van je server hangt af van langdurige processen, niet van een paar kb (zelfs al wordt die 1000000x aangeroepen per dag)

[ Voor 11% gewijzigd door Verwijderd op 09-04-2007 12:30 ]

maandag 9 april 2007 13:04

Acties:

Verwijderd

Verwijderd schreef op maandag 09 april 2007 @ 12:24:
Nee hoor, dit valt onder de nutteloze optimalisaties. Apache en IIS, load balancers etc.. vangen dat allemaal prima af, daar hoef jij niet onleesbare code voor te maken. Performance van je server hangt af van langdurige processen, niet van een paar kb (zelfs al wordt die 1000000x aangeroepen per dag)

Nee dus!
Dat heb je helemaal mis. Je moet verkomen dat er een wachtrij onstaat op de server doordat je uit je connecties loopt. Een wachtrij is nagenoeg equivalent aan een ddos. Het is dus altijd zaak om processen zo snel mogelijk te laten verlopen. Juist de op het eerste gezicht triviale plaatjes, css-en en js-en dienen zo snel mogelijk afgehandeld te zijn. Vergeet niet dat een browser meerdere connecties wil openen op je server juist voor dergelijke data.

Een simpel voorbeeld (zonder connectie restricities):
Neem een simpele website met 1 js, 1 css en 2 plaatjes.
Neem een server met 300 concurrent connecties/threads

dan loop je dus al uit je connecties bij 60 concurrent (300/5) clients!

Een beetje website heeft wel meer plaatjes, js-en en css en dus ook een veel hogere load. Dus ja het weghalen van onnodige info helpt daarbij wel degelijk en is dus zeker geen mierenneukerij.

maandag 9 april 2007 13:17

Acties:

Icelus

Verwijderd schreef op maandag 09 april 2007 @ 12:24:
[...]

Nee hoor, dit valt onder de nutteloze optimalisaties. Apache en IIS, load balancers etc.. vangen dat allemaal prima af, daar hoef jij niet onleesbare code voor te maken. Performance van je server hangt af van langdurige processen, niet van een paar kb (zelfs al wordt die 1000000x aangeroepen per dag)

Sites zoals Google doen dit ook dus het zal (naast het lastiger leesbaar maken

) ook wel een snelheidsvoordeel opleveren.

Developer Accused Of Unreadable Code Refuses To Comment

maandag 9 april 2007 13:34

Acties:

Electronical

Icelus schreef op maandag 09 april 2007 @ 13:17:
[...]
Sites zoals Google doen dit ook dus het zal (naast het lastiger leesbaar maken ) ook wel een snelheidsvoordeel opleveren.

Misschien is de winst in dataverkeer wel veel belangrijker voor partijen als Google.

I do not fear computers, I fear the lack of them - Isaac Asimov
"With enough eyeballs, all bugs are shallow" - Eric Raymond

maandag 9 april 2007 13:38

Acties:

Icelus

Electronical schreef op maandag 09 april 2007 @ 13:34:
[...]
Misschien is de winst in dataverkeer wel veel belangrijker voor partijen als Google.

Bedoelde snelheid in dataverkeer... niet slim opgeschreven.

Developer Accused Of Unreadable Code Refuses To Comment

maandag 9 april 2007 15:26

Acties:

Verwijderd

Icelus schreef op maandag 09 april 2007 @ 13:38:
[...]
Bedoelde snelheid in dataverkeer... niet slim opgeschreven.

Pas tegen de tijd dat jouw websites de grootte van Google gaan omvatten, kun je hier over gaan nadenken idd. Eerder NIET.

maandag 9 april 2007 15:38

Acties:

Verwijderd

Verwijderd schreef op maandag 09 april 2007 @ 15:26:
Pas tegen de tijd dat jouw websites de grootte van Google gaan omvatten, kun je hier over gaan nadenken idd. Eerder NIET.

Man lul toch niet zo slap. Je weet gewoon niet hoe de vork in de steel zit. Het is gewoon belangrijk, dat weet ik bijvoorbeeld uit eigen ervaring en ik heb het beargumenteerd. Dus je kunt wel blijven roepen dat het niet belangrijk is maar daarmee zit je er gewoon naast.

Anders gezegd: Er is in een productie site geen reden om het niet te doen.

maandag 9 april 2007 15:51

Acties:

AtleX

Tyrannosaurus Lex 🦖

Ik heb toch echt liever leesbare code die ik verstuur met HTTP compressie ipv onleesbare code die ook nog eens meer dataverkeer verbruikt.

Sole survivor of the Chicxulub asteroid impact.

maandag 9 april 2007 15:58

Acties:

maandag 9 april 2007 16:05

Devver

Pixelated

AtleX schreef op maandag 09 april 2007 @ 15:51:
Ik heb toch echt liever leesbare code die ik verstuur met HTTP compressie ipv onleesbare code die ook nog eens meer dataverkeer verbruikt.

Amen

Wat wellicht wel iets is om op te letten is het verminderen van het aantal benodigde requests door niet met alteveel losse CSS en JS-files te werken. Het gebruiken van 'sprites' voor veel gelijkende afbeeldingen die je als achtergrond-plaatje gebruikt is ook wel een aardige techniek

Intentionally left blank

Acties:

Verwijderd

crisp schreef op maandag 09 april 2007 @ 15:58:
Amen

Wat wellicht wel iets is om op te letten is het verminderen van het aantal benodigde requests door niet met alteveel losse CSS en JS-files te werken. Het gebruiken van 'sprites' voor veel gelijkende afbeeldingen die je als achtergrond-plaatje gebruikt is ook wel een aardige techniek

(Stress) Tests wijzen uit dat het aantal losse requests niet zo zeer van belang is. Het samenvoegen van bestanden levert nauwelijks iets op. Het is echt simpelweg het verkorten van de request duur die interessant is. Immers 1 groot bestand houdt ook nodeloos lang een connectie vast.

Een beetje website heeft meerdere omgevingen: Ontwikkeling, Test, Acceptatie en Productie. Je gaat natuurlijk niet debuggen op je productie omgeving. Conclusie: leesbaarheid is een compleet non-argument.

[ Voor 4% gewijzigd door Verwijderd op 09-04-2007 16:10 ]

maandag 9 april 2007 16:36

Acties:

Heb je daar ook een bron van, want ik vind het wel interessant. Ik ben ook bezig met een vrij grote webapp. met veel JS, en heb, om performance redenen wat bestanden samengevoegd (niet overdreven ongeordend, maar logisch). Hij lijkt daardoor iets sneller te laden, maar ik heb dit nog niet gemeten. Het lijkt mij idd. ook dat het voor de server niet zo veel uitmaakt, of er nu meer of minder requests zijn. Ik heb wel eens gelezen dat het voor de client wel voordelig kan zijn om het aantal requests te verminderen, puur omdat het verkrijgen van contact met de server een aardig deel van de tijd inneemt.

maandag 9 april 2007 16:38

Acties:

Verwijderd

Verwijderd schreef op maandag 09 april 2007 @ 15:38:
[...]
Man lul toch niet zo slap. Je weet gewoon niet hoe de vork in de steel zit. Het is gewoon belangrijk, dat weet ik bijvoorbeeld uit eigen ervaring en ik heb het beargumenteerd. Dus je kunt wel blijven roepen dat het niet belangrijk is maar daarmee zit je er gewoon naast.

Daarom draaien mijn websites vlekkeloos met miljoenen transacties per dag inderdaad, omdat ik niet snap dat 4kb verschil ook merkbaar is

Anders gezegd: Er is in een productie site geen reden om het niet te doen.

En verschil in code tussen dev, test en productie is de worst case scenario bad practise die je maar kunt doen. Iemand die dat doet is absoluut niet slim bezig (licht uitgedrukt). Dat de compiler optimaliseert prima en dat je dus switched van build type op de compiler zodat deze documentatie weg haalt en spaties is allemaal geen probleem. Maar zelf commentaar ed weghalen voor op productie is erg dom.

[ Voor 38% gewijzigd door Verwijderd op 09-04-2007 16:43 ]

maandag 9 april 2007 16:38

Acties:

maandag 9 april 2007 16:52

Devver

Pixelated

Verwijderd schreef op maandag 09 april 2007 @ 16:05:
[...]
(Stress) Tests wijzen uit dat het aantal losse requests niet zo zeer van belang is. Het samenvoegen van bestanden levert nauwelijks iets op. Het is echt simpelweg het verkorten van de request duur die interessant is. Immers 1 groot bestand houdt ook nodeloos lang een connectie vast.

Voor de beleving van je bezoeker maakt het wel degelijk uit of een pagina compleet met alle componenten in 2 of in 1 seconde binnen is: http://developer.yahoo.ne...7/04/rule_1_make_few.html

Ik heb daar ook nog wel eens een echte real-life performancetest van gezien, ik zal morgen die URL eens opzoeken.

Een beetje website heeft meerdere omgevingen: Ontwikkeling, Test, Acceptatie en Productie. Je gaat natuurlijk niet debuggen op je productie omgeving. Conclusie: leesbaarheid is een compleet non-argument.

Dat wordt ook niet als argument aangedragen, er wordt gezegd dat HTTP compressie vele malen effectiever is dan het strippen of op andere manieren compacten van je HTML, JS en CSS-bestanden.

[ Voor 15% gewijzigd door crisp op 09-04-2007 16:41 ]

Intentionally left blank

Acties:

Verwijderd

Verwijderd schreef op maandag 09 april 2007 @ 16:38:
Daarom draaien mijn websites vlekkeloos met miljoenen transacties per dag inderdaad, omdat ik niet snap dat 4kb verschil ook merkbaar is .

Je snapt het inderdaad niet.
Je had dus met minder goede hardware hetzelfde kunnen bereiken.

Verwijderd schreef op maandag 09 april 2007 @ 16:38:[..]
Dat de compiler optimaliseert prima en dat je dus switched van build type op de compiler zodat deze documentatie weg haalt en spaties is allemaal geen probleem.[..]

Ja mijn compiler gaat ook zo lekker om met css en js-script files...

crisp schreef op maandag 09 april 2007 @ 16:38:
Voor de beleving van je bezoeker maakt het wel degelijk uit of een pagina compleet met alle componenten in 2 of in 1 seconde binnen is: http://developer.yahoo.ne...7/04/rule_1_make_few.html

Oh maar dat ben ik ook wel met je eens hoor. Maar ik was in de context van de server aan het babbelen. Aangezien ik in had gestoken op het feit dat het compacter maken van je css-en en js-en wel degelijk je server ontlast.

crisp schreef op maandag 09 april 2007 @ 16:38:
Dat wordt ook niet als argument aangedragen, er wordt gezegd dat HTTP compressie vele malen effectiever is dan het strippen of op andere manieren compacten van je HTML, JS en CSS-bestanden.

Gewoon beide. Immers commentaar hoeft voor css en js niet over het lijntje...

maandag 9 april 2007 17:02

Acties:

Verwijderd

Verwijderd schreef op maandag 09 april 2007 @ 16:52:
[...]

Je snapt het inderdaad niet.
Je had dus met minder goede hardware hetzelfde kunnen bereiken.

Jij snapt commercie niet geloof ik. Je bouwt iets op de specs die je krijgt, niet op een p166 terwijl je een dual core ter beschikking hebt en je klant betaalt je daar ook niet voor. Optimalisaties als in CSS en JS gebruik je pas als je op andere plaatsen geen performance winst meer kan behalen en dit een vereiste is of wanneer de performance onacceptabel is.

[ Voor 40% gewijzigd door Verwijderd op 09-04-2007 17:04 ]

maandag 9 april 2007 17:05

Acties:

maandag 9 april 2007 17:32

Software Architect

Werkt hier

Verwijderd schreef op maandag 09 april 2007 @ 16:05:
Een beetje website heeft meerdere omgevingen: Ontwikkeling, Test, Acceptatie en Productie. Je gaat natuurlijk niet debuggen op je productie omgeving.

Precies, als je een bug in productie tegenkomt ga je die in een van de andere omgevingen testen. En om die omgeving te debuggen moet je natuurlijk wel goed na kunnen gaan wat er mis ging in productie en dan is het hebben van correcte regelnummers bij de foutmeldingen in je logfiles best wel zinvol.
Bovendien kan het strippen van whitespace bugs opleveren doordat de code verandert. Stel dat iemand in een sql-query string bijv voor parser hints een -- verwerkt (equivalent van // in java), je kan de whitespace niet zomaar uit die string verwijderen omdat dan de hele query syntactisch onjuist wordt en je kan die comments niet wegstrippen omdat je dan je parser hints kwijt bent. Bij C heb je natuurlijk ook compilerhints #define enzo.
Bij Java zal dat iets minder een argument zijn omdat die geen compilerhints kent en je strings niet over meerdere regels geplaatst mogen zijn.
Voor html zijn vergelijkbare cornercases te bedenken (sowieso is er de <pre>-tag en de white-space: pre; constructie in css). Dus in de praktijk zal je de gestripte versie dan ook moeten testen, wat het debuggen dan weer lastig maakt...

Ik vind persoonlijk dat het strippen van whitespace, comments en andere "overbodige syntax" alleen gedaan moet worden als je er wel een reden toe hebt. De reden 'er is geen reden om het niet te doen' vind ik niet zo sterk, bovendien heb ik je er net twee gegeven. Bij programmacode maakt het voor een gecompileerde omgeving toch al geen bal uit en voor een geinterpreteerde omgeving bijzonder weinig, zeker als je omgeving het resultaat van de on-the-fly compilatie ergens bewaart.
Voor html, css en javascript is het een beetje zinvol om de hoeveelheid dataverkeer terug te dringen, maar na gzip-compressie is een en ander niet bijster effectief meer.

Verwijderd schreef op maandag 09 april 2007 @ 16:52:
Oh maar dat ben ik ook wel met je eens hoor. Maar ik was in de context van de server aan het babbelen. Aangezien ik in had gestoken op het feit dat het compacter maken van je css-en en js-en wel degelijk je server ontlast.

k denk dat het dusdanig marginaal is, dat je daar beter niet eens tijd aan kan besteden. Je bereikt veel meer door de clients uberhaupt die files niet te laten opvragen (correcte caching headers) of door een (lightweight) webserver te installeren die dan eventueel ook nog de gegzipte versie in een cache bewaard om zo sneller op de browser-requests te kunnen reageren.
We hadden een niet zo lekker ingestelde caching-header voor IE6 (die is daar nogal gevoelig mee) met als gevolg dat bepaalde statische files toch elke request opnieuw opgevraagd werden, toen we dat gefixed hadden zag je een grote teruggang in het aantal verwerkte requests door apache, maar je zag eigenlijk nauwelijks teruggang in de cpu-usage en system load.
Kortom, voor de servers maakte het nihil uit dat ze dat extra werk niet meer hadden, ondanks dat het voor de clientside misschien een beetje merkbaar was.

Gewoon beide. Immers commentaar hoeft voor css en js niet over het lijntje...

Ook daar geldt het argument van veranderende code en regelnummers, imho.

[ Voor 25% gewijzigd door ACM op 09-04-2007 17:13 ]

Acties:

maandag 9 april 2007 17:44

Verwijderd schreef op maandag 09 april 2007 @ 15:26:
[...]

Pas tegen de tijd dat jouw websites de grootte van Google gaan omvatten, kun je hier over gaan nadenken idd. Eerder NIET.

Al met een simpele kleine website als de mijne, slechts 16 miljoen pageviews, kan een 10kb vermindering al 160GB maandelijks schelen. Zelfs als gzip het met een factor 100 verkleind, dan nog is een 1,6GB dataverkeer dat je gratis krijgt altijd mooi meegenomen. Zelfs al heb ik unmetered.

Hierbij even geen rekening houdend met de caching van constante files, etc.

AtleX schreef op maandag 09 april 2007 @ 15:51:
Ik heb toch echt liever leesbare code die ik verstuur met HTTP compressie ipv onleesbare code die ook nog eens meer dataverkeer verbruikt.

Doe zoals ik. Alle code in dev/staging-omgeving gewoon leesbaar houden. Zodra het op de productie moet, even een js/css/html-optimizer er door heen jagen. Wat moet een gebruiker nou met leesbare code?
Kost je paar minuten, dus waarom niet?

One thing's certain: the iPad seriously increases toilet time.. tibber uitnodigingscode: bqufpqmp

Acties:

Verwijderd

kmf schreef op maandag 09 april 2007 @ 17:32:
[...]

Al met een simpele kleine website als de mijne, slechts 16 miljoen pageviews, kan een 10kb vermindering al 160GB maandelijks schelen. Zelfs als gzip het met een factor 100 verkleind, dan nog is een 1,6GB dataverkeer dat je gratis krijgt altijd mooi meegenomen. Zelfs al heb ik unmetered.

Hierbij even geen rekening houdend met de caching van constante files, etc.

En laat je CSS en JS bestanden nu erg goed kunnen cachen wat vele malen effectiever is. En overigens is het inderdaad wel interessanter om het te doen op een site die 16 miljoen pageviews heeft.

[ Voor 8% gewijzigd door Verwijderd op 09-04-2007 17:46 ]

maandag 9 april 2007 17:50

Acties:

Verwijderd

Er wordt alweer compleet buiten de context geschreven. Het enige wat ik zei was dat het strippen van whitespace en comments uit css en js files wel degelijk uit maakt en niets te maken heeft met mierenneukerij. Dat is simpelweg een feit. Waarom hier nu weer java, php of weet ik veel wat voor geparsde/compileerde code bijgehaald moet worden ontgaat mij volkomen.

Of het handig is in een productie omgeving is een andere, niet relevante, discussie. Het liefst houd ik de omgevingen ook gelijk maar dat is vanwege vele factoren niet altijd mogelijk.

maandag 9 april 2007 18:08

Acties:

AtleX

Tyrannosaurus Lex 🦖

kmf schreef op maandag 09 april 2007 @ 17:32:
[...]

Doe zoals ik. Alle code in dev/staging-omgeving gewoon leesbaar houden. Zodra het op de productie moet, even een js/css/html-optimizer er door heen jagen. Wat moet een gebruiker nou met leesbare code?
Kost je paar minuten, dus waarom niet?

Klant belt op en zegt "he Alex, die site die je gemaakt hebt werkt geweldig, maar ik krijg een JS error op regel 1 met als foutmelding <insert onbegrijpelijke IE error message>".

* AtleX zoekt in zijn uncompressed code, en ziet niks op regel 1

* AtleX kijkt in de productie omgeving, en mag heel die brij compressed JS door gaan zoeken op zoek naar a) waar de fout optreedt en b) waarom die optreedt.

Veel plezier met debuggen.

Ik zou echt de winst eerst proberen te halen met HTTP compressie en goede caching. Zowel CSS als JS als HTML (want die zijn statisch) bestanden kan je prima cachen.

Sole survivor of the Chicxulub asteroid impact.

maandag 9 april 2007 18:47

Acties:

Even een vraagje met betrekking tot het cachen van javascript en CSS files door de browser. In hoeverre moet je hierzelf controle over nemen? Neemt apache dit helemaal zelf voor zijn rekening, of is het nog wat tweaken nodig, of misschien het serveren via een zelfgeschreven script?

En wanneer is HTTP compressie zinvol? Altijd, of zijn er bepaalde voorwaarden/grenzen waarbij het toepasbaar wordt?

Edit:

Dit is wel een interessant artikel, er worden wel goede argumenten gegeven.

[ Voor 17% gewijzigd door Michali op 09-04-2007 19:18 ]

maandag 9 april 2007 20:53

Acties:

Gomez12

Michali schreef op maandag 09 april 2007 @ 18:47:
Even een vraagje met betrekking tot het cachen van javascript en CSS files door de browser. In hoeverre moet je hierzelf controle over nemen? Neemt apache dit helemaal zelf voor zijn rekening, of is het nog wat tweaken nodig, of misschien het serveren via een zelfgeschreven script?

En wanneer is HTTP compressie zinvol? Altijd, of zijn er bepaalde voorwaarden/grenzen waarbij het toepasbaar wordt?

Edit:

Dit is wel een interessant artikel, er worden wel goede argumenten gegeven.

Apache kan dit zelf voor zijn rekening nemen, maar beter is het om het gewoon zelf te doen. Jij kan beter inschatten wanneer iets niet meer gecached mag worden dan apache.

Vb. Ik heb een site met daar op alle JS / CSS een caching header van een week staan. Klant weet dit ook, dus als klant iets aangepast wil hebben weet hij dat hij er een week van te voren mee moet komen, dan wordt de caching header drastisch verlaagt ( naar eerst enkele uren en vlak voor het in produktie zetten naar enkele minuten ). Is de update gebeurd dan gaat de caching header gewoon weer terug naar een week.

maandag 9 april 2007 20:58

Acties:

maandag 9 april 2007 21:03

Software Architect

Werkt hier

Verwijderd schreef op maandag 09 april 2007 @ 17:50:
Het enige wat ik zei was dat het strippen van whitespace en comments uit css en js files wel degelijk uit maakt en niets te maken heeft met mierenneukerij. Dat is simpelweg een feit.

Ok, onze default.css is standaard 22528 bytes
met alle tabs en newlines er uit en de eventuele dubbele spaties vervangen door eentje en verder geen whitespace voor en na '{', '}' en ':' is 20072 bytes.

Gecomprimeerd met gzip (gewoon cli) is de eerste 4761 bytes en de tweede 4502. Oftewel in een tabelletje wordt het dan voor deze specifieke file:

Unstripped	22528 B	4761 B	79%
Stripped	20072 B	4502 B	78%
	11%	5%	80%

Zoals je ziet is de besparing bij stripped+compressed 80%, maar unstripped+compressed is al 79%. Je wint dus ten op zichte van de originele file iets meer dan 1% dataverkeer, ondanks dat je 10% van je file afknabbelt. De reden is natuurlijk heel simpel, door de dictionary van gzip komt de hele 'spatie+{+enter' op maar 2 bytes in totaal neer dan de simpele '{'. In de praktijk zal het wel iets minder simpel zijn, maar het principe komt daar wel op neer. De meestgebruikte strings worden door een zo kort mogelijke vervangende bitsequence vervangen en het einde/begin van een css-block is natuurlijk een van de meestvoorkomende stukken tekst er in.
Om die reden maakt het verkorten van de identifiers en classnames ook maar weinig uit. Hoewel daar waarschijnlijk nog wel wat meer winst mee te halen valt.

Voor de j.js maakt het trouwens wel iets meer uit, uiteindelijk scheelt het 7 procentpunt extra op de 33kB die de file origineel was. Hoewel de file ongecomprimeerd 25% kleiner werd...

Waarom hier nu weer java, php of weet ik veel wat voor geparsde/compileerde code bijgehaald moet worden ontgaat mij volkomen.

Omdat je niet alleen bugs in de java- of phpcode hebt, maar ook in javascript, css en html.

Acties:

maandag 9 april 2007 21:23

Software Architect

Werkt hier

Michali schreef op maandag 09 april 2007 @ 18:47:
Even een vraagje met betrekking tot het cachen van javascript en CSS files door de browser. In hoeverre moet je hierzelf controle over nemen? Neemt apache dit helemaal zelf voor zijn rekening, of is het nog wat tweaken nodig, of misschien het serveren via een zelfgeschreven script?

Wij gebruiken daarvoor mod_expire voor statische files en natuurlijk php's eigen header-functionaliteit.

En wanneer is HTTP compressie zinvol? Altijd, of zijn er bepaalde voorwaarden/grenzen waarbij het toepasbaar wordt?

Voor alles wat goed comprimeerbaar is, dus met name tekstbestanden (o.a. css, js, html, xml), ik zou dan weer niet je jpg's en gifjes comprimeren, die kan je beter met een image-optimiser opnieuw comprimeren als je die te groot vindt.
Verder is er een bepaalde minimumgrootte die mod_gzip aanhoudt omdat er natuurlijk wel overhead bij komt. Waar die grens precies ligt weet ik niet, ik gok ergens tussen de 100 en de 500 bytes.

Acties:

RSpliet

*blink*

Wat ik eigenlijk veel interessanter vind, is welke kant men op optimaliseert. Meestal geven de kleine optimalisaties (comments wegwerken, zelfde programma met n variabele minder, iets andere functieaanroepen etc.) namelijk niet het echte resultaat.
Wil je echte performanceverschillen, dan zal je meestal geheugen moeten opofferen.
Zo zit ik zelf met een dilemma met C, ik ben bezig met een klein project waarbij een van de functies is het bijhouden van unieke entries. Dan is de eerste vraag al, hoe laat ik mijn array in capaciteit groeien, lineair (elke keer met een x aantal entries), of maak ik m steeds 2x zo groot zodat ik minder vaak moet vergroten (en dus minder vaak de data moet verplaatsen door t geheugen, omdat groeien niet meer past).
Ander dilemma: een geordende array kost bij het toevoegen aanzienlijk meer tijd (omdat de entries die erachter staan moeten worden opgeschoven), maar het doorzoeken kost nog maar een fractie van de tijd
Geordende lijst: op 10000 entries is een zoekactie in maximaal 14 stappen gedaan. Toevoegen kost gemiddeld 5000 stappen (omdat alle entries moeten worden opgeschoven in de array)
Ongeordende lijst: op 10000 entries kost een zoekactie maximaal 10000 stappen, minimaal 1, gemiddeld 5000. Toevoegen is in 1 stap gedaan.
Wat heeft hier de overhand... afhankelijk van de unieke entries. Als ik 15x zo vaak zoek (dus elke entry gemiddeld 15x voorkomt in de bron) is een geordende lijst sneller. Als ik minder zoek is een ongeordende berg rommel schijnbaar toch sneller.
Maar ik dwaal tever af: optmized men hier naar zo min mogelijk geheugen of naar zo min mogelijk CPU tijd?

[ Voor 16% gewijzigd door RSpliet op 09-04-2007 21:27 ]

Schaadt het niet, dan baat het niet

maandag 9 april 2007 21:27

Acties:

Freee!!

Trotse papa van Toon en Len!

Met de geheugenprijzen van tegenwoordig zou ik naar CPU tijd optimaliseren.

The problem with common sense is that sense never ain't common - From the notebooks of Lazarus Long

GoT voor Behoud der Nederlandschen Taal [GvBdNT

maandag 9 april 2007 21:40

Acties:

maandag 9 april 2007 22:07

Es gibt keine kleinen Punkte!

Topicstarter

ACM schreef op maandag 09 april 2007 @ 20:58:
[...]

Ok, onze default.css is standaard 22528 bytes
met alle tabs en newlines er uit en de eventuele dubbele spaties vervangen door eentje en verder geen whitespace voor en na '{', '}' en ':' is 20072 bytes.

Gecomprimeerd met gzip (gewoon cli) is de eerste 4761 bytes en de tweede 4502. Oftewel in een tabelletje wordt het dan voor deze specifieke file:

Unstripped 22528 B 4761 B 79%
Stripped 20072 B 4502 B 78%
11% 5% 80%

Zoals je ziet is de besparing bij stripped+compressed 80%, maar unstripped+compressed is al 79%. Je wint dus ten op zichte van de originele file iets meer dan 1% dataverkeer, ondanks dat je 10% van je file afknabbelt. De reden is natuurlijk heel simpel, door de dictionary van gzip komt de hele 'spatie+{+enter' op maar 2 bytes in totaal neer dan de simpele '{'. In de praktijk zal het wel iets minder simpel zijn, maar het principe komt daar wel op neer. De meestgebruikte strings worden door een zo kort mogelijke vervangende bitsequence vervangen en het einde/begin van een css-block is natuurlijk een van de meestvoorkomende stukken tekst er in.
Om die reden maakt het verkorten van de identifiers en classnames ook maar weinig uit. Hoewel daar waarschijnlijk nog wel wat meer winst mee te halen valt.

Voor de j.js maakt het trouwens wel iets meer uit, uiteindelijk scheelt het 7 procentpunt extra op de 33kB die de file origineel was. Hoewel de file ongecomprimeerd 25% kleiner werd...

[...]

Omdat je niet alleen bugs in de java- of phpcode hebt, maar ook in javascript, css en html.

Dat mijn post zoveel reacties zou krijgen, wie had dat gedacht. Heb zojuist even gespeeld met de grootte van een css file. De file was standaard 30kb, vervolgens heb ik de classes achter elkaar gezet en werdt het bestand 24kb. Tot slot heb ik de gehele inhoud van het bestand achter elkaar gezet en nu is het bestand 20kb groot.

Ben zelf niet bekend met compressie zoals gzip, kan dit in combinatie met asp en elke browser gebruikt worden. M.a.w. is dit een serverside compressie? Leuke links zijn altijd welkom.

Ein kleiner Punkt in einer grossen Welt

Acties:

maandag 9 april 2007 23:08

Software Architect

Werkt hier

DerKleinePunkt schreef op maandag 09 april 2007 @ 21:40:
Ben zelf niet bekend met compressie zoals gzip, kan dit in combinatie met asp en elke browser gebruikt worden. M.a.w. is dit een serverside compressie? Leuke links zijn altijd welkom.

Binnen een HTTP-response mag de content op een willekeurige manier encoded worden - mits de browser het snapt, o.a. dus met gzip-compressie. Dat wordt aangegeven met de Content-Encoding-responseheader en de browser kan aangeven wat hij snapt met de bijbehorende Accept-Encoding-requestheader. Elke huidige browser snapt het simpele deflate en de iets geavanceerdere gzip-compressie. Internet Explorer 4.0 had er geloof ik wel wat moeite mee, maar die wordt vrijwel niet meer gebruikt, dus je kan er veilig van uit gaan dat elke browser het snapt.

Hoe je vervolgens je content met gzip encode hangt natuurlijk af van wat er precies geserveerd wordt. Bij ons worden statische files (met name css en js) door apache met mod_gzip gecomprimeerd en opgestuurd. De html die we met php uitspugen wordt echter door php zelf gecomprimeerd (dmv output buffering en gzip output handler).
Het lijkt me dat IIS die eerste variant ook kan doen voor je en wellicht ook de html uit je asp kan comprimeren, als dat niet door IIS gedaan kan worden is er vast wel een of ander standaardcomponent voor je favoriete omgeving te vinden. De beste zoekterm zal wel 'HTTP compression' zijn.

Acties:

maandag 9 april 2007 23:41

Devver

Pixelated

ACM schreef op maandag 09 april 2007 @ 20:58:
[...]
Voor de j.js maakt het trouwens wel iets meer uit, uiteindelijk scheelt het 7 procentpunt extra op de 33kB die de file origineel was. Hoewel de file ongecomprimeerd 25% kleiner werd...

Maar had je na het strippen van de whitespace ook nog een werkend JS-bestand? Ik gok van niet

Overigens heb ik zelf ook wat testjes gedaan en kwam met een willekeurige JS-file op ongeveer dezelfde resultaten uit. Het gebruik van packer had uiteindelijk overigens geen extra positief effect meer in combinatie met HTTP compressie:

Unstripped	30314 B	6898 B	77%
Stripped	26377 B	6286 B	76%
Packed	14703 B	6273 B	57%

Intentionally left blank

Acties:

maandag 9 april 2007 23:48

AtleX schreef op maandag 09 april 2007 @ 18:08:
[...]

Klant belt op en zegt "he Alex, die site die je gemaakt hebt werkt geweldig, maar ik krijg een JS error op regel 1 met als foutmelding <insert onbegrijpelijke IE error message>".

* AtleX zoekt in zijn uncompressed code, en ziet niks op regel 1

* AtleX kijkt in de productie omgeving, en mag heel die brij compressed JS door gaan zoeken op zoek naar a) waar de fout optreedt en b) waarom die optreedt.

Veel plezier met debuggen.

Dan had AtleX de site niet goed getest op de drie grote browsers, maar geeft niet, want AtleX gaat dan even naar de staging omgeving en kijkt waar de foutmelding zit met een mooie javascript debugger.

One thing's certain: the iPad seriously increases toilet time.. tibber uitnodigingscode: bqufpqmp

Acties:

Verwijderd

kmf schreef op maandag 09 april 2007 @ 23:41:
[...]

Dan had AtleX de site niet goed getest op de drie grote browsers, maar geeft niet, want AtleX gaat dan even naar de staging omgeving en kijkt waar de foutmelding zit met een mooie javascript debugger.

En daar kom je achter door? Elk mogelijk scenario na te lopen, want je klant is altijd 100% onbetrouwbaar? Het enige waar hij betrouwbaar op is, is dat hij vind dat er een fout is. Dat gaat dus niet werken.

dinsdag 10 april 2007 00:03

Acties:

Gomez12

kmf schreef op maandag 09 april 2007 @ 23:41:
[...]

Dan had AtleX de site niet goed getest op de drie grote browsers, maar geeft niet, want AtleX gaat dan even naar de staging omgeving en kijkt waar de foutmelding zit met een mooie javascript debugger.

Jammer, maar daar kan AtleX de fout niet reproduceren, na 1/2 dag proberen de bug te reproduceren komt de klant erachter dat hij Norton Internet Security heeft en dat het hier ook maar op moet werken...

Veel plezier.

dinsdag 10 april 2007 11:53

Acties:

crisp schreef op maandag 09 april 2007 @ 23:08:
[...]

Maar had je na het strippen van de whitespace ook nog een werkend JS-bestand? Ik gok van niet

Heb je ervaring met Dojo ShrinkSafe? Ik ga het nu even uitproberen, het lijkt het ideale compromis tussen strippen en debuggen.

Edit:

Hmm, het behoudt regelsnummer niet helemaal, het haalt toch lege witregels weg, waardoor die niet meer kloppen. Verder heb ik het net geprobeerd op een redelijk groot JS bestand (32KB) en het resultaat was ongeveer 77% van het origineel (25KB) en een werkend bestand. Toch wel een redelijke besparing. Geen idee hoe veel je dan bespaart met GZIP compressie er extra overheen.

[ Voor 33% gewijzigd door Michali op 10-04-2007 12:09 ]

dinsdag 10 april 2007 21:26

Acties:

Verwijderd

Gomez12 schreef op dinsdag 10 april 2007 @ 00:03:
Jammer, maar daar kan AtleX de fout niet reproduceren, na 1/2 dag proberen de bug te reproduceren komt de klant erachter dat hij Norton Internet Security heeft en dat het hier ook maar op moet werken...

Veel plezier.

$_/-\o_$

Freee!! schreef op maandag 09 april 2007 @ 21:27:
Met de geheugenprijzen van tegenwoordig zou ik naar CPU tijd optimaliseren.

Tijd is geld

Ik denk dat de echte optimalisaties zitten in het zoveel als mogelijk gebruik maken van built-in functies. Bedrijven als Borland en consorten hebben daar al de nodige optimalisatie in verricht.

dinsdag 10 april 2007 22:11

Acties:

dinsdag 10 april 2007 23:18

Devver

Pixelated

Michali schreef op dinsdag 10 april 2007 @ 11:53:
[...]

Heb je ervaring met Dojo ShrinkSafe? Ik ga het nu even uitproberen, het lijkt het ideale compromis tussen strippen en debuggen.

Edit:

Hmm, het behoudt regelsnummer niet helemaal, het haalt toch lege witregels weg, waardoor die niet meer kloppen. Verder heb ik het net geprobeerd op een redelijk groot JS bestand (32KB) en het resultaat was ongeveer 77% van het origineel (25KB) en een werkend bestand. Toch wel een redelijke besparing. Geen idee hoe veel je dan bespaart met GZIP compressie er extra overheen.

Wel van gehoord, niet getest tot 5 minuten geleden

Deze tool heeft als voordeel boven packer dat het geen overmatige syntax-eisen stelt en toch redelijke resultaten bereikt. Mijn voorbeeld-JS ging van 30314 bytes naar 23366 bytes (23% besparing) en gezipped werd dat uiteindelijk 6090 bytes - totaal 80% besparing dus.

De vraag die je je moet stellen is echter: is die extra 3% besparing (immers, direct gzippen van een uncompressed file geeft ook al 77% besparing) de mogelijke nadelen wel waard? Je zal immers toch initieel elke keer weer moeten verifieren dat het 'shrinken' zelf geen problemen introduceerd...

Intentionally left blank

Acties:

LauPro

Prof Mierenneuke®

Volgens mij kan je veel meer winnen door je code te optimaliseren alsin functies centraliseren en SQL-queries nalopen op juiste indices en constraints. En zelfs dan zul je bij de meeste sites nog veel meer kunnen winnen door bijvoorbeeld slim te cachen, misschien een transparante proxy op een paar dirs etc.

Optimaliseren op code is meer iets voor embedded, maar zelf daar zie je de laatste tijd dat dit overbodig gaat worden gezien de hoeveelheid geheugen dat beschikbaar is.

Overigens wordt PHP5 intern al een klein beetje gecompileerd. Eenmalig wordt er een soort abstractie gemaakt van het script totdat deze wijzigt. CLI versie niet overigens, alleen de Apache2 SAPI voor zover ik weet. Bij gebruik van Zend gaat deze compilatie veel verder tot 'machine-code' voor zover ik weet.

Verder is het natuurlijk raadzaam om gewoon tabs te gebruiken ipv spaces (ANSI terminals zijn verleden tijd) dat is gewoon een mentaliteitskwestie en meestal 1 vinkje in je editor...

Inkoopacties - HENK terug! - Megabit
It is a war here, so be a general!

woensdag 11 april 2007 10:01

Acties:

voodooless

Sound is no voodoo!

Freee!! schreef op maandag 09 april 2007 @ 21:27:
Met de geheugenprijzen van tegenwoordig zou ik naar CPU tijd optimaliseren.

Zo eenvoudig is dat natuurlijk nog lang niet! Wat als je memory bandbreedte niet groot genoeg is en je CPU de halve tijd uit zijn neust staat te vreten?

Nee, code optimaliseren doe je pas nadat je hebt vastgesteld wat er precies mis mee is. Eerst ga je eens checken welk stukje precies traag is, en als je dat eenmaal weet ga je kijken waarom dat stukje traag is. Vervolgens ga je dat probleem aanpakken. Vaak is dan een CPU optimalisatie, maar het kan net zo goed een memoryoptimalisatie zijn. Net wat het beste uitpakt.

Ik ben zelf veel bezig met embedded java, en daar heb je nu eenmaal niet veel geheugen. Het was af en toe echt een kriem om alles passend en stabiel te krijgen

Helaas moet je dan vaak tegen je OO principes ingaan. Sommige stukken heb ik wel 5 keer herschreven

. Gelukkig hebben we nu met nieuwe hardware een stuk meer geheugen.

Do diamonds shine on the dark side of the moon :?

woensdag 11 april 2007 11:40

Acties:

Confusion

Fallen from grace

Verwijderd schreef op maandag 09 april 2007 @ 16:05:
\Het samenvoegen van bestanden levert nauwelijks iets op.

Het scheelt de overhead van extra connecties.

Wie trösten wir uns, die Mörder aller Mörder?

woensdag 11 april 2007 11:46

Acties:

woensdag 11 april 2007 12:51

Devver

Pixelated

Confusion schreef op woensdag 11 april 2007 @ 11:40:
[...]

Het scheelt de overhead van extra connecties.

idd, hoewel je ook op dat punt een gulden middenweg moet zien te vinden aangezien je bij teveel samenvoegen ook weer alles gaat concentreren op de eerste hit.

Overigens hier nog het linkje naar een echte benchmark-test mbt page loadtimes en het effect van het combineren van requests, pipelining e.d.: http://www.die.net/musings/page_load_time/

Intentionally left blank

Acties:

Verwijderd

Confusion schreef op woensdag 11 april 2007 @ 11:40:
Het scheelt de overhead van extra connecties.

En zoals ik eerder aangaf blijkt dat niet zo enorm veel uit te maken. Het zijn voornamelijk de threads die zo snel mogelijk dienen te worden vrij gegeven. Maar zoals altijd: alle beetjes helpen.

woensdag 11 april 2007 12:59

Acties:

Freee!!

Trotse papa van Toon en Len!

voodooless schreef op woensdag 11 april 2007 @ 10:01:
[...]
Zo eenvoudig is dat natuurlijk nog lang niet! Wat als je memory bandbreedte niet groot genoeg is en je CPU de halve tijd uit zijn neust staat te vreten?

Dat is voor mij meestal niet zo'n probleem, ik programmeer RPG en COBOL op een AS/400. En in de loop der jaren heb ik een aantal dingen geleerd waarmee ik die code vrij efficiënt schrijf.

The problem with common sense is that sense never ain't common - From the notebooks of Lazarus Long

GoT voor Behoud der Nederlandschen Taal [GvBdNT

woensdag 11 april 2007 13:23

Acties:

xces

To got or not to got..

Ik heb het niet helemaal gelezen, maar zelf heb ik een pagina van 300kb en 18 includes naar 1 pagina van 37kb gekregen zonder includes. Page load ging van 3 naar 1 seconde.

- Alle CSS combineren en strippen + wegschrijven als 1 file
- Alle JS combineren en packen + wegschrijven naar 1 file
- Vervolgens de CSS en JS van deze pagina server side in de head pompen en uitsturen met GZIP
- Volgende keer enkel de mtime checken. Bij geen wijziging het eerder gecomprimeerde bestand weer injecten.

Om de JS te packen gebruik ik een PHP klasse die de packer van Dean Edwards immiteerd, en voor CSS doe ik zelf het een en ander met regular expressions strippen...

Al je CSS en JS blijft zo gescheiden om aan te passen wat je wilt, en je pagina is toch retesnel. Voor mij werkt het prima, ik heb het e.e.a. getest met zowel Firebug als met een externe site die mijn site en includes inlaadde. Ook werk ik natuurlijk met CSS sprites, maar al met al zijn er een hoop dingen die allemaal geoptimaliseerd kunnen worden, al dan niet geautomatiseerd.

bronnen:
- http://www.thinkvitamin.c...nce-your-page-performance
- http://learningtheworld.eu/2007/performance/
- http://www.ejeliot.com/blog/73
- http://adrian3.googlepages.com/jsjuicer.html

Er is ook een Nederlands blog beschikbaar, maar dat weet ik even niet meer...

woensdag 11 april 2007 13:49

Acties:

woensdag 11 april 2007 15:33

Devver

Pixelated

xces schreef op woensdag 11 april 2007 @ 13:23:
- Vervolgens de CSS en JS van deze pagina server side in de head pompen en uitsturen met GZIP

Wat dan weer jammer is is dat je dan geen gebruik maakt van de clientcache...

Intentionally left blank

Acties:

woensdag 11 april 2007 15:36

Gomez12 schreef op dinsdag 10 april 2007 @ 00:03:
[...]

Jammer, maar daar kan AtleX de fout niet reproduceren, na 1/2 dag proberen de bug te reproduceren komt de klant erachter dat hij Norton Internet Security heeft en dat het hier ook maar op moet werken...

Veel plezier.

Dan gaat AtleX ervoor zorgen dat de stagiair bij de eerstelijns helpdesk een onvoldoende als beoordeling krijgt omdat die niet de standaard vragen had doorgenomen met de klant om dusdanige problemen te ondervangen.

One thing's certain: the iPad seriously increases toilet time.. tibber uitnodigingscode: bqufpqmp

Acties:

woensdag 11 april 2007 16:14

crisp schreef op woensdag 11 april 2007 @ 13:49:
[...]

Wat dan weer jammer is is dat je dan geen gebruik maakt van de clientcache...

Ik heb wel gemerkt dat als je er een .gz bestand van de css/jss maakt, dat de nieuwere browsers deze wel cachen.

maar tja... een aparte fileserver met lighttpd voorkomt veel van de HTTP requestproblemen eigenlijk.

[ Voor 14% gewijzigd door kmf op 11-04-2007 15:38 ]

One thing's certain: the iPad seriously increases toilet time.. tibber uitnodigingscode: bqufpqmp

Acties:

Hydra

Cavorka schreef op vrijdag 06 april 2007 @ 15:51:
Ruwe test met de include van 1 class file van 23kb (origineel) en 15kb (small):
Include tijd Origineel: 0.00220s
Include tijd Small: 0.00191s

Zo hee, boeiend.

Neem je ook ff de tijd mee die het je kost om uit te vogelen wat een bepaalde functie ook al weer doet? Duurt wel ff wat lander dan 0.00009s namelijk.

Ik dacht dat dit topic ging om code optimalisaties. Beknibbelen op commentaar hoort daar AB-SO-LUUT niet bij.

crisp schreef op maandag 09 april 2007 @ 15:58:
Wat wellicht wel iets is om op te letten is het verminderen van het aantal benodigde requests door niet met alteveel losse CSS en JS-files te werken. Het gebruiken van 'sprites' voor veel gelijkende afbeeldingen die je als achtergrond-plaatje gebruikt is ook wel een aardige techniek

Als je grote .js of .css files hebt zorg je dat die fijn client-side gecached kunnen worden. Daar haal je veel meer winst mee dan te gaan beknibbelen op een paar kB.

Daarnaast: code maintainability > alles. Als een overpaid consultant een paar uur langer bezig is omdat je code onleesbaar is, heb je echt geen fuck aan de bandbreedte die je bespaart.

[ Voor 41% gewijzigd door Hydra op 11-04-2007 16:19 ]

https://niels.nu

woensdag 11 april 2007 19:07

Acties:

Verwijderd

Verwijderd schreef op maandag 09 april 2007 @ 12:24:
[...]
Nee hoor, dit valt onder de nutteloze optimalisaties. Apache en IIS, load balancers etc.. vangen dat allemaal prima af, daar hoef jij niet onleesbare code voor te maken. Performance van je server hangt af van langdurige processen, niet van een paar kb (zelfs al wordt die 1000000x aangeroepen per dag)

Hmm dit begrijp ik niet helemaal...betekent dit dat nu iedere klant load balancers e.d moet gaan aanschaffen...en dat je als website leverancier geen websites meer kunt leveren aan klanten...die een externe hosting hebben omdat ze dan IIS moeten configureren?

Na goed...wat ik bedoelde ging eigenlijk niet over de server-side maar meer het dowloaden zelf..
Plus dat ik zie hier nogal wat post waarin men spreekt over seconden? Uh..dat begrijp ik ook weer niet helemaal...als een pagina e parstime heeft van 0.1 dan ga ik toch al tracen wat er zoveel tijd in beslag neemt......en nee dat ik niet de javascript..

Verder vind ik die caching wel interessant, maar is dat niet gevaarlijk bij dynamische js bestanden.
De aanroep blijft dan namelijk toch hetzelfde...of begrijp ik deze effe niet..

woensdag 11 april 2007 19:09

Acties:

Verwijderd

Verwijderd schreef op woensdag 11 april 2007 @ 19:07:
Na goed...wat ik bedoelde ging eigenlijk niet over de server-side maar meer het dowloaden zelf..
Plus dat ik zie hier nogal wat post waarin men spreekt over seconden? Uh..dat begrijp ik ook weer niet helemaal...als een pagina e parstime heeft van 0.1 dan ga ik toch al tracen wat er zoveel tijd in beslag neemt......en nee dat ik niet de javascript..

Die 0,1 seconde is leuk maar voor de browser dit getoond heeft is het als nog snel een paar seconde en voor de gebruiker is het al snel 5 seconde voordat hij het duidelijk heeft dat de pagina is geladen.

woensdag 11 april 2007 22:52

Acties:

vrijdag 13 april 2007 12:32

Devver

Pixelated

Hydra schreef op woensdag 11 april 2007 @ 16:14:
[...]
Als je grote .js of .css files hebt zorg je dat die fijn client-side gecached kunnen worden. Daar haal je veel meer winst mee dan te gaan beknibbelen op een paar kB.

De 'first impression' die een bezoeker heeft als hij/zij op je website komt is ook heel belangrijk. Cacheing of geen cacheing, als de eerste hit te lang duurt om te laden - bijvoorbeeld omdat je bijvoorbeeld 300KB aan javascript over de lijn gooit - dan is je bezoeker alweer vertrokken.

Intentionally left blank

Acties:

Klopt het trouwens dat Firefox niet cached als je gzip compressie toepast? Ik krijg het althans niet werkend met gzip compressie. Als ik het uitschakel, dan cached hij wel.

vrijdag 13 april 2007 12:37

Acties: