Excessive code produced by Muse-Theme widgets

Discussion in 'All Other Widgets' started by Chuck Braman, Feb 15, 2017.

  1. Chuck Braman

    Chuck Braman New Member

    2
    0
    The Muse-Themes widgets used on the top opening screen of my website (https://www.newwyorkjazzbands.com) generate 2700 lines of code at the opening of my index.html file. Four questions: is there presently a way the Muse-Themes team, now or at some near future date, could either (a) program their widgets to output the code to a separate javascript file (b) if not, because of the current development of Muse, persuade the Muse team the importance of making this possible in the future, or (c) if neither of these are possible, find a way to program the widgets to achieve their present functionality while producing significantly fewer lines of code, and/or (d) find a way to write the javascript code at the bottom of the file, below the html rather than above it?
     
  2. DjHerold

    DjHerold Moderator Staff Member Advisory Group

    2,740
    209
    Chuck, knowing our development team, I think the answer is slanted more towards what Muse allows today.
    But these are great questions and I'd like to suggest you ask them to the team (resources>contact us).
    Steve Harris is very well respected not only in the community, but by Adobe.
    If anyone can address this it will be him.
    Thanks
    Dj
     
  3. Steve Harris

    Steve Harris Museologist Staff Member Moderator

    212
    77
    Hey Chuck,

    Thanks for the note – just having a look here! I'll do my best to answer this, although our widgets are built by our devs (Kevin & Arifin) so I might need them to jump in.

    The 2700 or so lines of code are actually just CSS styles / properties, not HTML that's being rendered or JavaScript that's being run by the browser. Widgets that have "animation" type effects – flipping, rotating, etc – require different css properties for each different animation type. So each animation may have 5-10 different properties that are only actually used if that unique animation is selected within a widget on the site. Most users stick with a single animation type when selecting one in the panel (e.g. Flip) so any of the css included that isn't being used would just be ignored.

    Couple thoughts based on your questions / suggestions above:

    1. We could definitely have our widgets reference an external CSS file, and that's something we looked at in the past. The only issue here is that technically this might be a slower approach, because now the file has to download from an outside server before being used by the browser. Including CSS internally (within the head) is probably a faster approach. But keep in mind also CSS is very light style information, it's not excess code in the way that unnecessary html or javascript would slow down a site.

    2. Adobe could likely somehow enable outside developers to place their css in the external css files that a Muse site generates, although I doubt they would do that honestly. They would probably be too worried about developers writing conflicting css that messed with Muse site styling and sites start breaking. On a bigger site Muse can generate 1000's of lines of css itself in the external file, you just don't see it unless you view the css file itself (the link is in the head of the site).

    3. Honestly I don't think there is any way to reduce the css required to make these animations happen. It would be nice if we could somehow only load the css required for the specific animation selected, but I'm not sure how to make that happen (dev question!).

    4. Internal css can only be placed in the <head> area of a site – it's quite different from JS which can be moved to load before / after page elements, manipulate elements that have already loaded, etc.

    I actually saved this CSS out of your site, added it to an external file and checked the file size. When minified, it's about 40kb of load impact. So although it looks intimidating because it's internal and length (instead of in an external CSS file) it's not actually a terrible speed culprit. Optimizing a single .jpg using a service like JpgMini could net you 3-4x more in terms of file size savings than not including this code (and that's on one single image).

    I can appreciate you'd like the code to look tidier, but I can definitely assure you that we make every effort to write efficient, clean code using the latest standards. Technically if you wanted to remove that code you could copy everything between the opening and closing <style> tags, save it as a .css file and add a link in the head that looked like this:

    <link rel="stylesheet" type="text/css" href="css/yoursavedcss.css"/>

    Boom, 2700 lines removed. Speed gain... probably zero.

    One thing you also may want to consider is simply reducing the amount of animation widgets you're using. I can see Onload Animator, Headliner, Flipping Boxes all in this site, and those are pretty heavy widgets to be combining together. If you could reduce that down to one it would help big time. There is no way to implement animation on the web without a speed / code impact, and with these different widgets they have almost no shared elements. They all load a ton of unique style code that needs to be included. Can't comment on the other widgets from outside vendors too, but they could be contributing. Hey at least we don't stick a big logo in your source right? Ewwww... ;)

    Hope this helps! Take care.

    Steve
     
  4. Chuck Braman

    Chuck Braman New Member

    2
    0
    Hi Steve,

    Thank you very much for you detailed and very clear answers to each of my questions. I'm more than satisfied that I needn't worry about these issues anymore.

    While I have your ear, I would like to ask you a couple questions that are tangential to your comments regarding the combining of widgets.

    Now that you've shown that I don't have to be concerned with the amount of code these widgets produce affecting Google's ability to crawl the text, I don't see any problem with having a lot of widgets per se, if they each contribute to the usability of the page, which I think each of your widgets do. However, I do realize there are technical problems that can arise when combining widgets, and I am experiencing two of these right now.

    The first is that, since adding the Superhero widget to my home page, and using it to enclose the Headliner 2.0, Onload Animator, and Flipping Boxes widgets, my page no longer renders correctly on IOS, i.e., the right side of the page gets cut off: https://www.dropbox.com/s/9sjrob6kli8b0rx/IMG_0030.PNG?dl=0. (Compared to Desktop, where the functionality works just fine.)

    The second is that, since adding the Superhero widget to my home page, when I do a "Fetch and Render as Google" in Google Search Console (formerly Google Webmaster's), it shows that Google can't render or "see" the page: https://www.dropbox.com/s/93l3wkbu2eu9dkl/Screenshot 2017-02-17 13.10.01.png?dl=0

    Now, I realize that the problem is probably that I'm combining too many widgets. But I'd like to make an appeal here! That is that the Superhero widget is indispensable to the design and functionality of my home page, where I would really like to prompt and motivate visitors to make a choice and move on to another page before scrolling further down. The Superhero widget accomplishes filling the opening screen with these choices and only these choices, whatever the size of the visitors viewport. The enclosed widgets are engaging and informative, getting the visitor's attention, letting them know they've come to the right place, and what to do next. Basically, the Superhero widget's usefulness would really be increased if it could act as an "enclosing" widget, with functionality in this regard similar to how the Pushy Panes widget is able to enclose form widgets, for example.

    So my appeal is: the Superhero widget is so awesome, and so indispensable to my usage and perhaps the usage of many of your other customers, would be possible and worth the effort to consider if a 2.0 version might be coded in such a way as that it can squash this particular bug that occurs when enclosing relatively simple widgets (like the Headliner 2.0, Onload Animator, and Flipping Boxes widgets), and also coded in such a way that it does block Google from rendering the page?

    Thanks again for answering my previous question so well, and also for adding so much value to the Muse platform through your widgets.
     

Share This Page