Important Notice from AspDotNetStorefront
It is with dismay that we report that we have been forced, through the action of hackers, to shut off write-access to this forum. We are keen to leave the wealth of material available to you for research. We have opened a new forum from which our community of users can seek help, support and advice from us and from each other. To post a new question to our community, please visit: http://forums.vortx.com
Results 1 to 3 of 3

Thread: obfuscated nor minified

  1. #1
    tito is offline Senior Member
    Join Date
    Sep 2005
    Posts
    213

    Default obfuscated nor minified

    The following JavaScript files do not appear to be obfuscated nor minified.
    http://developer.yahoo.com/performan...es.html#minify

    Is this something we should consider doing?
    Gordon

    8.1.1

  2. #2
    estephen is offline Senior Member
    Join Date
    Apr 2006
    Location
    Dallas
    Posts
    208

    Default

    I suspect they aren't minified since it's a dev platform, so obfuscated or minified code might make it somewhat difficult to modify the js to meet a particular site's needs. And the text of the js files is generally pretty small. So I think it's the HTTP requests that you should focus on eliminating.

    ----------

    I know this wasn't what you asked, but I'll make some suggestions of things I've played around with that might be helpful for you are obviously using YSlow to critique your site's performance.

    I've set expiration headers for many of my files (kind of just for grins to see the impact). I'm a relatively low traffic site compared to some others here, so this may be of bigger impact to other sites.

    For the commonly called javascript "formvalidate.js" from the template.ascx files, I copied this into a subfolder for the jscripts folder of the ASPDNSF version, e.g. - /jscripts/7025/formvalidate.js. Then I added a 6 month expiration to that folder. When I upgrade, I'll add the new js file into a new version folder and update my templates accordingly. If ASPDNSF calls this file from the source, etc. then I've left it in the root jscripts folder for compatibility (without an expired header).

    I've done the same thing for versions of my skin. I've created a copy of the style.css like style_0308.css and updated all the templates (including popups). I leave the style.css (without an expiration header) in case I miss some place that references "style.css".

    And I do the same for images within the skin (create an images subfolder with expires). This was a little trickier to keep updated, so I simply added an appconfig for the current skin version (like mmyy) and I reference it from all of my xml packages as part of the path to my skin images. If I modify my skin images, I simply create a new skin version folder, copy all files to it, and update the appconfig - voila.

    Code:
    <xsl:param name="CurrentSkinVersion" select="aspdnsf:AppConfig('CurrentSkinVersion')"/>
    
    <img src="/skins/skin_{aspdnsf:SkinID()}/images/{$CurrentSkinVersion}/freeshipping.gif" alt="Free Shipping"/>
    I've been able to apparently improve my skin cached files and reduce http requests significantly with these basic modifications (at least according to YSlow). This must be beneficial for larger or higher volume sites.

  3. #3
    tito is offline Senior Member
    Join Date
    Sep 2005
    Posts
    213

    Thumbs up

    Wow thats a really nice reply.
    Thanks for taking your time to explain these great suggestions
    Shall try this out..
    Thanks again
    Gordon

    8.1.1