Micro Frontends - Websites / Custom Elements / Clientside Transclusion

Micro Frontends

https://micro-frontends.org/

Example Code using Custom Elements / CustomEvent

• Use innerHMTL property to attach sub DOM
• Shows usage of observedAttributes
• PubSub via CustomEvent, EventTarget
• Shows that every method of a Custom Element can be called on that element

Example using Skeleton Screen to eliminate page reflow. Also see

Micro­service Websites

https://gustafnk.github.io/microservice-websites/

Clientside transclusion for dynamic content (non-SEO-relevant) using h-include / include-fragment / hinclude.

Some salient point from Manifesto:

Heterogenous system (Evolvability)

• Allowing for diversity of technology (including different versions of software) is critical for evolvability
• The architecture itself should not be a limit for diversity of technology. Instead, the limit should other organisational factors, like being able to quite easily move between teams, etc

No shared libraries or frameworks in the client

• …because of coupling between teams, Heterogenous system, and Mobile performance
• Use a common base of JS polyfills and CSS resets. This should be regarded as infrastructure. Possibly have a small set of typography CSS rules as well.

Teams are responsible for their assembled pages

• Use a performance budget
• If a fragment is not good (operational, performance, etc), either it can no longer be used or it must immediately be fixed
• It’s ok for a page to depend on a JS library, as long as the page is within budget and is following agreed policies around accessibility, etc
• It’s not ok for a fragment to depend on a JS library

Self-Contained Systems

http://scs-architecture.org/





 

Notes about Web performance 2

# Critical Render Path

- https://calendar.perfplanet.com/2012/deciphering-the-critical-rendering-path/
- https://developers.google.com/web/fundamentals/performance/critical-rendering-path/

# Lifecycle Events, Navigation Timing API, Document.readyState

- The document is marked as “interactive” when the user agent stops parsing the document. Meaning, the DOM tree is ready.
- The user agent fires the DOMContentLoaded (DCL) event once any scripts marked with “defer have been executed, and there are no stylesheets that are blocking scripts. Meaning, the CSSOM is ready.

- **DOMContentLoaded** the browser fully loaded HTML, and the DOM tree is built, but external resources like pictures <img> and stylesheets may be not yet loaded
- **load** the browser loaded all resources (images, styles etc)

- https://developers.google.com/web/fundamentals/performance/critical-rendering-path/measure-crp
- https://developer.mozilla.org/en-US/docs/Web/API/Document/readyState

# Javascript

- **defer**: Download in parallel, execute in order just _before_ DOMContentLoaded
- **async**: Download in parallel, execute them as soon as possible in whatever order

Notes about Web Performance

Render-tree construction, layout, and paint

• The DOM and CSSOM trees are combined to form the render tree.
• Render tree contains only the nodes required to render the page.
• Layout computes the exact position and size of each object.
• Paint is the last step that takes in the final render tree and renders the pixels to the screen.

--> https://developers.google.com/web/fundamentals/performance/critical-rendering-path/render-tree-construction?hl=en

 
Render blocking CSS

• CSS is treated as a render blocking resource, which means that the browser will hold rendering of any processed content until the CSSOM is constructed

--> https://developers.google.com/web/fundamentals/performance/critical-rendering-path/render-blocking-css?hl=en


DOM blocking scripts

• Executing an synchronous inline/external script blocks DOM construction.
• The script is executed at the exact point where it is inserted in the document. When the HTML parser encounters a script tag, it pauses its process of constructing the DOM and yields control over to the JavaScript engine; once the JavaScript engine has finished running, the browser then picks up from where it left off and resumes the DOM construction.

• JavaScript execution blocks on CSSOM: The browser will delay script execution until it has finished downloading and constructing the CSSOM and during this time the DOM construction is also blocked.

• This is because JavaScript can query and modify the DOM and CSSOM

--> https://developers.google.com/web/fundamentals/performance/critical-rendering-path/adding-interactivity-with-javascript?hl=en


Analyzing critical rendering path performance

--> https://developers.google.com/web/fundamentals/performance/critical-rendering-path/analyzing-crp?hl=en



Navigation Timing API

• domInteractive - The moment just after the browser finished parsing the document including scripts inserted in "traditional" blocking way i.e. without defer or async attribute.

• domContentLoaded - The time just before DOMContentLoaded event is fired, which is just after browser has finished downloading and parsing all the scripts that had defer set and no async attribute.

• domComplete - The point when all resources (e.g. images) required by the page have been downloaded and processed - this is the point when the loading spinner can stop spinning in the browser

--> http://kaaes.github.io/timing/info.html

"The document is marked as “interactive” when the user agent stops parsing the document. Meaning, the DOM tree is ready."

"The user agent fires the DOMContentLoaded (DCL) event once any scripts marked with "defer" have been executed, and there are no stylesheets that are blocking scripts. Meaning, the CSSOM is ready"

"If you add a script and tag it with “defer”, then you unblock the construction of the DOM: the document interactive state does not have to wait for execution of JavaScript. However, note that this same script will be executed before DCL is fired."

"DCL does not have to wait for execution of async scripts"

"The DCL event is also a critical milestone. Many popular libraries, such as JQuery, will begin executing their code once it fires."

--> http://calendar.perfplanet.com/2012/deciphering-the-critical-rendering-path/


Notes about DomInteractive

Fonts: Chrome and Firefox use a three second timeout when waiting for fonts; if the font doesn’t arrive within three seconds then a default font is used. IE11 displays the critical content immediately using a default font. In Chrome, Firefox and IE11, the content is re-rendered when the font file finishes downloading.

--> http://www.stevesouders.com/blog/2015/08/07/dominteractive-is-it-really/


Document.readyState

--> https://developer.mozilla.org/en-US/docs/Web/API/Document/readyState


Custom Metrics

--> https://speedcurve.com/blog/user-timing-and-custom-metrics/


Optimizing the Critical Rendering Path

--> https://www.youtube.com/watch?v=YV1nKLWoARQ#t=704


Speed Index

--> https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/metrics/speed-index

Further Reads

--> https://www.igvita.com/2014/05/20/script-injected-async-scripts-considered-harmful/https://www.igvita.com/2014/05/20/script-injected-async-scripts-considered-harmful/

Some Links regarding blocking

• https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing
• https://stackoverflow.com/questions/29068064/scala-concurrent-blocking-what-does-it-actually-do 
• https://www.typesafe.com/blog/non-blocking-message-flow-with-akka-actors
• https://engineering.linkedin.com/play/play-framework-async-io-without-thread-pool-and-callback-hell

Downloading an entire website using wget

wget --recursive --no-clobber --page-requisites --html-extension --convert-links --no-parent [url]

See: http://www.linuxjournal.com/content/downloading-entire-web-site-wget

Check your page speed

• http://www.webpagetest.org/
• https://developers.google.com/speed/pagespeed/insights/

TCP overview and Wireshark example

Here is a summary of some TCP concepts described in the book "High Performance Browser Networking":

TCP provides an effective abstraction of a reliable network running over an unreliable channel:

• retransmission of data
• in-order delivery
• congestion control & avoidance
• data integegrity

Every TCP connection starts with a three-way handshake ("SYN" -> "SYN ACK" -> "ACK"): Any new connection will have a full roundtrip of latency before any application data can be transferred.

TCP Fast Open: Allows data transfer within the SYN packet (Linux 3.7+ kernels)

Receive window (rwnd): Each side of the TCP connection has its own rwnd which communicates the size of the available buffer space to hold incomming data. Each ACK packet carries the latest rwnd value for each side.

TCP window scaling: Allocated 16 bits place an upper limit of 65KB on the rwnd but "window scaling" raises the max rwnd to 1GB.

  > Check if window scaling is enabled: sysctl net.ipv4.tcp_window_scaling
  > Enable window scaling: sysctl -w net.ipv4.tcp_window_scaling=1

Congestion window (cwnd): Sender-side limit on the amount of data the sender can have in flight before receiving an ACK from the client. cwnd is not exchanged between sender and receiver. It is a private variable of the sender.

The max amount of data in flight is the min of the receive window and the congestion window.

Slow Start: Avoid to overwhelm the underlining network. The cwnd size starts with 4 or 10 (specified April 2013; Linux 2.6.39 kernel) network segments (1,460 bytes when the Max. Transmission Unit is 1500 bytes). For every received ACK the sender can increment its cwnd by one segment. No matter the available bandwidth every TCP connectoin must go thru the slow start phase.

Upon packet loss the cwnd is adjusted to avoid overwhelming the network.

Slow Start Restart (SSR): Resets the cwnd of a connection after it has been idle for a defined period of time. Should be disabled on a server.

  > Check SSR: sysctl net.ipv4.tcp_slow_start_after_idle
  > Disable SSR: sysctl -w net.ipv4.tcp_slow_start_after_idle=0

Head of line blocking: If one packet is lost the all subsequent  packets must be held in the receivers TCP buffer until the lost packet is retransmitted and arrives.


Wireshark Example:
---------------------------------

The file "sfchronicle.pcap" is a capture of the network traffic done with Wireshark of one HTTP get-request (http://www.sfchronicle.com/) between Munich/Germany and San Francisco/USA:

If opened in Wireshark one can see that:

• The latency/round-trip-time is about 210ms between the "SYN" and the "SYN ACK" package
• The first receive window size specified by the client was 29312 bytes (229 multiplied with the specified window scaling factor of 128)
• In later "ACK"s the receive window size was dynamically increased by the client
• The server has an initial congestions window of 10. After sending 10 packets the server had to wait for an "ACK" before being able to send more packets - this introduces another 200ms latency.
• Then the server increased its cwnd with every received "ACK" and could send 20 packets in the next burst before it had to wait again for "ACK"s - another 185ms latency
• In the next burst it could send about 40 packets and then had to wait once more for 165ms. With the following burst it finally managed to transmit all the data

The overall transaction took 1 second with most of the time being latency.

I used "Captcp" to create a nice TCP throughput diagramm from the pcap file.



Further Reads

--> http://calendar.perfplanet.com/2015/tcp-download-breakpoints/