CSS question...or disappointment

[Dll]

30 minutes ago, Adlago said:

Last night I went to work and built a new theme of mine based on 4.7.
In this theme I introduced my customizations in the accessible CSS.
Test scores - 100 points for desktop and an appalling 55-60 for mobile.
It is clear that IPS developers work actively only for desktop, and as it can be seen from tests on this site - they do nothing at all for mobile.
Given that they have neglected mobile, what is the point of preventing users from seeking their own solutions for mobile enhancements for their users...
I understand that IPS have ideas for modernization, but on a well-functioning version, to off the "fuel tank" because you want a motor to run on electricity is tantamount to a disaster...

I've already demonstrated to you that you don't need to do whatever customisations you're doing for your own site / selling to others isn't necessary to achieve good speed , ux and core web vitals scores on mobile. So, it seems as if you're being deliberately disingenuous there.

 

[Adlago]

@opentype Thanks for your opinion and criticism. I appreciate it.
To be fair - I'm using one of your plugins. I've never had an issue with it - it works perfectly on both desktop and mobile, for which I can only thank you - you're doing an excellent job.

3 minutes ago, Dll said:

So, it seems as if you're being deliberately disingenuous there.

On the contrary, I always write what I think. And how you perceive my thoughts is your right.

[Dll]

29 minutes ago, Adlago said:

On the contrary, I always write what I think. And how you perceive my thoughts is your right.

But what you've written there is clearly ignoring the facts and on top of that you're throwing unfounded accusations around. It's not reasonable behaviour.

Going back to the original point I've been trying to make though, take your own site as an example. I'm sure it scores very well, but I assume in order to better those scores you're using very low resolution images on there. Is that better or worse for the user?

Edited July 8, 2022 by Dll

[Matt]

I completely understand your position @Adlago. You are a power user with a very focused goal of attaining the highest possible pagespeed/CWV/lighthouse scores possible. This means spending days and weeks optimising CSS, JS, etc often making large amounts of changes and sacrifices to achieve your goal of a good rating from a brief audit with an automated tool.

That is what you want to do, and I understand that.

From my position, we want to deliver a very broad community platform that is capable of being used by a vast and diverse array of communities.

For example, these are both Invision Communities running the same major version.

 

Both of these websites use our base CSS. Now, if you wanted to make the Squarespace one super fast, you'd go in and remove virtually anything that is a colour, remove loads of the ipsBadge classes you won't need, all the various type styles and so on and save hundreds of bytes in the process. However, you could not then take that optimised CSS and make it work for the second example which has different needs.

My point here is that we cannot really create a very optimised set of CSS files for every potential community. What we want to do is overhaul the CSS to produce a much smaller footprint and be much more extensible but we don't have a magic wand. We have a finite number of developers with a growing list of things to do. Overhauling CSS means essentially starting a new theme from scratch and that means booking out our UI team for months.

Project planning is tough, but it's on the list to do.

[Adlago]

47 minutes ago, Matt said:

Both of these websites use our base CSS. Now, if you wanted to make the Squarespace one super fast, you'd go in and remove virtually anything that is a colour, remove loads of the ipsBadge classes you won't need, all the various type styles and so on and save hundreds of bytes in the process. However, you could not then take that optimised CSS and make it work for the second example which has different needs.

My point here is that we cannot really create a very optimised set of CSS files for every potential community. What we want to do is overhaul the CSS to produce a much smaller footprint and be much more extensible but we don't have a magic wand. We have a finite number of developers with a growing list of things to do. Overhauling CSS means essentially starting a new theme from scratch and that means booking out our UI team for months.

Project planning is tough, but it's on the list to do.

I understand your priority. I regret and apologize to you and the community here, for some of my harsher remarks.
What you have decided is a good idea, but my analyzes show that over 90-92% of css framework are unused initial loading of the home page, and also on pages for which the site owner has priorities for his users.
This is the basis of my last project that I was working on and yes, when all the used css rules are loaded in a quick file, such as custom css (one request only), while all other css rules are loaded as before - it no need for additional critical css. Of course, using such a practice requires direct access editing CSS.
Anyway, I was on the final stretch of my project and it's already been trashed...
I will look for other solutions...

[Matt]

4 minutes ago, Adlago said:

What you have decided is a good idea, but my analyzes show that over 90-92% of css framework are unused

It's quite tricky because we do have a lot of styles that could be potentially used, but are often not until a widget is added, for example. Tying specific styles to specific widgets is quite difficult.

However, we acknowledge that our CSS could be rebuilt and be more efficient. It's something we really want to fix.

[Adlago]

14 minutes ago, Matt said:

It's quite tricky because we do have a lot of styles that could be potentially used, but are often not until a widget is added, for example. Tying specific styles to specific widgets is quite difficult.

However, we acknowledge that our CSS could be rebuilt and be more efficient. It's something we really want to fix.

That is why I also wrote that the optimization process is individual, because each site uses different resources. I tried some time ago to derive generally valid content CSS rules... But after going into serious details, I became convinced that this is impossible.
Maybe if you create a basic css framework, with the most used rules, and have that file loaded via CDN with a single request, and all the rest of the css content in an install package, it will speed up mobile especially.

[sadams101]

4 hours ago, Matt said:

It's quite tricky because we do have a lot of styles that could be potentially used, but are often not until a widget is added, for example. Tying specific styles to specific widgets is quite difficult.

However, we acknowledge that our CSS could be rebuilt and be more efficient. It's something we really want to fix.

For years IPB has promised site speed increases, and every one that you've delivered to date has turned out to be too little, too late--at least for anyone who is concerned at all about their Google rankings.

Here is a speed test of this very forum thread--and you use CDN with zero ads running--you score a 51%, which is an F for FAILURE:

 

After mostly CSS changes made with the ability to edit CSS files directly--the feature you just took away from everyone (and with the help of @Adlago), here is a similar forum thread on my site--I have no CDN and am running a large number of graphical ads:

What you see here is a site with mostly CSS changes, and it scores 25% faster than a site that is on a CDN with no ads. How is that possible? Perhaps you need to hire @Adlago because apparently speed improvements are still not on your radar, and now you've gone out of your way to strip the ability for those of us who actually care about this issue to be able to do something about it ourselves.

[Matt]

I like to think of it as F for Fantastic. 
 

Complex layouts with user generated content on a platform that can manage text (forums) as well as gallery (large images) will never get an A from those automated tools. 
 

As I’ve mentioned multiple times, I can optimise the CSS for this site but it would break your theme. We want to reduce the footprint of our framework CSS but it is not a simple undertaking and will break every single theme on every single Invision community. 

[sadams101]

Hopefully you realize that your "Fantastic" means that most of your "beautiful" complex layouts on your customer's sites will never make it to first page Google results because they have a boat anchor tied around their necks, from which they cannot escape--thus their hard work, articles, posts, etc., will sink to page 5...10...20...who knows how low? The longer you fail to address this, the more weight Google will put on sites with such speed issues, because that is what Google does.

Also, you didn't address the real issue here, which is stripping away my ability to do this myself--so far in this thread none of the arguments for doing this are convincing--why not allow users who want to do this to be able to continue editing their CSS? 

Edited July 8, 2022 by sadams101

[Dll]

Errm, not wanting to spoil the snake-oil style sales pitch here. But, if you want to go and do some research, you'll find plenty of Invision based communities and websites doing very well in google. 

It's the core web vitals which can potentially have an affect on rankings due to the fact they measure things which affect user experience, and even in the apparently terrible example you posted for this site, they pass. 

Edited July 8, 2022 by Dll

[Balto]

On 7/6/2022 at 9:42 PM, Jim M said:

direct editing of our core CSS

Hello Jim,

 

what is exactly the "core CSS"? I mean, where could I find that in 4.6 version? Thanks!

[Jim M]

13 minutes ago, Balto said:

Hello Jim,

 

what is exactly the "core CSS"? I mean, where could I find that in 4.6 version? Thanks!

"Core CSS" refers to our CSS in themes. These are the files not added by yourself or your theme's author. 

[Matt]

As Dll has said, even with the example which shows 51% clearly passes all core web vitals which means it’s very unlikely Google will penalise you.

Pagespeed is an important metric but it is not the only metric.

As I keep mentioning, we want to rewrite our CSS to make it have a smaller footprint. It is going to take time. 

[marklcfc]

4 hours ago, sadams101 said:

For years IPB has promised site speed increases, and every one that you've delivered to date has turned out to be too little, too late--at least for anyone who is concerned at all about their Google rankings.

 

4.6.6 saw the only noticeable speed increase for me, I'd had issues for many years which were finally fixed in that release. I still have no idea what it was but I hope they never revert it as my site has ran as I always wanted it to since 😀

Edited July 8, 2022 by marklcfc

[nodle]

5 hours ago, Matt said:

As I keep mentioning, we want to rewrite our CSS to make it have a smaller footprint. It is going to take time. 

[sadams101]

On 7/8/2022 at 11:05 AM, Dll said:

Errm, not wanting to spoil the snake-oil style sales pitch here. But, if you want to go and do some research, you'll find plenty of Invision based communities and websites doing very well in google. 

It's the core web vitals which can potentially have an affect on rankings due to the fact they measure things which affect user experience, and even in the apparently terrible example you posted for this site, they pass. 

I have no doubt that some Invision communities are doing "very well" in Google. Some might even say that my site is one of those, however, I can assure you that I've gained at least at least 100,000 in my USA rank (now around 50,000) after dealing with the many speed and SEO issues inherent in the out of the box version of this software. This is a huge difference, and in my case represented the difference between ~100,000 unique monthly visitors before, and ~350,000 after.

So my question to you is, could those communities that are now doing "well" actually be doing a hell of a lot better? Yes.

[Dll]

11 hours ago, sadams101 said:

I have no doubt that some Invision communities are doing "very well" in Google. Some might even say that my site is one of those, however, I can assure you that I've gained at least at least 100,000 in my USA rank (now around 50,000) after dealing with the many speed and SEO issues inherent in the out of the box version of this software. This is a huge difference, and in my case represented the difference between ~100,000 unique monthly visitors before, and ~350,000 after.

So my question to you is, could those communities that are now doing "well" actually be doing a hell of a lot better? Yes.

I think you're misunderstanding a little in terms of how speed and google rankings relate. Although Google have never given a definitive answer (to my knowledge), the current consensus is that as long as you pass the core web vitals tests, then speed won't be a negative factor. So, once you do pass them, you're not going to gain anything in that respect by spending more time trying to get additional small gains in speed. 

Out of the box, assuming it's hosted on reasonable servers which are appropriately resourced for the traffic the community receives, and assuming there are no modifications causing issues, from what I've seen at least, Invision's software passes the core web vitals tests. 

So, for the vast majority of sites, that's great. If your hosting isn't great, or you have a bunch of modifications which slow things down, then you may need some extra help to pass the core web vitals test. Perhaps you were in that boat, who knows. But, personally I'd still recommend you and others in a similar position look first at the root causes of any specific problems you're having and dealing with those. Going to great lengths to minimise the css is more like a sticking plaster and a time consuming one at that. 

Edited July 12, 2022 by Dll

[opentype]

As I pointed out in (rather frustrating) debates years ago: someone doesn’t understand the post-hoc-ergo-propter-hoc fallacy. Doing X and seeing Y afterwards doesn’t mean that X caused Y. It’s why millions believe in homeopathy, and it’s why some admins believe whatever they happen to do on their website must have caused the ranking changes they saw in the following months. But unless the causal connection is demonstrated, it is not reasonable to accept that connection. Arguments based on that fallacy can and should be dismissed and discussions using such flawed arguments as a premise will usually end up being a waste of time. 

[sadams101]

I understand that IPB is unable or unwilling to deliver proper site speed, which is why I and others have handled this on our own. This thread, as you may recall, was created because you've now stripped those of us who actually care about this issue of the ability to upgrade our sites on our own and make them faster...why would you do this? So far I've not gotten a reasonable response about why you've stripped away the ability to edit all CSS from those who use that tool. What is next, stripping out ability to modify the templates?

[Marc]

13 hours ago, sadams101 said:

I understand that IPB is unable or unwilling to deliver proper site speed......

This comment is actually incorrect. I'm assuming you may have missed one of the comments above there, as my colleague did actually say specifically above a few times.

On 7/8/2022 at 8:26 PM, Matt said:

As I keep mentioning, we want to rewrite our CSS to make it have a smaller footprint. It is going to take time.

 

[Matt]

14 hours ago, sadams101 said:

I understand that IPB is unable or unwilling to deliver proper site speed, which is why I and others have handled this on our own. This thread, as you may recall, was created because you've now stripped those of us who actually care about this issue of the ability to upgrade our sites on our own and make them faster...why would you do this? So far I've not gotten a reasonable response about why you've stripped away the ability to edit all CSS from those who use that tool. What is next, stripping out ability to modify the templates?

I think we need to be careful when using terms like "proper" as a yardstick to compare us against. I would consider that Google is an authority on what it considers a proper, or acceptable page speed, and our core web vitals pass. I would consider that we do deliver a proper page speed.

What you are asking for is advanced tools to shift an acceptable or proper speed into a very fast speed, way above what is required for ranking purposes.

You still have designer's mode if you want to tear down our CSS and rebuild it yourself. It's just not a task that 99.9% of our customers are going to do.

We have said multiple times that rebuilding our CSS is on our engineering list but software development is hard. We have a finite team with finite time with a long list of things to do. We need to balance maintenance with developing new features and re-engineering old parts of the framework. We have feature lists and back logs and a forum full of clients who ask for new features they need. This is a sign of a healthy software product. It'd be awful if no one cared enough to tell us what they need. But I would ask you to consider the needs of all our clients who express themselves here, then plan out roughly how long each thing would take and then consider what is essential today, tomorrow or in the future. Rebuilding our CSS and JS frameworks is easily a 6-9 month project that will disrupt all themes, plugins, apps and so on.  It means that we need to have a subset of our development team out of action. I would say that we should really focus that energy on getting gallery, calendar, commerce and incrementally Pages improved first.

[Chris Anderson]

2 hours ago, Matt said:

we should really focus that energy on getting gallery, calendar, commerce and incrementally Pages improved first.

Wouldn't it be easier on your staff, third-party developers and customers to improve upon CSS in a phased approach?

Why not break down the CSS Project into sub-projects? 

One sub-project you concentrate your attention on commerce.  You develop the "new" features you want to offer for that module while addressing any appropriate CSS changes needed.  You concentrate many IPS developer's and testers eyes on just that section of your overall codebase.

By concentrating "lots" of eyes on "one" module of the suite you will make it easier to identify any underlying performance, security problems or bugs. At the end of such a CSS sub project, you will end up with a much better underlying codebase then trying to tackle the entire suite all at once. Once that CSS sub project is "golden" you move on to the next sub-project

Upon release of the "CSS Project - Sub Project X" the third-party developers, theme designers and your customer base only have to make appropriate changes to "one" section of the IPS suite not the entire suite. 

By adopting a more phased approach you will significantly lighten the load and make it much less stressful on your third-party developers, theme designers and your customer base.

[Matt]

Yes, we have indeed considered this both for CSS and JS. It's probable we'll do something like that but it won't really solve anything until the build is completed as you'll be loading two frameworks, the old and the new so the timeframe remains true.

[Chris Anderson]

37 minutes ago, Matt said:

the timeframe remains true.

If you are selling your house, you want to get the best possible price. If you place lots of ads in the newspaper and social media and have loads of people show up, you are NOT guaranteed the best price if your house "looks" undervalued.

The CSS Project is akin to advertising and the continued improvement of the suite will go a long way towards upping the site's overall perceived value.  Also known as "curb appeal".

It doesn't do us much good having lots of folks knock on our door if they immediately walk away to check out one of the other bright and shiny houses down the street.