Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sitecore JSS adding blocking JS/CSS to page, hurting performance. #1991

Open
chrissnyder2337 opened this issue Dec 3, 2024 · 3 comments
Open
Labels
backlog Issue/PR/discussion is reviewed and added to backlog for the further work 🐞 bug

Comments

@chrissnyder2337
Copy link

Describe the Bug

I am auditing the performance of our frontend XM Cloud application (built using Next.js). We found that sitecore is adding blocking third-party JS/CSS, and not following Next.js’s best practices for including scripts/stylesheets. Specify https://edge-platform.sitecorecloud.io/v1/files/pages/styles/content-styles.css?sitecoreContextId=XXXXXXXXXX

I have narrowed it down to the following code that is in Layout.tsx:

        {headLinks.map((headLink) => (
          <link rel={headLink.rel} key={headLink.href} href={headLink.href} />
        ))}

Is it possible to include these in a non-blocking way? In my case this would result in a potential savings of almost a second.

content-styles_css

To Reproduce

Run a lighthouse test on any page and note that the content-styles.css is reported as render blocking.

content-styles_css

Expected Behavior

The js/css added by sitecore's JSS SDK is not loaded in a blocking manner or in a way that does not negatively impact the page performance.

Possible Fix

Possibly load this using next/script with a non-blocking strategy.

Provide environment information

  • Sitecore Version: XM Cloud
  • JSS Version: 22.1.4 (but happens with other JSS versions too)
  • Browser Name and version: Chrome 131.0.6778.86 (Official Build) (arm64)
  • Operating System and version (desktop or mobile): Both desktop and mobile.
  • Link to your project (if available):
@art-alexeyenko art-alexeyenko added the backlog Issue/PR/discussion is reviewed and added to backlog for the further work label Dec 4, 2024
@art-alexeyenko
Copy link
Contributor

@chrissnyder2337 thanks for raising this!

Can you elaborate on your proposal with next/script please? As far as I know it only applies to scripts, not styles.

The styles themselves are needed for SXA components, the page can look unfinished until they are loaded. The styles can be configured in Pages and will be used on live site. However, these styles shouldn't be loading if SXA styles are not used on the page.

@gregorjan
Copy link

Hi we ended up injecting css directly to html to mitigate this issue.

First fetch css in getStaticProps in [[...path]].tsx

export const getStaticProps: GetStaticProps = async (context) => {
	const props: SitecorePageProps = await sitecorePagePropsFactory.create(context)

	const contentStylesLink = getContentStylesheetLink(
		props.layoutData,
		config.sitecoreEdgeContextId,
		config.sitecoreEdgeUrl,
	)

	if (contentStylesLink?.href) {
		props.contentStyles = await fetch(contentStylesLink.href)
			.then((response) => response.text())
			.catch((_e) => {
				//TODO add logging
			})
	}

	return {
		props,
		// Next.js will attempt to re-generate the page:
		// - When a request comes in
		// - At most once every 5 minutes
		revalidate: 300, // In seconds
		notFound: props.notFound, // Returns custom 404 page with a status code of 404 when true
	}
}

and then pass it as a prop to Layout component.

and in Layout.tsx inject those styles in Head


	return (
		<>
			<Head>
				{contentStyles && <style dangerouslySetInnerHTML={{ __html: contentStyles }} />}
			</Head>
		</>
	)
}

This makes html bigger however it has lower impact on performance than waiting for response

@chrissnyder2337
Copy link
Author

@gregorjan This is a great approach.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backlog Issue/PR/discussion is reviewed and added to backlog for the further work 🐞 bug
Projects
None yet
Development

No branches or pull requests

3 participants