𝗛𝗼𝘄 𝗪𝗲 𝗖𝘂𝘁 𝗦𝗹𝗼𝘄 𝗥𝗲𝘀𝗽𝗼𝗻𝘀𝗲𝘀 𝗯𝘆 𝟴𝟬%

Subito is a top marketplace in Italy. We handle thousands of requests every minute. Our ad detail page is vital for SEO and revenue.

We moved this page from Next.js Pages Router to App Router. We did not stop product work to do this. We moved in small steps.

Here is how we did it.

𝗧𝗵𝗲 𝗔𝗽𝗽𝗿𝗼𝗮𝗰𝗵

We used an incremental strategy. We added the App Router tree alongside the old Pages Router. This let us ship new features while we migrated.

We used Server Components to own data fetching. This removed the need to pass data through many layers. We also created a Data Access Layer. This made sure we only fetch data once per request.

We used Suspense and the use() hook to enable HTML streaming. This shows a skeleton screen while data loads. The user sees the page faster.

𝗧𝗵𝗲 𝗖𝗵𝗮𝗹𝗹𝗲𝗻𝗴𝗲𝘀

Problem 1: HTTP 410 Gone Search engines need a 410 status when a page is permanently removed. The App Router does not have a built-in way to send this. We solved this using our Express server. The server intercepts the response and changes the status code.

Problem 2: HTML Streaming We found that our loading skeletons did not appear. The page stayed blank for seconds.

We discovered that Nginx and Akamai were buffering our responses. If the CDN buffers the HTML, streaming fails. We had to turn off buffering in Nginx and apply custom settings in Akamai. Once we fixed this, content streamed to the user perfectly.

𝗧𝗵𝗲 𝗥𝗼𝗹𝗹𝗼𝘂𝘁

We rolled out in two phases to protect our SEO.

Phase 1: We moved traffic to the App Router but kept streaming off. We did this one category at a time.

Phase 2: We enabled HTML streaming. We tested this on small categories first. Our SEO team monitored rankings for two weeks before we moved to the next category.

𝗧𝗵𝗲 𝗥𝗲𝘀𝘂𝗹𝘁𝘀

The results were huge. Before the migration, up to 40% of our responses were slow. After the migration, slow responses dropped by 80%.

Most pages now load in under 500ms.

𝗧𝗮𝗸𝗲𝗮𝘄𝗮𝘆𝘀

ہم نے Next.js App Router پر منتقل ہو کر سست رسپانسز کو 80% تک کیسے کم کیا

Subito میں، ہم سست رسپانس ٹائمز (slow response times) کے مسئلے سے نبرد آزما تھے۔ ہمارے صارفین تاخیر کا سامنا کر رہے تھے، اور ہماری کارکردگی کے میٹرکس (performance metrics) وہاں نہیں تھے جہاں ہم انہیں دیکھنا چاہتے تھے۔

ہم Next.js Pages Router استعمال کر رہے تھے۔ اگرچہ اس نے ہماری اچھی خدمت کی تھی، لیکن ہم کلائنٹ سائیڈ ڈیٹا فیچنگ (client-side data fetching) کی وجہ سے ایک رکاوٹ کا شکار ہو رہے تھے۔ جب بھی کوئی صارف نئے صفحے پر جاتا، براؤزر کو پہلے صفحہ فیچ کرنا پڑتا، پھر ڈیٹا فیچ کرنا پڑتا، جس سے درخواستوں کا ایک "واٹرفال" (waterfall) بن جاتا تھا۔

Next.js App Router پر منتقلی نے سب کچھ بدل دیا۔

مسئلہ: کلائنٹ سائیڈ واٹرفالز (Client-side Waterfalls)

Pages Router میں، ہم اکثر useEffect کے اندر یا کلائنٹ سائیڈ پر SWR/React Query جیسی لائبریریوں کا استعمال کرتے ہوئے ڈیٹا فیچ کرتے تھے۔ اس کا مطلب تھا:

  1. براؤزر HTML ڈاؤن لوڈ کرتا ہے۔
  2. براؤزر JavaScript ڈاؤن لوڈ کرتا ہے۔
  3. JavaScript ایگزیکیوٹ ہوتی ہے اور ڈیٹا فیچنگ کا عمل شروع کرتی ہے۔
  4. ڈیٹا پہنچ جاتا ہے، اور کمپوننٹ رینڈر ہوتا ہے۔

یہ سلسلہ، خاص طور پر سست نیٹ ورکس پر، ایک نمایاں تاخیر کا باعث بنتا تھا۔

حل: Server Components اور Streaming

App Router کے ساتھ، ہم نے React Server Components (RSC) کا استعمال کرتے ہوئے اپنا ڈیٹا فیچنگ کا عمل سرور پر منتقل کر دیا۔

1. Server Components

کلائنٹ پر ڈیٹا فیچ کرنے کے بجائے، اب ہم اسے براہ راست سرور پر فیچ کرتے ہیں۔ اس سے کلائنٹ کو بڑی مقدار میں JavaScript بھیجنے کی ضرورت ختم ہو جاتی ہے اور راؤنڈ ٹرپس (round trips) کی تعداد کم ہو جاتی ہے۔

2. Suspense کے ساتھ Streaming

ہم نے Streaming کا بھی فائدہ اٹھایا۔ پورے صفحے کے تیار ہونے کا انتظار کرنے کے بجائے، ہم نے Suspense کا استعمال کیا تاکہ صفحے کے حصوں کو ان کے دستیاب ہوتے ہی اسٹریم کیا جا سکے۔ اس سے ہمارے Time to First Byte (TTFB) اور Largest Contentful Paint (LCP) میں بہتری آئی۔

نتائج

نتائج فوری تھے۔ App Router پر منتقل ہو کر اور ان پیٹرنز کو نافذ کر کے، ہم نے سست رسپانسز میں 80% کمی دیکھی۔