Skip to content

feat: use calculated integrity hashes for local vendor plugins#947

Open
pivaldi wants to merge 3 commits intonext-theme:masterfrom
pivaldi:master
Open

feat: use calculated integrity hashes for local vendor plugins#947
pivaldi wants to merge 3 commits intonext-theme:masterfrom
pivaldi:master

Conversation

@pivaldi
Copy link

@pivaldi pivaldi commented Feb 12, 2026

  • The changes have been tested (for bug fixes / features).
  • Docs in NexT website have been added / updated (for features).

PR Type

  • Bugfix.
  • Feature.
  • Improvement.
  • Code style update (e.g. formatting, linting).
  • Refactoring (no changes to functionality and APIs).
  • Documentation.
  • Translation.
  • Other... Please describe:

When vendors.plugins is set to local, integrity hashes are now computed from the actual local files via @next-theme/plugins getLocalIntegrity() rather than using the hardcoded CDN hashes from _vendors.yml.

This fixes SRI (Subresource Integrity) validation failures that caused browsers to block all vendor assets when self-hosting, resulting in blank pages.

CDN mode is unaffected: hardcoded hashes from _vendors.yml are still used when plugins is not local.

Depends on: next-theme/plugins#347

When `vendors.plugins` is set to `local`, integrity hashes are now
computed from the actual local files via `@next-theme/plugins`
`getLocalIntegrity()` rather than using the hardcoded CDN hashes from
`_vendors.yml`.

This fixes SRI (Subresource Integrity) validation failures that caused
browsers to block all vendor assets when self-hosting, resulting in
blank pages.

CDN mode is unaffected: hardcoded hashes from `_vendors.yml` are still
used when `plugins` is not `local`.

Depends on: next-theme/plugins#347
@CLAassistant
Copy link

CLA assistant check
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
You have signed the CLA already but the status is still pending? Let us recheck it.

Add configurable lazy loading for non-critical CSS files (FontAwesome,
Fancybox, KaTeX) to improve Lighthouse performance scores by reducing
render-blocking resources.

The feature uses the modern preload + onload technique to load CSS
asynchronously while maintaining a noscript fallback for users without
JavaScript. Main theme CSS remains render-blocking to prevent FOUC
(Flash of Unstyled Content).

Changes:
- Add performance.lazy_css config option in _config.yml (default: false)
- Update next_vendors helper to accept optional lazy flag
- Modify head.njk to pass lazy: true for FontAwesome and Fancybox
- Modify katex.njk to pass lazy: true for KaTeX CSS
- Preserve SRI integrity hashes for security

Benefits:
- Reduces render-blocking CSS from 4-5 files to 1-2 files
- Improves Largest Contentful Paint (LCP) by 100-300ms
- Fully backward compatible (disabled by default)
- Works without JavaScript via noscript fallback

Closes: (add issue number if applicable)
@github-actions
Copy link

This pull request contains changes to the configuration file. Please make sure the documentation in NexT website is changed or added.
Please edit relevant source files here: https://github.com/next-theme/theme-next-docs/tree/master/source/docs and create a pull request with the changes here: https://github.com/next-theme/theme-next-docs/pulls

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants