[Note: I wrote this 03-31-2015 with the primary subject being CDW.com. This was my research at the time and not all statements may be true.]
- Terms
- Page Performance
- How fast the page loads
- User Experience (in this context)
- How fast the user thinks the page loads
- Parse
- Break into pieces, and/or step through the pieces.
- Page performance vs. user experience
- A page can perform well, but be a bad user experience.
- More about this later.
- Load times
- Optimal: under 1 sec
- How fast is the CDW.com homepage?
- 5 seconds
- 2171 DOM elements
- (Source: http://www.webpagetest.org)
- How a page is built/rendered
- The execution is top down and single threaded.
- Single threaded: processing one command at a time
- As soon as the parser hits a closing script tag, it must download and execute the entire script before parsing any more of the HTML (source).
- “This means often the parser must idly wait while scripts and stylesheets are downloaded.”
- Unless it has the async attribute.
- JS can not execute until all CSS has been downloaded.
- $(document).ready() fires when the DOM is complete. – not necessarily needed
- It seems that’s when all CSS is downloaded and all JS has been executed… that can not be right.
- $(document).ready() fires when the DOM is complete. – not necessarily needed
- Process (overly simplistic)
- Read the HTML and parse it into a DOM tree.
- Load linked resources (stylesheets, scripts, images, media)
- Calculate the page layout (positions, sizes, colors, fonts, etc.)
- Render the page
- Make it faster (for real):
- Reduce file size – greatest advantage here usually
- Reduce number of files
- Move CSS and JS to external files
- Research blocks of styles – how bad this – Solutions pages
- Definitely, this should go into an external file
- Research blocks of styles – how bad this – Solutions pages
- Reduce the number of inline scripts
- Use CSS/HTML to replace images where possible
- Reduce the number of domains which your assets are called from
- Images: set height and width so browser doesn’t have to calculate this
- Is this still true? Especially given responsive design
- Use valid markup
- Browsers do not need to error-correct when you do this
- Reduce by depth
- When reflow happens, it executes faster if DOM is not super deep.
- Target a select set of browsers to develop for
- “Do not require your content to appear pixel-perfect in all browsers” (https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Tips_for_authoring_fast-loading_HTML_pages)
- Smart page structure
- head
- css
- scripts (necessary during page load)
- body
- content
- scripts (not necessary during page load – majority of scripts should go here)
- Scripts are parser blocking, meaning when the browser comes to a script tag, it downloads the entire file before continuing with the parsing.
- head
- Javascript calls
- Use async where possible <script async >
- “Otherwise the browser will not render anything that is after the script tags that do not have these attributes.”
- Good to use when the DOM does not need to be finished while this JS runs and when no other scripts depend on this one being loaded.
- Best used for third party scripts.
- There’s no need to use async of script is loaded at the bottom of the page.
- Download and execute while the page is loading.
- Use async where possible <script async >
- Minimise browser reflow
- “Reflow is .. the web browser process for re-calculating the positions and geometries of elements in the document” (source)
- What triggers reflow?
- Add/remove element from the DOM
- Change an element’s class
- Resize the window
- Optimize CSS
- Remove unused CSS
- Minimize complex CSS selectors – descendant selectors in particular
- This may be something that we ignore as we use a CSS preprocessor. And that’s fine with me.
- Optimize JS
- Make it faster (perceived)
- Speed Index: time for above-the-fold content to load (source)
- Load content above the fold quicker than all other content.
- Place most important/desired content at the top
- Perception of speed is influenced by how efficiently users can get what they most want out of your site
- Reassure users during wait times.
- Chrome dev tools and Firebug
- Chrome – Network panel – better
- Nifty options at the top, “from cache”
- Firefox – Net panel – has some cool stuff
- Browser differences
- “in Firefox there is this setting which limits the number of simultaneous requests per domain”
- How fast is my function?
- var t0 = performance.now();
[function here]
var t1 = performance.now();
console.log(“Call to doSomething took ” + (t1 – t0) + ” milliseconds.”); - Chrome – Profiles – “Collect JavaScript CPU Profile”
- Start the profile, refresh the page, and then stop the profiler
- Sources
- https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Tips_for_authoring_fast-loading_HTML_pages
- http://gent.ilcore.com/2011/05/how-web-page-loads.html
- http://stackoverflow.com/questions/1795438/load-and-execution-sequence-of-a-web-page
- Kind of helpful page on the “Net” panel in Firebug: https://getfirebug.com/wiki/index.php/Net_Panel
- http://www.smashingmagazine.com/2012/06/12/javascript-profiling-chrome-developer-tools/
- http://www.sitepoint.com/speed-index-measuring-page-load-time-different-way/
- http://www.sitepoint.com/optimizing-critical-rendering-path/
- https://developer.mozilla.org/en-US/docs/Web/API/Performance.now