Closed amakhrov closed 1 year ago
Hi @alan-agius4 , do you know whether standalone components and a possible migration from modules to standalone application could also impact negatively in the performance of the application? I migrated my entire application to standalone and couldn't see major improvements. In fact I saw a slightly decrease in performance - not sure if that could be related because we are currently making several changes to the application to try to optimize specially the initial bootstrap time. We still have inlineCriticalCss
set to false because our tests showed not very good performance yet but I still want to put in prod the app with optimizations: true
once we change all content we are going currently through.
Hi @CarlosTorrecillas @alan-agius4 One doubt: Is it enough to just set inlineCriticalCss: false in server.ts? Or is it necessary to update angular.json optimization param as mentioned in some answer? "optimization": { "scripts": true, "styles": { "minify": true, "inlineCritical": false }, "fonts": true }
Currently we have inlineCriticalCss: false and "optimization": true in angular.json
I have read also about purgeCss. Should we implement purgeCss? if we set "styles": { "minify": true, "inlineCritical": false }
Thanks
Hi @juanico18 ,
According to what has been said in this thread, some research I have performed about this topic and the results I got, you should modify BOTH the server.ts
and the angular.json
to set the inlineCriticalCss: false
. In my code for example I do have:
server.ts
(note that I have SSR using standalone components)
// Our Universal express-engine (found @ https://github.com/angular/universal/tree/main/modules/express-engine)
server.engine('html', ngExpressEngine({
bootstrap,
inlineCriticalCss: false
}));
my boostrap
defined in the main.server.ts
is:
import { bootstrapApplication, provideClientHydration } from '@angular/platform-browser';
import { AppComponent } from './app/app.component';
import { provideServerRendering } from '@angular/platform-server';
import { provideHttpClient } from '@angular/common/http';
import { provideRouter } from '@angular/router';
import routes from './app/app.routes';
const bootstrap = () => bootstrapApplication(AppComponent, {
providers: [
provideHttpClient(),
provideRouter(routes),
provideServerRendering(),
provideClientHydration()
]
});
export default bootstrap;
then the angular.json
has:
"optimization": {
"scripts": true,
"styles": {
"minify": true,
"inlineCritical": false
},
"fonts": true
}
With that and having reviewed my app in terms of component load and migrated to standalone components I do have better response times according to the Google Crawler (@alan-agius4 this can be interesting to you as well because it is the continuation of the graph I showed a while ago after disabling inlineCriticalCss and also after upgrading to Angular 16 and migrating to standalone components)
I also have an active post in StackOverflow regarding possible optimizations of the main bundle to try to reduc/optimize it and get better Google PageSpeed results - https://stackoverflow.com/questions/76730455/reduce-main-js-file-in-angular
Finally, about PurgeCss
that is separate to the minify flag and you have to do it yourself, normally by hooking up into the angular build process using the webpack plugin that does the stuff for you.
Hi @CarlosTorrecillas
Thanks for the info.
I have correct configuration.
Angular.json
For browser
"optimization": {
"scripts": true,
"styles": {
"minify": true,
"inlineCritical": false
},
"fonts": true
}
For server:
"optimization": true
By mistake I checked wrong the angular.json file
server.engine('html', ngExpressEngine({ inlineCriticalCss: false, bootstrap: AppServerModule }));
Some more questions:
Have you already mirgrated to angular16? Is a requirement to use standalone components? Did you notice a improvement in the perfomance because of the use of standalone components?
Is purgeCss compatible with minify done by the angular cli bulid?
Thanks
Hello @juanico18 ,
I have migrated to Angular 16
, yes, and I had this setting prior the migration (on Angular 15
) and Angular 16
. Then I migrated to standalone components but before I did have the classic module configuration. In terms of performance improvements, I have noticed less amount of bytes being transferred over the net because there is less javascript, but regarding speed, perhaps what I did notice is bit more stability with the hydration process that has been improved in SSR. The PageSpeed score I have seems to improve, but I have to say that I have also applied more optimizations to my APP so I don't think they are fully related to either standalone or Angular 16 itself.
PurgeCSS is compatible. You can apply it as part of the process.
The "only" test I have to conduct now is to revert back to inlineCriticalCss: true
and see the results with the current configuration. That is something we have planned to do in a month or so.
Regards
Hi @alan-agius4 ,
I rolled out an upgrade of the website including the latest Angular 16.2.2
and tried very quickly to revert back on the inlineCriticalCss
feature and run the page speed test - as a first feedback to see if there weren't mayor performance hits or even improvements. Unfortunately, as far as I can tell, setting that feature to true causes a big CLS penalty hit and the overall performance of the site decreases so decided to roll it back and keep it false
for the time being.
I'm sharing now the results about the before (inlineCriticalCss: false
) and after (inlineCriticalCss: true
- all optimizations set to true).
Before (inlineCriticalCss: false)
After (inlineCriticalCss: true)
Note that I have the latest version of the framework - 16.2.2
and my set up is with standalone components 100% (including SSR).
In my opinion, for the time being I think that feature should be defaulted to false to get the best performance until we have a version that offers better results.
@CarlosTorrecillas, would you be able to provide a repro please? Unfortunately without a reproduction it's hard to tell why the CLS increased.
Are you getting some errors or warnings on the server during the request?
Hi @alan-agius4 , I am not able to provide a repro unfortunately. I know it is complicated for you to know why this happens. For me is also difficult as I cannot upload a site to make the lighthouse target it in order to provide results. If I share the results form my local environment running locally the lighthouse I get different results - the site is very performant.
In terms of errors, I get none. It is simply that the performance gets worse.
you can invite him if you can, mostly the criticalCss fail because your API call not fast enough or some async function. I have no issue with that. You should solve this by check api call on platformBrowser and split the job between server render and client
@CarlosTorrecillas, at the very minimum can you provide a CPU profile?
Hi @alan-agius4 ,
If what you mean is the performance monitor that Chrome DevTools provide, I can provide the following screenshot that has the spike when the app loads then it lasts a short while and resource consumption goes back down again. I have seen the CPU going from 0 to 32-40% on my laptop (12th Gen Intel(R) Core(TM) i7-1270P 2.20 GHz) but on my mobile the app also loads pretty fast (iPhone XS).
I have two performance profiles (one in dev mode, running locally and one in prod which I can share with you over email if you provide me one - if that is of any use.
Now, looking back at the results I provided from the Lighthouse, I saw something interesting which maybe impacting the overall load time which again, may or may not be related to the CLS issue - I think it is worth checking it because it could have a side effect:
I was running DEV:SSR locally and, with CACHE DISABLED I paid close attention to the JS files that were loaded. I could clearly see the list of dependencies that are loaded which perfectly match all the standalone components I have on the route to be rendered:
Then I looked at the Lighthouse results which was telling me that I could reduce the unused JS. That, I thought could have an impact in the performance hence it could also impact somehow in the CLS score. So I opened the PROD version of the page (https://www.micarburante.com/gasolineras-en-granada/granada/shell-avenida-del-conocimiento-1-12355 - in order to perform the same test, please do not accept the cookies because other components are loaded once you have accepted them. The safest is to open in Incognito window) and looked at all the JS files beign loaded:
Then I matched them all against the chunks that were produced by Angular when running ng build
in PROD mode:
And there were two things that I could not understand. If you take a look, the chunks 7680.XXX.js
, 4567.XXX.js
and 9329.XXX.js
correspond to the gas-stations-provinces-gas-stations-province-gas-stations-province-component
(a different component rendered on a different route so in my view that should not be loaded) and the home-home-home-component
(last 2 chunks) which obviously is the home page and should not be loaded either.
I am sure I have no dependencies to those modules and I searched for them in the code that could cause Angular to pull the modules:
So to me it seems that the final PROD bundle, somehow, is including JS from other pages and it shouldn't. Note that I have FontAwesome installed and I think that is also causing us a performance hit from what we have investigated, but in any case we are applying many strategies to get the best performance possible: using OnPush change detection where possible (and reviewed change detection cycles using Angular Profiler), using interesection observers to hide elements under the fold, using track-by functions, removing the unused CSS using PurgeCSS...My believe is that somehow the FontAwesome code is being spread across those modules and therefore they get referenced instead of having a separate chunk just for that. We are using a few icons here and there and for now we are referencing the module in the standalone component in question and import the icon using deep paths so that the minimum code gets referenced - as suggested by FA.
Finally, to give a bit more visibility about the infrastructure, the set up is a full standalone component SSR solution, running on a node:18.10-alpine
Docker container on a 16GB machine with 8 virtual CPUs. The performance monitor of the server is pretty good and stable so I don't expect to be that the root cause. The APP is behind a NGINX acting as reverse proxy to send traffic to that particular container.
I have deployed a new version of the site withinlineCriticalCss: true
so that all optimizations are enabled to see if there is any difference and run a CPU monitoring - again I am not sure if that's what you mean, otherwise let me know and we can test:
Also we considered looking at this dependency mistery, what I can say, and there is no doubt about it, is that at the very moment I enable inlineCriticalCss the overall performance of the application gets reduced and I also have a worse CLS score. That happens toggling that flag instantly in the Lighthouse score so there is definitely something ELSE that is ALSO going on that is affecting it.
I'm happy to discuss that further on a call if needed
Hi @CarlosTorrecillas, thanks for the detailed information but it feels like we are diverging from the original issue which is that critical css inlining is slow, which needs to be benchmarked and profiled on the server.
I did mean a CPU profile (of the server) which can be captured by Chrome devtools. There is a good explanation https://github.com/angular/angular-cli/issues/8259#issue-269908550 on how to capture this, although in your case you need to replace ng build
with the script that spawns the node server.
This CPU profile is needed to see part of the code is the bottleneck of critical css inlining which does not happen on the browser. To why CLS has deteriorated with critical css inlining, is completely unrelated to this issue, but again without a minimal reproduction it's hard to tell what is happening. Although I did notice that some elements like cookies-banner-container
only get generated on the client, this can impact CWV negatively especially when critical css inlining is enabled as certain CSS classes might be missing.
Overall, I think your issue is completely unrelated to issue reported here, which is about critical css inlining is slow on the server.
OK cool, I am able to get the debugger attached but in my case, as we want to debug the server I am doing:
"debug": "node --max-old-space-size=8192 --inspect --inspect-brk dist/server/main.js"
because we want to debug the server. Then I get the debugger attached and it breaks at the very top line of the first file and I hit play so that I get the node server running.
After that I am not able to see the Profilter tab in Chrome DevTools. I only see a Performance tab which seems to be capturing only Memory but not CPU.
Any ideas?
@alan-agius4 , I have managed to run a node CPU profiler using another command so I can share some results and hopefully they can be of some use.
SETTING INLINE CRITICAL CSS TO TRUE
`Statistical profiling result from isolate-000001F0AEA656E0-4000-v8.log, (574 ticks, 0 unaccounted, 0 excluded).
[Shared libraries]: ticks total nonlib name 507 88.3% C:\Windows\SYSTEM32\ntdll.dll 66 11.5% C:\Program Files\nodejs\node.exe
[JavaScript]: ticks total nonlib name 1 0.2% 100.0% LazyCompile: *assertTNodeForTView C:\git\jq.micarburante.website\dist\server\main.js:64991:29
[C++]: ticks total nonlib name
[Summary]: ticks total nonlib name 1 0.2% 100.0% JavaScript 0 0.0% 0.0% C++ 1 0.2% 100.0% GC 573 99.8% Shared libraries
[C++ entry points]: ticks cpp total name
[Bottom up (heavy) profile]: Note: percentage shows a share of a particular caller in the total amount of its parent calls. Callers occupying less than 1.0% are not shown.
ticks parent name
507 88.3% C:\Windows\SYSTEM32\ntdll.dll
9 1.8% C:\Program Files\nodejs\node.exe
1 11.1% LazyCompile: ~provideZoneChangeDetection C:\git\jq.micarburante.website\dist\server\main.js:91200:36
1 100.0% LazyCompile: ~internalCreateApplication C:\git\jq.micarburante.website\dist\server\main.js:90382:35
1 100.0% LazyCompile: ~bootstrapApplication C:\git\jq.micarburante.website\dist\server\main.js:95694:30
1 100.0% LazyCompile: ~bootstrap C:\git\jq.micarburante.website\dist\server\main.js:778:19
1 11.1% LazyCompile: ~handle C:\git\jq.micarburante.website\dist\server\main.js:11872:49
1 100.0% LazyCompile: ~next C:\git\jq.micarburante.website\dist\server\main.js:12073:16
1 100.0% LazyCompile: ~dispatch C:\git\jq.micarburante.website\dist\server\main.js:12060:45
1 100.0% LazyCompile: ~handle C:\git\jq.micarburante.website\dist\server\main.js:11872:49
1 11.1% LazyCompile: ~findOne C:\git\jq.micarburante.website\dist\server\main.js:125835:17
1 100.0% LazyCompile: ~findOne C:\git\jq.micarburante.website\dist\server\main.js:125835:17
1 100.0% LazyCompile: ~findOne C:\git\jq.micarburante.website\dist\server\main.js:125835:17
1 100.0% LazyCompile: ~findOne C:\git\jq.micarburante.website\dist\server\main.js:125835:17
1 11.1% LazyCompile: ~executeViewQueryFn C:\git\jq.micarburante.website\dist\server\main.js:75005:28
1 100.0% LazyCompile: ~renderView C:\git\jq.micarburante.website\dist\server\main.js:75165:20
1 100.0% LazyCompile: ~renderComponent C:\git\jq.micarburante.website\dist\server\main.js:75114:25
1 100.0% LazyCompile: ~renderChildComponents C:\git\jq.micarburante.website\dist\server\main.js:75218:31
1 11.1% LazyCompile: ~require C:\git\jq.micarburante.website\dist\server\main.js:96895:49
1 100.0% LazyCompile: ~external/npm/node_modules/domino/lib/Node.js C:\git\jq.micarburante.website\dist\server\main.js:97619:49
1 100.0% LazyCompile: ~__require C:\git\jq.micarburante.website\dist\server\main.js:96895:49
1 100.0% LazyCompile: ~external/npm/node_modules/domino/lib/Document.js C:\git\jq.micarburante.website\dist\server\main.js:104145:53
1 11.1% LazyCompile: ~
SETTING INLINE CRITICAL CSS TO FALSE
`Statistical profiling result from isolate-000002C4FD1A5E40-29108-v8.log, (696 ticks, 0 unaccounted, 0 excluded).
[Shared libraries]: ticks total nonlib name 512 73.6% C:\Windows\SYSTEM32\ntdll.dll 175 25.1% C:\Program Files\nodejs\node.exe 2 0.3% C:\Windows\System32\KERNELBASE.dll
[JavaScript]: ticks total nonlib name 1 0.1% 14.3% Function: ^scanChars C:\git\jq.micarburante.website\dist\server\main.js:108075:25 1 0.1% 14.3% Function: ^runTask C:\git\jq.micarburante.website\dist\server\main.js:44554:14 1 0.1% 14.3% Function: ^nextTick node:internal/process/task_queues:103:18 1 0.1% 14.3% Function: ^insertBefore C:\git\jq.micarburante.website\dist\server\main.js:97450:30 1 0.1% 14.3% Function: ^drainMicroTaskQueue C:\git\jq.micarburante.website\dist\server\main.js:44941:31 1 0.1% 14.3% Function: ^createRenderer C:\git\jq.micarburante.website\dist\server\main.js:95123:19 1 0.1% 14.3% Function: ^ZoneTask C:\git\jq.micarburante.website\dist\server\main.js:44822:16
[C++]: ticks total nonlib name
[Summary]: ticks total nonlib name 7 1.0% 100.0% JavaScript 0 0.0% 0.0% C++ 4 0.6% 57.1% GC 689 99.0% Shared libraries
[C++ entry points]: ticks cpp total name
[Bottom up (heavy) profile]: Note: percentage shows a share of a particular caller in the total amount of its parent calls. Callers occupying less than 1.0% are not shown.
ticks parent name
512 73.6% C:\Windows\SYSTEM32\ntdll.dll
32 6.3% C:\Program Files\nodejs\node.exe
1 3.1% LazyCompile: ~╔ÁLocaleDataIndex C:\git\jq.micarburante.website\dist\server\main.js:62634:44
1 100.0% LazyCompile: ~getLocaleNumberSymbol C:\git\jq.micarburante.website\dist\server\main.js:53973:31
1 100.0% LazyCompile: ~
175 25.1% C:\Program Files\nodejs\node.exe
105 60.0% C:\Program Files\nodejs\node.exe
20 19.0% LazyCompile: ~compileFunction node:vm:316:25
20 100.0% LazyCompile: ~wrapSafe node:internal/modules/cjs/loader:1063:18
20 100.0% LazyCompile: ~Module._compile node:internal/modules/cjs/loader:1103:37
20 100.0% LazyCompile: ~Module._extensions..js node:internal/modules/cjs/loader:1158:37
7 6.7% Function: ^__webpack_require__ C:\git\jq.micarburante.website\dist\server\main.js:129248:39
2 28.6% LazyCompile: ~6649 C:\git\jq.micarburante.website\dist\server\6649.js:4164:8
2 100.0% Function: ^__webpack_require__ C:\git\jq.micarburante.website\dist\server\main.js:129248:39
2 100.0% Function: ^invoke C:\git\jq.micarburante.website\dist\server\main.js:44751:11
1 14.3% LazyCompile: ~97014 C:\git\jq.micarburante.website\dist\server\main.js:96848:8
1 100.0% LazyCompile: ~__webpack_require__ C:\git\jq.micarburante.website\dist\server\main.js:129248:39
1 100.0% Function: ~<anonymous> C:\git\jq.micarburante.website\dist\server\main.js:129435:2
1 14.3% LazyCompile: ~93737 C:\git\jq.micarburante.website\dist\server\6649.js:21111:8
1 100.0% Function: ^__webpack_require__ C:\git\jq.micarburante.website\dist\server\main.js:129248:39
1 100.0% LazyCompile: ~74084 C:\git\jq.micarburante.website\dist\server\6649.js:1164:8
1 14.3% LazyCompile: ~87107 C:\git\jq.micarburante.website\dist\server\main.js:22546:8
1 100.0% Function: ^__webpack_require__ C:\git\jq.micarburante.website\dist\server\main.js:129248:39
1 100.0% LazyCompile: ~63915 C:\git\jq.micarburante.website\dist\server\main.js:24934:8
1 14.3% LazyCompile: ~84040 C:\git\jq.micarburante.website\dist\server\main.js:121308:8
1 100.0% Function: ^__webpack_require__ C:\git\jq.micarburante.website\dist\server\main.js:129248:39
1 100.0% LazyCompile: ~63771 C:\git\jq.micarburante.website\dist\server\main.js:121148:8
1 14.3% Function: ~<anonymous> C:\git\jq.micarburante.website\dist\server\main.js:129480:2
1 100.0% Function: ~<anonymous> C:\git\jq.micarburante.website\dist\server\main.js:1:11
1 100.0% Function: ~<anonymous> C:\git\jq.micarburante.website\dist\server\main.js:1:1
5 4.8% Function: ^writevGeneric node:internal/stream_base_commons:122:23
5 100.0% Function: ^Socket._writeGeneric node:net:891:42
5 100.0% Function: ^Socket._writev node:net:923:36
5 100.0% Function: ^doWrite node:internal/streams/writable:401:17
3 2.9% LazyCompile: ~__webpack_require__ C:\git\jq.micarburante.website\dist\server\main.js:129248:39
1 33.3% LazyCompile: ~34228 C:\git\jq.micarburante.website\dist\server\main.js:52582:8
1 100.0% LazyCompile: ~__webpack_require__ C:\git\jq.micarburante.website\dist\server\main.js:129248:39
1 100.0% LazyCompile: ~97014 C:\git\jq.micarburante.website\dist\server\main.js:96848:8
1 33.3% Function: ~<anonymous> C:\git\jq.micarburante.website\dist\server\main.js:129435:2
1 100.0% Function: ~<anonymous> C:\git\jq.micarburante.website\dist\server\main.js:1:11
1 100.0% Function: ~<anonymous> C:\git\jq.micarburante.website\dist\server\main.js:1:1
1 33.3% Function: ~85028 C:\git\jq.micarburante.website\dist\server\main.js:27649:16
1 100.0% LazyCompile: ~__webpack_require__ C:\git\jq.micarburante.website\dist\server\main.js:129248:39
1 100.0% LazyCompile: ~59936 C:\git\jq.micarburante.website\dist\server\main.js:62493:8
3 2.9% Function: ^compileForInternalLoader node:internal/bootstrap/loaders:316:27
3 100.0% Function: ^nativeModuleRequire node:internal/bootstrap/loaders:353:29
1 33.3% Function: ~<anonymous> node:tls:1:1
1 100.0% Function: ^compileForInternalLoader node:internal/bootstrap/loaders:316:27
1 33.3% Function: ~<anonymous> node:child_process:1:1
1 100.0% Function: ^compileForInternalLoader node:internal/bootstrap/loaders:316:27
1 33.3% Function: ~<anonymous> node:_http_common:1:1
1 100.0% Function: ^compileForInternalLoader node:internal/bootstrap/loaders:316:27
2 1.9% LazyCompile: ~slice node:buffer:599:12
2 100.0% LazyCompile: ~toString node:buffer:789:46
2 100.0% LazyCompile: ~readFileSync node:fs:460:22
2 100.0% LazyCompile: ~Module._extensions..js node:internal/modules/cjs/loader:1158:37
2 1.9% Function: ^setNgReflectProperty C:\git\jq.micarburante.website\dist\server\main.js:74463:30
2 100.0% Function: ^setNgReflectProperties C:\git\jq.micarburante.website\dist\server\main.js:74480:32
2 100.0% Function: ^elementPropertyInternal C:\git\jq.micarburante.website\dist\server\main.js:74422:33
2 100.0% Function: ^╔Á╔Áproperty C:\git\jq.micarburante.website\dist\server\main.js:78094:20
2 1.9% Function: ^executeTemplate C:\git\jq.micarburante.website\dist\server\main.js:74015:25
2 100.0% Function: ^renderView C:\git\jq.micarburante.website\dist\server\main.js:75165:20
2 100.0% Function: ^createAndRenderEmbeddedLView C:\git\jq.micarburante.website\dist\server\main.js:85691:38
2 100.0% Function: ^createEmbeddedViewImpl C:\git\jq.micarburante.website\dist\server\main.js:85796:25
2 1.9% Function: ^createWriteWrap node:internal/stream_base_commons:109:25
2 100.0% Function: ^writevGeneric node:internal/stream_base_commons:122:23
2 100.0% Function: ^Socket._writeGeneric node:net:891:42
2 100.0% Function: ^Socket._writev node:net:923:36
2 1.1% Function: ^╔Á╔Áproperty C:\git\jq.micarburante.website\dist\server\main.js:78094:20
1 50.0% LazyCompile: ~BreadCrumbsComponent_ng_container_0_div_1_ng_container_3_ng_container_1_Template C:\git\jq.micarburante.website\dist\server\6649.js:775:90
1 100.0% Function: ^runInContext C:\git\jq.micarburante.website\dist\server\main.js:73733:15
1 100.0% Function: ^executeTemplate C:\git\jq.micarburante.website\dist\server\main.js:74015:25
1 100.0% Function: ^refreshView C:\git\jq.micarburante.website\dist\server\main.js:75443:21
1 50.0% Function: ^GasStationFuelPriceComponent_Template C:\git\jq.micarburante.website\dist\server\6649.js:1080:61
1 100.0% Function: ^runInContext C:\git\jq.micarburante.website\dist\server\main.js:73733:15
1 100.0% Function: ^executeTemplate C:\git\jq.micarburante.website\dist\server\main.js:74015:25
1 100.0% Function: ^refreshView C:\git\jq.micarburante.website\dist\server\main.js:75443:21
2 1.1% Function: ^scheduleTask C:\git\jq.micarburante.website\dist\server\main.js:45286:24
2 100.0% LazyCompile: *scheduleTask C:\git\jq.micarburante.website\dist\server\main.js:44600:19
2 100.0% Function: ^scheduleMacroTask C:\git\jq.micarburante.website\dist\server\main.js:44638:24
2 100.0% Function: ^scheduleMacroTaskWithCurrentZone C:\git\jq.micarburante.website\dist\server\main.js:45049:42
2 100.0% Function: ^<anonymous> C:\git\jq.micarburante.website\dist\server\main.js:45294:63
2 1.1% Function: ^<anonymous> C:\git\jq.micarburante.website\dist\server\main.js:46686:39
2 100.0% Function: ^<anonymous> C:\git\jq.micarburante.website\dist\server\main.js:45314:63
2 100.0% Function: ^proto.<computed> C:\git\jq.micarburante.website\dist\server\main.js:45272:30
1 50.0% Function: ^resume node:internal/streams/readable:989:16
1 100.0% Function: ^Readable.resume node:internal/streams/readable:975:37
1 50.0% Function: ^onwrite node:internal/streams/writable:428:17
1 100.0% Function: ^afterWriteDispatched node:internal/stream_base_commons:155:30
2 1.1% Function: ^<anonymous> C:\git\jq.micarburante.website\dist\server\6649.js:22324:56
2 100.0% C:\Program Files\nodejs\node.exe
2 100.0% Function: ^joinAttributes C:\git\jq.micarburante.website\dist\server\6649.js:22323:24
2 100.0% Function: ^toHtml C:\git\jq.micarburante.website\dist\server\6649.js:22443:16
1 50.0% Function: ^<anonymous> C:\git\jq.micarburante.website\dist\server\6649.js:23057:40
1 50.0% C:\Program Files\nodejs\node.exe
`
After that I am not able to see the Profilter tab in Chrome DevTools. I only see a Performance tab which seems to be capturing only Memory but not CPU.
The performance tab captures CPO profile by default as far as I recall. I am not quite sure on how can I interprit the above sent profiles as there is no timing information.
@alan-agius4 , I have tried again and did a "Performance" recording.
INLINE CRITICAL CSS FALSE
INLINE CRITICAL CSS TRUE
I have both profile files which I can send if needed via email.
Let me know if that is of any use.
Please do send them via email or you can zip them and upload them here.
There you go.
Hi @CarlosTorrecillas,
Thanks for the profiles.
I checked the profiles and critical css inlining is actually pretty fast in your case considering the large amount of nodes the DOM has. In total it takes around 78ms to perform the CSS inlining. It starts at around 1580ms in the profile.
Summary
The increase in CWV, (Which again is not related to this issue), is likely due some styles not being properly extracted. There can be multiple reasons for this, the main once being;
Finding the cause of an Increased CLS, should be straight forward in this case with Chrome devtools. If indeed you find that the root cause is a bug please file a new issue with a minimal reproduction
Closing as it does not seem that we had further reports that critical css inlining is slow. If you do encounter an issue were critical css inlining process is slow, please file a new issue with a minimal reproduction or at the very least a CPU profile of the server during request handling.
if so, it will be better if critters of chromelabs have some warning or notice about this. anyway, I have inlineCriticalCss work as expect without problem. Mostly project fail on this because it have issue on DOM or CSS extract, I can confirm that
Thanks for the feedback. Definitely will look at that. I only wonder how do you guys know the CSS extractor has a bug? How can you see that? Are you talking about the actual PurgeCSS itself? If so, do you recommend another extractor that won’t have that issue?
in terms of the CLS process and overall CWV I won’t be loading in the browser the components to see the difference…I will to run the DevTools to see the CLS problem yet I could not see previously by looking at the timeline/charts with the code run…
mostly, css death because component render process is delay, check your settimeout + observable, document.[anything] which cause the system try to render and... hanging. Yes hard to debug, use binary check. Turn off half off your module. Then test, then test the half other, one by one. Isolate your supicious page, check 404, about-us and anything simple page first, the one only render component and finish. If it work, it mean other have problem. Then one by one... It will take your time, about few week, maybe few month. Just try to check with your debug devtool with nodejs. Good luck sir. I know it is the hard way. BTW, only check in morning after a cup of coffee and about few hours only. Or you will accident punch your screen because don't know why :) if you want private join to check I can take a hand. Contact hiepxanh@gmail.com for more detail if you prefer my help.
This issue has been automatically locked due to inactivity. Please file a new issue if you are encountering a similar or related problem.
Read more about our automatic conversation locking policy.
This action has been performed automatically by a bot.
🐞 Bug report
What modules are related to this issue?
Is this a regression?
No
Description
Recently I tried to enable inlineCriticalCss on our project. And had to roll it back quickly - SSR times jumped sky high.
styles.css
in our project is around 250KB. This includes Angular Material (core + theme) and a number of old-style components that have not been converted tostyleUrls
yet. However even if I strip it down to bare minumum - it's still ~100KB (majority of that are Material styles).HTML is also somewhat significant - 200KB (after I stripped it off of transfered state), and contain 1500 DOM nodes.
Profiling shows that most of the css inlining time is spent on
findOne
call.My understanding is that
critters
has complexity roughlyO(N * S)
, where N is number of DOM nodes, and S is number of selectors in the stylesheets. That's because it queries every selector against the DOM. And our stylesheet (the minimal version) has 1000+ selectors. The regular prod version of the stylesheet - 2600 selectors.I'm wondering if it could be improved by grouping selectors and discarding a whole group if the top-most selector was not found. E.g if we checked
.mat-button
selector and didn't find any matching node - there is no point in looking for more specific selectors like.mat-button .mat-button-focus-overlay
🔬 Minimal Reproduction
🌍 Your Environment