Thread

I break my pages into templates then call them on a page. doing it this way is much cleaner for me. Pages like statistics and graphs will call all the plotting plugin stuff, while image rotations, and other ‘toys’ are loaded on pages that need them.

I’ve tried to minimize the number of pages to one or two and use all sorts of conditionals to expand the capability of each, but keep coming back to creating multiple template “pages” to do exactly what you describe. It’s just easier to manage, and much easier for someone else to take over and manage. At most, I’ve set up maybe a dozen “pages” on a complex site, and most elements on each page are nothing more than repeating {embeds} anyway, but that method makes it much easier to assign Javascripts to the page it should be on, rather than on every page.

Here is my attempt at being clever regarding this…

I actually do the following for CSS, JS, breadcrumbs, and anything else where it applies.

First, I create an includes folder that handles anything global.  All of the JS that applies globally would be put into template(s) with a naming convention of .js_jquery, .js_swfobject, et cetera.  For my master css template, .css_global.  My HTML fragments are called .html_css, .html_masthead, .html_footer, et cetera.  There is one HTML fragment for JS called .html_js which calls in the javascript.

Example:

{embed="includes/.js_global"}
{embed="{segment_1}/.js_local"}

Next, I create a template in my template group and name it “.js_local”.  All of the JS that applies to this group is within this JS file.

Finally, I embed {embed="includes/.html_js"} in all of my templates.  This keeps all of the JS nice and tidy between the head tags.  This allows me to forget about the inclusion of specific Javascript(s) in individual templates moving forward.  With this structure, I can add/delete/modify JS by heading to the .js_local or .js_global templates.

note: If JS applies to two or more template groups, I typically place it in the .js_global file with or without conditionals.  Inside the local file, I use conditionals if I want the JS to apply to only one template.

another note: For JS, I use embeds in my includes/.html_js template, but for CSS I use <link rel=“stylesheet” type=“text/css” media=“all” href=”{stylesheet={segment_1}/.css_local}” /> in place of the embeds.

This may seem confusing or extraneous at first, but in my mind, it breaks everything up in manageable pieces that follows the template_group/template structure of EE.  I typically avoid embeding other embeds, but I’ve noticed no penalty for this.  I’d love to hear from Derek or someone within EE that could actually confirm this.  This idea was born out of Derek’s Behind The Curtains II article.

I’m close to the point where I’m ready to flush MSIE 6 and non-Javascript compliant browsers completely. Well, except for those wonderful billable hours…

- It depends entirely on what type of audience you’re building for… My main corporate b2b site (circa 22,000 visits/month according to Google Analytics) had 40% IE6 users last month. I suspect most of those people are locked into IE6 by their IT department… those same IT depts that often block JavaScript and Flash. Ignoring those users would be corporate web suicide…

Java support (whatever that is… does it really mean ‘Javascript?’) was well over 96-percent.

- If you’re refering to Google Analytics, then no - this means Java, not JavaScript… very different. Google Analytics is based on JavaScript, so by definition is unable to tell you how many users have JS disabled. I was at the @media conference earlier this year where some developers from http://www.bbc.co.uk revealed that around 5% of their millions of visitors had JS disabled.

As for jQuery, as e-man says, it should be for bells n whistles - not things like layout or navigation. To minimise the impact of lots of plugins, you should follow the YSlow guidelines… among them:

1. Use the minified and gzipped jquery script from the google library here: http://ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js - this increases the chance that your visitor might already have the script in his browser cache, and you may also benefit from the parallel downloading capabilities built into browsers when you load page elements from two different domains or sub-domains.
2. Put your scripts at the end of the <body> so that the page can render on screen as soon as possible.
3. Combine all your jQuery plugins into one external file… Bad for maintainability, but very good for speeding up your site…
4. This one’s gold… If you get most of your hits on the home page, it’s really good to cut back on all http requests and stuff all your css into one <style> tag in the <head> and all your JS into one <scr*pt> tag at the end of the <body>. Then you can use some jQuery $.get() ajax calls at the end of the <body> to load the ‘real’ external assets into the user’s cache so that while they are viewing the fully-loaded speedy home page, everything they need for a deeper page view is being silently downloaded in the background. It’s a superb technique (called post-loading) that shaved 3.5 seconds off my home page loading time, despite a fair amount of jQuery.

James

2. Put your scripts at the end of the <body> so that the page can render on screen as soon as possible.

Why would you place them in the body when you can keep them in the head and rely on the document ready function?

$(document).ready(function(){});

Why would you place them in the body ...

The document.ready event is not the same as window.onload - you can use document.ready before the page actually appears to be finished loading, as it refers to the state of the DOM tree rather than the entire web page (I think anyway 😊). That means you can - and should - put it in your <body>.

Anything you put in your <head> will be fully downloaded before the page will start to render, thereby making the site feel slower. Not only that, but in the case of scripts, they block parallel downloads, so while the browser is downloading your JS it will not ‘do’ anything else: http://developer.yahoo.com/performance/rules.html#js_bottom