Performance enhancement opportunities

[gerardo-rodriguez]

Running the Chrome DevTools Performance Audit, there are some opportunities for us to make this better.

[grigs]

The bits about idle thread make me wonder if you just had too many processes running on your machine to conduct the audit well.

There are definitely places to improve (one of the biggest would be to simply pull the CSS in pwastats domain instead of grabbing it from our netlify pattern library), but I don't think it is quite as bad are your screenshot indicates.

[gerardo-rodriguez]

The bits about idle thread make me wonder if you just had too many processes running on your machine to conduct the audit well.

Thanks for pointing this out @grigs!

[calebeby]

• We are loading Source Code Pro and Source Sans Pro, but only using Source Sans Pro. We can remove Source Code Pro.
• We can save .5kb (after GZIP) with HTML minification. Probably not worth it 🤷‍♂️
• 90.8% of the loaded CSS is unused. What is the recommended way to only pull in parts of the styles from the pattern library?
• The images are not all the same size, they could all be reduced to 90x90 or something

[tylersticka]

What is the recommended way to only pull in parts of the styles from the pattern library?

You could include @cloudfour/cloudfour.com-patterns as a submodule and build a stylesheet only importing the parts that are necessary? (Just brainstorming.)

Alternatively we could use the cloudfour.com stylesheet path to at least use the same cached resource for visitors of both sites? (@grigs mentioned that it's using the pattern library path, which has far less traffic)

[tylersticka]

The images are not all the same size, they could all be reduced to 90x90 or something

This is probably a separate issue, but we've talked about figuring out some automated way of grabbing a PWA's touch icon... currently it's manual process of spelunking through manifest.json or trying to find apple-touch-icon files. (Mentioning in case there's any effort to automate that consistency.)

[calebeby]

@tylersticka Update on CSS:

• We can't do the submodule thing because the patterns are in postcss, and jekyll can only work with SASS/SCSS or plain css. Jekyll does not have any sort of postcss integration
• The cloudfour.com css file is ~1.4x the size of the cloudfour-patterns css file. Is the improved caching worth it? Do you know how much overlap there is between cloudfour.com and pwastats.com users there are?
• Do we want to set up a separate pipeline in pwastats for building css, so all the content is built in ruby-land with jekyll, and all the css is imported in node-land with postcss? I don't like needing to have 2 separate build pipelines, but maybe it is the best option? After all, we already do have the service workers thing being built in node.

[tylersticka]

The cloudfour.com css file is ~1.4 the size of the cloudfour-patterns css file.

I honestly am not sure why/how this would be the case? 🤔

Do you know how much overlap there is between cloudfour.com and pwastats.com users there are?

@grigs likes digging through analytics, not sure if it's possible to determine this.

Do we want to set up a separate pipeline in pwastats for building css, so all the content is built in ruby-land with jekyll, and all the css is imported in node-land with postcss? I don't like needing to have 2 separate build pipelines, but maybe it is the best option? After all, we already do have the service workers thing being built in node.

I'm open to this, I'd just need to see how much complexity or fragility it adds.

[calebeby]

It seems like the cloudfour.com css file has a lot more prefixes in it and pixel fallbacks for rems (maybe it has different autoprefixer options?)

Here is the diff: https://www.diffchecker.com/VqDVDgKb (cloudfour.com on the left, pattern library on the right)

If we went with the nodejs pipeline approach, we would probably nest the jekyll process in the nodejs process (so you would run npm start and it would automatically spawn a jekyll serve)