You are here: Foswiki>Tasks Web>Item9588 (30 Sep 2010, MichaelDaum)Edit Attach

Item9588: Rename body zone to script, {OptimizePageLayout} becomes {MergeHeadAndScriptZones}

pencil
Priority: Normal
Current State: Closed
Released In: 1.1.0
Target Release: minor
Applies To: Engine
Component: Zones, ZonePlugin
Branches:
Reported By: PaulHarvey, MichaelDaum
Waiting For:
Last Change By: MichaelDaum
On IRC it seems that MichaelDaum and others have come to a similar conclusion that moving script to the body might be more trouble than it is worth.

The proposal is:
  • Delete {OptimizePageLayout} functionality
  • Rename all current usage of body zone to script
  • Delete (or make configurable?) head + bodyscript "merge" functionality This means old plugins will be broken if they add <script> to head with dependencies

Question:
  • Should there be a dedicated css zone? - Set WaitingFor Michael to answer this

I hope that by 4/5 September we have these changes stabilised.

Why didn't this feature deliver the promise of snappier page loads?

Let's start with a worst-case Foswiki:
  • Everything in head
  • JS is loaded in between .css; <script> tags are inter-mixed with <link>
  • JS does expensive things immediately when the scripts are executed, blocking browser from rendering on each script until they complete
  • Slow PC on a crappy browser, so JS load/run times are significant.

Now, if you move the script to </body>, yes, the page is much faster! But this has its own problems - "jumping twisties" are only the beginning. Here's a much easier solution that doesn't have the pitfalls of moving script to <body>:
  • Everything in head this will always be slower than a carefully crafted page that has JS in the =<body>=
  • JS loaded at the end of <head>, after all .css
  • JS uses jQuery(document).ready() to defer execution until the page is ready

This approach will consume less developer time with only slight disadvantage to having <script> in the body

-- PaulHarvey - 30 Aug 2010

I think it's worth making the "merge" functionality configurable, there are probably lots of plugins not in svn which will break without that feature. Maybe a {MergeHeadAndScriptZones} option that is disabled by default?

-- PaulHarvey - 30 Aug 2010

Most of this is done; holding off on the commit until non-core plugins and ZonePlugin is cleaned up, hopefully within 24 hrs.

-- PaulHarvey - 02 Sep 2010

Tasks waiting on this (Please document current twisty defects as a result of my changes on Item9515). Tasks waiting on Item9588:

Item9515, Item9576, Item9625

-- PaulHarvey - 05 Sep 2010

Mostly done. Still to-do:

Downgrading to normal

Michael, I added you because many of the plugins are yours. Do you have any additional thoughts to the above plan? I can prepare the extensions that aren't yours, for a new release if you like? Which of us will be uploading the new releases of all these extensions?

-- PaulHarvey - 06 Sep 2010

distro:b074600e9b8e broke ZonePlugin quite heavily: the tag handlers don't take a topicObject. They take a topic and web. ... Fixed in Item9763 by reverting most of the recent checkin.

-- MichaelDaum - 29 Sep 2010

I'm sorry about that, I would have caught that if I got time to fix the tests. I'm not sure why you reverted the whole checkin if only the registerTag call was wrong; I guess this means zones behave differently trunk vs ZonePlugin now.

Anyway, set to closed, this doesn't need to be in 1.1.0 release notes (zone enhancement work was done in another task).

-- PaulHarvey - 30 Sep 2010

I tried fixing the tag handler only. But this change required a subsequent fix of all further methods being called using a topicObject as an argument further down. Fixing that too didn't help either as all of the plugin got stuck into an infinite loop for some reason. So I pulled the emergency stop and reverted to a version that I understand and that works. The only difference to foswiki/trunk is merging zones.

-- MichaelDaum - 30 Sep 2010
 
Topic revision: r18 - 30 Sep 2010, MichaelDaum - This page was cached on 26 Sep 2016 - 14:28.

The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License