JavaScript caching

Nao

  • Dadman with a boy
  • Messages: 16 082
JavaScript caching
« le 10 Mai 2011 à 18:43 »
Feature: JavaScript caching
Developer: Nao
Target: everyone
Status: 100% (believed to be complete.)
Comment:

Right after minifying your CSS and JS files, Wedge will cache them and gzip them. The good point is that it's smart enough to cache multiple files together, relieving the server a bit.

I'll use my script.js example again. At the time of writing, the regular script.js/theme.js duo is about 50KB in SMF2 (split over two files), less than 30KB in Wedge (with many extra functions in them), and the actual stuff you download is a single 6KB file, after minification and gzipping. Meanwhile in the wasteland, SMF2 still sends you 50KB of data. Because everyone knows all end-users absolutely need to have comments in the JavaScript code they execute.

Re: JavaScript caching
« Réponse #1, le 19 Juin 2011 à 10:34 »
Why not minify and cache the single built file, rather than minifying separately and then combining and caching?  You'll probably get better perf.

Honestly, this is why I didn't use comments in the js files of olde, I figured it was way too much to run something on them to remove comments.  But, it's getting more popular now and making sense.

-[Unknown]

Re: JavaScript caching
« Réponse #2, le 1er Juillet 2011 à 14:17 »
Citation de [Unknown
link=msg=262640 date=1308472459]
Why not minify and cache the single built file, rather than minifying separately and then combining and caching?  You'll probably get better perf.
I originally minified everything together, but performance was not any better. Probably a bit worse IIRC. Plus, it had other issues linked to it. Once I started doing files separately, it went better.

Also, performance is not very important at the minification stage. Indeed, since everything is cached forever as long as the css files aren't modified, after a few hundred visits (encompassing all possible browser setups), the minifier will no longer be called at all.
Citation
Honestly, this is why I didn't use comments in the js files of olde, I figured it was way too much to run something on them to remove comments.  But, it's getting more popular now and making sense.
Yeah, it's a blessing, I find.
Commenting JS files should be mandatory. If only to help future developers get into the groove :)


Re: JavaScript caching
« Réponse #4, le 2 Juillet 2011 à 20:52 »
Doesn't show up to guests (banned, remember? I tend not to go over there too often these days......)

Please copy & paste?

Re: JavaScript caching
« Réponse #5, le 2 Juillet 2011 à 21:20 »
Well ... I am not banned there (yet  :eheh: ) but I cannot see it either.

Re: JavaScript caching
« Réponse #6, le 2 Juillet 2011 à 21:44 »
Citation
An Error Has Occurred!
The topic or board you are looking for appears to be either missing or off limits to you.

Re: JavaScript caching
« Réponse #7, le 2 Juillet 2011 à 21:46 »
I can't see it either, but I would probably have to re-activate my account to do so.


Re: JavaScript caching
« Réponse #9, le 2 Juillet 2011 à 21:59 »
Why would I keep it? It's only another tie to the past I can do without and it means I find myself spending much less time browsing over there for stuff to laugh at - and I don't get dragged into stupid arguments with narrow-minded fools who don't really understand what's going on, and I was fed up of being labelled as a bringer of drama without due cause.

I don't need to go there, overall, except to browse for ideas for things to build for Wedge in the future, because I can. Oh, and it means that they're left to their own devices as far as security is concerned, after I called them out on a mod that allows for arbitrary iframe injection. I burned far far too much time there.

Re: JavaScript caching
« Réponse #10, le 2 Juillet 2011 à 22:16 »
Citation de Arantor le 2 Juillet 2011 à 21:59
Why would I keep it? It's only another tie to the past I can do without and it means I find myself spending much less time browsing over there for stuff to laugh at - and I don't get dragged into stupid arguments with narrow-minded fools who don't really understand what's going on, and I was fed up of being labelled as a bringer of drama without due cause.
I didn't realize you'd disabled your account as soon as SMF2 Gold was released... That was 3 weeks ago.
Of course I haven't been (much) to sm.org after that, myself... So I could hardly have noticed anything.
Still, it's a shock to see you aren't in the memberlist.

(And as always, the SMF team has yet to take your request into account. Your account can still be browsed.)
Citation
I don't need to go there, overall, except to browse for ideas for things to build for Wedge in the future, because I can. Oh, and it means that they're left to their own devices as far as security is concerned,
Which is always fun... Of course, the only one who'll ever know is you. Because if a hacker finds any way to hack into SMF, they probably won't tell. Hundreds of SMF forums, hacked, with no explanation at all... I feel bad for the users most of all.
Citation
after I called them out on a mod that allows for arbitrary iframe injection. I burned far far too much time there.
Agreed. Totally agreed.

Re: JavaScript caching
« Réponse #11, le 2 Juillet 2011 à 22:34 »
The usual rule is 30 days, so it's no surprise. Though I thought they'd be glad to see the back of me to be honest.

Re: JavaScript caching
« Réponse #12, le 2 Juillet 2011 à 23:01 »
They're seeing your back in every sense of the term!

Re: JavaScript caching
« Réponse #13, le 3 Juillet 2011 à 01:55 »
Citation de Joshua Dickerson le 9 Mars 2011 à 01:30
What does that have to do with this function?

It's used for the following to remove bad URLs from the indexers view. Well, if we just changed them to real, good URLs and then worked with those instead, that would make more sense and more understandable for everyone IMO.

It's not even in use everywhere. I took a look at the message index for this board:
result:
Code: [Sélectionner]
<span style="font-weight: bold;" onclick="expandPages(this, 'http://www.simplemachines.org/community/index.php?board=74.%1$d', 150, 2100, 50);" onmouseover="this.style.cursor='pointer';"> ... </span>

So, if it isn't being used there with an odd URL, shouldn't it be presenting errors or odd accesses in the logs?

It's used several times on the infocenter toggle object on the board index to add quotes around the $txt and session vars.

The following is a shining example from the display template. It is so much harder to read because of the escaping:
Code: [Sélectionner]
sTemplateBodyEdit: '\n\t\t\t\t\t\t\t\t<div id="quick_edit_body_container" style="width: 90%">\n\t\t\t\t\t\t\t\t\t<div id="error_box" style="padding: 4px;" class="error"><' + '/div>\n\t\t\t\t\t\t\t\t\t<textarea class="editor" name="message" rows="12" style="width: 100%; margin-bottom: 10px;" tabindex="5">%body%<' + '/textarea><br />\n\t\t\t\t\t\t\t\t\t<input type="hidden" name="af00a1ba031" value="c5e7963677f5827d8476125917ac76b2" />\n\t\t\t\t\t\t\t\t\t<input type="hidden" name="topic" value="382883" />\n\t\t\t\t\t\t\t\t\t<input type="hidden" name="msg" value="%msg_id%" />\n\t\t\t\t\t\t\t\t\t<div class="righttext">\n\t\t\t\t\t\t\t\t\t\t<input type="submit" name="post" value="Save" tabindex="6" onclick="return oQuickModify.modifySave(\'c5e7963677f5827d8476125917ac76b2\', \'af00a1ba031\');" accesskey="s" class="button_submit" />&nbsp;&nbsp;<input type="button" value="Spell Check" tabindex="7" onclick="spellCheck(\'quickModForm\', \'message\');" class="button_submit" />&nbsp;&nbsp;<input type="submit" name="cancel" value="Cancel" tabindex="8" onclick="return oQuickModify.modifyCancel();" class="button_submit" />\n\t\t\t\t\t\t\t\t\t<' + '/div>\n\t\t\t\t\t\t\t\t<' + '/div>',
It escaped the tabs with \\t and line breaks with \\n so they can be readable in JavaScript... but not the HTML output that anyone is actually going to read. It changed all of the closing divs... why? I don't even see any URLs here for it to escape.

I finally found one that supports what everyone is saying:
Code: [Sélectionner]
sTemplateSubjectNormal: ', JavaScriptEscape('<a href="' . $scripturl . '?topic=' . $context['current_topic'] . '.msg%msg_id%#msg%msg_id%" rel="nofollow">%subject%</a>'), ',
result:
Code: [Sélectionner]
sTemplateSubjectNormal: '<a hr'+'ef="http://www.simplemachines.org/community/index.php'+'?topic=382883.msg%msg_id%#msg%msg_id%" rel="nofollow">%subject%<' + '/a>'

How, you might ask, do I propose we fix that? Well, there are two (or even three) options.

One means that a normal, simple link is no longer created in the template. That makes the non-cached JavaScript a lot smaller.
Code: [Sélectionner]
Modify QuickModify() returning that link with the correct information. Makes a whole lot more sense that way.

Second would be to use the JavaScript var: smf_scripturl.
Code: [Sélectionner]
sTemplateSubjectNormal: \'<a href="\' + smf_scripturl \'?topic=', $context['current_topic'], '.msg%msg_id%#msg%msg_id%" rel="nofollow">%subject%</a>\'',

The last would be a URL creator function (pseudo since I'm using the browser to write all of this):
Code: [Sélectionner]
function url(base_uri = smf_scripturl, query_string, args)
{
   // see sprintf(): http://www.diveintojavascript.com/projects/javascript-sprintf
   return sprintf();
   // there are also easier replace().
}

Any way you look at that, it actually makes it easier for you to rewrite the URLs. It could still be possible to use a JS escaping function, but we should really figure out what we want to do with it and how it makes the user safer.

Re: JavaScript caching
« Réponse #14, le 3 Juillet 2011 à 01:57 »
Oh, I remember that discussion now. It was about what JavaScriptEscape did, and why it was necessary to call it for URLs - because there were all kinds of bad URLs getting into Google (namely the one indicated with %msg_id% in it)

Re: JavaScript caching
« Réponse #15, le 3 Juillet 2011 à 01:57 »
I just realised that can get be banned.