404344 - Public Pages Load Too Slowly

Status: RESOLVED FIXED

(addons.mozilla.org Graveyard :: Public Pages, defect)

Description

[David E. Ross]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.9) Gecko/20071030 SeaMonkey/1.1.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.9) Gecko/20071030 SeaMonkey/1.1.6

An example is Mnenhy.  Compare its home page at <https://addons.mozilla.org/en-US/firefox/addon/2516> versus its home page at <http://mnenhy.mozdev.org/>.  The former takes more than twice as long to display as the latter.  

Part of the problem is bloat.  Although both pages have approximately the same number of bytes of textual content, the Add-Ons page requires downloading more than four times as many bytes as the Mozdev page.  

The entire addons.mozilla.org site is SSL-secure (HTTPS).  I'm not sure how much this contributes to the problem.  However, navigating back and forth is affected by this since secure pages are often not cached.  Perhaps only download pages should be secure.  

Note the Mnenhy is only an example.  ALL pages at addons.mozilla.org are slow to load.  

Reproducible: Always




Yes, I'm using a dial-up modem, which makes this a significant problem.  However, according to reports from the U.S. Federal Communications Commission and other agencies and organizations, more than 40% of Internet users in the U.S. still connect through dial-up modems.  

According to the thread "No mention/link to mozdev.org" in the <news://news.mozilla.org:119/mozilla.support.seamonkey> newsgroup, Mozilla Add-Ons should be users' first choice for obtaining extensions.  Because it's too slow, many users instead consider Mozdev to be their first choice.

Comment 1

[Fred Wenzel [:wenzel]]

In general responsiveness, I do not see a big difference between AMO and any other similar website.

What you may try to do though if you are on a pretty slow connection is disabling images and/or Javascript. I do not think we have an overkill of images on the AMO website, but not loading them at all will certainly reduce load times on slow connections.

HTTPS does add overhead, too, this is true. However, since malicious add-ons can do significant harm, this is a means to reduce the possibilities for attackers. Switching to HTTP is therefore not an option, sorry.

I hope this helps explaining the situation.

Comment 2

[David E. Ross]

On addons.mozilla.org, the Mnenhy home page has about 43 KB of HTML and scripts and and 160 KB of images.  

On Mozdev, the Mnenhy home page has about 20 KB of HTML, no scripts, and 29 KB of images.  

Thus, addons.mozilla.org has about twice the HTML (with scripts) that Mozdev has (without scripts) and more than five times the size of images than Mozdev to deliver essentially the same content.  I do indeed suggest that this is bloat.  

By the way, disabling scripts does not remove them from the HTML file and from the number of bytes I must download to view a page (unless they are external scripts).  It merely stops them from executing.  For more than 40% of Internet users in the U.S., bandwidth is the limiting factor in how quickly Web pages display, not processor time (which is used by scripts).  

Comment 3

[David E. Ross]

I recently received an E-mail message asking if this was still a problem.  It seems that the Addons site has been both rehosted and revised.  I've lost the message, so I'm replying here.  

I just now timed the loading of the two Mnenhy home pages cited in the original description of this bug.  The Addons page took 45 seconds.  The Mozdev page took 12 seconds.  Both of these were through a dial-up modem.  

No, the two pages are not identical.  But that might be part of the problem.  See my comments about "bloat" in both the original description and comment #2.  

Comment 4

[Brian Krausz]

David: can you please test again, we have made a number of performance improvements that should significantly speed up page load (see bug 424187).  I'm interested in load time with an empty cache (hold shift+click refresh in most OSs/browsers) as well as with a primed cache (navigate away from the page and back to it).

I believe we have done nearly all that is possible (as per bug 424187) to improve load times without degrading the experience on faster connections.  If you have any other suggestions please let us know.

Thanks!

Comment 5

[David E. Ross]

Attachment: Page-load timing test report

I ran the test as requested in comment #4, again using the home pages for Mnenhy as indicated in the original description.  

At addons.mozilla.org, the page loads with a cleared cache in 70 sec and from a cache in 16 sec.  

At mnenhy.mozdev.org, the page loads with a cleared cache in 13 sec and from a cache in 6 sec.  Thus, the uncached mozdev page loads more quickly than the cached addons page.  

A test report with method, configuration, and results is attached as a PDF document.

Comment 6

[Wil Clouser [:clouserw]]

Here are even slower results from the way-handy webpagetest.org:

http://pagetest.patrickmeenan.com:8080/result/6GN/

Comment 7

[Brian Krausz]

Thanks David and Wil, nice stats.

I suppose the question is what loadtime are we ok with (which will determine if/when we can close this bug).  Can anyone comment on what is a fair compromise between speed and images?  A large problem is that we have a lot of preview images and addon icons, which we can't remove or sprite.

For comparison's sake, here are some other sites:

Yahoo: http://pagetest.patrickmeenan.com:8080/result/6K6/
Note: Yahoo has a datacenter in Virginia, which I'm sure helps a bit

Mozilla.com: http://pagetest.patrickmeenan.com:8080/result/6K7/

From the Optimization Report it seems that we're not gziping all of our content...anyone know why this may be? Netscaler issue?

We could also set expires headers on images for at least a few hours, perhaps a day.  Is there significant benefit to doing this over leaving out expires headers? (mentioning this in bug 449123)

Comment 8

[David E. Ross]

I'm not a professional expert in Web usability, so what follows is personal opinion.  

As I noted in my original description, at least 40% of the Internet connections in the U.S. still rely on dial-up modems receiving not more than 56 Kbps.  I think a user should not wait longer than 45 sec to receive a Web page.  To receive a completed Web page in that time, the total size should not exceed 315 KB, including the HTML/XHTML markup, graphics, external CSS, external scripts, etc.  If your server cannot deliver 56 Kbps under a moderate load (more than one user attempting to access a Web page), the total size should be less.  (b=bit, B=byte)

The fact that an uncached Mnenhy page from mozdev.org loads in less time than a cached Mnenhy page from addons.mozilla.org clearly indicates that the two pages should be analyzed to determine what is efficient in the former but not in the latter.  This analysis should then be expanded to cover the entire Addons site to make it more efficient.  

One efficiency is reducing the number of distinct entities that must be received from a Web server.  Each entity requires a message from the browser to the server and one or more packets back from the server to the browser.  In comment #7, the assertion is made: ". . . we have a lot of preview images and addon icons . . . ".  Gratuitous images and icons should be avoided.  Navigational images should be replaced with appropriate use of CSS.  Images that are retained should be reduced in file-size, even if they are not reduced in display-size.  

Another example of the problem is the Addons home page at <https://addons.mozilla.org/en-US/firefox/>.  After clearing my cache, it took 241 sec to load, one second more than 4 min!  The page has six distinct backgrounds and 21 distinct images.  (By "distinct", I mean they each have their own file, not that they appear to be different.)  Some of these images (e.g., <https://addons.mozilla.org/en-US/firefox/images/addon_icon/1865>) do not appear on the page today, although they might appear some other time; standardized Web page templates should include only those graphics that are always used.  Some images differ only in size (e.g., <https://addons.mozilla.org/en-US/firefox/images/addon_icon/5276> and <https://addons.mozilla.org/en-US/firefox/images/addon_preview/5276/1>); two images are not really required if proper size attributes or CSS properties are used to scale the display of the larger image.  

**Off-Topic Gripe**
At the bottom of the Addons home page is an input area for a form without any description of what is to be input.  Selecting the button with the triangle at the right of the input area caused my hard drive to speed up for several seconds during which SeaMonkey was locked and without any apparent result when it was unlocked.  When I view the page with CSS disabled, I see that this is a selector for language.  With CSS enabled, however, the portion that shows the "Other languages:" label and the "Go" button are off the opposite edges of the window even when I scroll horizontally as far as possible.  I realize this is quite a different problem from timing, but it does bring into question how thoroughly the Addons pages were tested by actually viewing them.  In any case, the need to use a horizontal scrollbar is quite annoying.  

Comment 9

[Brian Krausz]

(In reply to comment #8)
> As I noted in my original description, at least 40% of the Internet connections
> in the U.S. still rely on dial-up modems receiving not more than 56 Kbps.  I
> think a user should not wait longer than 45 sec to receive a Web page.  To
> receive a completed Web page in that time, the total size should not exceed 315
> KB, including the HTML/XHTML markup, graphics, external CSS, external scripts,
> etc.  If your server cannot deliver 56 Kbps under a moderate load (more than
> one user attempting to access a Web page), the total size should be less. 

The issue is not our servers, but the pipe itself.  I think 45 seconds is a fair goal to aim for, though I'm curious to get data on more popular sites besides us and Yahoo for comparison's sake.  For example, after you login to Facebook you'd be hard pressed to find a page that's less than 600KB, with many clocking in at over 1MB

> The fact that an uncached Mnenhy page from mozdev.org loads in less time than a
> cached Mnenhy page from addons.mozilla.org clearly indicates that the two pages
> should be analyzed to determine what is efficient in the former but not in the
> latter.  This analysis should then be expanded to cover the entire Addons site
> to make it more efficient.  

It's pretty easy to determine that: they have a relatively sparsely populated page.  There are very few images, the layout is a few CSS boxes, etc.  We have rounded corners, relatively dense content, JS functionality, etc.  Changing that would require actually changing out layout and functionality of the site, and would result in a degraded user experience for broadband users, which is not a very good option.

> One efficiency is reducing the number of distinct entities that must be
> received from a Web server.  Each entity requires a message from the browser to
> the server and one or more packets back from the server to the browser.  In
> comment #7, the assertion is made: ". . . we have a lot of preview images and
> addon icons . . . ".  Gratuitous images and icons should be avoided. 
> Navigational images should be replaced with appropriate use of CSS.  Images
> that are retained should be reduced in file-size, even if they are not reduced
> in display-size.

We are fully aware of this, as per the discussions in bugs 424187, 422815,  439702, and 449123.  We already compress, cache, sprite, combine, and minimize content.  We have explored most, if not all, options open to us for delivering a full-features, aesthetically pleasing, fast website.

> Another example of the problem is the Addons home page at
> <https://addons.mozilla.org/en-US/firefox/>.  After clearing my cache, it took
> 241 sec to load, one second more than 4 min!  The page has six distinct
> backgrounds and 21 distinct images.  (By "distinct", I mean they each have
> their own file, not that they appear to be different.)  Some of these images
> (e.g., <https://addons.mozilla.org/en-US/firefox/images/addon_icon/1865>) do
> not appear on the page today, although they might appear some other time;
> standardized Web page templates should include only those graphics that are
> always used.  Some images differ only in size (e.g.,
> <https://addons.mozilla.org/en-US/firefox/images/addon_icon/5276> and
> <https://addons.mozilla.org/en-US/firefox/images/addon_preview/5276/1>); two
> images are not really required if proper size attributes or CSS properties are
> used to scale the display of the larger image.

We use JS to show 5 addons in the middle "recommended addons" box.  If you use the navigation buttons you will see these addons switched out without reloading the page.  All images that are located in /images/ are uploaded by the addon developers, we have no control over the image and as such cannot combine them.

> **Off-Topic Gripe**
> At the bottom of the Addons home page is an input area for a form without any
> description of what is to be input.  Selecting the button with the triangle at
> the right of the input area caused my hard drive to speed up for several
> seconds during which SeaMonkey was locked and without any apparent result when
> it was unlocked.  When I view the page with CSS disabled, I see that this is a
> selector for language.  With CSS enabled, however, the portion that shows the
> "Other languages:" label and the "Go" button are off the opposite edges of the
> window even when I scroll horizontally as far as possible.  I realize this is
> quite a different problem from timing, but it does bring into question how
> thoroughly the Addons pages were tested by actually viewing them.  In any case,
> the need to use a horizontal scrollbar is quite annoying.  

If you have an issue with the display of the page, I suggest you file a bug ( https://bugzilla.mozilla.org/enter_bug.cgi?product=addons.mozilla.org ).  I'm sure you know the large number of OS's, browsers, and configuration possibilities, and the number of permutations.  Our site is tested by a very qualified Software QA Engineer in all major browsers on multiple OS's with and without JS enabled.  If you are having an issue, it is either because you are using an older browser, you have some non-standard configuration, or you found something we have overlooked (which is quite possible, considering the number of permutations that must be checked).  Either way I recommend you file a bug, preferably with a screen shot of the issue, and we will fix it.

Comment 10

[David E. Ross]

The emphasis on "user experience" makes me think the primary purpose of the Addons site is to entertain users, possibly to attract them to ads that generate revenues for the site.  I know this is not really the purpose, but it indicates that the real purpose -- to distribute extensions for Mozilla products -- has been forgotten.  

What kind of user experience exists for the 40%+ of the U.S. users who still use dial-up modems?  What is the user experience when it takes longer to load the page for an extension than it takes to download that same extension?  Even users with DSL should notice how long it takes to complete the viewing of the Addons home page.  

There is also the implication that the Addons site is somehow superior to the Mozdev site.  As a user, I don't see this.  

Comment 11

[Brian Krausz]

(In reply to comment #10)
> The emphasis on "user experience" makes me think the primary purpose of the
> Addons site is to entertain users, possibly to attract them to ads that
> generate revenues for the site.  I know this is not really the purpose, but it
> indicates that the real purpose -- to distribute extensions for Mozilla
> products -- has been forgotten.  

The goal of AMO is to make it as easy as possible for users to find and install addons.  Providing an easy-to-use and appealing interface fits well within that goal.

> What kind of user experience exists for the 40%+ of the U.S. users who still
> use dial-up modems?  What is the user experience when it takes longer to load
> the page for an extension than it takes to download that same extension?  Even
> users with DSL should notice how long it takes to complete the viewing of the
> Addons home page.  

1) I'd like you to clarify your 40% number and cite a source please.  In America, only 10% of people are still on dial-up ( http://www.cnn.com/2008/TECH/ptech/07/02/broadband.study.ap/index.html ).  While I don't have statistics on our site's dial-up usage, I'd guess that it's less than 10% considering the unfortunate correlation between technical savvy and add-on installation.
2) Load time on DSL is around 7 seconds

> There is also the implication that the Addons site is somehow superior to the
> Mozdev site.  As a user, I don't see this.  

I never said this nor did I intend to imply it.  Mozdev serves a different purpose than AMO.  Mozdev is a project host, and therefore caters to a more technical audience that doesn't demand, or even want, a graphic-heavy page.  We try to cater to a more general audience which, in today's Web 2.0 graphic-heavy environment, feel more comfortable browsing "pretty" pages.

Comment 12

[Fred Wenzel [:wenzel]]

(In reply to comment #11)
> > There is also the implication that the Addons site is somehow superior to the
> > Mozdev site.  As a user, I don't see this.  
> 
> I never said this nor did I intend to imply it.  Mozdev serves a different
> purpose than AMO.  Mozdev is a project host, and therefore caters to a more
> technical audience that doesn't demand, or even want, a graphic-heavy page.  We
> try to cater to a more general audience which, in today's Web 2.0 graphic-heavy
> environment, feel more comfortable browsing "pretty" pages.
> 

Brian's right. Please don't make the false assumption that Mozdev and AMO are exchangeable or serve the same purpose. In spite of the unfortunate correlation between tech-savvy and add-on installation Brian mentioned, not all people on Mozilla Add-ons are "power-users", nor do we only cater that crowd. I am convinced that you could even easily find the add-ons you need if we just gave you an FTP file listing of all add-ons to look at. But that's not a user experience you can serve to millions of users.

Comment 13

[David E. Ross]

The 40% figure came from testimony by the Communications Workers of America (CWA) at a Federal Communications Commission hearing on 15 June 2007.  On rereading the testimony (see footnote 18 in <http://files.cwa-union.org/national/communicationspolicy/comments/fcc07-38_comments_cwa.pdf>), I found that the CWA got their figure from a 2006 report by the Pew Internet & American Life Project.  

A more recent report (last month) by the Pew Internet & American Life Project indicates the figure is now 18% of Internet users still rely on dial-up modems at home.  See <http://www.pewinternet.org/pdfs/PIP_Broadband_2008.pdf>.  

The Pew Internet & American Life Project is conducted by the Pew Research Center and funded by the Pew Charitable Trusts.  The project's surveys were done by Princeton Survey Research Associates.  

No, 18% is not 40%.  However, the argument for Web sites complying with W3C specifications and for considering the guidelines of the Viewable With Any Browser Campaign has been that, while Internet Explorer (IE) might be the market's dominant browser, IE is not the only browser.  That argument was made back in 2003, when Gecko-based browsers held less than 8% of the market.  The similar argument, that broadband is not the only Internet connection in use, is even more valid since dial-up currently has about twice the market that Gecko had in 2003.  

Comment 14

[Brian Krausz]

David: This bug was discussed in our AMO meeting today.  We will keep the long load time in mind, leaving this bug open as a reminder and opening up other bugs as we identify ways to speed up page load times.

CCing morgamic so he can catch up and keep this in mind.  Also reassigning to Ryan for continued consideration.

Comment 15

[Wil Clouser [:clouserw]]

Please file specific bugs for specific concerns.  AMO has improved page loads in some areas and probably not others so it's important bugs are specific.