Make network API performance metrics queryable
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 39.9k
- Forks
- 3.4k
- Avg merge
- 7h 27m
- Merged PRs (30d)
- 222
Description
The replay team is currently considering improving PostHog by adding the ability to query network requests response times
We already capture network calls that are made and their performance data using the browsers' built-in PerformanceObserver. But we store these in blob storage as part of the source recording so we can't query them. If these were stored in ClickHouse we could allow you to query them using HogQL.
🗂 Considered Goals
- split ingestion so we also ingest performance data into ClickHouse
- add the PerformanceEntry table into HogQL
- allow search for sessions
- by network status code
- network response time
- allow finding network requests
- by their parent page
- by their target url
- by their resource type
- by their network status
- allow search for sessions
- update insights (once they are converted to use HogQL) so that we can query this data in insights
- allow graphing
- request/response size
- speed
- status
- allow graphing
- build a performance waterfall view on top of this data per session
- build a "lighthouse" performance view on top of this data per page
- show "page score" in the toolbar as you navigate around your site
These goals are being considered by the Replay Team and we'd love to hear user feedback, as well as ideas for stretch goals or implementation. Please add to this issue!
If you like this idea, please leave a 👍 or ❤️ reaction on this post to vote for it -- your votes and feedback help us prioritize what to work on next!
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing the existing browser PerformanceObserver capture and how its data is stored in source recordings. Then map the proposed ingestion into ClickHouse and exposure through HogQL, using the listed query, insight, waterfall, and page-score goals to define scope. Done would require an agreed implementation plan, not just one isolated change.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- clickhouse, javascript
- Domain
- analytics, data, databases
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 18/100