Porsche Design System

Initialization

Table of Contents

Setup
Optimization

Setup#

The most basic integration of @porsche-design-system/components-react/ssr looks like this.

<PorscheDesignSystemProvider>...</PorscheDesignSystemProvider>

When looking at Remix, we need to cover two different scenarios: the server side and the client side.

In the example from above we didn't render any component, yet, so let's render a single PButton.

<PButton>Hello</PButton>

Server Side

On the server side the components of the @porsche-design-system/components-react/ssr sub-package render static markup for something called Declarative Shadow DOM which is converted into a real Shadow DOM by modern browsers without any JavaScript.

To continue with the example, this is what the result that is returned by the server looks like.

<p-button class="ssr">Hello</p-button>

As you can see, the hydrated class isn't there since the web component is still "dead" until it is really initialized.

To verify what is rendered by the server without any client side hydration (and potential re-renders), you can disable JavaScript in your browser. In our scenario, this results in the following network traffic.

Client Side

Now, we already have a p-button tag in the DOM from the server side. From here on the exact same things happen as described at Vanilla JS Preparation and Vanilla JS Connect Lifecycle.

Any further client side rendering behaves just like it does for the React integration.

Optimization#

Now that it is clear what is happening under the hood when a simple PButton is rendered, let's see how this looks from the perspective of network requests and how to improve them if necessary.

Status Quo

By default, the network traffic looks something like this.

starts with the index.html

then continues with several *.js bundles of the Remix app

which then load the core chunk

that injects the component chunk

and last the font file after the styles within the component's Shadow DOM are applied

Preloading font files

By applying the getFontLinks() partial we can preload the font assets. As a default, both regular and semi-bold weights are preloaded since they are most commonly used but this can be customized.

As a result, both font files are additionally loaded in parallel, while earlier this happened not only in sequence but even last and only when a style is present on the page that uses the font-family and that particular font-weight which can lead to a phenomena called Flash of Unstyled Text (FOUT).

Preloading component chunks

The loading experience can be improved further by using the getComponentChunkLinks() partial. Without any configuration it simply preloads the core chunk.

Again, with this improvement, the asset is now being loaded in parallel, too.

For the next step, we also want to preload the component chunk by using the partial like

getComponentChunkLinks({ components: ['button'] });

Now, everything is preloaded in parallel while the Remix app chunks takes the longest and are executed last.

Just preloading all component chunks on the page or even every chunk available should be avoided.

Instead, the most performant but also more complicated approach would be to only preload the component chunks (and fonts) that are located above the fold which means visible on page load without scrolling.

Early initialization

This is where it may be interesting to apply the getLoaderScript() partial.

The loading behavior is essentially the same but the load() call happens way before the app chunks are even loaded. This can result in better user experience depending on the use case because the gap until the app actually being ready is bridged.

Hint