-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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
Minimize the number of CSS files requested #36186
Comments
Pinging @elastic/kibana-operations |
I'd like to bump this issue. We've had two customer complaints that I know of recently so I dug into this a bit and I think it's dramatically slowing down how long it takes for the frontend to start being usable. In an initial load, I saw 95 requests. The number of requests is a problem for us because most browsers will limit the number of open connections a window may have at a time. This causes a major bottleneck in loading all the files needed to render the page. In the most severe example, |
@joshdover any progress with the PR for this issue? I got another compliant in 6.7.1 mostly the navigation between applications and on login |
@AlonaNadler In my draft PR, I got a couple wins that shaved off ~2s. I need to take another look at our caching headers set on these bundles which may improve it quite a bit more. I'll probably pick this back up in the next week or so. It should be backportable to 6.8 if that's the route we want to go. |
So far, I only see mention of 6.x in this issue. This gets worse on 7.x given that we have more applications on 7.x and each application requires loading a CSS file on every page? |
Can it be closed? There are not separate CSS files per a plugin bundle with the new |
When we first introduced SCSS support for plugins, we did so by loading the resulting CSS on page-load. This was fine then, but with 31 plugins now doing so results in a performance bottleneck due to maxing out the parallel requests to the domain.
One option would be to serve the enabled plugins CSS file in a single request. A route could be created for this and the result cached if necessary. The goal would be to avoid any un-necessary action during plugin install.
The text was updated successfully, but these errors were encountered: