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.
elem.offsetLeft, elem.offsetTop, elem.offsetWidth, elem.offsetHeight, elem.offsetParentelem.clientLeft, elem.clientTop, elem.clientWidth, elem.clientHeightelem.getClientRects(), elem.getBoundingClientRect()
I wanted to figure out the fastest way to load non-critical CSS so that the impact on initial page drawing is minimal.
TL;DR: Here's the solution I ended up with: https://github.com/filamentgroup/loadCSS/
For async JavaScript file requests, we have the async attribute to make this easy, but CSS file requests have no similar standard mechanism (at least, none that will still apply the CSS after loading - here are some async CSS loading conditions that do apply when CSS is inapplicable to media: https://gist.github.com/igrigorik/2935269#file-notes-md ).
Seems there are a couple ways to load and apply a CSS file in a non-blocking manner:
| # to generate your dhparam.pem file, run in the terminal | |
| openssl dhparam -out /etc/nginx/ssl/dhparam.pem 2048 |
| public class SomeFragment extends Fragment { | |
| MapView mapView; | |
| GoogleMap map; | |
| @Override | |
| public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) { | |
| View v = inflater.inflate(R.layout.some_layout, container, false); | |
L1 cache reference ......................... 0.5 ns
Branch mispredict ............................ 5 ns
L2 cache reference ........................... 7 ns
Mutex lock/unlock ........................... 25 ns
Main memory reference ...................... 100 ns
Compress 1K bytes with Zippy ............. 3,000 ns = 3 µs
Send 2K bytes over 1 Gbps network ....... 20,000 ns = 20 µs
SSD random read ........................ 150,000 ns = 150 µs
Read 1 MB sequentially from memory ..... 250,000 ns = 250 µs