Webhook publishers send event notifications that require DNS resolution, TCP connection, and TLS handshake before data is received. The round trip times for these handshakes are the main network cost for distant receivers. Publishers impose strict timeouts for responses, with some offering retry mechanisms for failed deliveries. This article examines the cost of each handshake step and explores how BGP Anycast can shorten paths. It also discusses the benefits and drawbacks of TCP Fast Open (TFO) and TLS 1.3 0-RTT.Unicast delivery sends all traffic to a single endpoint location, regardless of sender distance. BGP Anycast, conversely, uses multiple points of presence that announce the same IP prefix, allowing senders to connect to a topologically closer site. "Nearest" in Anycast refers to the network path, not necessarily geographical distance. The stability of Anycast can be affected by routing policies, but for short-lived webhook requests, any routing flips are generally brief.Withdrawing routes from unhealthy Anycast points of presence is crucial to prevent traffic blackholing. This can be automated by monitoring service health and using tools like ExaBGP to manage route announcements. TCP Fast Open enables clients to send data in the initial SYN packet on repeat connections, saving a round trip. However, its effectiveness depends on sender support, potential middlebox interference, and the application's ability to handle duplicate data.TLS 1.3 completes its handshake in one round trip, and 0-RTT allows application data to be sent with the initial ClientHello on subsequent connections. This 0-RTT capability is risky for webhook POST requests due to replayability concerns, unless the handler is strictly idempotent. If accepting 0-RTT, deduplication by event ID and using a shared store are essential for replay defense.Combining Anycast with TFO and TLS 1.3 0-RTT offers significant latency reductions. Anycast shortens the fundamental round trip time, while TFO and 0-RTT minimize the number of round trips required for connection setup and data transmission. Even in the most optimized scenarios, some round trip overhead remains. Reusing connections through HTTP Keep-Alive also substantially reduces handshake costs for subsequent deliveries to the same host.