4 ms·

> yet I find this post misleading. The examples shown are ways NOT to do frontend performance Is advice different than what you prefer "misleading?" Anyway, h

> yet I find this post misleading. The examples shown are ways NOT to do frontend performance Is advice different than what you prefer "misleading?" Anyway, he doesn't actually weigh in on marking JS with `defer` or `async`. And the article is directly contesting preloading the styles, given his note on race conditions with `media` switching. Moving the CSS before the `</body>` closing tag is genuinely a way to really defer your CSS. > Why would we ever put non-Critical CSS in the <head> in the first place?! To this point from Harry, I find myself skeptical that anyone's really going to want to do that. Getting layout jank / cumulative layout shift fixed when the main stylesheet is applied is a sisyphean task.

troysk 4y ago
I said misleading as the author mentions JavaScript preventing rendering which isn't the case for anybody who is looking to optimize their site for speed. There are other such assumptions. Performance engineer is most times going against the default way and standards which the author is aware which is why I am surprised with this post. I have not run into layout janks when I have used critical path CSS. I'd look into other tools/settings while extracting the critical path CSS if this would happen to me.
- lelandfe 4y ago
  > the author mentions JavaScript preventing rendering which isn't the case for anybody who is looking to optimize their site for speed Rewriting your JS to be async-ready can be a huge lift. Not every site pursuing frontend performance is ready to do that, much less has done it. I think this article certainly has an audience. > I have not run into layout janks when I have used critical path CSS Call me a skeptic :) if a user is able to scroll beyond the fold before the CSS loads, you've introduced CLS. Spoiler: they will always be able to. Critical CSS and 0 CLS happens only when you create skeleton placeholder components for everything below the fold as well. There are no "tool/settings" that will do this automatically.
  - troysk 4y ago
    > Rewriting your JS to be async-ready can be a huge lift. Not every site pursuing frontend performance is ready to do that, much less has done it. I think this article certainly has an audience. CSSWizardry targets performance engineers which is why I pointed it out. I would never post that for some Next.js or other new hotness blogpost which isn't focussed on frontend performance. > Call me a skeptic :) if a user is able to scroll beyond the fold before the CSS loads, you've introduced CLS. Spoiler: they will always be able to. I can't speak on code I haven't worked on or predict how users will react on UIs without looking into data. But I read this as excuses from providing the best UX to the end user.

troysk 4y ago

I said misleading as the author mentions JavaScript preventing rendering which isn't the case for anybody who is looking to optimize their site for speed. There are other such assumptions. Performance engineer is most times going against the default way and standards which the author is aware which is why I am surprised with this post. I have not run into layout janks when I have used critical path CSS. I'd look into other tools/settings while extracting the critical path CSS if this would happen to me.

lelandfe 4y ago
> the author mentions JavaScript preventing rendering which isn't the case for anybody who is looking to optimize their site for speed Rewriting your JS to be async-ready can be a huge lift. Not every site pursuing frontend performance is ready to do that, much less has done it. I think this article certainly has an audience. > I have not run into layout janks when I have used critical path CSS Call me a skeptic :) if a user is able to scroll beyond the fold before the CSS loads, you've introduced CLS. Spoiler: they will always be able to. Critical CSS and 0 CLS happens only when you create skeleton placeholder components for everything below the fold as well. There are no "tool/settings" that will do this automatically.
- troysk 4y ago
  > Rewriting your JS to be async-ready can be a huge lift. Not every site pursuing frontend performance is ready to do that, much less has done it. I think this article certainly has an audience. CSSWizardry targets performance engineers which is why I pointed it out. I would never post that for some Next.js or other new hotness blogpost which isn't focussed on frontend performance. > Call me a skeptic :) if a user is able to scroll beyond the fold before the CSS loads, you've introduced CLS. Spoiler: they will always be able to. I can't speak on code I haven't worked on or predict how users will react on UIs without looking into data. But I read this as excuses from providing the best UX to the end user.