---

Jeg vil gerne have lavet nogle tests af hastighed af min side, hvor jeg
er ved at afprøve forskellige former for optimering, og eftersom ASP
ikke kan tage milisekunder, så tænkte jeg på Javascript.

Spørgsmålet går i første omgang på, om man kan tælle i milisekunder i
Javascript. Jeg tænkte bare på som en start at sætte en variabel
indeholdende nuværende tid, hente siden et antal gange i en
for-next-løkke og så udskrive forskellen.

Hvor nøjagtigtr kan JS operere i tid?

Er der en anden metode, som er bedre end JS?

PS: Siden er egentlig ikke en rigtig side, men resultat af testene, som
går på minify og sammenføjning af filer (fjern space før .dk)

Sammenføjning uden minify:
http://www.webdesigngruppen .dk/css/join.asp?f=meeting,main

Sammenføjning med minify:
http://www.webdesigngruppen .dk/css/join.asp?f=meeting,main&m=1

Derudover skal der være en test, hvor de hentes som "rigtige" filer hver
for sig, så man har en idé om forskellen.


MVH
Rune Jensen

---

Rune Jensen wrote:

> Jeg vil gerne have lavet nogle tests af hastighed af min side, hvor jeg
> er ved at afprøve forskellige former for optimering, og eftersom ASP
> ikke kan tage milisekunder,

Det menr jeg nu godt den(ASP) kan, eller noget der ligner.

> Spørgsmålet går i første omgang på, om man kan tælle i milisekunder i
> Javascript.

Kig efter Date objektet.

--
Med venlig hilsen
Stig Johansen

---

Den 26-04-2010 01:56, Stig Johansen skrev:
> Rune Jensen wrote:
>
>> Jeg vil gerne have lavet nogle tests af hastighed af min side, hvor jeg
>> er ved at afprøve forskellige former for optimering, og eftersom ASP
>> ikke kan tage milisekunder,
>
> Det menr jeg nu godt den(ASP) kan, eller noget der ligner.
>
>> Spørgsmålet går i første omgang på, om man kan tælle i milisekunder i
>> Javascript.
>
> Kig efter Date objektet.

Yak, Stig, det gav ret hurtigt dette, som bare skal tilpasses lidt AJAX:
http://stackoverflow.com/questions/1360818/javascript-how-to-measure-the-milliseconds-between-mousedown-and-mouseup

Jeg har også fundet ud af, at Google leverer en ret nøjagtig oversigt
over ressourcerne via Chrome Udviklingsværktøjer, og her kan man meget
nøjagtigt følge hvor hvad bliver loaded, og hvor meget det fylder i
størrelse og tid.

Imidlertid er der åbenbart ret stor svingning iflh. Chrome (ca. 0.3
sekund på en helt HTML-side) fra den ene load til den næste med den
samme optimeringsform, så er det svært at afgøre, om der er en fordel
ved de optimeringsmetoder, jeg afprøver.

AJAX-rutinen vil jeg bruge sådan at brugeren selv kan teste
optimeringen, men jeg vil lige vente lidt med at lave den, indtil jeg
har noget bedre testmateriale, og har lavet lidt forbedringer på
sammenføjningsfunktionen også.


MVH
Rune Jensen

---

Rune Jensen formulerede spørgsmålet:
> Den 26-04-2010 01:56, Stig Johansen skrev:
>> Rune Jensen wrote:
>>
>>> Jeg vil gerne have lavet nogle tests af hastighed af min side, hvor jeg
>>> er ved at afprøve forskellige former for optimering, og eftersom ASP
>>> ikke kan tage milisekunder,
>>
>> Det menr jeg nu godt den(ASP) kan, eller noget der ligner.
>>
>>> Spørgsmålet går i første omgang på, om man kan tælle i milisekunder i
>>> Javascript.
>>
>> Kig efter Date objektet.
>
> Yak, Stig, det gav ret hurtigt dette, som bare skal tilpasses lidt AJAX:
> http://stackoverflow.com/questions/1360818/javascript-how-to-measure-the-milliseconds-between-mousedown-and-mouseup
>
> Jeg har også fundet ud af, at Google leverer en ret nøjagtig oversigt over
> ressourcerne via Chrome Udviklingsværktøjer, og her kan man meget nøjagtigt
> følge hvor hvad bliver loaded, og hvor meget det fylder i størrelse og tid.
>
> Imidlertid er der åbenbart ret stor svingning iflh. Chrome (ca. 0.3 sekund på
> en helt HTML-side) fra den ene load til den næste med den samme
> optimeringsform, så er det svært at afgøre, om der er en fordel ved de
> optimeringsmetoder, jeg afprøver.
>
> AJAX-rutinen vil jeg bruge sådan at brugeren selv kan teste optimeringen, men
> jeg vil lige vente lidt med at lave den, indtil jeg har noget bedre
> testmateriale, og har lavet lidt forbedringer på sammenføjningsfunktionen
> også.
>
>
> MVH
> Rune Jensen

Du måler over netværket, hvor der vil være mange andre faktorer der
påvirker resultatet, end dem du prøver at måle.
Firebug har en udvidet NET sektion, eller der er Yslow, der kan bruges
til evaluering - om de kan give dig de data du søger, ved jeg ikke, men
det er da et forsøg værd.

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

Den 26-04-2010 08:40, Birger Sørensen skrev:
> Rune Jensen formulerede spørgsmålet:

<SNIP>
>> AJAX-rutinen vil jeg bruge sådan at brugeren selv kan teste
>> optimeringen, men jeg vil lige vente lidt med at lave den, indtil jeg
>> har noget bedre testmateriale, og har lavet lidt forbedringer på
>> sammenføjningsfunktionen også.

> Du måler over netværket, hvor der vil være mange andre faktorer der
> påvirker resultatet, end dem du prøver at måle.
> Firebug har en udvidet NET sektion, eller der er Yslow, der kan bruges
> til evaluering - om de kan give dig de data du søger, ved jeg ikke, men
> det er da et forsøg værd.

Hej, Birger, og tak for svar.

Mit problem er nok 2-delt (eller tre-delt)

1. Firebug har haft problemer med at fungere sammen med Web Developer,
SVJV - har den stadig det?

2. Jeg vil sådan set gerne have begge data, både de "kunstige", som er
direkte udenom netværket, samt de andre, som man kan kalde "IRL", over
nettet.

Nu sidder jeg lige og overvejer også, hvordan jeg skal begrænse
projektet. Jeg synes, det er interessant, men det lader til, hver gang,
jeg går ét skridt videre, dukker der to nye spørgsmål op ;)

Men jeg er helt sikker på, man er nødt til at kunne dokumentere med mere
end filstørrelse, som jeg overvejede i første omgang - havde det så bare
været det.


MVH
Rune Jensen

---

Rune Jensen wrote:

> Den 26-04-2010 08:40, Birger Sørensen skrev:
>> Rune Jensen formulerede spørgsmålet:
>
> <SNIP>
>>> AJAX-rutinen vil jeg bruge sådan at brugeren selv kan teste
>>> optimeringen, men jeg vil lige vente lidt med at lave den, indtil jeg
>>> har noget bedre testmateriale, og har lavet lidt forbedringer på
>>> sammenføjningsfunktionen også.
>
>> Du måler over netværket, hvor der vil være mange andre faktorer der
>> påvirker resultatet, end dem du prøver at måle.
>> Firebug har en udvidet NET sektion, eller der er Yslow, der kan bruges
>> til evaluering - om de kan give dig de data du søger, ved jeg ikke, men
>> det er da et forsøg værd.
>
> Hej, Birger, og tak for svar.
>
> Mit problem er nok 2-delt (eller tre-delt)
>
> 1. Firebug har haft problemer med at fungere sammen med Web Developer,
> SVJV - har den stadig det?
>
> 2. Jeg vil sådan set gerne have begge data, både de "kunstige", som er
> direkte udenom netværket, samt de andre, som man kan kalde "IRL", over
> nettet.
>
> Nu sidder jeg lige og overvejer også, hvordan jeg skal begrænse
> projektet. Jeg synes, det er interessant, men det lader til, hver gang,
> jeg går ét skridt videre, dukker der to nye spørgsmål op ;)
>
> Men jeg er helt sikker på, man er nødt til at kunne dokumentere med mere
> end filstørrelse, som jeg overvejede i første omgang - havde det så bare
> været det.

Til begge.

Jo - performance er flerdelt, og ikke kun et spørgsmål om
filstørrelser/transmissionstid.

For at måle performance kræves mere end 'millisekund' resolution, og i Runes
eksempler giver nr. 1:
.......
Start probe @ ms: 965543949.237771
Start connect @ ms: 965543949.755565 - deviation = 0.517794013023376
End connect @ ms: 965543998.255166 - deviation = 48.4996010065079
Last byte sent @ ms: 965543998.647666 - deviation = 0.392499923706055
First byte received @ ms: 965544064.536335 - deviation = 65.8886690139771
Probe end @ ms: 965544178.305375 - deviation = 113.769039988518
Probe total ms: 229.067603945732
Probe received bytes = 25577 @ 200 - OK
........
Og nr. 2 giver:
........
Start probe @ ms: 965797100.171384
Start connect @ ms: 965797100.705521 - deviation = 0.534137010574341
End connect @ ms: 965797147.56721 - deviation = 46.8616889715195
Last byte sent @ ms: 965797148.002195 - deviation = 0.434985041618347
First byte received @ ms: 965797177.683868 - deviation = 29.6816730499268
Probe end @ ms: 965797288.283032 - deviation = 110.599163889885
Probe total ms: 188.111647963524
Probe received bytes = 26141 @ 200 - OK
.......
Men ASP (og andre scriptsprog) cacher tingene, så nr. 1 giver nu:
.......
Start probe @ ms: 965907413.918447
Start connect @ ms: 965907414.44079 - deviation = 0.522343039512634
End connect @ ms: 965907461.268476 - deviation = 46.8276859521866
Last byte sent @ ms: 965907461.706773 - deviation = 0.438297033309937
First byte received @ ms: 965907492.852592 - deviation = 31.1458189487457
Probe end @ ms: 965907601.861468 - deviation = 109.008875966072
Probe total ms: 187.943020939827
Probe received bytes = 25577 @ 200 - OK
.......

(Undrer mig lidt at 'minify' versionen returnerer flere bytes, men who
knows..)

--
Med venlig hilsen
Stig Johansen

---

Den 26-04-2010 11:00, Stig Johansen skrev:
> Rune Jensen wrote:

<SNIP: Målinger>
> Men ASP (og andre scriptsprog) cacher tingene, så nr. 1 giver nu:
> ......
> Start probe @ ms: 965907413.918447
> Start connect @ ms: 965907414.44079 - deviation = 0.522343039512634
> End connect @ ms: 965907461.268476 - deviation = 46.8276859521866
> Last byte sent @ ms: 965907461.706773 - deviation = 0.438297033309937
> First byte received @ ms: 965907492.852592 - deviation = 31.1458189487457
> Probe end @ ms: 965907601.861468 - deviation = 109.008875966072
> Probe total ms: 187.943020939827
> Probe received bytes = 25577 @ 200 - OK

Hvordan har du testet det?

Er det noget, jeg også kan finde ud af?

> (Undrer mig lidt at 'minify' versionen returnerer flere bytes, men who
> knows..)

Det er fordi, at det virker, når man kalder den direkte, men hvis jeg
vil bruge den i et HTML-doument, så kommer CSSen ikke med. Ikke helt i
hvert fald. Så jeg har fjernet minify-funktionen i join.asp for at se,
om det var der den var gal, men det var det ikke. Så nu sidder jeg og
river mig lidt i håret over det ;)

PS: Den sender sikkert flere bytes, fordi minifien også sender en header
med, tror du ikke? Når den ikke minifier, er den ikke en fordel uden man
tænker på overhead også - tror jeg i hvert fald.


MVH
Rune Jensen

---

Rune Jensen wrote:

> Den 26-04-2010 11:00, Stig Johansen skrev:
>> Rune Jensen wrote:
>
> <SNIP: Målinger>
>> Men ASP (og andre scriptsprog) cacher tingene, så nr. 1 giver nu:
>> ......
>> Start probe @ ms: 965907413.918447
>> Start connect @ ms: 965907414.44079 - deviation = 0.522343039512634
>> End connect @ ms: 965907461.268476 - deviation = 46.8276859521866
>> Last byte sent @ ms: 965907461.706773 - deviation = 0.438297033309937
>> First byte received @ ms: 965907492.852592 - deviation = 31.1458189487457
>> Probe end @ ms: 965907601.861468 - deviation = 109.008875966072
>> Probe total ms: 187.943020939827
>> Probe received bytes = 25577 @ 200 - OK
>
> Hvordan har du testet det?

Ved at kalde de URL'er du angav i din oprindelige post.

> Er det noget, jeg også kan finde ud af?

Det er et godt spørgsmål.
Hvis du tænker javascript, så nej - det kræver adgang til lower-level API'er
og en high resolution timer for at gå ned i mikro/nanosekunder.

>
>> (Undrer mig lidt at 'minify' versionen returnerer flere bytes, men who
>> knows..)
>
> Det er fordi, at det virker, når man kalder den direkte, men hvis jeg
> vil bruge den i et HTML-doument, så kommer CSSen ikke med. Ikke helt i
> hvert fald. Så jeg har fjernet minify-funktionen i join.asp for at se,
> om det var der den var gal, men det var det ikke. Så nu sidder jeg og
> river mig lidt i håret over det ;)

Jeg har ikke kigget nærmere, da dette probing tool udelukkende handler om
serverens svartid, så jeg husker ikke hvor jeg har sat grænsen for received
bytes.

> PS: Den sender sikkert flere bytes, fordi minifien også sender en header
> med, tror du ikke? Når den ikke minifier, er den ikke en fordel uden man
> tænker på overhead også - tror jeg i hvert fald.

Received bytes i det her tilfælde er udelukkende indhold, og ikke hraders.

--
Med venlig hilsen
Stig Johansen

---

Den 26-04-2010 11:44, Stig Johansen skrev:
> Rune Jensen wrote:
>
>> Den 26-04-2010 11:00, Stig Johansen skrev:
>>> Rune Jensen wrote:
>>
>> <SNIP: Målinger>
>>> Men ASP (og andre scriptsprog) cacher tingene, så nr. 1 giver nu:
>>> ......
>>> Start probe @ ms: 965907413.918447
>>> Start connect @ ms: 965907414.44079 - deviation = 0.522343039512634
>>> End connect @ ms: 965907461.268476 - deviation = 46.8276859521866
>>> Last byte sent @ ms: 965907461.706773 - deviation = 0.438297033309937
>>> First byte received @ ms: 965907492.852592 - deviation = 31.1458189487457
>>> Probe end @ ms: 965907601.861468 - deviation = 109.008875966072
>>> Probe total ms: 187.943020939827
>>> Probe received bytes = 25577 @ 200 - OK
>>
>> Hvordan har du testet det?
>
> Ved at kalde de URL'er du angav i din oprindelige post.

OK

>> Er det noget, jeg også kan finde ud af?
>
> Det er et godt spørgsmål.
> Hvis du tænker javascript, så nej - det kræver adgang til lower-level API'er
> og en high resolution timer for at gå ned i mikro/nanosekunder.

Fair nok.

>>> (Undrer mig lidt at 'minify' versionen returnerer flere bytes, men who
>>> knows..)
>>
>> Det er fordi, at det virker, når man kalder den direkte, men hvis jeg
>> vil bruge den i et HTML-doument, så kommer CSSen ikke med. Ikke helt i
>> hvert fald. Så jeg har fjernet minify-funktionen i join.asp for at se,
>> om det var der den var gal, men det var det ikke. Så nu sidder jeg og
>> river mig lidt i håret over det ;)
>
> Jeg har ikke kigget nærmere, da dette probing tool udelukkende handler om
> serverens svartid, så jeg husker ikke hvor jeg har sat grænsen for received
> bytes.

Det er måske noget med content type, men skidtet virker ikke, lige meget
hva hulen jeg gør. Så nu gider jeg ikke mere lige nu.

>> PS: Den sender sikkert flere bytes, fordi minifien også sender en header
>> med, tror du ikke? Når den ikke minifier, er den ikke en fordel uden man
>> tænker på overhead også - tror jeg i hvert fald.
>
> Received bytes i det her tilfælde er udelukkende indhold, og ikke hraders.

Hmm. Måske det, som er problemet med "no-style". Synes nu ikke, jeg
plugger noget ekstra på. Jeg har fjernet hvad der var af replace.

Det må blive senere.

Iøvrigt er det jo så ASP, så nok bedre at smutte i den gruppe, hvis det
er. Men ikke nu.


MVH
Rune Jensen

---

Rune Jensen kom med følgende:
> Den 26-04-2010 08:40, Birger Sørensen skrev:
>> Rune Jensen formulerede spørgsmålet:
>
> <SNIP>
>>> AJAX-rutinen vil jeg bruge sådan at brugeren selv kan teste
>>> optimeringen, men jeg vil lige vente lidt med at lave den, indtil jeg
>>> har noget bedre testmateriale, og har lavet lidt forbedringer på
>>> sammenføjningsfunktionen også.
>
>> Du måler over netværket, hvor der vil være mange andre faktorer der
>> påvirker resultatet, end dem du prøver at måle.
>> Firebug har en udvidet NET sektion, eller der er Yslow, der kan bruges
>> til evaluering - om de kan give dig de data du søger, ved jeg ikke, men
>> det er da et forsøg værd.
>
> Hej, Birger, og tak for svar.
>
> Mit problem er nok 2-delt (eller tre-delt)
>
> 1. Firebug har haft problemer med at fungere sammen med Web Developer, SVJV -
> har den stadig det?
>
> 2. Jeg vil sådan set gerne have begge data, både de "kunstige", som er
> direkte udenom netværket, samt de andre, som man kan kalde "IRL", over
> nettet.
>
> Nu sidder jeg lige og overvejer også, hvordan jeg skal begrænse projektet.
> Jeg synes, det er interessant, men det lader til, hver gang, jeg går ét
> skridt videre, dukker der to nye spørgsmål op ;)
>
> Men jeg er helt sikker på, man er nødt til at kunne dokumentere med mere end
> filstørrelse, som jeg overvejede i første omgang - havde det så bare været
> det.
>
>
> MVH
> Rune Jensen

Hej Rune

1. Der bliver jeg dig svar skyldig. Jeg brugte WebDeveloper en kort
overgang, da Firebug havde problemer med opdatering af FF(3.5). De er
blevet fixet, og jeg har ikke WebDeveloper længere (Mener i øvrigt det
var FireBug og Validatoren, der havde problemer med at spille sammen).

2. Net delen af Firebug er blevet udvidet beytdeligt, så man kan se
hvor stor del af loadtiden der bruges til hvad - se evt. eksempel
http://bbsorensen.com/test/load/ps_load.jpg - hvor de tider du egentlig
er interesseret i er de grå, mens grønne og lilla er ventetider.
Eksemplet viser måske lige så meget, hvor vigtigt det er at have en
host med en god forbindelse - langt det meste her er ventetider, og
hverken optimering af CSS eller js, kan gøre dem kortere...
Og selvfølgelig er det interessant, at vide hvor meget man kan "tjene"
ved en optimering/komprimering - men set i den store sammenhæng, er det
måske lidt at spilde krudtet, hvor det gør mindst nytte ^^

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

Den 26-04-2010 11:12, Birger Sørensen skrev:
> Rune Jensen kom med følgende:
>> Den 26-04-2010 08:40, Birger Sørensen skrev:
>>> Rune Jensen formulerede spørgsmålet:
>>
>> <SNIP>
>>>> AJAX-rutinen vil jeg bruge sådan at brugeren selv kan teste
>>>> optimeringen, men jeg vil lige vente lidt med at lave den, indtil jeg
>>>> har noget bedre testmateriale, og har lavet lidt forbedringer på
>>>> sammenføjningsfunktionen også.
>>
>>> Du måler over netværket, hvor der vil være mange andre faktorer der
>>> påvirker resultatet, end dem du prøver at måle.
>>> Firebug har en udvidet NET sektion, eller der er Yslow, der kan bruges
>>> til evaluering - om de kan give dig de data du søger, ved jeg ikke, men
>>> det er da et forsøg værd.
>>
>> Hej, Birger, og tak for svar.
>>
>> Mit problem er nok 2-delt (eller tre-delt)
>>
>> 1. Firebug har haft problemer med at fungere sammen med Web Developer,
>> SVJV - har den stadig det?
>>
>> 2. Jeg vil sådan set gerne have begge data, både de "kunstige", som er
>> direkte udenom netværket, samt de andre, som man kan kalde "IRL", over
>> nettet.
>>
>> Nu sidder jeg lige og overvejer også, hvordan jeg skal begrænse
>> projektet. Jeg synes, det er interessant, men det lader til, hver
>> gang, jeg går ét skridt videre, dukker der to nye spørgsmål op ;)
>>
>> Men jeg er helt sikker på, man er nødt til at kunne dokumentere med
>> mere end filstørrelse, som jeg overvejede i første omgang - havde det
>> så bare været det.
>>
>>
>> MVH
>> Rune Jensen
>
> Hej Rune
>
> 1. Der bliver jeg dig svar skyldig. Jeg brugte WebDeveloper en kort
> overgang, da Firebug havde problemer med opdatering af FF(3.5). De er
> blevet fixet, og jeg har ikke WebDeveloper længere (Mener i øvrigt det
> var FireBug og Validatoren, der havde problemer med at spille sammen).

OK, jeg kigger på det, men mest, så var det nu, hvilke forskelle der er.
Der er nogle gode funktioner, i Web Developer, jeg gerne ville beholde ;)

<SNIP>
> Og selvfølgelig er det interessant, at vide hvor meget man kan "tjene"
> ved en optimering/komprimering - men set i den store sammenhæng, er det
> måske lidt at spilde krudtet, hvor det gør mindst nytte ^^

Det er netop for at teste, om det kan betale sig. Og i givet fald hvornår.

Hvis det ikke kan betale sig, eller kun kan betale sig på større sites
(hvorunder mine ikke hører, nok), så har jeg også den viden.

Jeg har to hostere, jeg kan sammenligne med, hvis det er, men jeg aner
ikke, endnu, om det er besværet værd, så det venter jeg også med.

Men alt andet lige, når jeg kigger på Chromes ressourceskema, så kunne
jeg spare nogle minisekunder på at sætte baggrundsbilleder fra menuen i
CSS-sprites, hvilket jeg vil forsøge, når det her er afviklet.

Tak for svar, Birger.


MVH
Rune Jensen