Performance: front-end

[tellyworth]

Let's put together a checklist of any front-end performance issues (current or potential) that need to be considered. We may not fix them all for initial launch, but the sooner we know about them the better.

• Use webp for images
• Load the download modal JS only on download page
• Load the MU Latest Posts block JS in the footer
• Largest Contentful Paint image was lazy loaded

[adamwoodnz]

Desktop performance is acceptable probably, but there are 3 opportunities for improvements:

Mobile performance is most likely unacceptable, mostly the same opportunities:

Image formatting and sizing, and optimisation of JS loading seem to be the key areas to focus on.

[adamwoodnz]

I've now replaced all the large images in the front page with .webp versions and that opportunity has been dismissed. The scores have dropped a little, but it seems the the JS issues have more impact.

[adamwoodnz]

Download page desktop score is excellent. Mobile shows similar issues to front page:

[adamwoodnz]

Gutenberg issue raised related to JS loading: WordPress/gutenberg#43054

[ryelle]

@adamwoodnz or @renintw Can you put together a checklist of any items that still need to be done?

[adamwoodnz]

Lighthouse scores are very good now, only Download page on mobile is below 90:

Desktop	Mobile

The download page mobile score is largely due to the wordpress/components import which we have Gutenberg issues for already but needs further discussion after launch.

The remaining opportunities/issues are:

1. Reduce server response time
   
2. Eliminate render blocking resources - mostly related to the latest posts block imports
   
3. Largest Contentful Paint image was lazy loaded - the cover image for 'Dream it, build it' section is lazy loaded
   

Of these I think 2 is the most important. We could look at a webpack tree shaking solution to reduce the size of the import, but also not loading the scripts in head would make a big difference.

[ryelle]

The homepage should stop loading lodash once GB 13.9 comes out, it looks like wp-element is the only dependant, and the lodash dep has been removed last week (WordPress/gutenberg#42898).

I just made a quick PR to move the latest posts code into the footer: WordPress/wporg-mu-plugins#245 — I'm not sure how much that helps in reality, since some of the deps are still loaded in the header.

[adamwoodnz]

I'm not sure how much that helps in reality, since some of the deps are still loaded in the header.

Just loading that up now to see how much effect it has. There is a ticket for enqueuing block scripts in the footer https://core.trac.wordpress.org/ticket/54018

[adamwoodnz]

2. Eliminate render blocking resources - mostly related to the latest posts block imports

Merged WordPress/wporg-mu-plugins#245 so this is largely mitigated. react-dom is still loaded in the head and flagged as render blocking. There are other smaller GB scripts which don't get flagged.

[ryelle]

1. Reduce server response time

That would be tracked in #44

3. Largest Contentful Paint image was lazy loaded - the cover image for 'Dream it, build it' section is lazy loaded

Could look into how core adds these attributes, I found a dev note about skipping X images from being lazy-loaded. That could be the answer or it could point us in the right direction.