Matt

This should be fixed in the next beta.

Just as a note to future readers of this topic, the issue looks to be by the Elastisearch provider not allowing access to the task and update by query APIs. If you get any odd issues with multiple entries where there shouldn't be in streams, it's almost always update by query not working or being blocked by the host.

Don't say it. Don't say it. Don't say it. Don't say it. Don't say it.

It looks like you are experiencing a MySQL problem. Get in touch with your host and see if they are aware of any issues. A missing table is not a good sign, so it's worth investigating the cause of that.

That looks to be the History.js jQuery plug-in we use. We can possibly do without it in the near future.

Yes, I like the idea of notifying someone when a topic is viewed a lot.

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.