Skip to content

Document page load wait strategy and live view URL handling - #567

Closed
robertjamesprior wants to merge 1 commit into
mainfrom
hypeship/page-latency-and-live-view-security
Closed

robertjamesprior wants to merge 1 commit into
mainfrom
hypeship/page-latency-and-live-view-security

Conversation

@robertjamesprior

Copy link
Copy Markdown

Summary

Two gaps where we have guidance that isn't written down publicly.

browsers/performance — page load latency

The page covered browser creation latency in detail and said nothing about page latency, which is the part a browser agent actually spends its time on.

Adds a section with the measured comparison from a production workload:

Page type domcontentloaded + selector load
Homepage 2.6s 6.6s
Product page 5.4s 8.6s

networkidle did not resolve within an additional 10s budget on either page type, and can never resolve on a long-dwell single-page app.

The recommendation is deliberately not "always use domcontentloaded" — it's domcontentloaded plus the exact actionable selector, because a content-heavy page can reach an app-ready state well after domContentLoaded fires. That caveat is in a Warning so it doesn't get lost.

browsers/live-view — treat the URL as a credential

The page documented readOnly as "the view will be non-interactive" and had no security guidance at all. A developer reading it reasonably concludes readOnly=true makes the URL safe to hand out.

Adds a section covering that the URL grants control of the browser, that readOnly is a display option rather than a security boundary, and that deleting the browser is the revocation path. The existing readOnly bullet now points at it.

Written as guidance about what not to rely on — it does not describe how the limitation is reached. Deliberately framed so embedding the live view in your own app reads as the intended use, because it is; the point is that your application decides who reaches the URL.

Verification

  • TypeScript, Python and Go examples in the new code group, matching the playwright.execute idiom already used in browsers/playwright-execution
  • example.com as the example host, consistent with the existing Playwright pages
  • Deduped against the existing URL lifetime section rather than restating it; the new section links to it
  • Internal links (/browsers/termination, #url-lifetime, #treat-the-url-as-a-credential) resolve to real pages and headings
  • Not run: mintlify dev. Worth a preview check on the two new in-page anchors before merge.

Context

browsers/live-view was previously tracked as KERNEL-2219, which was closed as not-planned when this content was covered in a customer-facing guide instead. That guide only reaches people we send it to, so the public gap stayed open — this closes it.

🤖 Generated with Claude Code

Performance only covered browser creation latency. Add a page load section with
the measured comparison: domcontentloaded plus a selector against load, and the
fact that networkidle may never resolve on a long-dwell single-page app.

Live view documented readOnly as making the view non-interactive, with nothing
about the URL granting control of the browser or readOnly not being enforced
server-side. Add a section on handling the URL as a credential, and qualify the
readOnly bullet to point at it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@mintlify

mintlify Bot commented Sep 14, 2026

Copy link
Copy Markdown
Contributor

Preview deployment for your docs. Learn more about Mintlify Previews.

Project Status Preview Updated
Kernel 🟢 Ready View Preview Sep 14, 2026, 11:40 AM

💡 Tip: Enable Automations to automatically generate PRs for you.

@robertjamesprior
robertjamesprior deleted the hypeship/page-latency-and-live-view-security branch September 14, 2026 11:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant