Open Bug 370681 Opened 19 years ago Updated 3 years ago

display webpage text as soon as possible (for extremely slow connections)

Categories

(Core :: General, enhancement)

x86
Windows XP
enhancement

Tracking

()

UNCONFIRMED

People

(Reporter: kenta, Unassigned)

References

()

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1 I would like my webpages to display faster, not stalling waiting for additional "parts" of the page to finish transferring. Perhaps it can be made into a user-configurable option. Reproducible: Always Steps to Reproduce: This problem is made more obvious for me when using Tor, but can probably can be reproduced over any slow internet connection. 1. Turn on Tor. 2. Go to http://slashdot.org 3. First a connection is made to slashdot.org presumably fetching index.html 4. Then, I stare a white screen for many seconds while many connections are to images.slashdot.org, presumably fetching things like javascript, CSS, and images. 5. Finally, the page displays. 6. Other images slowly load after the initial page paint. Actual Results: It takes longer than seemingly necessary to see the page for the first time. Expected Results: The key idea is the IMPORTANT content on slashdot is the TEXT. Everything else just makes the page prettier. The behavior I want is: 1. fetch index.html 2. display it. (Yes, it will be ugly black text on white background, but that's OK, the text is what I wanted to see anyway) 3. fetch the other stuff: images, javascript, CSS, iframes, etc. 4. reflow the page as necessary I have tried creating an Integer config option nglayout.initialpaint.delay and set it to 0, but this had no effect. I have not changed any of the following options from their default values: network.http.pipelining, network.http.pipelining.maxrequests, network.http.proxy.pipelining, network.http.max-persistent-connections-per-proxy.
Firefox already does a good job of incremental layout and rendering while waiting for images and iframes. So that leaves external CSS and JavaScript. For external CSS, see bug 84582. Once that is fixed, I imagine a followup bug will make it so if Firefox has to wait more than 5 seconds for external CSS, it will display the page unstyled while continuing to wait for the CSS, with "5 seconds" being a hidden pref. Firefox can't do the same for external JavaScript files because of document.write (unless the page uses the defer attribute -- bug 28293). You might consider disabling JavaScript.
Product: Firefox → Core
QA Contact: general → general
Summary: display webpage text as soon as possible → display webpage text as soon as possible (for extremely slow connections)
Version: unspecified → Trunk
Blocks: 1301893
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.