Architecture content is useful only if it survives real traffic. The stack in this repository is now past the design stage and into measured runtime behavior: Next.js on the public edge, PocketBase behind the app boundary, Caddy as the reverse proxy, and Cloudflare in front of the whole system.

These screenshots do not represent a mature high-volume platform yet. They represent something more valuable for this series: the first honest production signals from a small but real deployment, early enough to show what is already strong and what should be tightened next.

This summary graphic compresses the first seven days of live hosting into one view: hardware footprint, request volume, real-user LCP, cache behavior, and synthetic speed scores.

Reading the percentile markers: p50, p75, p90, and p99 show how fast the site is for 50%, 75%, 90%, and 99% of users, helping separate the typical experience from the slowest edge cases.

The broad traffic overview already looks credible for a first-week launch. Cloudflare shows 1.25k unique visitors,19.52k total requests, 111 MB served, and 32 MB cached in the seven-day view ending March 13, 2026.

• The demand signal is real. A small self-hosted platform clearing 19.52k requests in its first production week is already beyond hobby-only traffic.
• The request curve spikes sharply around March 9 and approaches the chart's 4.7k mark. That is a visual inference from the chart, not a labeled exact value.
• The cache ratio is the weakest number in this block. Only 28.42% of requests were cached, which means the origin is still doing too much repeat work.
• Even with that lower cache ratio, the platform stayed responsive enough to keep later user-experience metrics in a good range.

Cloudflare Web Analytics adds the view that matters more than synthetic tests alone: what real visitors actually felt. The main RUM panel reports 488ms page load time, 358 visits, and 747 page views for the same seven-day slice. That measurement scope is narrower than the raw edge visitor count, so it should be read as engagement telemetry, not as a contradiction.

• Cloudflare marks 94% of LCP samples as good, 3% as needs improvement, and 4% as poor in the page analytics screenshot.
• The p99 value is the most important warning sign in the whole dataset. When the median is fast but p99 is 15.156 seconds, the platform is not generally slow, but it has a meaningful tail-risk problem.
• The URL breakdown suggests the root experience is mostly healthy, while /vlogs/travel is the clearest outlier in the screenshot.
• Because iOS dominates the traffic mix, the next round of optimization should favor mobile Safari and mobile Chrome behavior before chasing desktop-only perfection.

Cloudflare Speed Test was run from Iowa, USA on March 12, 2026 at 10:47 AM. Synthetic results are never the whole truth, but they are useful for showing the ceiling of the current build when network conditions are controlled.

• Desktop performance is already elite. Nothing in that screenshot suggests the current stack is fundamentally too heavy for the workload.
• Mobile is still good, but the gap is obvious. LCP moves from 510ms on desktop to 2,174ms on mobile, and TTI moves to 2,187ms.
• The fact that both desktop and mobile keep CLS at 0 in synthetic tests is promising, but it does not replace the missing CLS visibility in the real-user panel.
• The mobile result reinforces what the iOS-heavy traffic sample already told us: optimizing the above-the-fold mobile experience will have the highest payoff.

• The architecture is production-capable now. The median and p75 numbers are too strong to dismiss this as a fragile demo.
• The Raspberry Pi host is not the immediate bottleneck. If it were, TTFB and INP would usually degrade earlier and more consistently.
• Cloudflare's broader vitals view still showed healthy interaction and server-response signals, so the main issue remains tail latency rather than baseline responsiveness.
• A palm-sized self-hosted server sustaining the first seven production days without downtime is a useful proof point for this stack at small scale.
• Cloudflare plus Caddy is doing its job, but cache leverage is still underused. The edge should be absorbing more of this traffic than 28.42%.
• The biggest risk is not baseline speed. It is inconsistency: a fast majority experience with a very slow outlier tail.

1. Raise the cache hit rate. Push more static assets and safe HTML responses to Cloudflare cache so the origin is not handling repeat traffic unnecessarily.
2. Reduce the p99 LCP tail. Audit the landing page and the /vlogs/travel route first, because the screenshots suggest that heavier pages are driving some of the worst sessions.
3. Tune the mobile hero path. Compress above-the-fold images, preload the real LCP asset, trim render-blocking work, and keep the home page copy dense but lighter on mobile.
4. Add better route-level observability. Track which deploy, asset, or cache state lines up with slow sessions instead of treating p99 as a vague aggregate warning.
5. Close the CLS measurement gap. Keep explicit media dimensions everywhere and verify that the RUM sample is large enough to surface layout stability data in the next report.
6. Add a UPS or other power backup. Seven stable days without one is encouraging, but it is still an avoidable infrastructure risk.
7. Keep a second review after a larger traffic window. Seven days is enough to expose the first issues, but not enough to call the system fully characterized.