current 'industry-standards' for page load?

4 Nov 2004 - 2:49pm
9 years ago
3 replies
1403 reads
Anastasia Fischer
2004

Help! I need to come up with some metric for page load performance (web
application)...

I realize that this topic is integrally tied up with efficiency of task
performance from the user perspective, none the less this does not free me
from the obligation (requested by my business team) to provide some sort of
metric on the subject. I have read through alot web sites, but find only
rough highly conditional measurements.

Can anyone direct me to resources, or have ideas on how to address this?

Thanks,

Anastasia

-----------------
Anastasia Fischer
Customer Experience
Tel: 207.596.5549

Comments

4 Nov 2004 - 3:45pm
Listera
2004

Anastasia Fischer:

> Help! I need to come up with some metric for page load performance (web
> application)...

Not sure what you mean. How long you are willing to wait for a page to
download depends on many factors, the size of the page being only one. If
the payback is great you'll easily wait longer. Generally speaking, users
can detect a 1/10 second wait as (undesired) latency. There are also many
ways to attenuate the perception of latency via design. So there's no simple
answer to this question.

If you want a bogus 'industry-standard' you'll need to take one of Nielsen's
seminars.:-)

Ziya
Nullius in Verba

4 Nov 2004 - 3:47pm
Dave Malouf
2005

> Help! I need to come up with some metric for page load performance (web
> application)...

if you mean how long to load a page, then at my last job we had a
performance expectation for our web application of no more than 3 seconds
from click to being able to use the next screen.

i then got that 'extended' by adding "loading" progress bars which make
the "wait" seem "shorter". Even then we had to be between 5 & 10 seconds.

-- dave

4 Nov 2004 - 5:28pm
subimage interactive
2004

I'm dealing with a similar situation while working on a TV-Ratings web
application that is replacing a win32 app.

This app makes use of LARGE html table pages (report data). The
company founders have made it a rule that response times must be very
close between the two applications, which has caused problems in the
implementation of the report into HTML.

A major stress point has been render time in IE vs Mozilla.
Mozilla/ffox just smokes IE rendering large tables & javascript
interpretation on this particular application. For instance, one 80
column report I was profiling took 8 seconds to load in Firefox from
request to full page render, while IE took upwards of 21 seconds
(before you saw anything on the screen).

This of course was unacceptable...There are a number of things you can
do to "speed up" the browser, including perception hacks like loading
indicators (animations, etc), along with profiling your display/render
code and doing things in a more intelligent way.

The first thing I did was place a loading screen that appears on the
form submission of their pull page that says "Now pulling report", and
added a "Now rendering report" indicator on the report page when it
loads.

This was still too slow, as it appeared that the page was still
"taking a long time" to pull a report - perception of speed is very
important when trying to sell an application to someone, especially in
this case. Therefore, we worked on the layout of the report page and
came up with a great idea which involves chunking the report into
multiple sections and loading them via IFRAMES.

Now we have "something" (the report headers and title) on screen
within 1/2 a second in all browsers, while the report data continues
to load in the invisible area offscreen. This is a wonderful way to
improve the perception of speed, and reduce load on your server (we're
not loading the rest of the report unless they use our control to jump
columns).

I realize this is kind of going off on a tangent, but I saw the
discussion leaning in this direction. Working with a variety of
clients on a variety of web applications I've come to find that
perception of speed is just as - if not more important than total page
load time.

Of course, this is just the front-end tweaks that I've been in charge
of. There are many other things you can do to speed up load times,
including optimizing your DB pulls, caching, gzipping content, etc.

My $.02

--
seth @ subimage interactive
http://www.subimage.com/

Syndicate content Get the feed