<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Website Performance on StackOnward</title><link>https://stackonward.com/tags/website-performance/</link><description>Recent content in Website Performance 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/website-performance/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></channel></rss>