[Pro] Flashing whole browser page on first load

Thanks for looking into this Walter.

Here’s what I see;
Currently if you profile the scripts on this page (http://artdesign.timplumb.com/nickrobertson6.html) using Safari’s web inspector with script debugging switched on you’ll see that the page waits for these libraries to load before showing any page content;
Dropbox - Error - Simplify your life

Here’s the paused script;

If I then move the scripts to the foot of the body so they are the last to load on the page, like this;

I can see that the browser at least has loaded the html and I can see everything other than the images;

The script is still paused (as you can see in the next screen grab) at this point and the images are yet to load but because the html for the page has loaded (included the CSS in the head) we avoid the totally white page while the scripts load. Although this happens almost instantly (certainly here on my broadband connection) I can see how a slower connection would cause the page to flicker as the user moves from page to page.

Walter are you aware of a way to defer these libraries until the page has loaded that would also preserve the required running order so any scripts that require them don’t blow up?

Nick, can you tell me if you see any flickering on the page I manually adjusted?
http://artdesign.timplumb.com/nickrobertson6.html
I think you’ll have to resign yourself to the fact that there will be a slight jump between pages but maybe we can shuffle the code about to minimise any jarring effects.
Thanks,
Tim.


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

Tim, Clicking on your link I get a top to bottom loading of the background image but it is very fast, but no flashing white ‘whole browser’ page that I can see. This is a definite improvement, however is this a Freeway issue thatI I will encounter when I make updates to various pages in this site? Nick


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

Not the way the page is constructed. I mean, you could try moving all of the scripts to the bottom of the page, but that’s still not going to fix the inline scripts spattered throughout the page code. Each rollover in the page calls out to a function it expects to be ready to go. Because those scripts are inline (so-called DOM zero), they resist any form of deferring of execution.

The modern way to write this sort of interaction is like this:

  1. Decorate the elements you wish to observe or alter with a classname or data-attribute.
  2. Set up an unobtrusive listener function (and it doesn’t matter if this is the top or bottom of the page, honestly) that is triggered by whatever action you wish to observe.

For rollovers, you could do something like this:

<p><img src="foo.jpg" data-rollover="bar.jpg" width="200" height="100" alt="foo" /></p>
(repeat a bunch of times, with different data)

Then in the head, you would wrap the following in document.observe(‘dom:loaded’), and in the foot, you wouldn’t need to.

$$('img[data-rollover]').invoke('observe','load',function(evt){
	var elm = this;
	if( ! elm._original ) elm['_original'] = elm.src;
	if( ! elm._over ) elm['_over'] = readAttribute('data-rollover');;
	new Element('img', {src: elm._over}); //preload
});
// now a single pair of observers watch all such images on the page
document.on('mouseover', 'img[data-rollover]', function(evt, elm){
	elm.src = elm._over;
});
document.on('mouseout', 'img[data-rollover]', function(evt, elm){
	elm.src = elm._original;
});

That’s a lot less script, and it’s quite a lot fewer JavaScript functions to register. Because you register one listener for all mouseovers and another for all mouseouts, you can also do clever things like memoize the entire collection of rollover images and reset them all in one whack.

Walter

On Nov 8, 2013, at 9:26 AM, Tim Plumb wrote:

Walter are you aware of a way to defer these libraries until the page has loaded that would also preserve the required running order so any scripts that require them don’t blow up?


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

For another example, here is ImageGuardian recast as a Prototype unobtrusive listener. One function for each action, not (each action * each image):

document.on('copy', '.ig', function(evt, elm){
  evt.stop();
  return false;
});
document.on('contextmenu', '.ig', function(evt, elm){
  evt.stop();
  return false;
});
document.on('dragstart', '.ig', function(evt, elm){
  evt.stop();
  return false;
});
document.on('mouseover', '.ig', function(evt, elm){
  window.status=elm.title;
});
document.on('mouseout', '.ig', function(evt, elm){
  window.status='';
});

Walter

On Nov 8, 2013, at 10:04 AM, Walter Lee Davis wrote:

That’s a lot less script, and it’s quite a lot fewer JavaScript functions to register.


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

Thanks for that Walter. I don’t think I’ll be moving Image Guardian over to using any particular library at the moment as what it does is both lightweight and quite easily achieved in vanilla JS.

Can you think of a solution that will get Nick back on track with his site and ease the loading delay (other than refactoring the whole page)?
Thanks,
Tim.

On 8 Nov 2013, at 15:23, Walter Lee Davis wrote:

For another example, here is ImageGuardian recast as a Prototype unobtrusive listener.


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

He could try using a different slideshow effect, maybe ScriptyFader (since it’s unobtrusive and removes the extra images from the page for even better initial load profile) in place of the Fading Slideshow effect. Other than that, I don’t know.

My reason for showing the IG refactor was to point out that initializing a bunch of inline observers (as the Rollover does, as IG does) takes measurably longer than setting up relatively few deferred observer functions on the page itself. There’s no requirement to use Prototype or jQuery to do this, it just means re-thinking the way you gather your objects and check the events. Here’s one without the library:

document.addEventListener('dragstart', function(evt){
	if(evt.target.className && evt.target.className.match(/\big\b/)){
		evt.preventDefault();
		return false;
	}
});

Most events like this bubble up to the document, so setting a single observer there can stand in for many discrete observers further down the DOM.

I’ve had a couple of cracks at refactoring the Rollover and other core effects over the years, maybe it’s time for me to really put my back into it and write something that’s more than a proof of concept in Protaculous.

Walter

On Nov 8, 2013, at 11:14 AM, Tim Plumb wrote:

Thanks for that Walter. I don’t think I’ll be moving Image Guardian over to using any particular library at the moment as what it does is both lightweight and quite easily achieved in vanilla JS.

Can you think of a solution that will get Nick back on track with his site and ease the loading delay (other than refactoring the whole page)?
Thanks,
Tim.

On 8 Nov 2013, at 15:23, Walter Lee Davis wrote:

For another example, here is ImageGuardian recast as a Prototype unobtrusive listener.


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

Thanks everyone for the interest in this but I have relunctantly taken out the elegant ‘fade’ transition in the slideshows to make the loading acceptable to lower speeds such as mine (4.1mbps). Hopefully the the problem will be addressed by Freeway in the future.


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options