I don't know about you, but I'm wondering if it's perhaps overdue that IPS got stuck into a huge performance and speed based review and implement it in the next medium sized update! I think a lot has changed in recent years in relation to site performance. Core Vitals in Lighthouse as many admins will be aware are now much more important in terms of SEO ranking, performance isn't just for the obsessed enthusiasts any longer!

Google Search Console tells me that on one of my IPS Communities, my Mobile Pagespeed test result sucks, just 28%-30% at present, so I started checking a few things under the hood. I like to keep my sites high performing, so I was quite surprised it was so low. 

One thing I found out in minutes looking at the optimisation list and then checking my IPS configuration is that if you have the IPS Lazy Loading feature enabled, it doesn't apply to your uploaded images in Advertisements or Post Author Member Group Icons. Both are shown in my topic view so I get scored down on mobile in particular.

I think it's now time that Native Lazy Loading was offered, either as a choice or as the default if enabled.
Also where possible IPS should support Local WebP conversion via the Task Manager.

I know some of us sometimes bash IPS for not delivering more obvious updates like Gallery, Blog, Pages and Commerce improvements for the sake of instead quick things like disabling features but IPS4 is quite a huge behemoth these days, no matter your pricey VPS, CiC, use of Redis pools etc.

More performance improvements I'd like to see considered include...

(Now admittedly I'm basing this list on a similar big audit that another website framework I invested in conducted and implemented last year. These are the options you can now simply toggle off/on as a result in their Dashboard. They can make a huge difference to bloat.)

Dynamic Modular Framework

Enable this to allow the IPS Framework to only load code that are actually used on the page, and process the logic for the features in actual use.

Dynamic CSS

Dynamic CSS could greatly reduce CSS file size by dynamically generating only the styles and assets necessary for the features and modules you actually use. This eliminates most if not all CSS file bloat and greatly improves load times.

Dynamic Icons

Font Awesome is 2 generations behind. The FA4 icon font could be broken up into various subsets. These subsets are loaded only when needed based on the modules and features used on each page. If you need access to the entire icon font on all pages (for example, if you are using lots of FA icons in a custom theme or want to allow members to insert them via the post editor), then you could disable this option and load the entire icon font library on all pages.

Load Dynamic Stylesheet In-line

This option dequeues the IPS style.css file and prints the needed contents in-line. This removes a render blocking request and improves the PageSpeed scores of individual pages. However, it also prevents the style.css file from being cached. Since the stylesheet is often smaller when dynamic or critical, it could be recommended to keep this option enabled. Accepted there are some potential CSP-related security concerns with inline CSS an or JS.

Critical CSS

Critical CSS greatly improves website load times and Google PageSpeed scores by deferring non-critical styles and eliminating render-blocking CSS requests. Critical CSS often covers what most users see when first loading the page, so called 'above the fold' content.

Critical Threshold Height

When Critical CSS is enabled, IPS would determine an "above the fold threshold" and defer all styles for elements below the fold. However, this threshold is just a estimate and can vary on different devices. Increasing threshold height will deffer fewer styles, resulting in slightly slower load times but less of a chance for Cumulative Layout Shifts to occur. If you are experiencing CLS issues you can then increase or lower the threshold 'height' via a drop-down low, medium, high setting.

Dynamic JavaScript Libraries

When enabled, IPS would only load external JavaScript libraries when they are needed by a specific sections or modules on the page. This removes unused JavaScript from the main scripts bundle and improves load times.

Improve Google Fonts Loading

Enable caching of Google Fonts and load them inline. This reduces render-blocking requests and improves page load times. Also presents an opportunity to switch to the Google Fonts API, to offer a dynamic dropdown list to allow admin to choose from all available GFonts. The Task Manager could check for and cache new versions of selected fonts in use weekly.

Limit Google Fonts Support For Legacy Browsers

Enabling this option will lower the size of Google Fonts and improve load times, however it will limit Google Fonts support in some very old browsers. You can turn this off to increase support for losers insisting on their older insecure browsers at a slight cost to performance.

Defer jQuery And jQuery Migrate

When possible, jQuery and jQuery Migrate could be moved to the body to speed up load times. If a third party plugin registers jQuery as a dependency, it would be moved back to the head.

Enqueue jQuery Compatibility Script

Some third party scripts may be incorrectly enqueued without declaring jQuery as dependency. If jQuery is deferred, these scripts could break. If you are experiencing console errors after enabling the "Defer jQuery And jQuery Migrate" option, you can enable this option, which will load an additional compatibility script that will attempt to solve the issue. (You can turn this feature off if everything is working fine without it).

Defer Additional Third Party Scripts

Warning: This can cause JavaScript errors in some cases and should be used with care. When enabled, scripts registered by plugins and themes will be deferred to improve performance and jQuery will always be loaded in the body.

Add official NGINX support to the list 😂😅

On 6/26/2022 at 11:15 PM, The Old Man said:

I don't know about you, but I'm wondering if it's perhaps overdue that IPS got stuck into a huge performance and speed based review and implement it in the next medium sized update!

Yes, it has been stuck for several years.

Any official position?

Yes, we're going to look at some of this for v5.

I have been curious if having multiple back end databases would also improve performance? Putting Schema content in to one file and then user added content in another file? 

47 minutes ago, Ocean West said:

I have been curious if having multiple back end databases would also improve performance? Putting Schema content in to one file and then user added content in another file? 

I'm not sure I follow.

Outside of the odd errant query, databases aren't really a bottleneck, especially in terms of page speed.

I don't know the performance barriers to SQL databases but my thought was more a separation of concerns. Would it be better to have separate DB file for say all marketplace apps? vs modifying core files? I am sure I have database detritus of columns from old stuff that just keeps hanging around. 

What do you mean by "DB file" in this context?

I think he’s asking to have the ability to separate marketplace and possibly pages DBs into a separate MySQL dbs.  That it is perceived as less risk to have them separated… not that it would improve performance. 

That would probably slow things down as you need to keep multiple DB connections open and less chance of using joins, etc.

I would specifically request that optimizations be made to the getItemsWithPermission() function
Seems like all things and kitchen sink at the moment. Perhaps there is opportunity for SQL optimizations here?
Queries relating to this function are currently the slowest on my site. they regularly show in my slow query log.

Edited March 1, 20231 yr by SJ77