- Use HTTP/2
- GraphQL
- CSS sprites
- Bundling
- Browser Caching
- Cache Busting
- Proper SSL setup
- Minification
- GZIP
- CSS shortcuts (reduce file size)
- CSS vendor props (increase file size)
- Reduce cookie size (simple user ids vs JW tokens)
- SVG vs Images
- Sprites
- Bundle splitting
- Lazy load images
- script and link tag location
- eliminate duplicate scripts
- https://hacks.mozilla.org/2017/09/building-the-dom-faster-speculative-parsing-async-defer-and-preload/
- https://bitsofco.de/async-vs-defer/
Asynchronous and deferred execution of scripts are more important when the <script> element is not located at the very end of the document. HTML documents are parsed in order, from the first opening element to it's close. If an externally sourced JavaScript file is placed right before the closing element, it becomes much less pertinent to use an async or defer attribute. Since the parser will have finished the vast majority of the document by that point, JavaScript files don't have much parsing left to block.
For script files that are not dependent on other files and/or do not have any dependencies themselves, the async attribute is particularly useful. Since we do not care exactly at which point the file is executed, asynchronous loading is the most suitable option.
Use on scripts like GA (async) and DOM-depending scrips (defer) which for some reasons are located not before </body>
- 3 steps: Fetching -> Parsing -> Execution (-> Rendering (HTML))
- JS fetching blocks HTML & CSS parsing (but not fetching)
- CSS fetching blocks JS execution (but not fetchin & parsing)
- CSS also blocks HTML rendering (DOM construction awaits JS & CSSOM) (unless @media or better media="print")
CSS at the TOP scripts at the BOTTOP basic model takes the above into account:
- fetch CSS -- non blocking for HTML
- parse CSS -- the same
- execute CSS -- blocks HTML rendering, blocks JS execution. Both can be not affected.
- fetch, parse, execute JS -- everything else is done
New speculative parsing (keep parsing even while JS executes) changes some of the above (basically it assumes there won't be "bad" types of document.write). If JS scripts are at the end – it doesn't matter
<link rel="preload" href="font.woff" as="font" crossorigin> - fonts should be preloaded (as they heavily affect rendering)
Font imports may be buried inside CSS and browser won't load them while it's busy with selectors. So it makes sense to start loading them earlier. I would use it for heavy assets.
preload vs async scripts -- preload doesn't delay onload event
preload vs defer vs async -- the last two work ONLY for scripts. preload can behave like async or defer and it's controlled by YOU