Closed Bug 834865 Opened 12 years ago Closed 10 years ago

Web inlining tool


(DevTools :: Inspector, defect)

Windows 7
Not set


(Not tracked)



(Reporter: taras.mozilla, Unassigned)




(1 file)

CSS advice on suggests that devs split css into an "important" inline bit and include the rest near </body>
This is true based on my experiments and 
12:33 <@bz> taras: we start layout after we've seen <body> and all stylesheets from <head> are loaded
12:34 <@bz> taras: furthermore, if there is a stylesheet loading, parsing a <script> tag will not run it until that sheet loads

Having developers do this by hand seems tedious, a browser has sufficient info to automate it.
Attached patch prototypeSplinter Review
Had some spare time. Here is a prototype. Thanks for putting up with my newbness on #devtools.

I tested this on and On this produces a subset of CSS usage that's 3x smaller than what I have in there. On the reduction is 10x.

I haven't tested how well the reduced css works yet. 

I think having 'strip crap from my website' tool that eliminates unused JS, CSS + has option to inline it to speed up pageload would be very cool.

To test this I paste:
let {CssLogic} = devtools.require("devtools/styleinspector/css-logic")
cl = new CssLogic();

into browser console.
Let me try to understand what's happening here and what we could build from that:

This code finds ("extracts") the current used rules. If we run your code after the page has loaded, the code that is NOT extracted can be moved after </body> because it's not required to load the page (it's the "interactive" part of the CSS code, and loading this code would block other important operations). The extracted code should be moved in <head>.

So what we could build would be a GCLI command ("CSS_Snapshot" ?) that would:
- reload the page
- split CSS code in 2 chunks (important vs. interactive code)
- open a new tab, with an explanation about "important vs interactive" and 2 <pre> that would include the 2 chunks

Am I getting this right?
I wasn't sure where to hook up such a tool, was going to ask for ideas. A GCLI command is a great idea!

I think this is a tool to take out menial labor out of reducing the css footprint/overhead. As such the only important part is identifying rules that are used. We can then display those in a single <pre> and the developer can decide what to do with the rest. We should also display a basic statistic like "10% CSS rule utilization", etc. Ideally we'd estimate network overhead savings by seeing how long the page spent waiting for css to download. We'd also want to link to an mdn article explaining that CSS blocks rendering of the page.
Here is another video showing the benefits of such a tool, 20 to 1 second reduction in visible-content-time

Inclining is the next big thing in tools
I suggested inlining css as a first step towards a 'make my page fast' tool...but I didn't make that clear in the bug.

The ideal highlevel tool would: look at the network timeline, figure out resources that are needed to render the page and suggest a proposed improvement (in time to load page) + html with inlined css, modified <script> tags, filled in DOM, etc.
Summary: CSS inlining tool → Web inlining tool
Axel, can you take a look at this?
Flags: needinfo?(akratel)
That's actually a pretty good idea. Sounds to me like we would have to simply "observe" the page load and extract all CSS rules and JS scripts that didn't get used during the initial page load and put them at the end of the page.

It's true that initial load time is critical. 

This should be developed as a plugin first.
Flags: needinfo?(akratel)
Blocks: perf-kanban
Bug 975522 looks like we can handle this by splitting rules into 3 groups - initially-used / used-later-unused.
Closed: 10 years ago
Resolution: --- → DUPLICATE
Joe, I think it's useful to have a tool that produces a inlined css to cut/paste as a result. Unless the other bug will have that, this isn't a dupe
(In reply to Taras Glek (:taras) from comment #9)
> Joe, I think it's useful to have a tool that produces a inlined css to
> cut/paste as a result. Unless the other bug will have that, this isn't a dupe

Agreed. I think it would be good to have a GCLI command that shows you all 3 parts.

>> export css --used --clipboard
>> export css --initial --tab

(I've not spent much time thinking about how the command should work, but something like that)
Whether it gets done in bug 975522 is a matter of the progress I make with that bug (I have a deadline!)
For now, I'll reopen this, so it's not lost.  If you get it done in 975522, dupe away!
Resolution: DUPLICATE → ---
Closed: 10 years ago10 years ago
Resolution: --- → DUPLICATE
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.