New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move all js to footer (Trac #2718) #2718

Closed
elgg-gitbot opened this Issue Feb 16, 2013 · 11 comments

Comments

Projects
None yet
3 participants
@elgg-gitbot

elgg-gitbot commented Feb 16, 2013

Original ticket http://trac.elgg.org/ticket/2718 on 40938946-03-15 by ewinslow, assigned to unknown.

Elgg version: 1.7

It makes a huge difference in page render time (hundreds of milliseconds) to move scripts from the head to the footer of the page. We should really try to do this if at all possible.

At the very least, they definitely need to come after the CSS.

@elgg-gitbot

This comment has been minimized.

Show comment
Hide comment
@elgg-gitbot

elgg-gitbot Feb 16, 2013

trac user hellekin wrote on 40940413-01-15

As most Javascript uses the DOM and will only start when it's fully loaded (JQuery), it makes a lot of sense to defer it to the last moment, i.e., just before . The rendering engine can then start displaying the document before the script is downloaded, as the <script> tags don't use any space. In the real world, counting network latency, it can definitely give the user a better feeling. Some script are especially long to bootstrap (e.g., Google Analytics) and can really slow down the rendering if coming too early.

I recommend YSlow, the Yahoo! extension to Firebug to testdrive page's speed and find ways to optimize it.

elgg-gitbot commented Feb 16, 2013

trac user hellekin wrote on 40940413-01-15

As most Javascript uses the DOM and will only start when it's fully loaded (JQuery), it makes a lot of sense to defer it to the last moment, i.e., just before . The rendering engine can then start displaying the document before the script is downloaded, as the <script> tags don't use any space. In the real world, counting network latency, it can definitely give the user a better feeling. Some script are especially long to bootstrap (e.g., Google Analytics) and can really slow down the rendering if coming too early.

I recommend YSlow, the Yahoo! extension to Firebug to testdrive page's speed and find ways to optimize it.

@elgg-gitbot

This comment has been minimized.

Show comment
Hide comment
@elgg-gitbot

elgg-gitbot Feb 16, 2013

cash wrote on 40941257-10-30

As long as our JavaScript files are being registered through elgg_register_js(), this should be trivial as it has a location parameter ('head' or 'footer').

elgg-gitbot commented Feb 16, 2013

cash wrote on 40941257-10-30

As long as our JavaScript files are being registered through elgg_register_js(), this should be trivial as it has a location parameter ('head' or 'footer').

@elgg-gitbot

This comment has been minimized.

Show comment
Hide comment
@elgg-gitbot

elgg-gitbot Feb 16, 2013

ewinslow wrote on 40941382-09-30

But it means plugins can't be allowed to insert js that relies on jQuery or elgg. That's what I'm most concerned about. Do we just say "don't do that, or you're out of luck"?

elgg-gitbot commented Feb 16, 2013

ewinslow wrote on 40941382-09-30

But it means plugins can't be allowed to insert js that relies on jQuery or elgg. That's what I'm most concerned about. Do we just say "don't do that, or you're out of luck"?

@elgg-gitbot

This comment has been minimized.

Show comment
Hide comment
@elgg-gitbot

elgg-gitbot Feb 16, 2013

cash wrote on 40941400-12-09

By insert - you mean inline inserts, right?

We could leave it in the head by default and add a configuration to move it to the footer. That or you could write a plugin that moves the js to the footer if this is desired.

elgg-gitbot commented Feb 16, 2013

cash wrote on 40941400-12-09

By insert - you mean inline inserts, right?

We could leave it in the head by default and add a configuration to move it to the footer. That or you could write a plugin that moves the js to the footer if this is desired.

@elgg-gitbot

This comment has been minimized.

Show comment
Hide comment
@elgg-gitbot

elgg-gitbot Feb 16, 2013

ewinslow wrote on 40941435-01-25

Yea, inline inserts. The trouble with making it a plugin is that I won't have control over other plugins. If we make this a feature of core, then that will force plugins to adhere to best practices.

elgg-gitbot commented Feb 16, 2013

ewinslow wrote on 40941435-01-25

Yea, inline inserts. The trouble with making it a plugin is that I won't have control over other plugins. If we make this a feature of core, then that will force plugins to adhere to best practices.

@elgg-gitbot

This comment has been minimized.

Show comment
Hide comment
@elgg-gitbot

elgg-gitbot Feb 16, 2013

cash wrote on 40979515-11-14

Closing this since a plugin can move all javascript to footer if desired on a site in 1.8 with new elgg_register_js code.

elgg-gitbot commented Feb 16, 2013

cash wrote on 40979515-11-14

Closing this since a plugin can move all javascript to footer if desired on a site in 1.8 with new elgg_register_js code.

@elgg-gitbot

This comment has been minimized.

Show comment
Hide comment
@elgg-gitbot

elgg-gitbot Feb 16, 2013

ewinslow wrote on 42324880-12-08

I really think we ought to reconsider this and take a more opinionated stance here. If plugins are inserting javascript into the middle of the page, they're doing it wrong, and I don't think we should have to support that.

At the very least we could make the footer the default location, forcing plugins to move the js up if that's what they really need to do.

elgg-gitbot commented Feb 16, 2013

ewinslow wrote on 42324880-12-08

I really think we ought to reconsider this and take a more opinionated stance here. If plugins are inserting javascript into the middle of the page, they're doing it wrong, and I don't think we should have to support that.

At the very least we could make the footer the default location, forcing plugins to move the js up if that's what they really need to do.

@ewinslow ewinslow added the major label Jul 6, 2014

@ewinslow ewinslow removed this from the Elgg 2.0.0 milestone Jul 10, 2014

@ewinslow

This comment has been minimized.

Show comment
Hide comment
@ewinslow

ewinslow Mar 16, 2015

Member

Putting this back on the 2.0 milestone as I think it would make a great hackathon ticket.

Member

ewinslow commented Mar 16, 2015

Putting this back on the 2.0 milestone as I think it would make a great hackathon ticket.

@ewinslow ewinslow added this to the Elgg 2.0.x milestone Mar 16, 2015

@ewinslow

This comment has been minimized.

Show comment
Hide comment
@ewinslow

ewinslow Mar 16, 2015

Member

Chrome has a very nifty feature that allows you to do network throttling to simulate very slow environments. I decided to try 2G... (Lots of people around the world are on 2G, or just imagine a flaky 3G/4G, etc.)

The community site takes 15 seconds to load with an unprimed cache (you can disable caching in dev tools).

Thankfully, once you turn on the cache, it renders something in under 1s on 2G! This is great news, but just means we absolutely need to defer-load the JS.

One trivial step we could take is just make turn on the defer attribute by default for all the scripts that we currently load. They are guaranteed to execute in order and only after the document has loaded, but will download in parallel, which is great.

This would also help us root out all the inline scripts currently in core by causing them to fail., which we would then HAVE to fix before releasing 2.0 final. 😀

Member

ewinslow commented Mar 16, 2015

Chrome has a very nifty feature that allows you to do network throttling to simulate very slow environments. I decided to try 2G... (Lots of people around the world are on 2G, or just imagine a flaky 3G/4G, etc.)

The community site takes 15 seconds to load with an unprimed cache (you can disable caching in dev tools).

Thankfully, once you turn on the cache, it renders something in under 1s on 2G! This is great news, but just means we absolutely need to defer-load the JS.

One trivial step we could take is just make turn on the defer attribute by default for all the scripts that we currently load. They are guaranteed to execute in order and only after the document has loaded, but will download in parallel, which is great.

This would also help us root out all the inline scripts currently in core by causing them to fail., which we would then HAVE to fix before releasing 2.0 final. 😀

@ewinslow

This comment has been minimized.

Show comment
Hide comment
@ewinslow

ewinslow Apr 25, 2015

Member

@Elgg/owners How do people feel about making this massively breaking change? Haven't heard anything from the rest of you.

As stated above, I'd like to just make all register/load scripts as "defer" so that this happens more or less automatically with minimal changes.

IMO it's critical for performance going forward. The scripts in head thing is just ridiculously out of control.

Member

ewinslow commented Apr 25, 2015

@Elgg/owners How do people feel about making this massively breaking change? Haven't heard anything from the rest of you.

As stated above, I'd like to just make all register/load scripts as "defer" so that this happens more or less automatically with minimal changes.

IMO it's critical for performance going forward. The scripts in head thing is just ridiculously out of control.

ewinslow added a commit to ewinslow/Elgg that referenced this issue Apr 25, 2015

perf(scripts): Load all scripts in foot regardless of registered loca…
…tion

BREAKING CHANGE:
If you use any inline scripts that depend on scripts in head,
you'll need to change them to external AMD modules and
load them with `elgg_require_js`.

Fixes #2718

ewinslow added a commit to ewinslow/Elgg that referenced this issue Apr 25, 2015

perf(scripts): Load all scripts in foot regardless of registered loca…
…tion

BREAKING CHANGE:
If you use any inline scripts that depend on scripts in head,
you'll need to change them to external AMD modules and
load them with `elgg_require_js`.

Fixes #2718

ewinslow added a commit to ewinslow/Elgg that referenced this issue Apr 25, 2015

perf(scripts): Load all scripts in foot regardless of registered loca…
…tion

BREAKING CHANGE:
If you use any inline scripts that depend on scripts in head,
you'll need to change them to external AMD modules and
load them with `elgg_require_js`.

Fixes #2718
@mrclay

This comment has been minimized.

Show comment
Hide comment
@mrclay

mrclay Apr 27, 2015

Member

Just to chime in in this thread, I'm hesitantly behind #8242.

Member

mrclay commented Apr 27, 2015

Just to chime in in this thread, I'm hesitantly behind #8242.

mrclay added a commit to mrclay/Elgg-leaf that referenced this issue May 2, 2015

perf(scripts): Load all scripts in foot regardless of registered loca…
…tion

BREAKING CHANGE:
If you use any inline scripts that depend on scripts in head, you'll need to
change them to external AMD modules and load them with `elgg_require_js`.

Fixes #2718

mrclay added a commit to mrclay/Elgg-leaf that referenced this issue May 2, 2015

perf(scripts): Load all scripts in foot regardless of registered loca…
…tion

BREAKING CHANGE:
If you use any inline scripts that depend on scripts in head, you'll need to
change them to external AMD modules and load them with `elgg_require_js`.

Fixes #2718

mrclay added a commit to mrclay/Elgg-leaf that referenced this issue May 2, 2015

perf(scripts): Load all scripts in foot regardless of registered loca…
…tion

BREAKING CHANGE:
If you use any inline scripts that depend on scripts in head, you'll need to
change them to external AMD modules and load them with `elgg_require_js`.

Fixes #2718

@mrclay mrclay closed this in #8271 May 2, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment