Jump to content

Recommended Posts

Posted

After re-reading all Google blog posts on site speed as a ranking factor there is zero evidence that they are using a simple pass/fail for their core web vitals in their algorithm (perhaps they were initially when they first began ranking for site speed), and there is a lot of evidence from SEO companies who study this in great detail and compare thousands of Web sites and their rankings that they are indeed using the 0-100 score as a ranking factor. 

Why would Google's speed tools go into incredible detail and provide 6 separate speed categories with tons of links for how to fix each speed issue that your site has if they were not incorporating such things directly in their algorithm for ranking? Why do you think they use the standard red, yellow and green rankings for each of these categories?

Google has clearly spent a great deal of time creating tools to help you speed up your site incrementally, 1% at a time, and according to SEO companies like SEM Rush and others, every little bit of speed gained will help increase your rankings. In fact, I've never seen an article on site speed ranking from a reputable SEO company that says that all you need to do is pass the core web vitals--51% is fine, and you don't need to aim for a 90% or higher score. 

  • Management
Posted

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.

Posted

Page speed aside, there was really no need to remove the core CSS from the templates. I agree that most users do not need it so they would of course simply ignore it; but the ones that do need it had the option to view, understand, learn and modify if they wanted to.

CSS is basically harmless and any issue that may come up we could just restore the file to the original version so this shouldn't strain IPS support.

Basically: us self-hosters are already getting hammered with the cloud only features. There's no need to remove features too now.

Posted
57 minutes ago, David.. said:

Page speed aside, there was really no need to remove the core CSS from the templates. I agree that most users do not need it so they would of course simply ignore it; but the ones that do need it had the option to view, understand, learn and modify if they wanted to.

CSS is basically harmless and any issue that may come up we could just restore the file to the original version so this shouldn't strain IPS support.

Basically: us self-hosters are already getting hammered with the cloud only features. There's no need to remove features too now.

The ones who need them are actually the minority of users. These however can still be edited in designer mode as mentioned by Matt. 

I would say, with regards CSS being harmless, and people being able to restore, you are referring to yourself as a user here, and not the majority. While we do provide tools to revert templates, and even to check on default themes without doing that, people tend to post a topic/ticket on these things in the first instance. Something being harmless really depends on context. What is harmless to you, may be harmless to others. One person missing all the CSS on the front end and posting a ticket, is another persons "Its probably cache, so I cleared that and it was fixed in a second".

Posted
21 minutes ago, Marc Stridgen said:

While we do provide tools to revert templates, and even to check on default themes without doing that, people tend to post a topic/ticket on these things in the first instance.

I’m sure they do; but that’s when IPS can simply have an automated reply at the ready or even a tutorial link to resolve. So really it shouldn’t strain support at all and increase overall user satisfaction even though it is a trivial issue.

26 minutes ago, Marc Stridgen said:

The ones who need them are actually the minority of users. These however can still be edited in designer mode as mentioned by Matt.

Designer mode is recommended to use on a test install. While that may work, it is an extra step which realistically feels like only expert theme designers use.

4.7.0 did introduce an easier way of adding CSS which is great for newbies, but again, I don’t see why there was a need to remove the intermediate option.

It was a very convenient way of playing around with (a copy of) your theme.

  • 2 weeks later...
Posted
On 7/8/2022 at 11:42 AM, Matt said:

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.

 

On 7/8/2022 at 6:36 PM, Matt said:

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.

Great to see its kind of on the to do list. I posted about this in a different topic here,

and I still believe a system task/s used to create dynamic templates would address a lot of these one-size doesn't fit all related issues in terms of critical CSS and optimised CSS.

The current custom lazy loading approach is a quick fix (to switch to use the widely adopted and simple loading='lazy' tag and either remove or switch the current but clunky method to optionally support legacy browsers that doesn't support the loading tag). Similarly image optimisation in terms of system task-based Local WebP generation on servers that support it by having the relevant libraries available.

Actually, thinking about it, that presents a timely opportunity to address the heinous issue of IPS deleting original uploaded image resources after copying them to AWS S3; that's really bad practice unless the admin opts in to transferring to save storage space. Retaining your media library should be the default.

...

It quite annoys me when the proverbial we/I contribute to the bottomless pit known as the IPS feedback forum and never receive an IPS Team response, of any fashion. I'm not talking about just obscure or niche requests for individual sites, some relate to form accessibility improvements, oversights like referring to font weights in CSS that have never been called in the HTML etc.

A topic in a client feedback forum should NEVER go unanswered or unacknowledged. A person in the IPS team should be tasked with monitoring your feedback forum to at least acknowledge feedback or requests and then flag them back to your relevant team.

  • Management
Posted
20 hours ago, The Old Man said:

A topic in a client feedback forum should NEVER go unanswered or unacknowledged. A person in the IPS team should be tasked with monitoring your feedback forum to at least acknowledge feedback or requests and then flag them back to your relevant team.

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

  • 1 month later...
Posted (edited)
On 7/7/2022 at 9:08 AM, Matt said:

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.

This sound like a preparation of taking a control of self-hosted solutions and eventually enforcing whatever you think of 😞

Watching your other moves around cloud based solutions I started to have worries about upcoming future.

Edited by PatrickRQ
  • Management
Posted

Not at all, just trying to keep our platform moving in the correct direction. We would be doing the same as any other modern platform.

Posted

Your reasoning behind not allowing to edit core CSS does make sense, but can we at least view the CSS files? I’m not even sure how to create a theme anymore without knowing what I’m supposed to edit?

Posted
1 hour ago, Kirill N said:

Your reasoning behind not allowing to edit core CSS does make sense, but can we at least view the CSS files? I’m not even sure how to create a theme anymore without knowing what I’m supposed to edit?

You can still use designer mode if you wish to view the files themselves.

Posted
3 minutes ago, Marc Stridgen said:

You can still use designer mode if you wish to view the files themselves.

Why can’t we just view the files in the theme editor in the AdminCP?

This change makes creating new themes 10x harder. I now pretty much have to rewrite everything that I want to customize, but that would be at least manageable if I could search for a class/id in the editor, copy the default code and paste it into custom.css. But now I need to spend 10x much time searching for the code in the files to figure out what to edit.

Posted
12 minutes ago, greek_parea said:

how find ccs for plugin?

You would have to let us know more what you mean here. If you are referring to CSS specifically a a plugin you have, it would be in the same place as any other CSS. You would need designer mode if you wish to view all CSS

Posted
On 8/30/2022 at 5:47 PM, Matt said:

Not at all, just trying to keep our platform moving in the correct direction. We would be doing the same as any other modern platform.

The problem on this platform is not CSS, but JS. Tasks too long.
I think it's a big mistake on your part to look for a CDN core for CSS for this platform. It would be better if it was JS core in CDN.
Let the CSS be as before - editable, also every CSS file has a revert function - ie. even if someone messes up the site's css, it's easiest to post a message - use a Revert and you won't have to deal with your support about it.
Consider javascript - there's the biggest TBT for mobile…

  • Management
Posted
2 minutes ago, Adlago said:

The problem on this platform is not CSS, but JS. Tasks too long.
I think it's a big mistake on your part to look for a CDN core for CSS for this platform. It would be better if it was JS core in CDN.
Let the CSS be as before - editable, also every CSS file has a revert function - ie. even if someone messes up the site's css, it's easiest to post a message - use a Revert and you won't have to deal with your support about it.
Consider javascript - there's the biggest TBT for mobile…

Indeed we are! We have plans to change how we package up JS to make it smaller and faster.

  • 3 weeks later...
Posted
6 minutes ago, Genestoy said:

Here is my problem with what was done... You also removed the "Classifieds" css from the css tab which is not a core css to my knowledge and I need to add css to that file and now I can't!

You should be adding any custom CSS to the custom.css file instead of editing the CSS distributed by other apps. You'll only give yourself headaches upgrading them in future.

Posted
On 8/31/2022 at 2:01 PM, Kirill N said:

Why can’t we just view the files in the theme editor in the AdminCP?

This change makes creating new themes 10x harder. I now pretty much have to rewrite everything that I want to customize, but that would be at least manageable if I could search for a class/id in the editor, copy the default code and paste it into custom.css. But now I need to spend 10x much time searching for the code in the files to figure out what to edit.

Absolutely agree, hiding the CSS templates is ridiculous! It was like a live, instant reference, so useful and tbh having realised, I'm unwilling to update the last of my live sites. Having to enter and exit designers mode is no good, it's slow, clunky, buggy, and you even advise us not to do it on live sites. Who in their right mind would do that when they need to make some quick changes to custom css templates or look up some css to refresh their memory?

By all means, remove edit permissions if you absolutely must, but what's the harm in leaving the templates read only and searchable?

Posted
On 9/15/2022 at 11:05 PM, Stuart Silvester said:

You should be adding any custom CSS to the custom.css file instead of editing the CSS distributed by other apps. You'll only give yourself headaches upgrading them in future.

That’s understandable but we need to be able to VIEW them to know what we are supposed to edit

Posted
9 minutes ago, Kirill N said:

That’s understandable but we need to be able to VIEW them to know what we are supposed to edit

Personally, when I'm theming or updating CSS for something on my site, I'm in the browser inspector for most of time. Looking at how the relevant rules interact with each other and determining which change I want to make to achieve my goal.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...