Citat:
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.