Docs: Client-side feature flag querying behavior update (#5244)

Added a detailed explanation into how frontend / client-side SDKs behave
with regards to fetching multiple feature flags and network
connectivity.

Content has been reviewed/approved by engineering rotation team (Simon
and Chris).

website/docs/reference/sdks/index.md

@@ -137,11 +137,24 @@ If you can't find an SDK that fits your need, you can also develop your own SDK.
 - [Unleash Client Specifications](https://github.com/Unleash/client-specification) - Used by all official SDKs to make sure they behave correctly across different language implementations. This lets us verify that a gradual rollout to 10% of the users would affect the same users regardless of which SDK you're using.
 - [Client SDK overview](../client-specification) - A brief, overall guide of the _Unleash Architecture_ and important aspects of the SDK role in it all.
 
+
+## Client-side SDK behavior
+
+The following section details the behavior of frontend / client-side SDKs when initializing and fetching flags with respect to network connectivity.  
+
+When the SDK is initialized in the application, an in memory repository is setup and synchronized against the frontent API using the configured token and context. Note that the frontend API is hosted by either the Unleash Proxy/Edge or the upstream Unleash instance directly.  
+
+1. All feature flag evaluation is performed by the Proxy/Edge or Unleash instance. A payload of all enabled flags and their variants (if applicable) is returned as a single request. Disabled flags are not included.
+
+2. When a page inside the application requests a feature flag, the SDK will return the flag state from memory. No network connection to the frontend API is performed.
+
+3. The SDK periodically syncs with the frontend API to retrieve the latest set of enabled toggles
+
 ## Working offline
 
 Once they have been initialized, all Unleash clients will continue to work perfectly well without an internet connection or in the event that the Unleash Server has an outage.
 
-Because the SDKs and the Unleash Proxy cache their feature toggle states locally and only communicate with the Unleash server (in the case of the server-side SDKs and the Proxy) or the Proxy (in the case of front-end SDKs) at predetermined intervals, a broken connection only means that they won't get any new updates.
+Because the SDKs and the Unleash Proxy/Edge cache their feature toggle states locally and only communicate with the Unleash server (in the case of the server-side SDKs and the Proxy) or the Proxy/Edge (in the case of front-end SDKs) at predetermined intervals, a broken connection only means that they won't get any new updates.
 
 Unless the SDK supports [bootstrapping](#bootstrapping), it _will_ need to connect to Unleash at startup to get its initial feature toggle data set. If the SDK doesn't have a feature toggle data set available, all toggles will fall back to evaluating as disabled or as the specified default value (in SDKs that support that).