மெதுவான பதில்களை (Slow Responses) நாங்கள் எவ்வாறு 80% குறைத்தோம்

Subito என்பது இத்தாலியில் உள்ள ஒரு முன்னணி சந்தை (marketplace) ஆகும். நாங்கள் ஒவ்வொரு நிமிடமும் ஆயிரக்கணக்கான கோரிக்கைகளை (requests) கையாளுகிறோம். எங்களது விளம்பர விவரப் பக்கம் (ad detail page) SEO மற்றும் வருவாய்க்கு மிகவும் முக்கியமானது.

நாங்கள் இந்தப் பக்கத்தை Next.js Pages Router-லிருந்து App Router-க்கு மாற்றினோம். இதைச் செய்வதற்காக நாங்கள் தயாரிப்புப் பணிகளை (product work) நிறுத்தவில்லை. நாங்கள் சிறிய படிகளாக இதைச் செய்தோம்.

நாங்கள் இதை எவ்வாறு செய்தோம் என்பது இதோ.

அணுகுமுறை

நாங்கள் ஒரு incremental strategy-ஐப் பயன்படுத்தினோம். பழைய Pages Router உடன் சேர்த்து App Router tree-ஐயும் சேர்த்தோம். இது நாங்கள் மாற்றங்களைச் செய்து கொண்டிருக்கும் போதே புதிய அம்சங்களை (features) வெளியிட உதவியது.

தரவுப் பெறுதலை (data fetching) நிர்வகிக்க நாங்கள் Server Components-ஐப் பயன்படுத்தினோம். இது பல அடுக்குகளின் (layers) வழியாகத் தரவை அனுப்ப வேண்டிய தேவையைக் குறைத்தது. நாங்கள் ஒரு Data Access Layer-ஐயும் உருவாக்கினோம். இது ஒவ்வொரு கோரிக்கைக்கும் (request) ஒருமுறை மட்டுமே தரவை எடுப்பதை உறுதி செய்தது.

HTML streaming-ஐச் செயல்படுத்த நாங்கள் Suspense மற்றும் use() hook-ஐப் பயன்படுத்தினோம். இது தரவு ஏற்றப்படும் போது ஒரு skeleton screen-ஐக் காட்டுகிறது. இதனால் பயனர் பக்கத்தை விரைவாகப் பார்க்க முடிகிறது.

சவால்கள்

பிரச்சனை 1: HTTP 410 Gone ஒரு பக்கம் நிரந்தரமாக நீக்கப்படும்போது, தேடுபொறிகளுக்கு (search engines) 410 status தேவைப்படும். App Router-இல் இதை அனுப்ப உள்ளமைக்கப்பட்ட (built-in) வழி இல்லை. இதை எங்கள் Express server மூலம் நாங்கள் தீர்த்தோம். சர்வர் response-ஐ intercept செய்து அதன் status code-ஐ மாற்றுகிறது.

பிரச்சனை 2: HTML Streaming எங்களது loading skeletons தோன்றவில்லை என்பதைக் கண்டறிந்தோம். பக்கம் பல வினாடிகள் காலியாகவே இருந்தது.

Nginx மற்றும் Akamai எங்களது பதில்களை buffering செய்திருப்பதை நாங்கள் கண்டறிந்தோம். CDN, HTML-ஐ buffer செய்தால், streaming தோல்வியடையும். நாங்கள் Nginx-இல் buffering-ஐ அணைத்துவிட்டு, Akamai-இல் custom settings-களைச் செயல்படுத்தினோம். இதைச் சரிசெய்தவுடன், உள்ளடக்கம் பயனருக்குத் தடையின்றிச் சென்றடைந்தது.

வெளியீடு

எங்களது SEO-வைப் பாதுகாக்க நாங்கள் இரண்டு கட்டங்களாக இதை வெளியிட்டோம்.

கட்டம் 1: நாங்கள் traffic-ஐ App Router-க்கு மாற்றினோம், ஆனால் streaming-ஐ அணைத்து வைத்திருந்தோம். இதை ஒவ்வொரு வகையாக (category) செய்தோம்.

கட்டம் 2: நாங்கள் HTML streaming-ஐச் செயல்படுத்தினோம். முதலில் சிறிய வகைகளில் இதைச் சோதித்தோம். அடுத்த வகைக்குச் செல்வதற்கு முன், எங்களது SEO குழு இரண்டு வாரங்களுக்கு rankings-களைக் கண்காணித்தது.

முடிவுகள்

முடிவுகள் பிரம்மாண்டமாக இருந்தன. மாற்றத்திற்கு முன்னதாக, எங்களது பதில்களில் 40% வரை மெதுவாக இருந்தன. மாற்றத்திற்குப் பிறகு, மெதுவான பதில்கள் 80% குறைந்துவிட்டன.

பெரும்பாலான பக்கங்கள் இப்போது 500ms-க்கும் குறைவான நேரத்தில் ஏற்றப்படுகின்றன.

முக்கியக் கருத்துக்கள்

How we cut slow responses by 80% migrating to Next.js App Router

Next.js App Router-க்கு இடமாற்றம் செய்வதன் மூலம் மெதுவான பதில்களை (slow responses) நாங்கள் 80% எவ்வாறு குறைத்தோம்

மெதுவான பதில்கள் (slow responses) பயனர் அனுபவத்தை (user experience) மிக மோசமாகப் பாதிக்கும். எங்களுக்கும் அது ஒரு தொடர்ச்சியான போராட்டமாகவே இருந்தது.

The Problem: The Waterfall Effect and Heavy Client-side Bundles

பிரச்சனை: "Waterfall" விளைவு மற்றும் அதிகப்படியான Client-side Bundles

எங்கள் முந்தைய அமைப்பில், Next.js Pages Router-ஐப் பயன்படுத்தினோம். அங்கு நாங்கள் ஒரு பெரிய சிக்கலை எதிர்கொண்டோம்: "Waterfall" விளைவு.

Client-side தரவுப் பெறுதலின் (data fetching) போது, ஒரு component தனது தரவைப் பெற்ற பின்னரே அடுத்த component தரவைப் பெறத் தொடங்கும். இதனால் பயனர் ஒரு பக்கத்தைப் பார்க்க நீண்ட நேரம் காத்திருக்க வேண்டியிருந்தது. மேலும், அதிகப்படியான JavaScript கிளையண்டிற்கு அனுப்பப்படுவதால், Bundle size அதிகரித்தது, இது உலாவியின் (browser) செயல்திறனைப் பாதித்தது.

The Solution: Embracing React Server Components and Streaming

தீர்வு: React Server Components மற்றும் Streaming முறையைப் பயன்படுத்துதல்

நாங்கள் Next.js App Router-க்கு மாறினோம். இது எங்களுக்குப் பல புதிய வசதிகளை வழங்கியது:

1. React Server Components (RSC)

React Server Components மூலம், தரவுப் பெறுதல் (data fetching) நேரடியாக சர்வரிலேயே நடைபெறுகிறது. இதனால் கிளையண்டிற்கு அனுப்பப்படும் JavaScript அளவு கணிசமாகக் குறைந்தது. சர்வர் தரவைப் பெற்று, HTML-ஆகவே கிளையண்டிற்கு அனுப்புவதால், லோடிங் வேகம் அதிகரித்தது.

2. Streaming with Suspense

முழுப் பக்கமும் தயாராகும் வரை காத்திருக்காமல், தயாராக உள்ள பகுதிகளை (components) உடனடியாகப் பயனருக்குக் காட்ட 'Streaming' வசதியைப் பயன்படுத்தினோம். Suspense மூலம் லோடிங் நிலைகளை (loading states) மிகச் சிறப்பாகக் கையாள முடிந்தது. இது பயனர் ஒரு பக்கத்தைப் பார்க்கத் தொடங்கும் நேரத்தை (perceived performance) மேம்படுத்தியது.

<Suspense fallback={<LoadingSkeleton />}>
  <SlowComponent />
</Suspense>

The Results

முடிவுகள்

இந்த மாற்றத்திற்குப் பிறகு, எங்களது செயல்திறனில் மிகப்பெரிய முன்னேற்றம் ஏற்பட்டது: