[pelmered]

Ursprungligen postat av Jim_Westergren

Jag skulle vilja tipsa om gtmetrix.com som jag själv använder för att visa kunder. Den kör både YSlow och Page Speed online. Den får 10.44 sek för tv.nu: http://gtmetrix.com/reports/www.tv.nu/777DmT4h

Tack!
Riktigt bra sida!

[tartareandesire]

På en sida som folk besöker regelbundet är det ju inte lika viktigt med extremt snabba laddningstider heller. Då är det extremt få som får de tiderna.

[studiox]

Ursprungligen postat av ITisGood.se

Tack!
Riktigt bra sida!

Håller med. Den där borde Internet World använt.

[Dennis Holm]

allt runt 1-3 sekunder är riktigt bra flyt. 5-10 så börjar det bli störande.
Inte så stora marginaler.
Men vill man att besökarna ska må bra och stanna länge på siten så ska man INTE reta dem med att slå i 10 sekunders gränsen och däröver ofta är väldigt förödande för många siter.

[linusoleander]

Ursprungligen postat av mervinst

allt runt 1-3 sekunder är riktigt bra flyt. 5-10 så börjar det bli störande.
Inte så stora marginaler.
Men vill man att besökarna ska må bra och stanna länge på siten så ska man INTE reta dem med att slå i 10 sekunders gränsen och däröver ofta är väldigt förödande för många siter.

3 sekunder, är det verkligen rimligt?
Jag har alltid hört att man aldrig ska ligga över 500ms, eftersom det är där i krokarna som användaren upplever siten som seg.

Körde precis apache benchmark mot ett projekt som jag nyligen optimerade. Fick ner laddningstiderna (lokalt) till ~60 ms. Och nej, sidan är inte en statisk HTML-fil.

Anledningen till att laddningstiderna är så låga är bl.a för att all HTML-kod cachas, inget läses från databasen plus att alla css- och js-filer är komprimerade m.h.a googles kompressor och där efter lagds i en fil.
I min värd så görs nästan allt ovanstående automatiskt, så jag slipper te.x komprimera js- och css-filerna manuellt och flytta koden till en fil.

Här är de olika resultaten, det bästa och det som används i nästa version är varianten längst ner. Längst upp visas laddningstiderna för siten utan någon cache.

Förutsättningar
Servern körs i production mode.
Cachen är inladdad vid initiering, alltså vid start av servern.
Memcached används för att lagra AR-objekten.

Rails 3.0.3 under OS X, Mongrel.

Ingen cache med partials
ab -n 200  http://127.0.0.1/
min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:  1315 1464  94.9   1432    2268
Waiting:     1313 1460  94.2   1430    2265
Total:       1315 1464  94.9   1432    2268
Medel: 1464 ms

Memcached utan partials, ingen fragment-cache
ab -n 1000  http://127.0.0.1/
min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:   398  548  35.6    535     823
Waiting:      397  547  35.2    534     822
Total:        398  548  35.6    535     823
Medel: 548 ms

Memcached med partials, ingen fragment-cache
ab -n 200  http://127.0.0.1/
min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:   518  542  26.9    532     648
Waiting:      518  542  26.5    531     645
Total:        519  542  26.9    532     648
Medel: 542 ms

Med partials, fragment-cache och memcached
ab -n 200  http://127.0.0.1/
min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:    30   71  49.0     37     185
Waiting:       29   69  48.8     34     181
Total:         30   71  49.0     37     185
Medel: 71 ms

Memcached med fragment-cache utan partials
ab -n 100  http://127.0.0.1/
min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:    28   62  46.1     31     182
Waiting:       23   61  46.2     30     179
Total:         28   62  46.1     31     182
Medel: 62 ms

EDIT: Kom precis på att ab inte testar inläsningen av js- och css-filer och andra webbläsarspecifika detaljer. Där av så spelade min optimeringen av dessa filer ingen roll i siffrorna som visades över.

[Dennis Holm]

det var mest att ca 3 sekunder är gränsen där man känner att det flyter okej.
Många siter laddar ju snabbt efter man besökt en sida så alla bilder osv är cachade.
Sedan går det ju oftast på nolltid.

[Clarence]

Ursprungligen postat av linusoleander

3 sekunder, är det verkligen rimligt?
Jag har alltid hört att man aldrig ska ligga över 500ms, eftersom det är där i krokarna som användaren upplever siten som seg.

Körde precis apache benchmark mot ett projekt som jag nyligen optimerade. Fick ner laddningstiderna (lokalt) till ~60 ms. Och nej, sidan är inte en statisk HTML-fil.

Anledningen till att laddningstiderna är så låga är bl.a för att all HTML-kod cachas, inget läses från databasen plus att alla css- och js-filer är komprimerade m.h.a googles kompressor och där efter lagds i en fil.
I min värd så görs nästan allt ovanstående automatiskt, så jag slipper te.x komprimera js- och css-filerna manuellt och flytta koden till en fil.

Här är de olika resultaten, det bästa och det som används i nästa version är varianten längst ner. Längst upp visas laddningstiderna för siten utan någon cache.

EDIT: Kom precis på att ab inte testar inläsningen av js- och css-filer och andra webbläsarspecifika detaljer. Där av så spelade min optimeringen av dessa filer ingen roll i siffrorna som visades över.

I de allra flesta fall står serverns bearbetningstid av huvudsidan för en extremt liten del (inte ovanligt att det är endast ett fåtal procent) av hela tiden som det tar att ladda in sidan. Därmed svarar också din undersökning för en extremt liten del av den för besökaren relevanta tiden. Missförstå mig inte, ab är smidigt och enkelt för att se hur ens lösningar eller server hanterar sekventiell och parallell belastning mot en enstaka sida. Men där slutar också nyttan.

Det enklast sättet att titta på laddningstider för ens besökare skulle jag påstå är att i firefox installera firebug (främst net tabben, viktigast är dock content load eventen på huvuddokumentet) och yslow (allt.) och använda från en normal internetuppkoppling. Kan också vara värt att installera web developer toolbar eller annat verktyg där man enkelt kan stänga av cachen.