Subject: New web page is slow

From: Dominik Vogt <[email-masked]>
Date: Mon, 28 Apr 2003 10:40:54 +0200

Any ideas why the new web page takes 30 seconds on my ISDN line to
load?

Bye

Dominik ^_^  ^_^
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Uwe Pross <[email-masked]>
Date: Tue, 29 Apr 2003 13:16:17 +0200

Hi there,

On 28 Apr 2003 at 10:40:54 +0200, Dominik Vogt wrote:

> Any ideas why the new web page takes 30 seconds on my ISDN
> line to load?

All files together loaded when requesting
www.fvwm.org/index.php are 122880 Bytes in size. So on an
ISDN line it should take about

122880 Bytes / 64 Kbit/s * 8 = 15 sec

Regarding that the background picture which should be the
latest file to load is 50860 Bytes in size. The loading time
should be about

72020 Bytes / 64 Kbit/s * 8 = 8.8 sec

before the background picuture will be requested.

But the web page was described in a way that the information
should be displayed before loading all images. I have got an
analog modem at home which runs at about 40 Kbit/s and I
think it does not take that long. I will check that tonight.

What browser do you use? Does the plain layout load much
faster than the default layout? How about using ISDN in dual
channel mode at 128 Kbit/s? Does this half the loading time?

Regards, Uwe
-- 
  ,_,  Uwe Pross
 (O,O) mailto:[email-masked]
 (   ) http://www.tu-chemnitz.de/~uwp
=-"-"-================================
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 29 Apr 2003 13:51:02 +0200

On Tue, Apr 29, 2003 at 01:16:17PM +0200, Uwe Pross wrote:
> www.fvwm.org/index.php are 122880 Bytes in size.

Ah so that's the reason.  120kB seems to be huge.  What is using
so much space?  The background image plus the logo take up 57kB,
so there are still about 69kB left to explain.  Is it because of
the (uncompressed?) gifs?  Is there any alternative to gifs?  How
about reducing the size of the background image?  At 2/3 of the
original size at quality 0.65 it shrinks to 17274 bytes
(attached).

> So on an ISDN line it should take about
> 
> What browser do you use?

Mozilla 1.0.something.

> Does the plain layout load much faster than the default layout?

Yes, at least ten times faster.

> How about using ISDN in dual channel mode at 128 Kbit/s?
> Does this half the loading time?

The contract with my provider does not allow it.

Bye

Dominik ^_^  ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 29 Apr 2003 14:15:18 +0200

On Tue, Apr 29, 2003 at 01:51:02PM +0200, fvwm-workers wrote:
> so much space?

I was able to reduce the size of navgen.cli and navgen.php by 25%
by removing all comments (especially the comment markers waste a
lot of bandwidth) and by indenting with one tab instead of two
spaces.  Using shorter variable names should save another couple
of kBs...  Yes, down from 16518 to 9860 bytes in navgen.php with
one to four letter variable names.

Bye

Dominik ^_^  ^_^

---

From: Uwe Pross <[email-masked]>
Date: Tue, 29 Apr 2003 14:22:16 +0200

Hi there,

On 29 Apr 2003 at 13:51:02 +0200, Dominik Vogt wrote:

> Ah so that's the reason.  120kB seems to be huge.  What is
> using so much space?  The background image plus the logo
> take up 57kB, so there are still about 69kB left to
> explain.  Is it because of the (uncompressed?) gifs?  Is
> there any alternative to gifs?

The following list gives the files on index.php and its size:

  1336 alternate.css
   369 authors_pager.gif
   369 contact_mailing_list_pager.gif
  1400 default.css
   955 default_pager.gif
   369 doc_developers_pager.gif
   369 doc_faq_pager.gif
   369 doc_manpages_pager.gif
   543 documentation_pager.gif
   439 download_icons_pager.gif
   955 download_pager.gif
   699 features_pager.gif
  7309 fvwm-logo-steelblue.gif
   369 fvwm_cats_pager.gif
 50860 gray.jpg
   955 home_pager.gif
 25642 index.php
  4543 index_plain.php
   227 item_dot_blue.gif
   955 links_pager.gif
   543 news_pager.gif
    67 pager_empty.gif
   439 screenshots_decor_pager.gif
   439 screenshots_desks_pager.gif
   162 screenshots_menu_pager.gif
   369 screenshots_pager.gif
    71 transparent.gif
    71 transparent_002.gif

You see the gifs are quite small. The default index.php is
about 25 kB which is caused by the table/cell definitions
for the window decoration.

You can also see that the file index_plain.php is 5 times
smaller than the default layout index.php.

> How about reducing the size of the background image?  At
> 2/3 of the original size at quality 0.65 it shrinks to
> 17274 bytes (attached).

I have changed the bg image to grey color and  quality  0.35
which reduced the image size to 18660 bytes. 

> Mozilla 1.0.something.

Mozilla should use your internet connection quite efficiently.

> Yes, at least ten times faster.

That was one reason why I made the plain layout (or theme
from now :).  Browsing through the man pages or the faq is
much more efficient using the plain theme.

Maybe we need to adapt the default theme a bit and reduce
its size. But I think we need to exchange the pager
navigation with a simpler menu navigation. When I got the
new modular theme concept ready - hopefully tonight or
tommorow - I am going to make (a) new theme(s). Maybe we use a
simpler one for default.

Regards, Uwe

---

From: Uwe Pross <[email-masked]>
Date: Tue, 29 Apr 2003 14:38:42 +0200

Hi there,

> one to four letter variable names.

Comments are not bad :-)

navgen.cli is only a helper script which is started by the
user only when something has changed on the navigation
structure. It generates a php array description which
contains the file relations on the web site.
navgen.php is obsolete. I have removed this from cvs by now.

All *.php and *.inc files are executed at the server
site. This means comments and long variable names will not
be transmitted to the user and does therefore not effect
loading times. Only the echo and print commands in these
files produce traffic to the user (but navgen.cli never).

If you want to reduce the traffic you need to look in the
php output not in the sources. But I don't think that there
is much which can be removed in there.

BTW: I prefer spaces instead of tabs since they have
the same size indepent from editor settings. What do you use
for the fvwm souce files?

Regards, Uwe

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 29 Apr 2003 15:36:33 +0200

> for the fvwm souce files?

Tabs (= 8 spaces).  Linux kernel coding style.

Bye

Dominik ^_^  ^_^

---

From: Bob Woodside <[email-masked]>
Date: Tue, 29 Apr 2003 10:45:38 -0400

On Tue, 29 Apr 2003 13:16:17 +0200

> before the background picuture will be requested.

	It's clearly the graphics that cause it. On my cable connection the
load time runs between 8 & 12 seconds. For comparison, loading time in
Lynx is sub-second; so there's no textual material that's slowing it
down (which you addressed elsewhere in this thread).

	I just tried several more test loads - it looks like your smaller image
change has propagated to the Web site - I'm now getting load times
consistently in the range of about 5 - 7 seconds.

Cheers,
Bob

---

From: Uwe Pross <[email-masked]>
Date: Tue, 29 Apr 2003 17:11:31 +0200

Hi there,

On 29 Apr 2003 at 10:45:38 -0400, Bob Woodside wrote:

> It's clearly the graphics that cause it. 

It's is mix of the size of the graphics and the number of
files to load. The window decoration requires quite a lot of
small files. Each of them needs a own http request which has
a response time. These times needs also to take in account.

> On my cable connection the load time runs between 8 & 12
> seconds. For comparison, loading time in Lynx is
> sub-second; so there's no textual material that's slowing
> it down (which you addressed elsewhere in this thread).

> I just tried several more test loads - it looks like your
> smaller image change has propagated to the Web site - I'm
> now getting load times consistently in the range of about
> 5 - 7 seconds.

How fast is your cable connection?

BTW: The total size I have given was not correct. I have
  forgotten the window decoration pictures. They come to
  another 25 kByte.  Since they are loaded due style sheet
  definition they should be loaded at last after the
  background pic has been loaded.

Regards, Uwe

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 29 Apr 2003 18:09:47 +0200

On Tue, Apr 29, 2003 at 05:11:31PM +0200, Uwe Pross wrote:
>   another 25 kByte.

Wow, 25kB?  Why are they so big?

At work (fastest possible connection, I work for an internet
provider), 75% of the time (2 to 2.5 seconds) is used to load and
display the icons in the pager.  Is there a big penalty for
loading 20 small files?

>   Since they are loaded due style sheet

By the way, it might be good to load the outline of the pager
earlier so that the layout does not suddenly change later.

Bye

Dominik ^_^  ^_^

---

From: Dan Espen <[email-masked]>
Date: Tue, 29 Apr 2003 12:52:51 -0400

> Wow, 25kB?  Why are they so big?

Using tcpdump, it doesn't look like it sends the pictures.
It looks like the client requests the image but supplies a timestamp
for the last image that it has, and the server responds that the image
hasn't changed.  The message from the client is 568 bytes
and the response is 96.

I see it getting about 23 images.

I think most of these are the images in the pager.

-- 
Dan Espen                           E-mail: [email-masked]

---

From: Uwe Pross <[email-masked]>
Date: Wed, 30 Apr 2003 09:29:45 +0200

Hi there,

> Wow, 25kB?  Why are they so big?

25k was what "du -sk" showed me. If there are many small
files in the directories "du -sk" reports quite more space
than the files are together needed.

Each of them is not that big:

 55 bottom.gif
 58 bottom_left.gif
 57 bottom_right.gif
108 button_1.gif
108 button_2.gif
 89 button_3.gif
110 button_4.gif
 73 button_5.gif
 88 button_6.gif
 76 deco_definitions.inc
 57 left.gif
 51 middle.gif
 57 right.gif
 73 title.gif
 55 top.gif
 57 top_left.gif
 58 top_right.gif
 71 transparent.gif

> display the icons in the pager.  Is there a big penalty for

What do you mean by penalty in this context?

The pager is implemented as a set of html-tables.  The many
pictures need some time to load and some time is needed to
render the table. I guess with your internet connection
download times can be neglected. Say you have got 10Mbit/s
connection (I guess you have much more) 200 kbyte take less
than 0.2 s to load (neglecting the times needed for request,
request delay, processing and response delay). Most time
will be needed for rendering the site. You may check this by
loading the site from a locally installed web server.

> By the way, it might be good to load the outline of the
> pager earlier so that the layout does not suddenly change
> later.

I don't get that. What does suddenly change on your layout?

Regards, Uwe

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 30 Apr 2003 14:29:16 +0200

> What do you mean by penalty in this context?

Performance penalty.  Slowing down the load time.

> loading the site from a locally installed web server.

I can hardly believe that rendering 20 tiny images takes more than
1.5 seconds.  Okay, mozilla is slow, but not *this* slow(?)

> I don't get that. What does suddenly change on your layout?

The page is initially displayed with the "window" using all the
available page width.  When the pager frame is loaded, the window
shrinks to make room for the pager.  I don't see it with mozilla
1.2.1 here (fast connection), but with 1.0 on my ISDN line.

Bye

Dominik ^_^  ^_^

---

From: Uwe Pross <[email-masked]>
Date: Wed, 30 Apr 2003 16:26:54 +0200

Hi there,

On 30 Apr 2003 at 14:29:16 +0200, Dominik Vogt wrote:

> > > At work (fastest possible connection, I work for an
> > > internet provider), 75% of the time (2 to 2.5 seconds)
> > > is used to load and display the icons in the pager.
> > > Is there a big penalty for loading 20 small files?
> > 

Maybe I am a bit slow today but I don't see any coherence
between a couple of small image files and a performance
penalty (if there is such a thing).

> I can hardly believe that rendering 20 tiny images takes
> more than 1.5 seconds.  Okay, mozilla is slow, but not
> *this* slow(?)

Have you checked the render times by using a local version
of the web page? You may save the web page with mozilla and
load it again afterwards.

> 1.2.1 here (fast connection), but with 1.0 on my ISDN line.

I think this can be hardly avoided with gecko. Netscape4.x
starts render the table if it got all image and text
information this avoids the layout change you described but
displays nothing until all contents have been loaded. Gecko
starts rendering even it has not all information. 

Regards, Uwe

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 30 Apr 2003 17:21:52 +0200

> penalty (if there is such a thing).

One big file = small overhead = little performance penatly
Many small files = big overhead = ??? performance penalty

> load it again afterwards.

I'd have to learn how to set up apache first. :-(

> displays nothing until all contents have been loaded.

> Gecko starts rendering even it has not all information. 

Yeah.  I would think choosing a clever order of the components
lessens that problem.  Maybe an invisible placeholder for the
pager first?

Bye

Dominik ^_^  ^_^

---

From: Bob Woodside <[email-masked]>
Date: Wed, 30 Apr 2003 12:44:20 -0400

On Wed, 30 Apr 2003 16:26:54 +0200

> starts rendering even it has not all information. 

	I think we have to play the same trick we did with the pager icons, and
explicitly speciy the width of the pager border table at the top of
insert_pager_navigation(). Then the browser will know how much
horizontal space to reserve for the pager.

	This may take a little trial and error to get the width just right.
I'll commit a change in a little bit, and we can see how it looks.

	It can't be perfect, because we'll always be somewhat at the mercy of
the user's fonts. The width only specifies a minimum width. If the
browser needs more room to fit all the elements in, it'll expand it. So,
if one of the desk titles requires more space than we allowed, the table
will expand (but not as much).

	So, Dominik, after I commit the change, see if you notice any
improvement.

Cheers,
Bob

---

From: [email-masked]
Date: Wed, 30 Apr 2003 09:59:05 +0200

> I think most of these are the images in the pager.

I think it's not the size of the images that slows down loading.
It seems that the images are requested sequentially.

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Bob Woodside <[email-masked]>
Date: Wed, 30 Apr 2003 17:36:11 -0400

On Wed, 30 Apr 2003 17:21:52 +0200

> lessens that problem.  Maybe an invisible placeholder for the

	Dominik, did the change I committed earlier today alleviate the problem
of the pager frame resizing?

Cheers,
Bob