Closed batbattur closed 1 year ago
Created pull with JS disabled on iFixit/ifixit side: https://github.com/iFixit/ifixit/pull/47314
Tested generating critical css with JS disabled. The overall performance score was similar to with JS enabled.
Then noticed one important thing from the screenshot artifacts: if the JS is disabled, then the WIki and Device pages don't load at all. Here's how to reproduce:
Go to your chrome JS settings, and add ifixit.com
in the not allowed list:
chrome://settings/content/javascript?search=javascript
Then visit a wiki or device page.
Therefore, we still need to have JS enabled when generating the critical CSS. Going to close this issue since this issue was originally created to debug/find the flakiness in the manta page critical css changes. Since we found the cause of flakiness in https://github.com/iFixit/ifixit/pull/47312#issuecomment-1501968121, we will be tackling it in https://github.com/iFixit/ifixit/issues/47316.
Summary
Currently, we take 2 screenshots (
-before
and-after
) per URL we provide using the penthouse tool. However, the-after
screenshots are ending up looking weird, see https://github.com/iFixit/ifixit/pull/47019#issuecomment-1483295353.Explanation of
-before
and-after
images from penthouse:Example artifact with weird
*-after
images: critical-css-screenshots-weird-after.zipDo this
Fix
*-after
screenshot.One possible fix was to disable JS (
blockJSRequests: true
) in the penthouse config to get the screenshot working, however, this will affect the generation of the critical-css, so we are not sure if we should do this.Here is an example artifact with fixed
*-after
images (whenblockJSRequests: true
): critical-css-screenshots-normal-after.zipAs penthouse docs and this article suggest, they recommend to disable JS requests while generating the critical css:
Let's try generating the critical css with
blockJSRequests: true
and see how it affects the First Contentful Paint (FCP) and the page load.