<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>TTFB on StackOnward</title><link>https://stackonward.com/tags/ttfb/</link><description>Recent content in TTFB on StackOnward</description><generator>Hugo</generator><language>en-US</language><lastBuildDate>Fri, 11 Sep 2026 12:00:00 +0800</lastBuildDate><atom:link href="https://stackonward.com/tags/ttfb/index.xml" rel="self" type="application/rss+xml"/><item><title>How to Troubleshoot a Slow Website: DNS, TTFB, and LCP</title><link>https://stackonward.com/posts/slow-website-troubleshooting/</link><pubDate>Fri, 11 Sep 2026 05:18:00 +0800</pubDate><guid>https://stackonward.com/posts/slow-website-troubleshooting/</guid><description>&lt;p&gt;How to troubleshoot a slow website starts with the URL, the time window, and who is affected. Split one load into DNS, connection, TLS, waiting for the first byte, body download, and rendering. Hosting, CDN, database, and frontend changes only help after that interval has an owner.&lt;/p&gt;
&lt;figure&gt;
 &lt;img src="https://stackonward.com/images/posts/slow-website-troubleshooting/en/performance-path.svg" alt="Performance path from confirming URL and time, through curl phase timings, then to CDN and origin when TTFB is high or to browser rendering when HTML is already fast" loading="lazy" decoding="async"&gt;
 &lt;figcaption&gt;curl locates network and first-byte time. Origin metrics and the browser timeline explain the remaining wait.&lt;/figcaption&gt;
&lt;/figure&gt;

&lt;h2 id="start-troubleshooting-a-slow-website-from-the-affected-url"&gt;Start troubleshooting a slow website from the affected URL&lt;/h2&gt;
&lt;p&gt;Record the incident before opening a profiler:&lt;/p&gt;</description></item><item><title>What Happens When You Type a URL in the Browser</title><link>https://stackonward.com/posts/domain-request-flow/</link><pubDate>Fri, 11 Sep 2026 05:18:00 +0800</pubDate><guid>https://stackonward.com/posts/domain-request-flow/</guid><description>&lt;p&gt;What happens when you type a URL in the browser is a sequence of hops, not a round trip to one origin. The request usually travels through DNS, a TCP or QUIC connection, TLS, a CDN or reverse proxy, and only then the application. The HTML that comes back is not the end; the browser still fetches styles, scripts, fonts, and images. &lt;a href="https://developer.mozilla.org/en-US/docs/Learn_web_development/Getting_started/Web_standards/How_the_web_works" target="_blank" rel="noopener"&gt;MDN’s account of how the web works&lt;span class="sr-only"&gt;(opens in a new tab)&lt;/span&gt;&lt;/a&gt; lists DNS, the HTTP request, the server response, and the browser assembling the page as consecutive stages.&lt;/p&gt;</description></item></channel></rss>