sass_inline about django-sass-processor

[Natureshadow]

I agree that inlining CSS is bad practice. The argument about network speeds does not hold, because the requested file will be cached (in constrast, it is transmitted over the wire for every single page load if inlined).

Encouraging such bad practice is beyond the scope of django-sass-processor, imho ;). Closing this issue as @jrief seems to agree.

[ivictbor]

Tested django-sass-processor===0.8.2 on Django 3.2 and manifested issue was not there.

[jrief]

The problem with inlining is, that you still have to create the file. That's what you do in your example. Then however that content always will be included into the rendered HTML, otherwise the browser will cache the generated CSS file.

If you have concerns about slow networks and additional requests, go ahead and use django-compressor with django-sekizai.

Another approach is to use HTTP/2.0, there all requests are handled by in the same TCP/IP session.

[ivictbor]

he argument about network

Where it would be cached? Are you aware of the Google Page speed insight and May 21 SEO update? It loads simulation with a clear cache like a new user comes to read your content. So there will be no browser cache and PSI (lighthouse) simulates throttled network with big ping, so if you think your CDN will cache it be aware you will have ping time to CDN server, because of throttled delay. and you will double request the time of the critical render path.

I agree that inlining CSS is bad practice

I even can't guess why you think so because it is well-known best practice:
(copy you can google what is web dev and understand their role influence and role in tech)
https://web.dev/extract-critical-css/

Though HTTP 2 might solve it, but for me sounds like a well-known and recommended inlines much simpler and more compatible approach

[Natureshadow]

Where it would be cached? Are you aware of the Google Page speed insight and May 21 SEO update? It loads simulation with a clear cache like new user comes to read your content. The cache and simulates throttled network with big ping, so if you think you will cache CDN your ing to CDN will be still thtrottled and you will double request time

How many of the page loads made from your application are first page loads of new users? I take it you have no links to other pages in your application, and the majority of users come once, look at one page, then leave? If that is the use case, then, and only then, inlining makes sense.

[ivictbor]

How many of the page loads made from your application are first page loads of new users?
There are a lot of niches where it is critical like SEO.
Viral content, any marketing porpuses of Django websites wants EMPTY users, new users, new clients some of them will go down to funnel. Each new empty user might be bounced because of a white page duren several seconds.
https://www.searchenginewatch.com/wp-content/uploads/sites/25/2018/07/think-with-Google.jpg

Well, if you wish to challenge your new "empty cache and mobile network" users or blog readers for patience before inviting to sail funnel then your are thinking right 😉

[Natureshadow]

Well, if you wish to challenge your new "empty cache and mobile network" users or blog readers for patience before inviting to sail funnel then your are thinking right wink

Your argumentation might hold for websites that mainly deliver content (and if speed matters, really should be built into static pages instead of going through a full-blown Django…). I do not think that this is the scope of django-sass-processor — frameworks aiming at delivering content websites through Django will rely on SEO mechanisms, including inlining of content where it makes sense. We do not need t ocopy such functionality into django-sass-processor.