A tad un-needed?

TomTester · March 2007

Wall, food for thought...

This page (at present) is 148,735 bytes uncompressed. It consists of one HTML page
and 18 elements (incl. scripts & CSS) requiring up to (depending on browser caching) 19 server
connections (ignoring images, not compressed by mod_gzip).

Now, if I compress all of these files (HTML, CSS & JS) into one ZIP archive I end up
with 40,919 bytes (or about 27% of original) -- I think this is a fair approximation of a
page where all CSS and JS are included and then delivered on a server with mod-gzip.
This 'integrated compressed page' would now require only 1 connection for HTML, CSS & JS
(saving significant time as well as server resources)

The proposed JS/CSS packager solution is in effect not that different, in that it would also
spend time to create the dynamic package (similar to per-page inclusion of JS/CSS in the
HTML page). To allow for browser-side caching all UNIQUE package combos need UNIQUE
names.
These Alternatively the packages could be cached on the server side, but I think there's
a small issue there(*). Either way, every page would now require up to TWO separate
connections.

Now as Mallow (and Google) know, ONE connection is better than TWO.

So... I really wonder if the additional size reduction/gain that can be achieved is significant
(especially in comparison to images in the page).

Moreover, the additional *complexity* (dynamic packaging, caching, perhaps unpacking etc.
etc.) is now MUCH higher. I can see the bug reports fluttering in the wind (and hours spent
on debugging packaged JS/CSS combos, think about issues like JQuery vs order of plugin
activation requirements)

I like simple, anyone in the market for a FULL INCLUSION add-on or core patch?
I'd love to see a run-off between the two methods...

TT

(*) Stash, is this true?!?
Will inclusion of a single inline image in a thread, e.g. via InlIne Image and JQThickBox
change the header requirements for that thread vs a thread without inline images?

Stash · March 2007

Tom, that depends on how you're doing the packing/combining

A simple compromise would be to just bundle up all of the JS from extensions (and the core) that are enabled into one super file, irrespective if the JS isn't shown on some pages, and the same with the CSS. This would be done ONLY when an extension/theme/style is enabled/changed. So, all the time you're not changing the setup of your forum, the JS/CSS isn't doing anything, but being sent once to the client (3 connections - HTML, CSS and JS) and then, hopefully cached. This way, you don't have too much added complexity of different bundles of JS for different pages which use some but not others, as everything is included the whole time.

It is possible that an approach like this may conflict with extensions that allow the users to pick and choose, like the style chooser extension for instance. A way around this would be to have the "bundler extension" configurable, so you can choose to not add themes/styles or selected extensions?

Stash · March 2007

While connections are important, you need to get a balance between them and bandwidth. As a hoster you may be more interested in saving bandwidth, so you want to get the client to cache as much as possible. Keeping the number of connections down should be seen as a part of the puzzle, not the only one.

Loading the Extensions page in the Settings section of my test forum results in 34 requests to deliver 271kb according to FireBug, 66KB of HTML, 34KB of CSS and 162KB of JS. But even so, that's a lot of data for a single, graphically light page. If the CSS and JS were cached this drops to only 66KB or 24% of the bandwidth required per page load. This is a heavy case that most forums won't experience, I'd imagine, since I'm testing lots of extensions, but even so, on a heavy traffic forum, this could theoretically mean the difference between using 10GB or 40GB per month. For the sake of two extra client-sever connections each click, most people who pay the bandwidth bill will tell you it's a fair compromise.

Dinoboff · March 2007

The package have to be merge again only if an addon is updated, or if you add a file to the pack. Most of the time, the parker will just load the cached package.
Case 1: server and client cache are up-to-date: 304 response
Case 2: server cache up-to-date, client cache empty; serve the cache
Case 3: server cache obsolete, merge the files, save a new cache and serve the new package.

There also the case when the client just assume his cache version is up-to-date

Stash · March 2007

Just out of interest, are you using this class?

TomTester · March 2007

and then, hopefully cached
So any performance gain over straight inclusion will depend on browser caching policy/behavior...

Vanilla includes different CSS/JS file combinations in the header depending on the PAGE you're
accessing e.g. the discussion overview, categories, account, settings, all have different includes,
check it out...

The 'safe solution' of combining all JS/CSS can lead to a mighty big include... (and, I assume,
problems that will be difficult to analyze).

Anyhow, I look forward to seeing the difference. I'll take a look this weekend at modding the
core routines to obtaining all-in-one rendered pages.

Dinoboff · March 2007

@[-Stash-] No, my own, inspired by http://www.ejeliot.com/blog/72 We talked about that 2 months ago, but started to work on it recently. I was hoping it could go in vanilla 1.1, but will be some problem with relative path in css and there wasn't enough time to test it properly.

WallPhone · March 2007

You know, that version numbering is pretty slick--changed or updated CSS/JSS will give a whole new file name so browsers will ignore their cached versions and just request the version number passed to them.

in other words--no more 'hard refresh/clear your cache if it looks or acts wierd' bugs.

Dinoboff · March 2007

Thanks WallPhone, I didn't thought to use that, because the Head controller would need to check the last modification time of the files to merge and compare it with the one of the server cache (a part of its name, I can't rely on the one of cache). I wanted to leave that to the merger script but since he trouble with the last release, that look like a very good idea. I will think to that again.

skube · March 2007

@Stash: This is an example of how I would have done it...


<style type="text/css">
#Panel {width:180px;font:11px 'Trebuchet MS';border:1px solid #ccc;background:#fff}
#Panel * {margin:0;padding:0}
#Panel #start {display:block;margin:10px;font-size:14px;color:#c00;font-weight:bold}
#Panel dl {margin:10px;}
#Panel dd, #Panel dt {padding:0 5px; color:#999}
#Panel dt {font-weight:bold;color:#000; border-bottom:1px solid #ccc;}
#Panel dd a {display:block;margin:2px 0;color:#335EB7;text-decoration:none}
#Panel dd a:hover {background:#ffc}
#legend dd {padding:2px 5px;border-bottom:1px solid #ccc; background:#feebfa}
#legend dd.you {background:#fefceb}
</style>
<div id="Panel">
	<a id="start" href="/">Start a new Discussion</a>
	<dl id="options">
		<dt>Options</dt>
		<dd><a href="/">Bookmark this discussion</a></dd>
	</dl>
	<dl id="filters">
		<dt>Discussion Filters</dt>
		<dd><a href="/">Participated Discussions</a></dd>
		<dd><a href="/">Bookmarked Discussions</a></dd>
		<dd><a href="/">Your Discussions</a></dd>
		<dd><a href="/">Whispered Discussions</a></dd>
		<dd><a href="/">Whispered Comments</a></dd>
	</dl>
	<dl id="searches">
		<dt>Searches</dt>
		<dd>You have no searches</dd>
	</dl>
	<dl id="legend">
		<dt>Legend</dt>
		<dd class="you">You whispered</dd>
		<dd>Whispered to you</dd>
	</dl>
</div>

Stash · March 2007

Tom, if the combined ALL JS/CSS files are source compressed, then you pretty much get the benefit of having non source compressed ones included only on pages they're required for. At elast with the external files they can be cached, whereas included in the page they cannot, ever. Basically, it works for Google because of their usage model (2-3 pages views then off again), but it won't work fora forum - good to have thought about though.

Schiz, the auto incrementing filename is a genius idea for simply and effectively solving the cache refresh issues

Given how there are only 5-10 different pages/options for different CSS/JS options, perhaps a base CSS/JS can be created for inclusion on all pages, and then a page specific one? This would potentially end up with loading 4 files in totoal (base.css, page.css, base.js, page.js), but could end up creating the best compromise between loading in a whole new CSS/JS file per page and including ALL the CSS/JS on ALL pages?

Skube, I'll try and take a look at that and bung it in a style later...

TomTester · March 2007

Great link/site Dino (ejeliot).

Did you see his 'main' web site optimization post on there? Mentions some important things on CSS. Also has two source files for JSMin in PHP.
Some good points and related JS-related issues too at this Vitamin post.

(links as text:
http://learningtheworld.eu/2007/performance/
http://www.thinkvitamin.com/features/dev/enhance-your-page-performance )

Mark · March 2007

You can do autocomplete with jQuery. Perhaps we should look into replacing the autocomplete function with a JQuery equivalent?

PLEASE DO. I've been asking for this for AGES.

mallow005 · March 2007

@skube: Wow! Sorry about that, I didn't even check the markup. You are indeed correct when you say that the H2 should definitely NOT be nested in a list, that's terrible! I assumed that it was like this:

<h2>Title</h2>
<ul>
    <li>item</li>
    <li>item2</li>
</ul>

As for the simplebits quiz, I do believe they arrived to the conclusion that for the most part, navigation is best off using a header and an unordered list because the navigation items are not necessarily definitions, or *defining* the definition term. I'm not saying that DLs are only for definitions and terms (see dialog example), but if you do not reserve the DL for clear and direct "definition/term" relationships then it loses meaning. Tantek himself has the last comment on that blog post and he explains why A is the preferred answer in that situation (list of stuff).

In our situation, we have a panel with totally unrelated sections, some are navigation lists, some are actions, others are filters, others are legends, and RSS feeds (and lets not forget any and all future extensions which may stuff things into the panel). To me, it makes more sense to separate these not as terms but as sections, and headers separate sections. Each of them are distinct and separate enough to be different sections and not lumped together in a definition list.

By the way, in your example markup you could just combine all the DT/DD combos into one definition list, in fact that would be the more correct way since there is no reason not to...

<dl>
  <dt>Options</dt>
  <dd><a href="/">Bookmark this discussion</a></dd>
  <dt>Discussion Filters</dt>
  <dd><a href="/">Participated Discussions</a></dd>
  <dd><a href="/">Bookmarked Discussions</a></dd>
  <dd><a href="/">Your Discussions</a></dd>
  <dd><a href="/">Whispered Discussions</a></dd>
  <dd><a href="/">Whispered Comments</a></dd>
  <dt>Searches</dt>
  <dd>You have no searches</dd>
  <dt>Legend</dt>
  <dd class="you">You whispered</dd>
  <dd>Whispered to you</dd>
</dl>

... however, you DID separate these into individual DLs per DT/DD. This suggests that you also think that they are semantically unrelated and deserve their own space or separation. That's my argument for why it should use the Hx/UL approach (but of course not nested how it is now!).

On the optimization discussion: I agree that whether or not you optimize for HTTP Requests or for bandwidth/caching is definitely reliant on the type of traffic you get. As Stash and Wall stated, Google doesn't really care about caching since most people don't spend tons of time browsing through search results (heck, it just shows how confident they are that you will find what you want in one or two pages!). That's why I suggested a stitching/compiling/compressing approach would be best (for Vanilla) and to bring the AMOUNT of includes down as much as possible.

Mr Do · March 2007

I would welcome an extension that packs the css and js files, because as far as i can seem the number of connects has a big impact on load time of my forum on some systems.

skube · March 2007

@mallow005: Obviously many people—including Tantek—believe the most semantic and proper way to markup "a list of stuff" is with Hx/UL combos. Others—including Douglas Bowman—challenge that idea pointing to "relationships between concepts/things" rather than strict definitions. I continue to side with those in the Bowman camp for a number of reasons. Put into practice, I've found DLs are easier to control across browsers than Hs. I've found generally people have an easier time when code (or anything actually) is compartmentalized. This is especially important in this particular scenario, where a wide range of developers are adding various extensions that directly affect the Panel. Hx/UL defines no boundaries strictly speaking. Does the Hx relate to any information immediately following the UL or just to the UL itself? I suppose you could wrap it all up in DIV, but that leads to unnecessary code. Also, I firmly believe the use of H1,H2,H3,etc. should be used sparingly and only to subdivide the main content logically.

I still think in this situation multiple DLs would be best suited. While I concur with you and Bowman on combining multiple DLs into one, I kept them separated here for modular and readability reasons. In fact, they should probably each have IDs for targeting purposes.

In any case, we are probably way over analyzing and the existing layouts won't change in either direction for some time...

mallow005 · March 2007

"A list of stuff", in the context of the Simplebits discussion, is referring to a list of completely random items and a very non-descript header, so I don't think even Bowman would side with a DL in the end. He was merely trying to tell us that we shouldn't write off DLs so fast in similar situations where the items and the header have some kind of "concept/thing" relationship. I completely agree, they do have many uses for listing things with relationships. It could very well go either way in this situation. But then you brought up targeting and headers, so I will explain why I still think the header and UL approach would be best in this situation for both those reasons.

Headers (Hx) relate to any information underneath it until the next header of equal or higher level, just like in a book or paper. So to answer your question, it would relate to the UL and any information immediately following the UL, not just the UL itself (unless the thing immediately following the UL is a header of equal or higher level). This leads me to question your belief for using Hxs only to subdivide the main content logically, since the "side information" NEEDS headers just as much as the main content, or else the "side information" will all be under the last header of the main content (unless the "side information" comes before the main content in the markup... but that would be wrong)! That's probably why the "Start a new discussion" line was made a header, to separate the main content and the panel. However, another method is to use a horizontal rule, this is often used to separate the header and footer since the footer usually doesn't have headers in it. For the screen media, you would set HR to display:none, but if you were to view the page without CSS, it would look proper. So unless an HR is added to separate the panel from the main content in the markup, it should still use headers to subdivide the content.

As for DIVs being unnecessary code, in this case they would be perfectly semantic since you are compartmentalizing different sections, not unlike using DIVs to separate the header, main, footer, and panel. If you are worried about targeting, how would you target the all the list items as a group if you use a DL (DDs)? For example, what if I wanted to make all the list items do a "blind up" effect? I wouldn't be able to with a DL, I could only target each DD individually for a blind up effect... that wouldn't look right. I guess you could say "blind the bottom one first and then the one above it when it is done, repeat until no more DDs left" but my point is that using DLs does not make the targeting easier. Using semantic DIVs with IDs to compartmentalize the panel into sections with headers and unordered lists would be even easier to target than DLs.

Over analyzing? Maybe. I'm no standardista, I wouldn't care much if Vanilla went with DLs. But at the same time I think you're leaning towards DLs for the wrong reasons. With all due respect

Stash · March 2007

Nice example of "blinding up" DTs in a single DL.

I quite like the DTs and DDs all under one DL with id=Panel

mallow005 · March 2007

Right, that's only with one DD per DT though.

Dinoboff · March 2007

The packer is done for most of it, a beta version should be available tomorrow. It will be a patch.

Some few changes are needed to the core. For the extension the problem will come from relative paths in css, the ones used for backgrounds. If you use the patch, you have to change the relative path to the extension for a relative path the style folder.