For years, my notes have lived in Markdown. Not because I was forced into it but because I genuinely prefer it. There’s something freeing about writing in plain text. No proprietary formats. No mystery around what the file actually contains. Open it in any editor, on any machine, and it just works. Markdown is humble in the best possible way.

And for almost everything else like code, documentation, changelogs, even this app’s own roadmap; I use GitHub. Commits are how I think. Diffs are how I review. The repository is the source of truth.

So when I sat down to think about what Mandrill needed next, the answer arrived quickly. Almost embarrassingly quickly. My notes are Markdown. My workflow is GitHub. Of course these two things should talk to each other.

The Missing Link

Here’s a scenario I found myself in repeatedly.

I’d open a folder of notes in Mandrill; maybe a collection of meeting notes, a set of ideas I was developing, or documentation for a project. I’d edit a few files. Then I’d flip over to Terminal, remember which folder I was in, and run git add . && git commit -m "update notes" && git push. Every single time. I even made a shortcut.

The cognitive tax wasn’t huge, but it was there. A small speed bump between thinking and shipping. And speed bumps compound.

The folder was already a Git repository. Mandrill could see it. The .git folder was right there. All the information needed to understand the state of those files was sitting in plain sight. Mandrill just wasn’t looking.

What Changed

The latest update to Mandrill adds native GitHub integration, and it starts with something small: detection.

When you open a folder that’s backed by a Git repository, Mandrill now recognizes it. You’ll see it indicated right in the interface; a subtle but clear signal that this isn’t just a folder of files, it’s a folder with a history, a remote, and a purpose. The repository context is always visible.

From there, Mandrill tracks the state of your files. Edited a note? You’ll see it marked as modified in the sidebar. The visual feedback is immediate; the same kind of awareness you’d get in a proper code editor, now applied to your Markdown notes. You always know what’s changed and what hasn’t.

And when you’re ready to push those changes? You don’t need to leave Mandrill. A single action commits and pushes everything to your remote repository. No terminal switch. No copy-pasting paths. No wondering which branch you’re on. Your notes are synced with the same gesture it takes to save a document.

Why This Matters (to Me, at Least)

I build Mandrill for myself first. I am, in many ways, the target user: someone who writes a lot of Markdown, thinks in plain text, and lives inside a GitHub workflow. When I add a feature, it’s usually because I got tired of working around the absence of it.

This one I got tired of quickly.

There’s a particular kind of friction that’s hard to articulate until it’s gone. It’s not painful enough to stop you, but it’s present enough to remind you, every single time, that the tools aren’t quite working together. Switching to Terminal to push a commit felt like that. A constant small interruption.

Now it’s gone. I open a folder, I write, I see what changed, I push. The loop is closed inside a single app. GitHub integration. Open a Git-backed folder and Mandrill identifies it instantly. Modified files are flagged in the sidebar. Push everything to GitHub in one click, without leaving the app. —

The Broader Idea

I think a lot about what it means for an app to be native, not just in the technical sense (though Mandrill is genuinely a native macOS app, built with SwiftUI, no Electron in sight), but in the philosophical sense. A native experience respects the way you already work. It meets you in your workflow rather than asking you to change it.

For me and I suspect for a lot of developers, Vibe Coders, solopreneurs, and technical writers, the workflow runs through Git. Notes, docs, changelogs, ideas: if it matters, it lives in a repository.

Mandrill now understands that. And it feels, to be honest, like the app finally clicked into place.

Try It

If you use Mandrill and keep any of your Markdown notes in a Git-backed folder, open that folder in the new version. You’ll see the integration light up immediately. The repository is detected, your modified files are tracked, and pushing is one click away.

If you haven’t tried Mandrill yet, it’s on the Mac App Store. Free to try. No accounts. No telemetry. Just a fast, native Markdown editor that now speaks GitHub fluently.

Your notes deserve version control. They probably already have it. Mandrill just got out of the way.

The response was encouraging. But there was one piece of feedback I kept hearing: tabs worked, but they weren’t the right mental model for people who navigate between many files or want to keep their sidebar separate from their reading area. So I rebuilt it.

New: Left navigation panel

The tab bar is gone. In its place is a persistent left-hand navigation panel; a much more natural way to manage multiple open Markdown files. You can see all your documents at a glance, jump between them instantly, and keep your reading area completely clean.

The change might sound small, but it fundamentally shifts how the app feels to use. Instead of a browser-style top bar, you now have something closer to a proper document workspace the kind of focused, structured layout that tools like VS Code and Obsidian have proven works well for file-heavy workflows.

Keyboard shortcuts, finally

If you live at the keyboard, Mandrill 2.0 should feel like home. I’ve added a full set of shortcuts so you can navigate files, toggle the sidebar, and change your reading preferences without ever reaching for the mouse.

Open a file⌘ O

Toggle sidebar⇧ ⌘ D

Toggle Bettween Tabs^ tab

Increase font size⌘ +

Decrease font size⌘ −

Actual Size⌘ 0

Easier font & theme controls

Reading comfort matters. In 2.0 I’ve made it quicker to dial in exactly how you want your Markdown to look. Font size, typeface, and theme; GitHub Light, GitHub Dark, or System (which follows your macOS appearance automatically). These are all a shortcut or one-click away.

This was always the pitch for Mandrill, and 2.0 makes it feel even more true. Less time fiddling with settings, more time actually reading.

Privacy, by design

Zero data collected. Mandrill has no analytics, no crash reporting that phones home, no accounts. The App Store listing reflects this: the developer collects no data from the app, period. What you read stays on your Mac.

What’s next

I’m already thinking about what comes after 2.0. A few things on the list: better support for internal Markdown links, and possibly a way to open folders so you can browse a whole documentation tree in the sidebar.

If you have a feature request or you’ve run into a bug, reach out; I read everything. And if Mandrill is useful to you, an App Store review genuinely helps other developers find it.

Every developer has been there. You clone a repo, open the README.md, and stare at a wall of raw Markdown syntax instead of the formatted document the author intended. So you open VS Code, install a preview extension, and wait. Or you push it to GitHub just to read it. Or you squint and mentally parse the asterisks yourself.

None of those are good answers. That frustration is exactly why I built Mandrill.

Mandrill does one thing: it opens a *.md file and renders it beautifully. That’s it.*

Built for the way developers actually work

Mandrill is a native macOS application. Drag a file onto it, or open one from the file picker, and your Markdown is rendered instantly; headings, code blocks, tables, task lists, and all. No setup wizard. No account. No cloud sync. The file never leaves your machine.

What’s Inside

• Renders GitHub-flavored Markdown including headings, tables, task lists, and blockquotes
• Syntax highlighting in fenced code blocks
• Drag-and-drop or standard file picker — open any.mdfile in one step
• Fully offline — no network requests, ever
• No account, no sign-up, no data collected of any kind
• Lightweight and fast — launches in under a second

Privacy by design

Mandrill has no analytics, no crash reporting, and no telemetry of any kind. We have no idea how many people use it, what files they open, or where they are in the world and I prefer it that way. Your files are yours. The app is a tool, not a data collection endpoint.

This also means Mandrill works in air-gapped environments, on planes, and anywhere else you need to read a document without a network connection.

A small app with a clear purpose

I deliberately kept Mandrill small. It isn’t a Markdown editor (yet), a note-taking app, or a writing environment. Those tools exist and many of them are excellent. Mandrill fills a specific gap: reading Markdown files quickly, cleanly, and without friction. If you find yourself reaching for a heavy editor just to preview a document, Mandrill is the tool that was missing from your Mac.

At Sensoji, one of the oldest and most storied temples in Tokyo, it’s easy to get swept up in the crowds, the incense smoke, and the energy of Asakusa. But sometimes, the most memorable moments come when you pause and look above it all. The bold vermilion beams cut sharply against a soft, washed out, empty sky. The layered rooflines, almost floating, reveal the precision and symmetry that define traditional Japanese architecture. Every joint, every curve, every ornamental detail feels intentional; crafted not just for structure, but for beauty.

What stood out to me wasn’t just the scale of the temple, but the quiet discipline in its design. Even in a place filled with thousands of visitors, there are these pockets of stillness. If you isolate a single frame the noise disappears, leaving only form, color, and history.

Senso-ji dates back to the 7th century, yet it doesn’t feel old in the way ruins do. It feels preserved. Alive. Maintained with care and respect, as if each generation understands they are only temporary custodians of something much larger than themselves.

And maybe that’s what this image represents. Not just a temple but continuity.

A reminder that even in a fast-moving city like Tokyo, there are places where time slows down. Where craftsmanship outlives trends. Where looking up is enough to ground you.

Consider the analogy of watching a movie of equal duration, where the total time is constant. When the movie maintains a consistent frame rate of 24fps, it appears smooth and immersive. Conversely, if the movie randomly fluctuates between 5-60fps, it becomes janky and even irritating.

Consistency matters!

**Inter-Arrival Time **is simply the time gap between receiving consecutive chunks of data.

For Example:

Chunk 1 arrives at: 0ms
Chunk 2 arrives at: 45ms    → Inter-arrival: 45ms
Chunk 3 arrives at: 90ms    → Inter-arrival: 45ms
Chunk 4 arrives at: 180ms   → Inter-arrival: 90ms
Chunk 5 arrives at: 220ms   → Inter-arrival: 40ms

Average inter-arrival time: (45 + 45 + 90 + 40) / 4 = 55ms

Why Inter-Arrival Time is Critical

Perceived Performance

1. Inconsistent (Bad):

   Gaps: 10ms, 500ms, 20ms, 400ms, 15ms, 600ms Average: 257ms Feeling: Stuttery, unpredictable, frustrating

2. Consistent (Good):

   Gaps: 250ms, 260ms, 255ms, 250ms, 265ms, 240ms Average: 253ms Feeling: Smooth, predictable, pleasant

As you can see in both cases, the average is more or less the same but the user experience is completely different.

Network Quality Indicator

1. Stable connection:

   Inter-arrival times: 40ms, 42ms, 38ms, 41ms, 40ms Standard deviation: ~1.5ms Meaning: Great connection!

2. Poor connection:

   Inter-arrival times: 20ms, 200ms, 30ms, 500ms, 25ms Standard deviation: ~200ms Meaning: Packet loss, congestion, or throttling

Server Health

1. Healthy server:

   Consistent gaps: 30-50ms throughout Meaning: Server processing steadily

2. Struggling server:

   Increasing gaps: 30ms → 50ms → 100ms → 200ms Meaning: Server under load, getting slower

Measuring Inter-Arrival Time in Console

Paste the below scrip in your Chrome Developer tools console:

(function() {
    const originalFetch = window.fetch;
    window.fetch = async function(...args) {
        const response = await originalFetch(...args);
        const contentType = response.headers.get('Content-Type');
        
        if (contentType?.includes('text/event-stream')) {
            console.log('📊 Monitoring inter-arrival times...');
            
            const reader = response.clone().body.getReader();
            const times = [];
            let lastTime = performance.now();
            let chunkCount = 0;
            
            while (true) {
                const {done, value} = await reader.read();
                if (done) break;
                
                const now = performance.now();
                const gap = now - lastTime;
                
                if (chunkCount > 0) { // Skip first chunk (no previous time)
                    times.push(gap);
                }
                
                chunkCount++;
                lastTime = now;
            }
            
            // Calculate statistics
            const avg = times.reduce((a,b) => a+b, 0) / times.length;
            const min = Math.min(...times);
            const max = Math.max(...times);
            const sorted = [...times].sort((a,b) => a-b);
            const median = sorted[Math.floor(sorted.length/2)];
            
            // Calculate standard deviation
            const variance = times.reduce((sum, val) => 
                sum + Math.pow(val - avg, 2), 0) / times.length;
            const stdDev = Math.sqrt(variance);
            
            console.log('📈 Inter-Arrival Analysis:');
            console.log('  Total chunks:', chunkCount);
            console.log('  Average gap:', avg.toFixed(2) + 'ms');
            console.log('  Median gap:', median.toFixed(2) + 'ms');
            console.log('  Min gap:', min.toFixed(2) + 'ms');
            console.log('  Max gap:', max.toFixed(2) + 'ms');
            console.log('  Std deviation:', stdDev.toFixed(2) + 'ms');
            console.log('  Consistency:', stdDev < 50 ? '✅ Excellent' : 
                        stdDev < 100 ? '⚠️ Good' : '❌ Poor');
            
            // Show distribution
            console.log('\n📊 Distribution:');
            const buckets = [0, 25, 50, 100, 200, 500, Infinity];
            const labels = ['0-25ms', '25-50ms', '50-100ms', '100-200ms', '200-500ms', '>500ms'];
            
            labels.forEach((label, i) => {
                const count = times.filter(t => 
                    t >= buckets[i] && t < buckets[i+1]
                ).length;
                const bar = '█'.repeat(Math.round(count / times.length * 20));
                console.log(`  ${label.padEnd(12)} ${bar} ${count}`);
            });
            
            // Store for later analysis
            window.lastInterArrivalTimes = times;
        }
        
        return response;
    };
})();

Below is an example out on a good experience I had today:

📊 Monitoring inter-arrival times...
📈 Inter-Arrival Analysis:
  Total chunks: 245
  Average gap: 42.15ms
  Median gap: 38.50ms
  Min gap: 12.30ms
  Max gap: 156.80ms
  Std deviation: 23.45ms
  Consistency: ✅ Excellent

📊 Distribution:
  0-25ms       ███░░░░░░░░░░░░░░░░░ 38
  25-50ms      ████████████████░░░░ 156
  50-100ms     ███░░░░░░░░░░░░░░░░░ 42
  100-200ms    ░░░░░░░░░░░░░░░░░░░░ 8
  200-500ms    ░░░░░░░░░░░░░░░░░░░░ 1
  >500ms       ░░░░░░░░░░░░░░░░░░░░ 0

And for the same question I used a different chatbot and the experience was quiet different:

📊 Monitoring inter-arrival times...
📈 Inter-Arrival Analysis:
  Total chunks: 53
  Average gap: 159.14ms
  Median gap: 68.80ms
  Min gap: 0.40ms
  Max gap: 1744.90ms
  Std deviation: 263.13ms
  Consistency: ❌ Poor
 
📊 Distribution:
  0-25ms       ███████░░░░░░░░░░░░░ 17
  25-50ms      █░░░░░░░░░░░░░░░░░░░ 2
  50-100ms     ███░░░░░░░░░░░░░░░░░ 9
  100-200ms    ███░░░░░░░░░░░░░░░░░ 7
  200-500ms    ██████░░░░░░░░░░░░░░ 15
  >500ms       ███░░░░░░░░░░░░░░░░░ 2

Inter-arrival time, also known as jitter, is a significant factor that contributes to the perception of faster performance in certain artificial intelligence (AI) systems. It serves as a diagnostic tool for identifying connection issues and helps determine which AI model is optimized for providing a seamless user experience.

For developers, this information provides insights into server performance characteristics, identifies potential optimization opportunities, and enables the measurement of user experience quality.

Without robust monitoring, an enterprise is operating its AI chatbot initiative blindly, risking inefficiencies, user dissatisfaction and wasted investment.

To track any kind of performance/user experience monitoring one needs to understand how these chatbots work. Modern AI chatbots don’t send you the entire response at once. They stream it; i.e. sending small chunks as they generate them. This creates that satisfying “typing” effect.

I started using ChatGPT and eventually transitioned to Claude or Google Gemini depending on my use case. And there is no surprise that different chatbots use different mechanisms to stream data.

1. Server-Sent Events (SSE) - Used by Claude, ChatGPT, Perplexity
2. XHR Streaming - Used by Google Gemini
3. WebSocket - Used by Microsoft Copilot

Let’s take a look behind the scenes on how these work. On any of your chromium browser, open up your Developer Tools and navigate to the “Network” tab.

I’m using Claude.ai for this example. Now, click the clear icon to start fresh. Once cleared, go to your UI and send a message “Count to 10”

In your DevTools, Network Tab:

1. Look for a request containing "completion"
2. Click on it
3. Go to "Timing" tab

What to look for:

• Name: …/completion
• Status: 200
• Type: fetch or eventsource
• Time: How long the stream lasted
• Size: Total data transferred

Reading the Timing Tab:

Waiting (TTFB): Time until first byte 
Content Download: How long streaming took

Click on the EventStream (or Response) Each event: message block is one chunk!

Pretty cool. You can now take one more step further and write a simple script to basically look at a few important metrics. To get started, the most basic metrics I like to see the time it took to get the first chunk after I sent a message, how many chunks were received and the total time.

In your Chrome Developer Tools, navigate to the “Console” tab and paste this script (thanks Claude.ai):

// Monitor for Claude (SSE)
(function() {
    const originalFetch = window.fetch;
    window.fetch = async function(...args) {
        const start = Date.now();
        const response = await originalFetch(...args);
        
        const url = args[0];
        const contentType = response.headers.get('Content-Type');
        
        if (contentType && contentType.includes('text/event-stream')) {
            console.log('🔥 Streaming response detected!');
            console.log('URL:', url);
            
            const reader = response.clone().body.getReader();
            const decoder = new TextDecoder();
            let chunks = 0;
            let firstChunk = null;
            
            while (true) {
                const {done, value} = await reader.read();
                if (done) break;
                
                chunks++;
                if (!firstChunk) {
                    firstChunk = Date.now() - start;
                    console.log('⏱️ Time to first chunk:', firstChunk + 'ms');
                }
            }
            
            const total = Date.now() - start;
            console.log('📊 Total chunks:', chunks);
            console.log('⏰ Total time:', total + 'ms');
        }
        
        return response;
    };
    
    console.log('✅ Monitor active! Send a message to Claude.');
})();

Once you paste this in your console tab, you should see this message:

✅ Monitor active! Send a message to Claude.

This time I asked Claude to count o 100. As you hit enter, the console tab should show our the below results:

🔥 Streaming response detected!
URL: /api/organizations/.../completion
⏱️ Time to first chunk: 2269ms
📊 Total chunks: 39
⏰ Total time: 4550ms

Pretty neat! Similarly you can capture these metrics for different AI Chatbot’s and view the user experience.

This is particularly useful to ensure positive user experience & satisfaction, driving operational efficiency and cost savings, optimizing performance, improving business outcomes and understanding scalability & capacity.

To make your user experience dashboard even more powerful, consider adding a few more advanced metrics. Here are a few ideas:

Calculate tokens per second (Measure Typing Speed)

// Calculate tokens per second
const startTime = Date.now();
let tokenCount = 0;

// Watch the DOM for changes
const observer = new MutationObserver(() => {
    const responseText = document.querySelector('.response-text')?.innerText || '';
    tokenCount = responseText.split(' ').length;
});

observer.observe(document.body, { 
    subtree: true, 
    childList: true 
});

// After response completes, run:
const duration = (Date.now() - startTime) / 1000;
console.log('Tokens per second:', (tokenCount / duration).toFixed(2));

Check Connection Quality

// See all active connections
console.table(
    performance.getEntriesByType('resource')
        .filter(e => e.initiatorType === 'fetch' || e.initiatorType === 'xmlhttprequest')
        .map(e => ({
            name: e.name.split('/').pop(),
            duration: Math.round(e.duration) + 'ms',
            size: Math.round(e.transferSize / 1024) + 'KB'
        }))
);

**Monitor Network Speed **

// Check if you have slow connection
if (navigator.connection) {
    const conn = navigator.connection;
    console.log('Connection type:', conn.effectiveType);
    console.log('Downlink speed:', conn.downlink + ' Mbps');
    console.log('RTT:', conn.rtt + 'ms');
}

Tip: Bookmark this guide and test your AI platforms monthly - performance changes over time as models and infrastructure improve!

Besides that, you could also whip up a basic browser plugin that checks for SSE, XHR, or WebSockets and grabs the initial metrics of the chatbot you’re using. I made one for myself, and it’s been a handy way to figure out whether the issue is with my network or the chatbot itself.

• You control costs.
• You’re the customer.
• It’s comfortable. 🙂

Strategy

• Actual customers are the customer.
• You don’t control them.
• You don‘t control revenues. 😬

The Empire State Building anchors the center of the image, a familiar silhouette against a dynamic sky. Around it, glass towers rise like digital mountains — One Vanderbilt stretching skyward to the left, and the futuristic faces of Hudson Yards to the right. Each building, a chapter in the city’s ever-unfolding story.

Standing at this vantage point a decade back; the view was very different. Definitely a lot of cranes. They have all gone but one remains.

Urban landscapes aren’t just about buildings — they’re about energy. Even in stillness, New York buzzes.

The chapel at Princeton University

Cloistered Corridors at Princeton University

Some of the key features of HTTP/2 include the multiplexing of multiple messages within a single TCP packet and the use of a binary message format and HPACK compression for headers. To illustrate this, consider HTTP/1.1. In the diagram, it is evident that two requests cannot be transmitted concurrently within the same TCP connection. This is because HTTP/1.1 operates on a sequential basis, and request 2 cannot be sent until response 1 has been received. This phenomenon is known as head-of-line blocking.

HTTP/2 addresses this issue by using streams, which correspond to individual messages. Multiple streams can be interleaved within a single TCP packet. If a stream encounters a delay in transmitting its data, other streams can take its place in the TCP packet.

HTTP/2 streams are divided into frames, each containing the frame type, the stream it belongs to, and its byte length. In the diagram below, a colored rectangle represents a TCP packet, and a ✉ represents an HTTP/2 frame within it. The first and third TCP packets contain frames from different streams.

Measuring HTTP/2 application performance

The most cost-effective way to measure response time and availability for HTTP/2 applications is to use the cURL command-line tool. With cURL, the response time, also known as latency, refers to the time it takes to establish the connection and receive the first byte of the response (TTFB). To obtain response headers and timing metrics in a readable format, you can use the -w (write-out) option or create a simple configuration file. The configuration file can be downloaded from GitHub and includes a formatted and readable representation of response headers and timing metrics.

To use cURL with HTTP/2, add the --http2 option before the URL. For example, to test a URL like host.domain.com, use the following command:

curl -K curl.cfg <host.domain.com> --http2

When running with HTTP/2, you can still access the same timing variables that apply to HTTP/1.x, but the protocol will be HTTP/2.

As we learned earlier, HTTP/2 supports multiplexing, which allows multiple streams to be active within a single connection. If you’re testing multiple requests over the same connection, curl won’t directly display stream-level latency. However, you can still measure individual request timings by executing multiple cURL invocations for different URLs or by measuring the overall connection’s multiplexing performance.

HTTP/2’s primary performance advantage lies in its multiplexing feature, where multiple streams are handled simultaneously over a single TCP connection. Inefficient multiplexing can lead to inefficiencies, such as one stream slowing down others (head-of-line blocking) or a connection not fully utilizing its capacity.

To measure multiplexing efficiency using curl, you would need to execute multiple concurrent requests and observe the total connection time and performance under load.

curl —http2 https://example.com &
curl —http2 https://example.com &
curl —http2 https://example.com &

However, this approach won’t provide detailed information about individual streams or their multiplexing behavior. For this purpose, specialized tools like Wiresharkare essential for protocol analysis.

Using nghttp2

nghttp, a command-line tool part of the **nghttp2** project, is a versatile library and suite designed to work with the HTTP/2 protocol. It offers users comprehensive control over various aspects of the protocol, including stream multiplexing, prioritization, and flow control.

Imagine you’re monitoring a web application that loads multiple assets like CSS, JS, and images. Despite using HTTP/2, you notice inconsistent or slow page load times. nghttp can help you identify the issue.

To test multiplexing, run nghttp with multiple URLs and observe the performance.

nghttp -v -s https://example.com/style.css https://example.com/script.js https://example.com/image.jpg

Analyze the connection logs to check if requests are truly multiplexed or if streams are waiting for each other.

If multiplexing isn’t efficient (e.g., only one stream seems active), it could indicate a server-side issue where the server isn’t handling multiple streams correctly. Check the server’s configuration to see if it limits the number of concurrent streams.

By identifying whether multiplexing works as expected, you can adjust server settings or investigate bottlenecks related to network congestion or server capacity.

When you run the nghttp command, the very first line in the output will look something like this:

[ 0.037] Connected

This indicates that nghttp successfully established a connection to the server, and it took 0.037 seconds (37 milliseconds) to do so. This “Connected” time typically includes DNS Resolution Time (if not cached); TCP Connection Time & TLS/SSL Handshake Time (if HTTPS).

nghttp does not separate these components; it combines them into a single “Connected” time. For a more detailed breakdown (DNS, TCP, and SSL times separately), you would need to use cURL.

Since HTTP/2 does this once, and reuses for subsequent requests, you would need to do a cURL on the first URL to get the timing metrics independently.

When running nghttp, the output will contain detailed information about the HTTP/2 session and streams for each URL requested. At first the output would look alien if you are using to cURL. Here is a simple way to breakdown the key parts of the output:

Session Initiation

• Connecting to... will show the IP address and port being used.
• If https is being used, nghttp will perform a TLS handshake and display the details about the cipher suite, protocol, version, and certificate.

Stream Information: Each URL requested is assigned a stream ID. In HTTP/2, multiple streams allow for multiplexing, so each resource (CSS, JS, JPG) will have a unique stream ID – typically starting with an odd number and incrementing with each request.

[id=1] [id=3] [id=5]

Request Headers will display in detail:

• **:method**: Shows the HTTP method (usually GET).
• **:scheme**: Indicates the scheme (typically https for secure connections).
• **:path**: The path to the requested resource (/style.css, /script.js, /image.jpg).
• **:authority**: The hostname (e.g., example.com).

These headers are part of the HTTP/2 protocol and help the server understand each request’s method, path, and target.

Response Headers: Each response will also have headers associated with it, including:

• **:status**: The HTTP status code, such as 200 for success, 404 for not found, etc.
• Other headers, like content-type (e.g., text/css, application/javascript, image/jpeg) and content-length.

Stream Timing Metrics: This is where things get very interesting

• [id=X] [END_STREAM]: This marks the end of data transmission on a specific stream, indicating the resource download is complete.
• Timing Information: For each stream, nghttp provides basic timing information, including:
• First byte time: The time taken to receive the first byte.
• Completion time: The time at which the full content was received.

These times can help you see how quickly each resource loads and identify potential bottlenecks.

Summary of Multiplexing: When you use the -s flag, at the end of the output the statistical summary of all the three resources will be displayed.

• Since all requests run concurrently, nghttp may indicate how the streams are interleaved. Multiplexing lets nghttp download style.css, script.js, and image.jpg simultaneously over the same connection.
• This section is especially useful for understanding how well the server handles concurrent HTTP/2 requests and if any stream experiences noticeable delays.

Here is a sample output of the statistics:

***** Statistics *****

Request timing:
  responseEnd: the  time  when  last  byte of  response  was  received
               relative to connectEnd
 requestStart: the time  just before  first byte  of request  was sent
               relative  to connectEnd.   If  '*' is  shown, this  was
               pushed by server.
      process: responseEnd - requestStart
         code: HTTP status code
         size: number  of  bytes  received as  response  body  without
               inflation.
          URI: request URI

see http://www.w3.org/TR/resource-timing/#processing-model

sorted by 'complete'

id  responseEnd requestStart  process code size request path
 15    +17.75ms       +179us  17.57ms  200   7K /jpeg/2023/03/me.jpg
 17   +164.68ms       +256us 164.42ms  200  17K /assets/built/main.min.js
 13   +165.11ms       +153us 164.96ms  200   7K /assets/built/screen.css

To effectively monitor HTTP/2 based applications, it’s essential to test multiple URLs as part of the same transaction. This allows you to assess how efficiently the server handles multiplexing, where multiple streams are sent over a single connection simultaneously. By using multiple URLs, you can evaluate key HTTP/2 features such as stream prioritization and flow control, which optimize resource delivery and responsiveness. Monitoring these metrics helps identify performance bottlenecks, detect inefficient resource allocation, and ensure that your application is leveraging the full benefits of HTTP/2 for improved user experience.