Module Description
Do you host a very simple site? Is your entire CSS package relatively small? Does your usual site traffic involve folks landing on a page, performing an action, and never seeing them again?
If you've answered yes the the above questions, then you might be able to gain a considerable perceived performance boost by serving all render-blocking CSS inline with the document response.
How does it work? This module takes all system, module, and theme CSS external files and replaces the links in <head> with inline CSS via <style> tags.
Why?
CSS is render blocking. Critical CSS generation is complicated and likely requires a developer or perhaps even an engineer to set up and maintain.
If there is a meager amount of CSS (say, under 10kB compressed), then it will likely improve the perceived page load speed for end-users with little more than the click of a button.
What if this doesn't make my site faster? If your needs are more complex, then please check out the excellent Critical CSS project.
What if this breaks a style? There are some things that are fundamentally incompatible with critical CSS without additional work. These outliers fall outside of the scope of this module.
Relative paths in url(...)
Relative paths in stylesheets that are not originally in the document root may break if styles are made inline. In order to fix this, the relative paths will either have to be updated or made absolute.
A note on security Because of the nature of adding styles directly into pages, unless special precautions are taken, this module may increase the likelihood of a successful exploit if a malicious actor manages to inject content into CSS assets.
This simply implies that the consequence of a potential security incident slightly increases. Luckily, there are counter-measures that can be taken to not only nullify the risk, but to harden your application's security beyond what the out-of-the-box core mechanisms offer.
Hardening security through a Content Security Policy
To use this module it is recommended to have a Content Security Policy configured that does not allow unsafe-inline in the script-src source value.
For more information about using a Content Security Policy with Drupal, please check out the CSP project.
Hardening security through a CSS pre-render event
If a Content Security Policy isn't an option for your organization, this module also dispatches an event that allows third parties to alter the CSS before it is rendered. Custom code may tap into this event in order to run their own sanitize methodology on the resulting CSS.
If you've answered yes the the above questions, then you might be able to gain a considerable perceived performance boost by serving all render-blocking CSS inline with the document response.
How does it work? This module takes all system, module, and theme CSS external files and replaces the links in <head> with inline CSS via <style> tags.
Why?
CSS is render blocking. Critical CSS generation is complicated and likely requires a developer or perhaps even an engineer to set up and maintain.
If there is a meager amount of CSS (say, under 10kB compressed), then it will likely improve the perceived page load speed for end-users with little more than the click of a button.
What if this doesn't make my site faster? If your needs are more complex, then please check out the excellent Critical CSS project.
What if this breaks a style? There are some things that are fundamentally incompatible with critical CSS without additional work. These outliers fall outside of the scope of this module.
Relative paths in url(...)
Relative paths in stylesheets that are not originally in the document root may break if styles are made inline. In order to fix this, the relative paths will either have to be updated or made absolute.
A note on security Because of the nature of adding styles directly into pages, unless special precautions are taken, this module may increase the likelihood of a successful exploit if a malicious actor manages to inject content into CSS assets.
This simply implies that the consequence of a potential security incident slightly increases. Luckily, there are counter-measures that can be taken to not only nullify the risk, but to harden your application's security beyond what the out-of-the-box core mechanisms offer.
Hardening security through a Content Security Policy
To use this module it is recommended to have a Content Security Policy configured that does not allow unsafe-inline in the script-src source value.
For more information about using a Content Security Policy with Drupal, please check out the CSP project.
Hardening security through a CSS pre-render event
If a Content Security Policy isn't an option for your organization, this module also dispatches an event that allows third parties to alter the CSS before it is rendered. Custom code may tap into this event in order to run their own sanitize methodology on the resulting CSS.
Module Link
Project Usage
121
Security Covered
Covered By Security Advisory
Version Available
Production
Module Summary
This module aims to improve perceived performance by serving all render-blocking CSS inline with the document response for simple sites with small CSS packages and low traffic.
Data Name
inline_all_css
OPENAI CHATBOT
OPENAI CHATBOT
