Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add forceInclude option for :where selectors #11

Closed
wants to merge 2 commits into from

Conversation

batbattur
Copy link
Contributor

@batbattur batbattur commented May 11, 2023

Summary

For some reason, penthouse doesn't think that :where selectors are not part of the critical css.
Let's add it to the config so that it includes the :where selectors in the generated critical css.

Edit: The new regex will match selectors like the following: :where(), :has(), :not(), :host(), :root().

See https://github.com/iFixit/ifixit/pull/47766#issuecomment-1544460438 for more info.

QA notes

We can qa this on iFixit/ifixit side by running the critical.css workflow (with this branch checked out).

cc: @ianrohde @mlahargou

For some reason, penthouse doesn't think that :where selectors are not
part of the critical css. Let's add it to the config so that it includes
the :where selectors in the generated critical css.

See iFixit/ifixit#47766 (comment) for more info.
@batbattur batbattur added the QAE Quality Assurance Engineering label May 11, 2023
@batbattur batbattur self-assigned this May 11, 2023
@batbattur
Copy link
Contributor Author

critical-css.js Outdated
@@ -46,6 +46,7 @@ function findCriticalCss(cssString, url) {
height: 2160,
blockJSRequests: false,
forceExclude: excludeArr,
forceInclude: [/where/i],
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As I understand it, this is going to force including any CSS selector that matches. I think we want to be as specific as we can be here because I don't think it's necessarily the case that every use of :where() is critical CSS. Beyond that, I think /where/ is too broad as that would match selectors like .where-empty.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we want to be as specific as we can be here because I don't think it's necessarily the case that every use of :where() is critical CSS.

I agree. In the future, if we want to exclude some of the :where() uses, then we can exclude them by specifically adding to this array in our exclude array in critical.css.json config like the following: "excludes": [":where(.someSpecificSelector)"]

Beyond that, I think /where/ is too broad as that would match selectors like .where-empty.

I modified the regex to match other css features as requested in https://github.com/iFixit/ifixit/pull/47766#issuecomment-1544475631. Updated in 80656ab.

The new regex will match selectors like the following: :where(), :has(), :not(), :host(), :root().

Verified that it will not match selectors like the following: li(:last-child), .green:not(:disabled), and .card-hover:hover.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm still not convinced that this is an appropriate solution. The point of the tool is that it identifies which CSS ultimately affects above-the-fold content. We're unconditionally insisting that any of these selectors always affects above-the-fold content, which is surely false. While that may be a solution to the problem we were seeing, I think at best it's papering over some deeper issue, either with penthouse or css-gather or our styles in general.

If this fixes the problem we were seeing (CLS), then as a temporary measure I think we could add more-specific forceInclude selectors that, when omitted, cause the CLS that we're currently seeing. But as-is, this pull has the potential to add a bunch of CSS that isn't critical to our critical CSS, and that means sending more bytes than we need to on every page load because we send that CSS directly in the HTML.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not optimal, but our options are limited. Your points are all valid, but without these changes, the resets are removed entirely. That would cause major CLS on every page.

I looked at the penthouse repo and the last closed issue was about a year ago. I doubt the maintainer is still active. Should we spin up an issue to address this more thoroughly? I'd be happy to contribute here if it would help.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They are on a super old version of puppeteer. Might be related.

pocketjoso/penthouse#347

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm ok with being explicit, but we are going to have to be careful moving forward if the reset ever changes. I was hoping to avoid manual work (hence the regex), but I don't see a median in this situation. Perhaps we can put a note in the automated PR description to check if there have been any reset changes since the previous week's run? It rarely changes, so that may be overkill.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was hoping to avoid manual work (hence the regex), but I don't see a median in this situation.

Totally fair. I'd just like us to prove that we're going to need more manual work before we try to solve for that. I'm hoping that we figure out a way to address the root cause before that becomes a problem. I think that @mlahargou's theory about being on an old version of puppeteer is a promising avenue to pursue. Ideally that gets fixed upstream, but perhaps we just need to fork and apply the pull linked in that comment.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just verified that pocketjoso/penthouse#347 fixes the problem.

Manually updated the penthouse in package.json to point at the fork (with the updated puppeteer version) from the comment and re-ran the css-gather. The generated critical-css now includes the :where selectors.

         "cssnano-preset-advanced": "^5.0.0",
-        "penthouse": "^2.3.2",
+        "penthouse": "feedanal/penthouse#master",
         "postcss": "^8.2.10",

In that case, should we just close this pull and make a fork for penthouse? Then when pocketjoso/penthouse#347 gets fixed we can drop the fork. That seems like a better idea.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Going to close this pull, create a fork for penthouse with updated puppeteer, and use that fork for css-gather. 👍

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, @batbattur!

This new regex will match selectors like the following:
:where(), :has(), :not(), :host(), :root().

Verified that it will not match selectors like the following:
li(:last-child), .green:not(:disabled), .card-hover:hover.
@batbattur batbattur added the QAing Under QA team review label May 11, 2023
@batbattur
Copy link
Contributor Author

batbattur commented May 11, 2023

Steps used to test:

  1. Create a test branch to run the critical-css.yml from this branch: https://github.com/iFixit/ifixit/compare/testing-critical-css-forceInclude
  2. Ran gh workflow run critical-css.yml --ref=testing-critical-css-forceInclude from cominor. Then it created https://github.com/iFixit/ifixit/actions/runs/4951784687 run.
  3. Finally, it created a pull request with the changes from this pull: https://github.com/iFixit/ifixit/pull/47846/files
  4. Made sure the :where(...) selectors are included in the generated critical-css files.

QA 🚛

@batbattur batbattur removed the QAing Under QA team review label May 11, 2023
Copy link
Member

@mlahargou mlahargou left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CR 📱

@batbattur batbattur closed this May 12, 2023
@batbattur batbattur mentioned this pull request May 12, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
QAE Quality Assurance Engineering
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants