Home Messages Index
[Date Prev][Date Next][Thread Prev][Thread Next]
Author IndexDate IndexThread Index

Re: Stop trying to load slow images?

  • Subject: Re: Stop trying to load slow images?
  • From: Roy Schestowitz <newsgroups@xxxxxxxxxxxxxxx>
  • Date: Fri, 28 Apr 2006 15:23:10 +0100
  • Newsgroups: uk.net.web.authoring
  • Organization: schestowitz.com / MCC / Manchester University
  • References: <gb84g.8410$tT.597@news01.roc.ny> <Kw84g.210$AD2.38@newsfe4-win.ntli.net> <cC84g.8415$tT.285@news01.roc.ny> <r57252p1gk63il4vdim5jiarr1i11ao5er@news.markshouse.net>
  • Reply-to: newsgroups@xxxxxxxxxxxxxxx
  • User-agent: KNode/0.7.2
__/ [ Doug Kanter ] on Thursday 27 April 2006 19:37 \__

> Be patient - I'm asking this question before ever having designed a web
> page. Perhaps I'm asking about doing brain surgery before knowing how to
> put on a Band-Aid.
> 
> Let's say you've got a web page that includes pictures from a server other
> than the one where most of your content resides. You're not always sure the
> outside source will always be available. Is there a way to code your web
> page to wait a certain period of time for outside content to load, and just
> give up, to avoid giving the user an error message from their browser?


I don't believe it is something you could achieve and have honoured by all
Web browsers. You could do all sorts of strange things like render the page
as an image (e.g. khtml2png) and deliver it as an image if no errors arise,
yet that's a big no-no. The browser is work-hungry. It will make
simultaneous requests (pipelining) to different sites with the aim or
rendering the page from its constituent parts as quickly as possible.


__/ [ Mark Goodge ] on Thursday 27 April 2006 20:44 \__

> On Thu, 27 Apr 2006 19:05:44 GMT, Doug Kanter put finger to keyboard
> and typed:
> 
>>"Gazza" <news@xxxxxxxxxxxxxxxxxxxxxxx> wrote in message
>>news:Kw84g.210$AD2.38@xxxxxxxxxxxxxxxxxxxxxxx
>>>
>>>
>>> Doug Kanter mumbled the following on 27/04/2006 19:37:
>>>
>>>> Or, is there a way to code the page so it first loads the content you
>>>> have some control over, saving the external stuff for last? At least
>>>> that way, the user can begin reading the page while waiting for external
>>>> content which may not be crucial to the page's usefulness.


You can prefetch images, but it is not quite the same thing. I believe that
JavaScript is a must for this. Maybe you can add some conditional statement
to raise an error popup (msgbox) if one image or another cannot be fetched.


>>> When putting the html together and including an <img> element (to,
>>> suprisingly display images), you should specify the width and height.
>>> This, in most browsers, creates a placeholder-type effect, so even if the
>>> image doesn't load (and shows the broken image/red 'x' sign), the text
>>> won't be jumping about as the user is trying to read it.


Good point.


>>OK - this raises another question, then. Sometimes, I go to web pages where
>>it seems that the external data (like an advertisement, for instance) is
>>taking forever to load, and nothing else appears on the page until that
>>external data loads. So, the page is useless during that delay. Is there a
>>way to determine the order in which elements load?
> 
> A browser will start by loading the HTML source, sequentially as
> presented by the server, and then render it as and when it has enough
> to be able to do so. At any point in the rendering, if it encounters a
> link for another resource (such as an image or object) it will open a
> new request to the server and attempt to fetch it simultaneously with
> whatever else it's getting. (There's a limit on the number of
> simultaneous requests, which is usually configurable somewhere in the
> browser settings).
> 
> A browser doesn't have to wait for an image to fully load before it
> can render the HTML, so the mere fact of an image being slow shouldn't
> slow down the text. But it can't render some elements until they are
> complete - the most common of these being that it can't render a table
> until it's got the </table> tag, as until then the layout isn't
> confirmed. That's one reason why table-based layouts often seem to be
> slower than CSS-based layouts, as CSS will visually render section by
> section while a table will do nothing for a while and then suddenly
> appear in its entirety.


One workaround I can think of is 'channelling' the user through some
benevolent doorway page (even the site's front page). That page should
contain some elements that you want fetched earlier on. When the user
advances to the next, potentially heavyweight page, some items will have
already resided in cache and will thus be pulled and rendered almost
immediately. The order in which elements are rendered, however, depends on
the structure of the page, as Mark already pointed out. The same /may/ apply
to requests for files, but I cannot be sure. A look at HTTP headers or log
can give insight into the order in which files are requested.

Best wishes,

Roy

-- 
Roy S. Schestowitz      |    Have you hugged your penguin today?
http://Schestowitz.com  |    SuSE Linux    ¦     PGP-Key: 0x74572E8E
  3:10pm  up  22:15,  14 users,  load average: 0.17, 0.60, 0.61
      http://iuron.com - next generation of search paradigms

[Date Prev][Date Next][Thread Prev][Thread Next]
Author IndexDate IndexThread Index