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 considerations and optimization opportunities to be aware of.

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.

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, you must ensure your images are managed by Plasmic. Optimization does not apply with images where you paste in a remote URL. You must either paste or upload the actual image file into Plasmic, so that it shows up in the Image Assets left tab.

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

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, the only JS Plasmic produces is for the React components needed to render your page. However, usage of additional code/React components is the most common contributor of additional JS weight. This includes both components from the Plasmic component store, and code/components from your own codebase. Ant components, for instance, can contribute significantly to page weight.

If you don’t need specific components from the component store, then don’t include those in your project.

Reducing page complexity

Another concern is 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 font loading by using skipFonts:

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

React server components (future work)

Frameworks like Next.js are working on adding support for 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.

Plasmic is working on supporting this, as the technology develops in the underlying framework.

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?

Give feedback on this page