ผลกระทบของการแสดงผลฝั่งเซิร์ฟเวอร์ (SSR)
ประเมินข้อแลกเปลี่ยนด้านประสิทธิภาพระหว่างการแสดงผลฝั่งเซิร์ฟเวอร์ (SSR) กับการแสดงผลฝั่งไคลเอ็นต์ (CSR) และผลกระทบต่อ TTI
ผลกระทบของการแสดงผลฝั่งเซิร์ฟเวอร์ (SSR) เป็นบทเรียน Web Performance Optimization & Lighthouse ฟรีบน CoddyKit นี่คือบทเรียนที่ 3 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Web Performance Optimization & Lighthouse และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Web Performance Optimization & Lighthouse มีบทเรียนทั้งหมด 4 บทเรียน
บางส่วนของบทเรียนนี้ยังไม่ได้รับการแปล และแสดงเป็นภาษาอังกฤษ
SSR vs. CSR: The Core Idea
Welcome to understanding how web pages get built! Today, we'll explore two fundamental ways web content reaches your browser: Client-Side Rendering (CSR) and Server-Side Rendering (SSR).
Both have unique impacts on performance, especially how quickly a user can see and interact with your page.
How Client-Side Rendering Works
With CSR, your browser receives a minimal HTML file, often just a blank page with a link to a JavaScript bundle. It's like an empty canvas.
- Browser downloads HTML: Very small, quickly.
- Browser downloads JavaScript: This is the main part, often large.
- JavaScript fetches data & builds UI: After loading, JS executes, calls APIs, and dynamically injects content into the page.
The user sees content only after these steps complete.
CSR Performance & Initial Load
CSR can feel slow initially. The user might see a blank screen or a loading spinner for a noticeable period. This impacts metrics like First Contentful Paint (FCP) and Largest Contentful Paint (LCP).
However, once loaded, subsequent navigation within the app can be very fast, as only data (not full pages) needs to be fetched.
Try this simple CSR example:
<!DOCTYPE html>
<html>
<head>
<title>CSR Demo</title>
<style>
body { font-family: sans-serif; text-align: center; }
#app { border: 1px solid #ccc; padding: 20px; margin: 20px auto; max-width: 300px; min-height: 50px; }
</style>
</head>
<body>
<div id="app"><p>Loading content...</p></div>
<script>
document.addEventListener('DOMContentLoaded', () => {
setTimeout(() => {
document.getElementById('app').innerHTML = '<h2>Welcome!</h2><p>Content rendered by JS.</p><button>Click Me</button>';
}, 1000); // Simulate network/processing delay
});
</script>
</body>
</html>How Server-Side Rendering Works
With SSR, the server does the heavy lifting. When a user requests a page, the server processes the request, fetches any necessary data, and constructs the full HTML response.
- Browser requests page: Sends request to server.
- Server builds HTML: Fetches data, renders the complete page on the server.
- Browser receives full HTML: Gets a ready-to-display page.
The user sees content almost immediately as the HTML arrives.
SSR Performance & Initial Load
SSR generally leads to much faster First Contentful Paint (FCP) and Largest Contentful Paint (LCP). Users see meaningful content very quickly, improving perceived performance and SEO.
However, the server must generate the HTML for every request, which can add latency on the server side if not optimized. Let's see an SSR-like output:
<!DOCTYPE html>
<html>
<head>
<title>SSR Demo</title>
<style>
body { font-family: sans-serif; text-align: center; }
.content { border: 1px solid #ccc; padding: 20px; margin: 20px auto; max-width: 300px; }
</style>
</head>
<body>
<div class="content">
<h2>Welcome!</h2>
<p>Content rendered directly by the server.</p>
<button onclick="alert('Hello from SSR!')">Click Me</button>
</div>
</body>
</html>Understanding Time To Interactive (TTI)
Time To Interactive (TTI) measures how long it takes for a page to become fully interactive. This means:
- The page has displayed useful content (FCP/LCP).
- Event handlers are registered for most visible UI elements.
- The page responds to user interactions within 50 milliseconds.
TTI is critical because a user can see content but still be unable to click buttons or type into fields if the page isn't interactive.
SSR's TTI Challenge: Hydration
While SSR delivers content quickly, it often sends static HTML. To make this HTML dynamic and interactive, the client-side JavaScript still needs to load and 'take over' the DOM. This process is called hydration.
During hydration, JavaScript attaches event listeners and builds the virtual DOM. If this JS bundle is large, or takes a long time to execute, it can delay TTI even after the content is visible.
Comparing TTI: SSR vs. CSR
The TTI impact differs:
- CSR: TTI often aligns closely with FCP/LCP, as all content and interactivity are loaded together. If the JS bundle is small, TTI can be fast.
- SSR: FCP/LCP are fast, but TTI can be delayed if hydration is slow. Users might see content but experience a frustrating 'dead zone' where nothing responds.
The goal is to minimize this gap between visible content and interactive content.
Choosing the Right Approach
Deciding between SSR and CSR depends on your project's needs:
- SSR is great for: Content-heavy sites (blogs, e-commerce), good SEO, fast initial load for users on slow connections.
- CSR is great for: Highly interactive web applications (dashboards, social media feeds), where initial load time is less critical than rich user experience post-load.
Hybrid approaches like Static Site Generation (SSG) or Progressive Hydration also exist to combine benefits.
Quick Check: Rendering Strategies
Based on what we've learned, which statements correctly describe the performance trade-offs between Server-Side Rendering (SSR) and Client-Side Rendering (CSR)?
Recap: SSR, CSR & TTI
In this lesson, we explored Server-Side Rendering (SSR) and Client-Side Rendering (CSR). You learned:
- CSR defers rendering to the browser, potentially slowing initial content display but offering dynamic experiences.
- SSR renders HTML on the server, providing fast initial content (FCP/LCP) but can delay interactivity (TTI) due to hydration.
- Time To Interactive (TTI) is crucial, measuring when a page is fully usable.
Choosing between them involves balancing initial load speed, interactivity needs, and the impact of hydration on TTI.
เรียนรู้ Web Performance Optimization & Lighthouse ด้วย AI tutor — ฟรี
เขียนและเรียกใช้โค้ดจริงในเบราว์เซอร์ของคุณ รับความช่วยเหลือทันทีจาก AI tutor 24/7 และเรียนรู้ต่อจากที่คุณหยุดบนเว็บหรือในแอป
- คอร์ส
- 12
- บทเรียน
- 48
คำถามที่พบบ่อย
บทเรียน “ผลกระทบของการแสดงผลฝั่งเซิร์ฟเวอร์ (SSR)” ฟรีหรือไม่
ใช่ — ข้อความเต็มของ “ผลกระทบของการแสดงผลฝั่งเซิร์ฟเวอร์ (SSR)” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Web Performance Optimization & Lighthouse ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Web Performance Optimization & Lighthouse มีบทเรียนทั้งหมด 4 บทเรียน
คุณจะเรียนรู้อะไรในบทเรียน “ผลกระทบของการแสดงผลฝั่งเซิร์ฟเวอร์ (SSR)”
ประเมินข้อแลกเปลี่ยนด้านประสิทธิภาพระหว่างการแสดงผลฝั่งเซิร์ฟเวอร์ (SSR) กับการแสดงผลฝั่งไคลเอ็นต์ (CSR) และผลกระทบต่อ TTI คุณปฏิบัติ Web Performance Optimization & Lighthouse ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน
คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Web Performance Optimization & Lighthouse หรือไม่
ไม่จำเป็นต้องมีประสบการณ์มาก่อน Web Performance Optimization & Lighthouse บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 3 จากทั้งหมด 4 บทเรียน
บทเรียน “ผลกระทบของการแสดงผลฝั่งเซิร์ฟเวอร์ (SSR)” ใช้เวลานานแค่ไหน
บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย
ฉันเขียนและรันโค้ดในบทเรียน Web Performance Optimization & Lighthouse นี้ได้ไหม
ได้ บทเรียน Web Performance Optimization & Lighthouse ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ
บทเรียนทั้งหมดในหลักสูตรนี้
- คอขวดด้านประสิทธิภาพฝั่งแบ็กเอนด์
- การปรับปรุงประสิทธิภาพคำสั่งฐานข้อมูล
- ผลกระทบของการแสดงผลฝั่งเซิร์ฟเวอร์ (SSR)
- การแคชและการบีบอัดการตอบสนองของ API