Matt

That's fair. We do read them all, and we often discuss them but we can do better at acknowledging them.

I'm fast and because of the heat, furious.

Whoops. Just fixed it. 🙂

What version are you using? A fix was made of this issue for 4.7.0 Beta 9.

I was just working on your site and wondered why there was an upgrade process running. 😂 Glad it's resolved.

Welcome to Invision Community! There may be a short delay while our systems sync. I just checked your site and the buy now button does not appear. Hopefully this is now resolved for you.

We can probably make it 301 redirect to the top of the topic if the param value is malformed anyway. It's better than getting an error. But I'd like to see the notification email to see how the HTML is built. It may be the email client (Gmail?) that is doing it also. Can you forward one of those emails to me please? I'll PM you the address.

Thanks J, I'll look at this. That is a lot of ES activity which is wasteful.

I think we broadly agree that faster is better. I disagree that our current core web vitals are bad, or indeed contributing to poor rankings. I think we broadly agree our CSS and JS footprint needs to be lighter. The only sticking point is that I won't action it as an immediately priority. We have been discussing it again today internally. It's very much on our minds. As I mentioned previously, I have a finite team of developers and a lot of priorities. Changing all our CSS and JS will mean moving to Invision Community 5 as a version number, so we will also look at some of our engineering priorities that have been stacked up for the past 18 months. We then need to bring this whole thing together at the right time without losing pace on maintenance and support. I also think we need to keep in mind that a site with perfect core web vitals, a 100% score but with no members is worth a great deal less than a thriving community with 51% core web vitals. Likewise, a perfect 100% score does not guarantee top positioning in rankings. You need great content, backlinks and so on.

(We're investigating)

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.

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.

I'm unsure what this could be, outside of it actually parsing the HTML and setting up JS handlers, etc.

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.

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.

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.

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.

I'm hoping to have this up tomorrow.

I've released a patch so that custom CSS in other areas, and also CSS that has been edited is now visible when editing a theme.

I accept that the very few who make significant edits to our core CSS will find this change uncomfortable. The vast majority want to add or override existing CSS, so this change will not affect them. We want to get to a point where we can serve CSS from a single set of files via a CDN. We also want to overhaul and modernise our CSS for efficiency and enabling a more streamlined output from a better build process. These things do take time, and we have to take steps towards that goal, and drawing a line with 4.7.0 and asking that core CSS is not edited is the first step towards this. As a temporary measure, a template edit in core/front/global/includeCSS to remove the framework CSS and instead link to a separate directory of your own optimised CSS would enable you to carry on with your heavily optimised CSS. I can help you with this if you wanted to explore this.

That's fair. I can add this to our development documentation. I'm working on an upgrade step to resolve this. 👍

I don't understand what the issue is @Adlago? You can still edit and add custom CSS.

As mentioned above, we would prefer that the core CSS is not edited, and instead that you use the custom/ folder(s) to add your custom CSS. This gives us the option in the future to serve all CSS from a single set of CSS files on a fast CDN. There is an issue with those that *have* edited core CSS files, and I'm working on an update to solve that.

Custom theme? I do recall a mod or theme recently that used 'large' without quotes and it was treated as a constant and silently ignored previous to PHP 8. The word 'large' is not used in that default template for the userPhoto.

As of 4.7.0, only true custom CSS files will show to discourage editing framework CSS. Have you edited framework CSS files in the past?