Page load performance tips

Page load performance is an important metric for many marketing and ecommerce websites. Plasmic is designed to work with frameworks like Next.js, which focus on performance.

If you are looking to improve the performance of your own page, there are several common pitfalls, considerations and optimization opportunities to be aware of.

Use SSR and SSG

If your application codebase is performing client-side rendering or is not already doing static site generation (SSG) and/or server-side rendering (SSR), this will likely yield the greatest performance improvement. This is supported out of the box by frameworks such as Next.js. It ensures that your page is served with pre-rendered HTML/CSS, and will display as quickly as possible for users, followed by hydration of the interactive parts of the page.

Plasmic was built to first and foremost support such pre-rendering methods, and this is the predominant way of serving Plasmic pages in production environments. You should be able to get this out of the box if you follow (say) the Next.js quickstart or used create-plasmic-app.

Remember to disable preview mode

initPlasmicLoader takes an optional preview parameter, which you may forget to turn off.

  • If you set this to true, then Plasmic will load the latest draft version of your project from the Plasmic API servers. Helpful for development.
  • If you set this to false, then Plasmic will load the latest published version of your project from the Plasmic CDN.

While this won’t affect the performance of static pages (outside of build times), it will affect pages served using SSR or client-side rendering—anything where you are actively fetching the Plasmic bundles at user request time. So make sure it is set to false in production.

Image optimization

Plasmic includes built-in image optimization, which ensures images are served at optimal sizes and at the proper resolution for the device screen.

To take advantage of this, Plasmic needs to know the intrinsic size of each image. All images uploaded to Plasmic will use image optimization automatically. An image with an external URLs will only be optimized if its width and height are set.

Note that optimization currently only applies to image elements. If you set a background image on an element, it does not get optimized.

Avoid overriding content or props in responsive variants

When you have (say) a mobile variant of a design, you should avoid overriding the content or props of anything in those variants. You should override only the styles of elements—things like layout, typography, visibility, and so on. Avoid changing the text, changing images, or changing props. (In other words, make sure you do not see colored dots on those settings for responsive variants of a page.)

This affects more than just performance, since users will see a flash of the wrong content. With incorrectly built pages, mobile users will see a flash of the desktop version of the page before it is replaced by the mobile version.

Example scenarios:

  • If you want to change some text or image on mobile, don’t directly edit the text or change the image. Instead, duplicate your text or image, and alternatively show or hide the correct element based on the variant.

  • If you want to hide an element on mobile, make sure you are setting “Not Visible” rather than “Not Rendered” on it. (You normally don’t need to think about this since clicking the eye icon in the right sidebar or the outline will toggle its “Not Visible” setting.)

Common examples of things that are fine to override:

  • Change the visibility of an element
  • Change layout of a stack from horizontal to vertical
  • Change the number of grid columns
  • Change the margin/padding/size of an element
  • Change the font size of some text (though, note that you can do this at a project-wide level in the Default Styles settings)
  • Change the background color of a box

We are working on some tools to alert you to these overrides so that you can fix them.

Reducing Javascript used on the page

One of the most impactful levers you can exercise in controlling page performance is reducing the amount of JavaScript shipped to the page. This in turn improves hydration performance and time-to-interactive of the page.

By default, Plasmic generates code to render your page. However, this is typically not the main culprit—additional code/React components is the dominant contributor of additional JS weight. This includes both components from the Plasmic component store, and code components from your own codebase.

If you don’t need specific components from the component store, then don’t include those in your project, and they won’t appear in any JS bundles.

For more on optimizing JS bundle sizes for code components you register from your own codebase, see code component tree-shaking and bundle optimization.

Reducing page complexity

Another concern is the amount of HTML and CSS in the page. Typically, there is a very straightforward relationship between the Plasmic page structure and the HTML/CSS generated—a box in Plasmic usually just corresponds to one div in HTML, along with some associated CSS class.

If you are finding that your website has excessive HTML, then you can remove elements from the Plasmic project. One common source of excessive HTML elements is Figma imports. The importer recreates exactly the structure you had in the Figma file, and often Figma files may have many more elements than meets the eye as they were not crafted with production concerns in mind, and are typically illustrations that need to undergo rapid iteration. See the Figma import docs for more tips.

Note that often, even somewhat verbose-seeming HTML/CSS have high compression ratios due to repetition in strings. That said, Plasmic is also continually looking to improve the bundle sizes of both JS and CSS.

Font optimization

One common low-hanging performance opportunity is with font loading. Plasmic lets you load arbitrary Google fonts in your pages. This is accomplished by loading some CSS from Google, such as:()

Copy
<link rel="preconnect" href="https://fonts.googleapis.com" />
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin />
<link rel="preconnect" href="https://fonts.googleapis.com" /><link
  rel="preconnect"
  href="https://fonts.gstatic.com"
  crossorigin
/><link href="https://fonts.googleapis.com/css2?family=Roboto&display=swap" rel="stylesheet" />

This CSS in turn contains snippets like the following:

Copy
/* cyrillic-ext */
@font-face {
  font-family: 'Roboto';
  font-style: normal;
  font-weight: 400;
  font-display: swap;
  src: url(https://fonts.gstatic.com/s/roboto/v30/KFOmCnqEu92Fr1Mu72xKKTU1Kvnz.woff2) format('woff2');
  unicode-range: U+0460-052F, U+1C80-1C88, U+20B4, U+2DE0-2DFF, U+A640-A69F, U+FE2E-FE2F;
}
/* cyrillic */
@font-face {
  /* ... */
}
/* ... */

So there is a waterfall of fetches from Google’s servers happening—the CSS, and then the fonts themselves.

Next.js contains some automatic optimization for Google Fonts, but this requires the fonts to be hardcoded into your source files. You can apply the same optimization to your site:

Copy
import { Inter } from '@next/font/google';


// If loading a variable font, you don't need to specify the font weight
const inter = Inter({ subsets: ['latin'] });


export default function MyApp({ Component, pageProps }) {
  return (
    <main className={inter.className}>
      <Component {...pageProps} />
    </main>
  );
}

And then instruct Plasmic to skip its own font loading.

If you’re using loader, you can do so by using skipFonts:

Copy
<PlasmicRootProvider skipFonts>{/* ... */}</PlasmicRootProvider>

Otherwise, if you’re using codegen, you should set fontOpts.scheme = "none" in your plasmic.json file:

Copy
"fontOpts": {
  "scheme": "none"
},

Why is my pageProps size so large?

You may notice a larger pageProps, or see this warning in the Next.js console:

Copy
One of your pages includes a large amount of page data (>= 128kB).

(You can read more about the warning here.)

The 128kb measures size of data passed as page props returned from getStaticProps. For a Plasmic page, this by default would include everything needed to render the Plasmic page including all CSS and Javascript as well. This differs from a normal non-Plasmic page, where the CSS and Javascript are loaded separately from page props and don’t count towards that limit.

Ultimately, what matters is your measured page speed experience. You can configure the threshold using largePageDataBytes if you’d like to not see the warning.

React server components

Frameworks are beginning to support React server components. This will enable you to ship less JavaScript to the browser, instead keeping more code exclusively executing on the server, thus reducing hydration costs.

React server components is currently supported for the following frameworks: Next.js

Still have questions?

The Plasmic team has worked with some extremely high-traffic and performance sensitive websites. If you’re interested in our expertise, please get in touch with our sales team.

Was this page helpful?

Have feedback on this page? Let us know on our forum.