Next.js 14 ਦੇ Server Components ਬੰਡਲ ਸਾਈਜ਼ ਨੂੰ ਲਗਭਗ 60% ਘਟਾ ਦਿੰਦੇ ਹਨ ਅਤੇ ਇੱਕ ਆਮ ਬਲੌਗ ਪੇਜ 'ਤੇ first-paint ਸਮੇਂ ਨੂੰ 200 ms ਤੋਂ ਘੱਟ ਕਰ ਦਿੰਦੇ ਹਨ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਉਪਭੋਗਤਾ ਸਮੱਗਰੀ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਦੇਖ ਸਕਦੇ ਹਨ ਅਤੇ ਸਰਚ ਇੰਜਣਾਂ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਰੈਂਡਰ ਕੀਤਾ ਹੋਇਆ HTML ਮਿਲਦਾ ਹੈ।

ਨਵਾਂ ਰਿਲੀਜ਼ Next.js ਨਾਲ ਬਣੀਆਂ React ਐਪਸ ਲਈ ਡਿਫੌਲਟ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਮਾਡਲ ਨੂੰ ਬਦਲ ਦਿੰਦਾ ਹੈ। ਜਿੱਥੇ ਪਹਿਲਾਂ ਹਰ ਕੰਪੋਨੈਂਟ ਬ੍ਰਾਊਜ਼ਰ ਤੱਕ ਭੇਜਿਆ ਜਾਂਦਾ ਸੀ, ਹੁਣ ਡਿਵੈਲਪਰ UI ਦੇ ਹਿੱਸਿਆਂ ਨੂੰ “Server Components” ਵਜੋਂ ਮਾਰਕ ਕਰ ਸਕਦੇ ਹਨ ਤਾਂ ਜੋ ਉਹ ਸਿਰਫ਼ ਬੈਕਐਂਡ 'ਤੇ ਚੱਲ ਸਕਣ। ਉਹਨਾਂ ਕੰਪੋਨੈਂਟਸ ਦਾ ਕੋਡ ਕਦੇ ਵੀ ਕਲਾਇੰਟ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਦਾ, ਜਿਸ ਨਾਲ ਬ੍ਰਾਊਜ਼ਰ ਕੋਲ ਸਿਰਫ਼ ਉਹੀ ਹਿੱਸੇ ਬਚਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਇੰਟਰਐਕਟੀਵਿਟੀ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

ਇਹ ਬਦਲਾਅ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹੈ

React ਡਿਵੈਲਪਰ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਤਿੰਨ ਆਪਸ ਵਿੱਚ ਜੁੜੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨਾਲ ਜੂਝ ਰਹੇ ਹਨ: ਨੈੱਟਵਰਕ ਰਿਕੁਐਸਟਾਂ ਦੀ ਭਰਮਾਰ, ਭਾਰੀ JavaScript ਬੰਡਲ, ਅਤੇ ਸੁਸਤ ਪੇਜ ਲੋਡਿੰਗ। ਇਹ ਸਮੱਸਿਆਵਾਂ SEO ਨੂੰ ਵੀ ਨੁਕਸਾਨ ਪਹੁੰਚਾਉਂਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਕ੍ਰੌਲਰਾਂ (crawlers) ਨੂੰ ਭੇਜਿਆ ਗਿਆ ਸ਼ੁਰੂਆਤੀ HTML ਅਕਸਰ ਖਾਲੀ ਹੁੰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਸਰਚ ਬੋਟਸ ਨੂੰ ਕਲਾਇੰਟ-ਸਾਈਡ ਹਾਈਡ੍ਰੇਸ਼ਨ (client-side hydration) ਦੀ ਉਡੀਕ ਕਰਨ ਲਈ ਮਜਬੂਰ ਹੋਣਾ ਪੈਂਦਾ ਹੈ। Next.js 14 ਡੇਟਾ-ਭਾਰੀ ਕੰਮ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਕਲਾਇੰਟ ਤੋਂ ਦੂਰ ਕਰਕੇ ਇਸਦੀ ਮੂਲ ਵਜ੍ਹਾ ਨੂੰ ਹੱਲ ਕਰਦਾ ਹੈ।

Server Components ਪੁਰਾਣੇ ਮਾਡਲ ਤੋਂ ਕਿਵੇਂ ਵੱਖਰੇ ਹਨ

  • Server Components – ਸਰਵਰ 'ਤੇ ਚੱਲਦੇ ਹਨ, ਡੇਟਾ ਫੈਚ (fetch) ਕਰਦੇ ਹਨ, ਡੇਟਾਬੇਸ ਨਾਲ ਗੱਲਬਾਤ ਕਰਦੇ ਹਨ, ਅਤੇ ਸਾਦਾ HTML ਆਉਟਪੁੱਟ ਕਰਦੇ ਹਨ। ਉਹਨਾਂ ਦਾ JavaScript ਕਦੇ ਵੀ ਨੈੱਟਵਰਕ ਰਾਹੀਂ ਨਹੀਂ ਜਾਂਦਾ।
  • Client Components – ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ ਰਹਿੰਦੇ ਹਨ ਅਤੇ UI ਇੰਟਰਐਕਸ਼ਨਾਂ ਜਿਵੇਂ ਕਿ ਬਟਨ ਕਲਿੱਕ, ਫਾਰਮ ਸਬਮਿਸ਼ਨ, ਜਾਂ ਕਿਸੇ ਵੀ ਕੰਪੋਨੈਂਟ ਨੂੰ ਸੰਭਾਲਦੇ ਹਨ ਜੋ React state ਜਾਂ effects ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ।

ਫਰੇਮਵਰਕ ਇੱਕ ਸਧਾਰਨ ਡਾਇਰੈਕਟਿਵ (directive) ਨਾਲ ਇਸ ਵੰਡ ਨੂੰ ਲਾਗੂ ਕਰਦਾ ਹੈ। ਕਿਸੇ ਫਾਈਲ ਦੇ ਉੱਪਰ use client ਜੋੜਨ ਨਾਲ Next.js ਨੂੰ ਦੱਸਿਆ ਜਾਂਦਾ ਹੈ ਕਿ ਉਸ ਕੰਪੋਨੈਂਟ ਨੂੰ ਸਿਰਫ਼ ਕਲਾਇੰਟ-ਸਾਈਡ ਵਜੋਂ ਮੰਨਿਆ ਜਾਵੇ। ਉਸ ਮਾਰਕਰ ਤੋਂ ਬਿਨਾਂ ਕੁਝ ਵੀ ਡਿਫੌਲਟ ਰੂਪ ਵਿੱਚ ਇੱਕ Server Component ਹੁੰਦਾ ਹੈ।

ਅਸਲ ਦੁਨੀਆ ਦੇ ਅੰਕੜੇ

ਇੱਕ ਨਿੱਜੀ ਬਲੌਗ ਪੇਜ 'ਤੇ ਇੱਕ ਛੋਟਾ ਜਿਹਾ ਪ੍ਰਯੋਗ ਇਸਦੇ ਪ੍ਰਭਾਵ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ। Fetch ਨੂੰ ਇੱਕ Server Component ਵਿੱਚ ਮੂਵ ਕਰਨ ਅਤੇ ਸਰਵਰ ਨੂੰ ਲਿਸਟ ਨੂੰ ਸਟੈਟਿਕ HTML ਵਜੋਂ ਰੈਂਡਰ ਕਰਨ ਦੇਣ ਤੋਂ ਬਾਅਦ, JavaScript ਬੰਡਲ 60% ਘਟ ਗਿਆ ਅਤੇ ਪੇਜ 200 ms ਤੋਂ ਘੱਟ ਸਮੇਂ ਵਿੱਚ ਰੈਂਡਰ ਹੋ ਗਿਆ।

ਇੱਕ ਵਿਵਹਾਰਕ ਲੇਅਰਿੰਗ ਪੈਟਰਨ

  1. Bottom layer (Server) – APIs ਜਾਂ ਡੇਟਾਬੇਸ ਤੋਂ ਡੇਟਾ ਕੱਢੋ। ਕੋਈ ਵੀ ਨਿੱਜੀ ਲੌਜਿਕ ਇੱਥੇ ਰੱਖੋ; ਇਹ ਕਦੇ ਵੀ ਸਰਵਰ ਤੋਂ ਬਾਹਰ ਨਹੀਂ ਜਾਂਦਾ।
  2. Middle layer (Server) – ਕੱਚੇ ਡੇਟਾ ਨੂੰ ਸ਼ੁੱਧ HTML ਮਾਰਕਅੱਪ ਵਿੱਚ ਬਦਲੋ। ਇਹ ਲੇਅਰ ਅਜੇ ਵੀ React ਦੇ JSX ਸਿੰਟੈਕਸ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੀ ਹੈ ਪਰ ਸਿਰਫ਼ ਸਰਵਰ ਤੱਕ ਹੀ ਸੀਮਤ ਰਹਿੰਦੀ ਹੈ।
  3. Top layer (Client) – ਇੰਟਰਐਕਟੀਵਿਟੀ ਲਈ ਛੋਟੇ, ਅਲੱਗ-ਥਲੱਗ ਵਿਜੇਟਸ (widgets) ਪਾਓ। ਆਮ ਉਦਾਹਰਣਾਂ “like” ਬਟਨ, ਕਮੈਂਟ ਫਾਰਮ, ਜਾਂ ਡ੍ਰੌਪਡਾਊਨ ਮੇਨੂ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ state ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

ਇਸ ਹਾਇਰਾਰਕੀ ਦੀ ਪਾਲਣਾ ਕਰਨ ਨਾਲ ਐਪ ਦਾ ਜ਼ਿਆਦਾਤਰ ਹਿੱਸਾ ਹਲਕਾ ਰਹਿੰਦਾ ਹੈ ਅਤੇ ਨਾਲ ਹੀ ਉਹ ਡਾਇਨਾਮਿਕ ਅਹਿਸਾਸ ਵੀ ਬਣਿਆ ਰਹਿੰਦਾ ਹੈ ਜਿਸ ਦੀ ਉਮੀਦ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਹੁੰਦੀ ਹੈ।

ਕਦਮ ਜੋ ਤੁਸੀਂ ਅੱਜ ਅਜ਼ਮਾ ਸਕਦੇ ਹੋ

  1. ਆਪਣੇ ਕੋਡਬੇਸ ਵਿੱਚ ਉਹਨਾਂ ਕੰਪੋਨੈਂਟਸ ਦੀ ਜਾਂਚ ਕਰੋ ਜੋ ਸਿਰਫ਼ ਡੇਟਾ ਫੈਚ ਕਰਨ ਲਈ useEffect ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ।
  2. Fetch ਕਾਲ ਨੂੰ ਇੱਕ ਨਵੇਂ Server Component ਵਿੱਚ ਕੱਢੋ ਅਤੇ ਇਸਨੂੰ ਰੈਂਡਰਡ ਮਾਰਕਅੱਪ ਵਾਪਸ ਕਰਨ ਦਿਓ।
  3. ਬਚੇ ਹੋਏ ਕਿਸੇ ਵੀ ਇੰਟਰਐਕਟਿਵ ਤੱਤ ਲਈ ਇੱਕ ਨਿਗਰੂ (minimal) ਕਲਾਇੰਟ ਕੰਪੋਨੈਂਟ ਬਣਾਓ (ਉੱਪਰ use client ਜੋੜੋ)।
  4. ਆਪਣਾ ਬੰਡਲ ਐਨਾਲਾਈਜ਼ਰ (bundle analyzer) ਦੁਬਾਰਾ ਚਲਾਓ; ਤੁਹਾਨੂੰ ਸਾਈਜ਼ ਵਿੱਚ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਗਿਰਾਵਟ ਦਿਖਾਈ ਦੇਣੀ ਚਾਹੀਦੀ ਹੈ।

ਹਰ ਜਗ੍ਹਾ use client ਦੀ ਵਰਤੋਂ ਕਰਨ ਤੋਂ ਬਚੋ। ਜੇਕਰ ਕੋਈ ਕੰਪੋਨੈਂਟ React state, context, ਜਾਂ lifecycle hooks 'ਤੇ ਨਿਰਭਰ ਨਹੀਂ ਕਰਦਾ ਹੈ, ਤਾਂ ਇਸਨੂੰ Server Component ਵਜੋਂ ਹੀ ਰਹਿਣ ਦਿਓ। ਤੁਸੀਂ ਜਿੰਨਾ ਜ਼ਿਆਦਾ ਕੋਡ ਕਲਾਇੰਟ ਤੋਂ ਦੂਰ ਰੱਖੋਗੇ, ਡਾਊਨਲੋਡ ਉਨਾ ਹੀ ਛੋਟਾ ਹੋਵੇਗਾ ਅਤੇ ਪੇਜ ਉਨਾ ਹੀ ਤੇਜ਼ ਹੋਵੇਗਾ।

Takeaway: ਡੇਟਾ ਫੈਚਿੰਗ ਅਤੇ ਭਾਰੀ ਰੈਂਡਰਿੰਗ ਨੂੰ ਸਰਵਰ 'ਤੇ ਮੂਵ ਕਰਕੇ, Next.js 14 ਤੁਹਾਨੂੰ ਬਹੁਤ ਘੱਟ JavaScript ਭੇਜਣ, ਤੁਰੰਤ ਪੂਰੀ ਤਰ੍ਹਾਂ ਰੈਂਡਰ ਕੀਤਾ ਹੋਇਆ HTML ਪ੍ਰਦਾਨ ਕਰਨ, ਅਤੇ ਜਿੱਥੇ ਅਸਲ ਵਿੱਚ ਲੋੜ ਹੋਵੇ ਉੱਥੇ ਇੰਟਰਐਕਟੀਵਿਟੀ ਬਣਾਈ ਰੱਖਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। ਨਤੀਜਾ ਇੱਕ ਤੇਜ਼, ਹਲਕਾ ਵੈੱਬ ਅਨੁਭਵ ਹੈ ਜੋ ਉਪਭੋਗਤਾਵਾਂ ਅਤੇ ਸਰਚ ਇੰਜਣਾਂ ਦੋਵਾਂ ਲਈ ਲਾਭਦਾਇਕ ਹੈ।