photo

michael shirley

shared this idea
1 year ago

Employees Involved

photo

PIV Support

Admin

Statistics

6
Comments
1076
Views

Relates to

Share

Tags

1
votes

minimized js and css

Hi all. Let me just say how astounded I am that we are still using inline CSS and un-compressed CSS & JS... I have been working hard on a clients site recently to increase speed and micro/schema data. It has been an up hill battle as most of what OR does is not friendly with this.

Run your site through a test over at https://gtmetrix.com/. Now just try to get it to and A or B rating... Please for the love of God, use async for the JS. Use only one version of JQuery, current version please. Use secure cdn if possible. Implement HTML minified... I input in minified and it is parsed formatted adding so much more overhead.

Add Comment

Comments (6)

photo Employee
2

Not sure what you mean when you say "OR is not friendly with this", perhaps you could cite some specific unfriendliness? There are sometimes very necessary reasons to use inline CSS, but not if you don't have to do it.

You are correct otherwise in your general suggestions for template developers regarding library duplication, the use of CDN's for popular libraries, minifying your files and etc, and I would only add that if you are going to minify your OR template files, that you take special care regarding curly brace characters { } used in any embedded javascript or jQuery code as outlined in the OR docs. Working code can potentially stop doing so after being minified, and the javascript console in your browser will usually start collecting errors to alert you to this.

http://docs.transparent-tech.com/open-realty/latest/troubleshootingdisplayproblems.html

(bottom of page)

You may also find it impossible to score an 'A' if you are using shared hosting or a shared server depending on how much weight the specific testing service you are using places on "time to first byte" when scoring.

photo
1

The recent changes helped alot:

  • OR-295 Added a new template tag {load_ORjs}. This tag loads only the bare javascript OR needs to operate, and moves items such as jQuery, and jQuery plugins back to the public templates for developers to control. This is intended to replace the existing {load_js} template tag in all public templates, which is now deprecated.

A/B (sometimes A/C) rating on my clients site now. Working to improve this more. Switching to the new template tag, dropping the forced load of jquery really helps. (Shared host) Yes TTFB is high in the scoring, as is the number of server requests... I think the latter should be looked at for any future updates. Just going to toss it out there for thought, argument and review... Base64 encoding? Yes I know there are cases for and against it's use and times it is not appropriate, external images...

Now the more specific part I would suggest going forward is: I've minified my HTML input on the page editor. The minute I save it, it goes back to having additional line beaks and spaces. Now mind you that may not be much on a small page but if you have a good deal of content on said page it is a waste...

Another example, even with the change to remove the jquery call, we still have the minimal javascript load:

  1. <script type="text/javascript">

    function confirmDelete(msg) { if (!msg) { msg="Are you sure you want to delete?" } var agree=confirm(msg); if (agree) { return true ; } else{ return false ; } };

    </script>

Why not:

  1. function confirmDelete(e){e||(e="Are you sure you want to delete?");var r=confirm(e);return r?!0:!1}
Testing the above suggestions I've found an savings from 8-15% on many of my pages.

photo Employee
1

michael shirley wrote:

(Shared host) Yes TTFB is high in the scoring, as is the number of server requests... I think the latter should be looked at for any future updates. Just going to toss it out there for thought, argument and review... Base64 encoding? Yes I know there are cases for and against it's use and times it is not appropriate, external images...

Now the more specific part I would suggest going forward is: I've minified my HTML input on the page editor. The minute I save it, it goes back to having additional line beaks and spaces. Now mind you that may not be much on a small page but if you have a good deal of content on said page it is a waste...

Another example, even with the change to remove the jquery call, we still have the minimal javascript load:

  1. <script type="text/javascript">

    function confirmDelete(msg) { if (!msg) { msg="Are you sure you want to delete?" } var agree=confirm(msg); if (agree) { return true ; } else{ return false ; } };

    </script>

Why not:

  1. function confirmDelete(e){e||(e="Are you sure you want to delete?");var r=confirm(e);return r?!0:!1}
Testing the above suggestions I've found an savings from 8-15% on many of my pages.

What server requests do you believe can be looked at, for future updates of what exactly?

What about base64 encoding? I am not following your first paragraph above very well.

You need to use the source code view of the code editor, and it should not insert line breaks and etc.

You don't have to load the {load_ORjs} JS if you don't need it. Do you have anything that uses it in your templates?

photo
1

Server request wise I think there are a few things that could be done on the back end. Bundle CSS and JS requests for example... If we are calling add-on JS variables and loading them inline or as file links, why not offer the option of combining them in a bundled request to save on round trips? CSS wise, it would be great to have a function for add-ons, similar to the global $jscript

What about base64 encoding - Save HTTP requests, avoids adding to object overhead

Save concurrent thread - browsers default to two simultaneous connections per hostname,HTTPS requests are simplified and performance improved

While it can larger than the binary image, use of gzip makes it minimal. The saving of server request vs actual html data size with compression might be a worthy trade off. Within reasonable limits of use.

Personally I have no use for the {load_ORjs} shy of when I am loading add-ons. However, it is pretty much a given there will be some add-ons loaded on the majority of OR sites.

The short of it is, I am suggesting the core code and anything that may be rendered as html, inline css, inline js or linked files in use of OR front end and even back end be minified.

Noted on the source code view: I must have updated the page outside of it.

photo Employee
1

You are free to bundle or combine or minify any CSS and JS in your templates you wish. Using the {load_js} and the new {load_ORjs} tags or the CSS included with OR has always been optional. The example templates need them, but they are just examples. Lots of developers skip using any of the example template materials altogether. I don't otherwise know what you mean by "save on round trips" please provide specific examples of where this is occurring.

You can in fact already use the $jscript global var to contain CSS. Whatever gets appended or substituted to that var is inserted into the <head>. You are also free to minify any of that content should you choose.

I still do not understand what want to do with base64 encoding, or what "Save concurrent thread " means in the very limited context you are using. Please provide a specific, detailed example of what you want to achieve if possible and maybe I can comment further or direct you to an existing solution.

You basically want to minify "all the things". What specific html, inline css or linked files related to the OR front-end (public areas) would you like to be minified? You are already in control of what library files you link to in your templates (I am unaware of any OR uses internally), and if there is inline CSS in the program core (not the templates) that you can identify, I have no doubt it will be removed.

The short of it: Please if possible be less general, and much more specific when suggesting improvements and provide specific examples when possible.

photo
1

michael shirley wrote:

A/B (sometimes A/C) rating on my clients site now. Working to improve this more. Switching to the new template tag, dropping the forced load of jquery really helps. (Shared host) Yes TTFB is high in the scoring, as is the number of server requests... I think the latter should be looked at for any future updates. Just going to toss it out there for thought, argument and review... Base64 encoding? Yes I know there are cases for and against it's use and times it is not appropriate, external images...

...

Testing the above suggestions I've found an savings from 8-15% on many of my pages.

Hi Michael,

Have you gone down the path of using a CDN for assets?

I'm looking at the practical implementation of this...

Listing images being the biggest one.

Cheers.

Leave Comment

photo

Attach files...

The file must be a jpg, gif, png, bmp, ico, pdf, doc, rtf, txt, zip or rar no more than 20M