A strong answer
I would first clarify whether we are discussing a fresh navigation or a request to a page the browser has already visited. For a fresh HTTPS navigation, the browser parses the URL, applies security and cache rules, and determines whether it can reuse a connection. If it needs an address, it asks the configured resolver to resolve the hostname.
The browser then connects to an address. With HTTP/2, this commonly means establishing TCP and then negotiating TLS. The client validates the service certificate for the requested hostname before sending protected HTTP data. If the browser and server use HTTP/3, QUIC over UDP replaces the separate TCP setup.
The HTTP request may pass through a CDN, firewall, reverse proxy, or load balancer. Those components can serve cached content, reject traffic, or route it to an application server. Application code handles the request and may read a database or call another service. The server returns a status, headers, and content, which travel back to the browser. The browser may keep the connection for later requests and may fetch additional resources such as scripts, styles, and images.
I would avoid claiming that every request performs a new DNS lookup, TCP handshake, and TLS handshake. Caches and connection reuse can skip those steps. I would also separate what the protocols guarantee from choices made by one deployment, such as whether it uses a CDN or how many services handle the request.
How to make the answer precise
State the protocol path you are describing, then name alternatives. HTTP is the request/response layer; TLS protects a connection to its endpoint; TCP or QUIC transports data; DNS helps resolve a name. If asked about latency, break it into name resolution, connection setup, server processing, and response transfer instead of giving one unexplained number.
Continue through the linked HTTPS request trace, then answer the follow-ups without assuming a single fixed network topology.