Wp-calypso: Framework: App Shell

[apeatling]

Rendering the shell of the app on the server helps with the perception of speed.

Intricacies include not knowing specifics of the layout for a given section — sidebar, full-width, etc. We are already rendering an empty layout which is good. Extending this to include user-based information (like the masterbar) requires solving hurdles around internationalization, like having to avoid displaying text until we can use i18n-calypso on the server side.

The other aspect is looking at shipping critical CSS for the shell earlier.

[flootr]

After some thoughts I think there are some steps needed before this issue actually can be resolved:

• [x] #19822 Eliminate Jade: I think this should be done before to save work. We would have to refactor the work on the app shells if we change the way anything got tied together on the server afterwards. @ockham worked on this before, would it be okay for you if I continue the work you've begun?
• [ ] Inline critical css: This is actually part of this issue, but also good to be done before. If we can inline critical css and defer loading the rest of the css we can improve performance significantly. @alexsanford has already done some work on this which I also'd like to continue.

Lighthouse

According to the performance audit there's currently have ~10 seconds until the first meaningful paint:

These stats were relatively stable during my tests. And it's mainly due to CSS blocking the rendering path:

Noticons

About the noticons.css (blocking for ~1.2s) I found this:

I haven't found an open issue regarding this statement, may be worth revisiting.

/cc @ehg

[stephanethomas]

Are you going to consider pages that are rendered server-side as well, such as the Login page?

[flootr]

Hey @stephanethomas, thanks for your question. I think server side rendered pages are not in the scope of this issue, because there won't be an app shell as they're rendered completely on the server. Or is there another aspect we might need to consider?

The Login page isn't server rendered for me. Is there anything I'm missing? I get an empty layout when disabling JavaScript in the browser.

[stephanethomas]

I think server side rendered pages are not in the scope of this issue, because there won't be an app shell as they're rendered completely on the server. Or is there another aspect we might need to consider?

Sorry, I wasn't clear at all - I should have taken more coffee. My concern was more about keeping these specific pages in mind to avoid any bad surprise since you're going to touch Jade templates or server/pages/index.js.

The Login page isn't server rendered for me. Is there anything I'm missing? I get an empty layout when disabling JavaScript in the browser.

We don't render pages server-side when the user is logged in. Moreover in the case of the Login page we only render the default English variant that lives at https://wordpress.com/log-in. Variants for other languages (e.g. https://wordpress.com/log-in/fr) are only rendered client-side.

[flootr]

I agree this needs to be considered and will make sure to not break any server rendered content, thanks for clarification and pointing that out 👍 ☕️