extension_id=jifpbeccnghkjeaalbbjmodiffmgedin # change this ID
curl -L -o "$extension_id.zip" "https://clients2.google.com/service/update2/crx?response=redirect&os=mac&arch=x86-64&nacl_arch=x86-64&prod=chromecrx&prodchannel=stable&prodversion=44.0.2403.130&x=id%3D$extension_id%26uc"
unzip -d "$extension_id-source" "$extension_id.zip"Thx to crxviewer for the magic download URL.
All of the below properties or methods, when requested/called in JavaScript, will trigger the browser to synchronously calculate the style and layout*. This is also called reflow or layout thrashing, and is common performance bottleneck.
Generally, all APIs that synchronously provide layout metrics will trigger forced reflow / layout. Read on for additional cases and details.
elem.offsetLeft, elem.offsetTop, elem.offsetWidth, elem.offsetHeight, elem.offsetParent
| // ==UserScript== | |
| // @name UTM param stripper | |
| // @author Paul Irish | |
| // @namespace http://github.com/paulirish | |
| // @version 1.2 | |
| // @description Drop the UTM params from a URL when the page loads. | |
| // @extra Cuz you know they're all ugly n shit. | |
| // @include http*://* | |
| // ==/UserScript== |
I've heard this before:
What I really get frustrated by is that I cannot wrap
console.*and preserve line numbers
We enabled this in Chrome DevTools via blackboxing a bit ago.
If you blackbox the script file the contains the console log wrapper, the script location shown in the console will be corrected to the original source file and line number. Click, and the full source is looking longingly into your eyes.
Just jotting some notes on delivering webfonts performantly…
still an incomplete draft.
Critical fonts are neccessary for the above-the-fold content to be useful. Identify which of the fonts you NEED for the first render, as they get very different treatment vs the others.
You want the network reqs for your critical fonts to start ASAP. ideally the @font-face req is in a style tag, following CRP guidelines
A few conversations have circled around user-side structural profiling. For context, see React PR #7549: Show React events in the timeline when ReactPerf is active
One particular concern is the measurement overhead. This gist has a benchmarking script (measure.js) for evaluating overhead and initial results.
Runs about 0.65µs per mark() call. Naturally, that's ~= an overhead of 1ms for 1500 mark()s.
I say "animated gif" but in reality I think it's irresponsible to be serving "real" GIF files to people now. You should be serving gfy's, gifv's, webm, mp4s, whatever. They're a fraction of the filesize making it easier for you to deliver high fidelity, full color animation very quickly, especially on bad mobile connections. (But I suppose if you're just doing this for small audiences (like bug reporting), then LICEcap is a good solution).
none (default)layout, paint, style - the easy ones.
content === these threecontain: layout -- any pos:fixed children will be relative to it.size - harder. the element must define its own size, can't rely on laying out its children.
strict === content + sizeinline-size - dunno? size but for display:inline-ish things?| // http://paulirish.com/2011/requestanimationframe-for-smart-animating/ | |
| // http://my.opera.com/emoller/blog/2011/12/20/requestanimationframe-for-smart-er-animating | |
| // requestAnimationFrame polyfill by Erik Möller. fixes from Paul Irish and Tino Zijdel | |
| // MIT license | |
| (function() { | |
| var lastTime = 0; | |
| var vendors = ['ms', 'moz', 'webkit', 'o']; |
| // everyone's new favorite closure pattern: | |
| (function(window,document,undefined){ ... })(this,this.document); | |
| // when minified: | |
| (function(w,d,u){ ... })(this,this.document); | |
| // which means all uses of window/document/undefined inside the closure | |
| // will be single-lettered, so big gains in minification. | |
| // it also will speed up scope chain traversal a tiny tiny little bit. |