reducing .css and .js requests in future SE versions?

  • gs
    • 857 posts
    August 22, 2017 12:19 PM EDT

    I wasn't sure if this should be here or in FRs, but since I don't know exactly the cause of the issue or how to resolve it, I thought I'd post here.

    Yesterday I was comparing page load performance between SE Demo and my site, and was impressed with both (although very different due to my site having 130+ Plugins and 5 3rd-Party Cores).  But typical page loads (limited by my laptop, bandwidth, etc.) were around 1 sec for SE (give or take a few hundredths), and 2-4 sec for my site.  Phenomenal for SE, acceptable (IMHO) for my site, considering #Plugins/Cores.

    One thing though that stood out was the #http requests.  Many SE pages were around 30ish, whereas most of my site pages were 100-200 (yes I may be loading more content, but not enough for a huge # of http requests, based on what I'm seeing in Chrome).  That alone will explain some of the page load time descrepancy.  But this is what got me thinking: Many of my pages have 50+/.js requests, and 20+/.css requests.  Many of these seem redundant (i.e. multiple Devs accessing their own FontAwesome file for example).  BTW - I am using an excellent Minifier Plugin by SEAO which has helped tremendously in this regard.

    All of that to ask this ....

    Although I've read some comments about the possibility of eliminating 3rd-Party Cores (again, possibility - I am not asking about this specifically in this post), what I'm asking about in this post is: is SE considering a plan to reduce the # .css/.js requests, especially when it seems (again, it 'seems' - I'm no expert) that much of it may be redundant?

    Again, I'm not asking about the elimination of Cores (unless that discussion will impact the issue in this ticket in a huge positive way), nor am I asking about how to speed up things by using a CDN (which is in my plans), nor am I asking about using another 'better/faster' host (I'm very happy with mine).  I'm addressing how to reduce .js/.css requests.  Just the sheer magnitude of 5-7x the # http requests is enough to cause longer page loads; heck - the number of .js+.css files loaded on most (all?) pages of my site exceeds the total # of requests for everything on SE Demo site page by around 100% (i.e. total .js/.css on my site = 70, total ALL requests on SE Demo = 31).

    This could all be caused (complete guess on my part) due to each Dev making sure they're loading 'stuff' they need, rather than relying on an integration with something in SE Core.  Sortof a sloppy way of doing things, but probably necessary (like a bunch of people bringing their own paint supplies to a painting party, just to be sure they have a roller & pan because either the host doesn't have the supplies already, or they aren't sure if the host does). 

     

    So, all of that to ask: Does SE have any specific plans for future versions to address reducing .js/.css requests somehow?

     


    This post was edited by gs at August 22, 2017 12:25 PM EDT
    • Moderator
    • 6923 posts
    August 22, 2017 1:48 PM EDT

    Even if we did reduce it, that wouldn't help your issue. You show in your post that your requests are 100% over the SE demo. The assumption is that it's caused by having all of those plugins and them not being optimized. SE will be making improvements in future releases but we can't do anything with third party products. This is where all clients should be knocking on the door of experts to get them to improve things. Even now, apparently, there needs to be improvement from them since you have such an issue. 

    Many SE pages were around 30ish, whereas most of my site pages were 100-200 

    the number of .js+.css files loaded on most (all?) pages of my site exceeds the total # of requests for everything on SE Demo site page by around 100% (i.e. total .js/.css on my site = 70, total ALL requests on SE Demo = 31).

    I can't say what improvements will come, just that we do intend on making improvements. We hope that third party experts will view this thread and perhaps see it as good constructive feedback in order to improve their plugins now and also when we improve things in the SE script. 

    Thanks for your post.

     

  • gs
    • 857 posts
    August 22, 2017 2:08 PM EDT

    Thanks Donna.

    ==>"SE will be making improvements in future releases but we can't do anything with third party products."

    What I was getting at is if SE would be including/developing libraries (or whatever) Devs can integrate with, since 'stuff will exist' in those that can be shared, rather than each Dev providing what seems like duplication, primarily because they probably have no choice because they have to make sure certain things exist that they need.  I might be barking up the wrong tree as I'm not familiar with SEPHP coding, thus my other software experience/knowledge may be of no use here.

    • Moderator
    • 6923 posts
    August 23, 2017 5:44 AM EDT

    I guess if we knew some things that all or most experts use, it might be possible to consider that. However, it would mean that clients who don't need it would be loading it. It would be better if experts could tie in to what we use and find a way to use that. It's a good idea that does bear consideration and thought.

  • gs
    • 857 posts
    August 23, 2017 2:39 PM EDT

    I guess this may be another of those items that could be part of an 'Advanced' ADMINcp that I've discussed in FRs.  I'd be happy to spend a few hundred$ on an Advanced ADMINcp (depending on the functionality of course).  After all, I already purchased the Advanced instead of Essentials and don't use any of the Modules in Advanced (in fact, other than SE Core, I only use the Photo Albums Module in Essentials). 

    • 629 posts
    September 9, 2017 3:28 AM EDT

    I'm going to tell you this based on experience.

    Third party developers make some code a site wide occurrence on every page load. This cannot be helped, and it is shameful. It isn't just core, it's stuff that doesn't need to be loaded. Such as language editor code, and tons of unnecessary scripts and css files not related to any widget.

    Having said this, widgets take up the majority of all loading problems. The more data it has to fetch from the database, it does so by validating each network round trip currently for each request. So instead of making one database call via cache to complete a request, it has to check to seeif the files exist before loading them, before interpreting their data and then redoing the cycle all over again until all the data is loaded. Each time this happens, a singular request is used to make it happen because of the Zend templating engine. It absolutely sucks but there you have it, the reason why se4 functions great but has the performance of something worse than Facebook based on a single person viewing one page at a time.

    \The only way to fix this is to find a different templating engine.

  • gs
    • 857 posts
    September 9, 2017 3:35 PM EDT

    ==>"Third party developers make some code a site wide occurrence on every page load."

    Yep - that's what it seems the more I test this.  But I can see why - it's easier than building in controls to check for what to load.  If it's always loaded, then it's guaranteed (within reason) to be available. 

     

    ==>"..widgets take up the majority of all loading problems. The more data it has to fetch from the database, ..."

    That may be true for some sites, but on mine I can see the time it takes to load 50+ .css/.js files, and when subtracted from the total page load time, the rest of everything else is almost negligible. The SEAO Minify Plugin I use definitely helps a lot thank goodness.

     

    ==>"\The only way to fix this is to find a different templating engine."

    My hope is they can come up with a better alternative, such as a 3PD checking for what to load first (obviously if the time to check is negligible).  Maybe as some 3PDs start recoding using LESS, they may revisit this and integrate a better method (for .css at least, if not for .js) to determine what to load rather than loading 'it all every time'.