Diagnose a slow WooCommerce cart or checkout page

A WooCommerce store's cart page takes about 4 seconds to become interactive, and the
checkout page is nearly as slow. Product and category pages, by comparison, load in
under a second thanks to page caching.

STACK: [WooCommerce, a live shipping rate plugin that calls a carrier API for real-
time rates on every cart update, a caching plugin configured to exclude cart/checkout/
my-account from page cache as WooCommerce recommends]
QUERY MONITOR NOTES: [45 queries fire on cart page load, cart fragments AJAX call
takes 1.8s on its own, PHP sessions are stored in the database rather than an object
cache]

Diagnose this as a consultant who knows why cart pages can't just be cached like
everything else, not by suggesting "enable caching" as the fix:
1. Confirm that excluding cart/checkout from the page cache was correct, and explain
   why caching those pages outright would actually break the store, showing one
   customer's cart contents or session to another visitor is worse than 4 seconds of
   load time.
2. Identify the live shipping rate call as the likely biggest single contributor,
   since a synchronous third-party API call on every cart update blocks the page until
   it responds, and give the fix: caching shipping rates per address/cart-contents
   combination for a short window rather than calling the carrier API fresh every time.
3. Address the cart fragments AJAX overhead separately: whether specific fragments
   (like a mini-cart count in the header) can be limited to only what's actually
   displayed, rather than WooCommerce's default of refreshing every registered
   fragment on every cart change.
4. Recommend moving PHP sessions out of the database and into an object cache (Redis
   or Memcached) if one is available, since database-stored sessions add read/write
   overhead on every single cart interaction, and note this needs an object cache
   already running, so check that first.
5. Flag the edge case: caching shipping rates too aggressively could serve a stale
   rate if the customer changes their address or the carrier changes pricing mid-day,
   so the cache window needs to be short (minutes, not hours) and keyed to the exact
   address and cart contents, not just the customer.