A signed-in member is served the same stored copy of a public page as anyone else, so slowness for members comes from what renders for them. In order:

  1. The pages they use are the ones that always render. Member pages under /my-account, members-only records and the cart are never stored, for anyone. Their cost is the full render on every view, so they are where query-per-row hurts most (member areas and carts).
  2. Fragments render on every page view. A cached public page that fetches a personal fragment pays for that fragment on every view of every member. A fragment that loads a menu, a list or a cart line by line is a slow page in disguise. Keep fragments small (in a fragment template).
  3. Per-member lists without a limit. Order history, enrolments or saved items printed in full grow with the member's history. Paginate them.
  4. The session cookie. A request carrying PHPSESSID works without the shared Memcached layer, so each render does a little more set-up work. On its own this is a small cost; it matters only on top of one of the above.
  5. It is not a member problem. If staff are signed in to the admin and see a slow site, check whether they are on the same hostname and environment as visitors; staging is often slower and is easy to mistake for production.