ਵੈੱਬਸਾਈਟ ਕੈਸ਼ਿੰਗ ਅਨੁਕੂਲਨ

ਕਿਸੇ ਵੈੱਬਸਾਈਟ ਦੀ ਹੌਲੀ-ਗਤੀ ਦਾ ਮੂਲ ਕਾਰਨ ਆਮ ਤੌਰ “ਤੇ ਇੱਕ ਤਸਵੀਰ ਨਹੀਂ ਹੁੰਦੀ, ਸਗੋਂਰੂਟਿੰਗ + ਸਰਵਰ-ਸਾਈਡ ਜਨਰੇਸ਼ਨ + ਸਥਿਰ ਸਰੋਤ ਡਿਲਿਵਰੀ ਦੀ ਬੇਨਤੀਓਵਰਲੈਪ ਕਾਰਨ:

• ਉਪਭੋਗਤਾ ਤੁਹਾਡੇ ਸਰਵਰ ਤੋਂ ਬਹੁਤ ਦੂਰ ਹਨ, ਜਿਸ ਕਾਰਨ ਨੈੱਟਵਰਕ RTT ਵੱਧ ਹੈ (ਇਹ ਖਾਸ ਤੌਰ 'ਤੇ ਮਹਾਂਦੀਪਾਂ ਵਿਚਕਾਰ ਵਧੇਰੇ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ)
• WordPress ਨੂੰ PHP ਚਲਾਉਣਾ ਪੈਂਦਾ ਹੈ, ਡੇਟਾਬੇਸ ਨੂੰ ਕਵੈਰੀ ਕਰਨਾ ਪੈਂਦਾ ਹੈ ਅਤੇ ਹਰ ਬੇਨਤੀ ਨਾਲ ਟੈਂਪਲੇਟ ਨੂੰ ਰੈਂਡਰ ਕਰਨਾ ਪੈਂਦਾ ਹੈ → TTFB (ਪਹਿਲੇ ਬਾਈਟ ਤੱਕ ਦਾ ਸਮਾਂ) ਵੱਧ ਗਿਆ ਹੈ।
• ਪੰਨੇ ਨੂੰ JavaScript, CSS, ਫੌਂਟ ਅਤੇ ਤੀਜੀ-ਪੱਖੀ ਸਕ੍ਰਿਪਟਾਂ ਵੀ ਲੋਡ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਜਿਸ ਨਾਲ ਰੈਂਡਰਿੰਗ ਅਤੇ ਇੰਟਰਐਕਟਿਵਿਟੀ ਹੌਲੀ ਹੋ ਜਾਂਦੀ ਹੈ।

ਕੈਸ਼ਿੰਗ ਪਲੱਗਇਨਇਸ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਦੀ ਕੁੰਜੀ ਇਹ ਹੈ ਕਿ “ਦੁਬਾਰਾ ਗਣਨਾ ਕੀਤੇ” ਗਏ ਪੰਨਿਆਂ ਦੇ ਨਤੀਜੇ ਸਟੋਰ ਕੀਤੇ ਜਾਣ, ਤਾਂ ਜੋ ਸਰਵਰ ਨੂੰ ਹਰ ਵਾਰੀ ਉਹਨਾਂ ਦੀ ਦੁਬਾਰਾ ਗਣਨਾ ਨਾ ਕਰਨੀ ਪਵੇ; ਅਤੇ ਉਚਿਤ ਰਣਨੀਤੀਆਂ ਲਾਗੂ ਕਰਕੇ ਇਹ ਯਕੀਨੀ ਬਣਾਇਆ ਜਾਵੇ ਕਿ ਵੱਧ ਤੋਂ ਵੱਧ ਯੂਜ਼ਰ ਕੈਸ਼ ਨੂੰ ਹਿੱਟ ਕਰਨ, ਜਿਸ ਨਾਲ TTFB ਵਿੱਚ ਕਾਫੀ ਘਟਾਅ ਆਵੇ।ਵਰਡਪ੍ਰੈੱਸ ਅਧਿਕਾਰਤ ਦਸਤਾਵੇਜ਼ੀਕਰਨਇਹ ਇਹ ਵੀ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ W3 Total Cache ਅਤੇ WP Super Cache ਵਰਗੇ ਪਲੱਗਇਨ ਪੰਨਿਆਂ ਨੂੰ ਸਥਿਰ ਫਾਈਲਾਂ ਵਜੋਂ ਕੈਸ਼ ਕਰ ਸਕਦੇ ਹਨ ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਸਿੱਧਾ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਸਰਵ ਕਰ ਸਕਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਸਰਵਰ 'ਤੇ ਲੋਡ ਘੱਟ ਹੁੰਦਾ ਹੈ।

ਇਸ ਪੰਨੇ ਨੂੰ ਪੜ੍ਹਨ ਤੋਂ ਪਹਿਲਾਂ, ਇਹ ਤਿੰਨ ਸੁਨਹਿਰੀ ਨਿਯਮ ਯਾਦ ਰੱਖੋ।

ਇੱਕ ਸਮੇਂ 'ਤੇ ਸਿਰਫ਼ ਇੱਕ ਪੇਜ ਕੈਸ਼ਿੰਗ ਪਲੱਗਇਨ ਦੀ ਵਰਤੋਂ ਕਰੋ।

ਜਦੋਂ ਇੱਕੋ ਸਮੇਂ ਕਈ ਕੈਸ਼ਿੰਗ ਪਲੱਗਇਨ ਚਾਲੂ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਸਭ ਤੋਂ ਆਮ ਨਤੀਜਾ ਤੇਜ਼ ਕਾਰਗੁਜ਼ਾਰੀ ਨਹੀਂ ਹੁੰਦਾ, ਸਗੋਂ:

• ਓਵਰਲੈਪ ਹੋਣ ਵਾਲੇ ਕੈਸ਼ ਨਿਯਮ, ਇੱਕ ਦੂਜੇ ਨੂੰ ਓਵਰਰਾਈਟ ਕਰਨ ਵਾਲੇ ਕੈਸ਼, ਅਤੇ ਕੈਸ਼ ਹਿੱਟ ਦਰਾਂ ਵਿੱਚ ਗਿਰਾਵਟ।
• ਲੌਗਇਨ ਸਥਿਤੀ, ਭਾਸ਼ਾ, ਖਰੀਦਦਾਰੀ ਟੋਕਰੀ ਅਤੇ ਕੀਮਤਾਂ ਵਰਗੀ ਗਤੀਸ਼ੀਲ ਸਮੱਗਰੀ ਕੈਸ਼ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਜਿਸ ਨਾਲ “ਗਲਤ ਸਮੱਗਰੀ” ਦੀਆਂ ਗਲਤੀਆਂ ਆਉਂਦੀਆਂ ਹਨ।
  ਕਈ ਪਲੱਗਇਨ ਦਸਤਾਵੇਜ਼ ਅਤੇ ਗਾਈਡਾਂ ਸਿਫ਼ਾਰਸ਼ ਕਰਦੀਆਂ ਹਨ ਕਿ ਜਦੋਂ ਕਿਸੇ ਖਾਸ ਕੈਸ਼ਿੰਗ ਪਲੱਗਇਨ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ,ਹੋਰ ਕੈਸ਼ਿੰਗ ਪਲੱਗਇਨਾਂ ਨੂੰ ਅਯੋਗ ਕਰੋਟਕਰਾਅ ਤੋਂ ਬਚਣ ਲਈ

2. ਈ-ਕਾਮਰਸ/ਮੈਂਬਰਸ਼ਿਪ/ਬਹੁ-ਭਾਸ਼ੀ ਸਾਈਟਾਂ: ਕੈਸ਼ਿੰਗ ਕੋਈ “ਟੌਗਲ ਸਵਿੱਚ” ਨਹੀਂ, ਸਗੋਂ “ਨਿਯਮਾਂ ਦਾ ਇੱਕ ਸਿਸਟਮ” ਹੈ।”

ਵੂ-ਕਾਮਰਸ ਅਧਿਕਾਰਤ ਕਾਰਗੁਜ਼ਾਰੀ ਦਸਤਾਵੇਜ਼ੀਕਰਨਕਿਰਪਾ ਕਰਕੇ ਧਿਆਨ ਦਿਓ: ਕੈਸ਼ਿੰਗ ਪਲੱਗਇਨ ਵਿੱਚ, ਕਿਰਪਾ ਕਰਕੇ ਇਹ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਖਰੀਦਦਾਰੀ ਟੋਕਰੀ / ਚੈੱਕਆਊਟ / ਖਾਤਾ ਇਹ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਇਹ ਪੰਨੇ ਕੈਸ਼ ਨਾ ਕੀਤੇ ਜਾਣ, ਅਤੇ ਇਹ ਵੀ ਸਿਫਾਰਸ਼ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਕਿ ਤੁਸੀਂ JavaScript ਫਾਈਲਾਂ ਨੂੰ ਮਿਨੀਫਾਈ ਕਰਨ ਤੋਂ ਬਚੋ (ਕਿਉਂਕਿ ਇਸ ਨਾਲ ਆਸਾਨੀ ਨਾਲ ਅਨੁਕੂਲਤਾ ਸੰਬੰਧੀ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਹੋ ਸਕਦੀਆਂ ਹਨ)।

3. “ਕੈਸ਼ਿੰਗ ਪਲੱਗਇਨ ≠ CDN”, ਪਰ ਕੈਸ਼ਿੰਗ ਪਲੱਗਇਨ CDN ਦੀ ਬੁਨਿਆਦ ਬਣਾਉਂਦਾ ਹੈ।

ਕੈਸ਼ਿੰਗ ਪਲੱਗਇਨ ਮੂਲ ਸਰਵਰ “ਤੇ ਗਿਣਤੀ ਘੱਟ ਹੋਣ ਦੀ ਸਮੱਸਿਆ ਦਾ ਹੱਲ ਕਰਦਾ ਹੈ;ਇੱਕ ਟੀਪੀ273ਟੀ ਹੱਲ ਇਹ ਹੈ ਕਿ ਸਮੱਗਰੀ ਨੂੰ ਉਪਭੋਗਤਾਵਾਂ ਦੇ ਨੇੜੇ ਲਿਆਂਦਾ ਜਾਵੇ। ਇਹ ਦੋਵੇਂ ਤਰੀਕੇ ਇੱਕ ਦੂਜੇ ਨੂੰ ਪੂਰਕ ਕਰਦੇ ਹਨ: ਪਹਿਲਾਂ ਮੂਲ ਸਰਵਰ ਦਾ TTFB ਘਟਾਓ, ਫਿਰ ਸਥਿਰ ਸਰੋਤਾਂ ਨੂੰ CDN ਰਾਹੀਂ ਵੰਡੋ। ਇਹ ਦੁਨੀਆ ਭਰ ਦੇ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਸੇਵਾ ਦੇਣ ਲਈ ਸਭ ਤੋਂ ਭਰੋਸੇਯੋਗ ਤਰੀਕਾ ਹੈ।

ਤੁਰੰਤ ਚੋਣ: ਵੈੱਬਸਾਈਟ ਦੇ 4 ਸਭ ਤੋਂ ਆਮ ਦ੍ਰਿਸ਼

ਜੇ ਤੁਸੀਂ ਪੂਰਾ ਲੇਖ ਨਹੀਂ ਪੜ੍ਹਨਾ ਚਾਹੁੰਦੇ, ਤਾਂ ਹੇਠਾਂ ਦਿੱਤੇ ਚਾਰ ਵਿਕਲਪਾਂ ਵਿੱਚੋਂ ਚੁਣੋ – ਤੁਸੀਂ ਗਲਤ ਨਹੀਂ ਹੋ ਸਕਦੇ:

1. ਮਨ ਦੀ ਸ਼ਾਂਤੀ, ਭਰੋਸੇਯੋਗਤਾ ਅਤੇ ਵਿਸ਼ਵ ਪੱਧਰੀ ਪਹੁੰਚ ਦੀ ਭਾਲ → ਡਬਲਯੂਪੀ ਰਾਕੇਟ(ਭੁਗਤਾਨੀ)
2. ਸਰਵਰ ਯਕੀਨਨ LiteSpeed/OpenLiteSpeed 'ਤੇ ਚੱਲ ਰਿਹਾ ਹੈ। → ਲਾਈਟਸਪੀਡ ਕੈਸ਼(ਮੁਫ਼ਤ, ਪਰ ਸਰਵਰ ਦੀ ਸਮਰੱਥਾ 'ਤੇ ਬਹੁਤ ਜ਼ਿਆਦਾ ਨਿਰਭਰ)ਕੈਸ਼ਿੰਗ ਦੀ ਕਾਰਜਕੁਸ਼ਲਤਾ ਲਾਜ਼ਮੀ ਹੈ। ਲਾਈਟਸਪੀਡ ਸਰਵਰ ਕੰਪੋਨੈਂਟਕੰਮ ਕਰਨ ਦੇ ਯੋਗ ਹੋਣਾ
3. ਮੁਫ਼ਤ ਅਤੇ ਭਰੋਸੇਯੋਗ ਹੱਲ ਦੀ ਭਾਲ ਵਿੱਚ ਸਮੱਗਰੀ ਵਾਲੀਆਂ ਸਾਈਟਾਂ/ਬਲੌਗ/ਦਸਤਾਵੇਜ਼ ਭੰਡਾਰ → WP ਸੁਪਰ ਕੈਸ਼(ਸਥਿਰ HTML ਕੈਸ਼ਿੰਗ): ਲੌਗ ਇਨ ਨਾ ਕੀਤੇ ਜ਼ਿਆਦਾਤਰ ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਸਥਿਰ HTML ਫਾਈਲਾਂ ਤਿਆਰ ਕਰੋ
4. ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਤਕਨੀਕੀ ਟੀਮ ਹੈ ਅਤੇ ਤੁਹਾਨੂੰ ਬਾਰੀਕ-ਪੱਧਰੀ ਨਿਯੰਤਰਣ (CDN/ਓਬਜੈਕਟ ਕੈਸ਼/ਕਈ ਮੋਡੀਊਲ) ਦੀ ਲੋੜ ਹੈ। → ਡਬਲਯੂ3 ਟੋਟਲ ਕੈਸ਼(ਸ਼ਕਤੀਸ਼ਾਲੀ ਪਰ ਜਟਿਲ): CDN ਨਾਲ ਏਕੀਕ੍ਰਿਤ ਇੱਕ ਵਿਆਪਕ ਪ੍ਰਦਰਸ਼ਨ ਢਾਂਚਾ ਪੇਸ਼ ਕਰਦਾ ਹੈ।

ਕੈਸ਼ ਅਸਲ ਵਿੱਚ ਕੀ ਸਟੋਰ ਕਰਦਾ ਹੈ?

“ਕੈਸ਼ ਇੰਸਟਾਲ ਕਰਨ ਦੇ ਬਾਵਜੂਦ ਕੁਝ ਵੈਬਸਾਈਟਾਂ ਹਾਲੇ ਵੀ ਹੌਲੀ ਕਿਉਂ ਹਨ?” ਅਸੀਂ ਵਰਡਪ੍ਰੈੱਸ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਨੂੰ ਪੰਜ ਪਰਤਾਂ ਵਿੱਚ ਵੰਡਿਆ ਹੈ:

1. ਬ੍ਰਾਊਜ਼ਰ ਕੈਸ਼: ਅਗਲੇ ਦੌਰਿਆਂ ਨੂੰ ਤੇਜ਼ ਬਣਾਓ (ਸਥਿਰ ਸਰੋਤਾਂ ਲਈ ਕੈਸ਼ਿੰਗ ਹੈੱਡਰ, ਸੰਸਕਰਣ ਨੰਬਰ)
2. ਪੰਨਾ ਕੈਸ਼ਿੰਗ: ਪੰਨੇ ਦੇ ਆਉਟਪੁੱਟ ਨੂੰ HTML ਵਜੋਂ ਕੈਸ਼ ਕਰੋ (ਇਸ ਪੰਨੇ ਦਾ ਮੁੱਖ ਕੇਂਦਰ)
3. ਆਬਜੈਕਟ ਕੈਸ਼: ਡੇਟਾਬੇਸ ਕੁਐਰੀ ਦੇ ਨਤੀਜਿਆਂ ਨੂੰ ਕੈਸ਼ ਕਰਨਾ (ਖਾਸ ਤੌਰ 'ਤੇ ਗਤੀਸ਼ੀਲ ਵੈੱਬਸਾਈਟਾਂ ਲਈ ਕੀਮਤੀ)
4. PHP ਓਪਕੈਸ਼: 1TB–184TB ਬਾਈਟਕੋਡ ਕੈਸ਼ ਕਰੋ (ਆਮ ਤੌਰ 'ਤੇ ਸਰਵਰ ਦੁਆਰਾ ਸੰਰਚਿਤ; ਪਲੱਗਇਨ ਦਾ ਮੁੱਖ ਧਿਆਨ ਨਹੀਂ)
5. CDN/ਐਜ ਕੈਸ਼: ਉਪਭੋਗਤਾਵਾਂ ਦੇ ਨੇੜੇ ਵਾਲੇ ਨੋਡਾਂ 'ਤੇ ਸਰੋਤ ਰੱਖੋ

ਇਹ ਲੇਖ ਇਸ 'ਤੇ ਕੇਂਦਰਿਤ ਹੈ: ਪੇਜ ਕੈਸ਼ਿੰਗ ਪਲੱਗਇਨ;
ਪਰ ਅਸੀਂ ਤੁਹਾਨੂੰ ਯਾਦ ਦਿਵਾਉਂਦੇ ਰਹਾਂਗੇ: ਵੈੱਬਸਾਈਟਾਂ ਨੂੰ “ਸੱਚਮੁੱਚ ਤੇਜ਼” ਹੋਣ ਲਈ ਅਕਸਰ 2 ਅਤੇ 5 ਦੇ ਮਿਲਾਪ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

ਪਲੱਗਇਨ 1:ਡਬਲਯੂਪੀ ਰਾਕੇਟ(ਭੁਗਤਾਨੀ) — ਇੱਕ “ਚਿੰਤਾ-ਰਹਿਤ” ਸਰਬ-ਇੱਕ ਹੱਲ

WP Rocket WordPress ਭਾਈਚਾਰੇ ਵਿੱਚ ਇਸ ਲਈ ਲੋਕਪ੍ਰਿਯ ਹੈ ਕਿ ਇਹ ਜਾਦੂਈ ਨਹੀਂ, ਸਗੋਂ ਇਸ ਨੇ ਤਿੰਨ ਸਭ ਤੋਂ ਆਮ ਪ੍ਰਦਰਸ਼ਨ ਸੁਧਾਰ ਦੀਆਂ ਕਿਸਮਾਂ ਨੂੰ “ਸੰਭਾਲਣਯੋਗ ਪੈਕੇਜਾਂ” ਵਿੱਚ ਪੈਕ ਕੀਤਾ ਹੈ:

• ਪੰਨਾ ਕੈਸ਼ਿੰਗ (ਮੂਲ ਸਰਵਰ ਦੇ TTFB ਨੂੰ ਘਟਾਉਣਾ)
• ਕੇਸ਼ ਪ੍ਰੀਲੋਡਿੰਗ/ਵਾਰਮਿੰਗ (ਦੁਨੀਆ ਭਰ ਦੇ ਸਥਾਨਾਂ ਤੋਂ ਸਾਈਟ 'ਤੇ ਪਹੁੰਚਣ ਵਾਲੇ ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਪਹਿਲੀ ਵਾਰ ਦੇ ਅਨੁਭਵ ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਣ ਲਈ)
• ਮੁੱਖ ਫਰੰਟ-ਐਂਡ ਅਨੁਕੂਲਨ (ਖਾਸ ਕਰਕੇ JS ਮੁਲਤਵੀਕਰਨ, CSS ਪ੍ਰੋਸੈਸਿੰਗ, ਆਦਿ)

ਇਸਦਾਅਧਿਕਾਰਕ ਦਸਤਾਵੇਜ਼ਇਹ ਵੀ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਦੱਸਦਾ ਹੈ ਕਿ ਜੇ ਤੁਸੀਂ ਪੇਜ ਕੈਸ਼ਿੰਗ ਬੰਦ ਕਰ ਦਿੰਦੇ ਹੋ, ਤਾਂ ਵੀ ਪ੍ਰੀਲੋਡਿੰਗ ਚਾਲੂ ਕਰਨ ਨਾਲ ਕੁਝ ਅਨੁਕੂਲਨ ਪ੍ਰਕਿਰਿਆਵਾਂ (ਜਿਵੇਂ ਕਿ CSS ਅਤੇ JavaScript-ਸਬੰਧੀ ਅਨੁਕੂਲਨ) ਸ਼ੁਰੂ ਜਾਂ ਚਲਾਉਣ ਲਈ ਪ੍ਰੇਰਿਤ ਹੋ ਸਕਦੀਆਂ ਹਨ।

1.1 WP ਰਾਕਿਟ ਕਿਸ ਲਈ ਢੁਕਵਾਂ ਹੈ?

WP Rocket ਖਾਸ ਤੌਰ 'ਤੇ ਹੇਠ ਲਿਖੀਆਂ ਕਿਸਮਾਂ ਦੀਆਂ ਵੈੱਬਸਾਈਟਾਂ ਲਈ ਬਹੁਤ ਉਚਿਤ ਹੈ:

• ਕਾਰਪੋਰੇਟ ਵੈੱਬਸਾਈਟਾਂ, ਬ੍ਰਾਂਡ ਵੈੱਬਸਾਈਟਾਂ, ਸਮੱਗਰੀ ਮਾਰਕੀਟਿੰਗ ਸਾਈਟਾਂ, ਲੈਂਡਿੰਗ ਪੇਜ (ਕਈ ਦੇਸ਼ਾਂ ਅਤੇ ਖੇਤਰਾਂ ਤੋਂ ਆਉਣ ਵਾਲਾ ਟ੍ਰੈਫਿਕ)
• ਮੈਂ ਸਥਿਰਤਾ ਨੂੰ ਸਭ ਤੋਂ ਵੱਧ ਤਰਜੀਹ ਦੇ ਕੇ ਤੇਜ਼ੀ ਨਾਲ ਲਾਂਚ ਕਰਨਾ ਪਸੰਦ ਕਰਾਂਗਾ, ਨਾ ਕਿ ਮੁਫ਼ਤ ਪਲੱਗਇਨਾਂ ਦੇ ਗੁੰਝਲ “ਤੇ ਨਿਰਭਰ ਕਰਨਾ।
• ਸਾਡੇ ਕੋਲ ਕੋਈ ਸਮਰਪਿਤ ਓਪਰੇਸ਼ਨ ਜਾਂ ਪ੍ਰਦਰਸ਼ਨ ਇੰਜੀਨੀਅਰ ਨਹੀਂ ਹੈ, ਪਰ ਯੂਜ਼ਰ ਅਨੁਭਵ ਅਤੇ SEO ਬਾਰੇ ਸਾਡੀਆਂ ਲੋੜਾਂ ਹਨ।
• ਵੂ-ਕਾਮਰਸ ਇਸਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ, ਪਰ ਵਧੇਰੇ ਸਾਵਧਾਨੀ ਨਾਲ (ਜਿਵੇਂ ਕਿ ਇਸ ਭਾਗ ਵਿੱਚ ਬਾਅਦ ਵਿੱਚ ਚਰਚਾ ਕੀਤੀ ਜਾਵੇਗੀ)ਨਿਯਮ ਅਤੇ ਜੋਖਮ）

1.2 ਵੈੱਬਸਾਈਟ ਬ੍ਰਾਊਜ਼ਿੰਗ ਦੇ ਦ੍ਰਿਸ਼ਾਂ ਵਿੱਚ ਇਸਦੀ ਮੁੱਖ ਕੀਮਤ (“ਕੇਵਲ ਕੈਸ਼ ਟੌਗਲ” ਤੋਂ ਵੱਧ)

A. ਕੈਸ਼ ਪ੍ਰੀਲੋਡਿੰਗ: ਵੰਡੇ ਹੋਏ ਵੈੱਬਸਾਈਟ ਟ੍ਰੈਫਿਕ ਕਾਰਨ ਪਹਿਲੀ ਵਾਰੀ ਦੌਰਿਆਂ ਦੌਰਾਨ ਹੋਣ ਵਾਲੀ ਅਸਥਿਰਤਾ ਦੀ ਸਮੱਸਿਆ ਦਾ ਹੱਲ“

ਜਦੋਂ ਵੈਬਸਾਈਟ ਦੇ ਉਪਭੋਗਤਾ ਵੱਖ-ਵੱਖ ਥਾਵਾਂ 'ਤੇ ਫੈਲੇ ਹੁੰਦੇ ਹਨ, ਤਾਂ ਤੁਹਾਨੂੰ ਇੱਕ ਬਹੁਤ ਆਮ ਕਿਸਮ ਦੀ ਸੁਸਤਤਾ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪੈਂਦਾ ਹੈ:
ਜਦੋਂ ਕਿਸੇ ਖਾਸ ਖੇਤਰ ਵਿੱਚ ਕੋਈ ਉਪਭੋਗਤਾ ਪਹਿਲੀ ਵਾਰੀ ਇੱਕ ਪੰਨਾ ਖੋਲ੍ਹਦਾ ਹੈ, ਅਤੇ ਉਸ ਪੰਨੇ ਦੀ ਕੈਸ਼ ਮਿਆਦ ਪੁੱਗ ਚੁੱਕੀ ਹੋਵੇ ਜਾਂ ਕਦੇ ਵੀ ਪਹਿਲਾਂ ਤੋਂ ਲੋਡ ਨਹੀਂ ਕੀਤੀ ਗਈ ਹੋਵੇ → ਉਸ ਉਪਭੋਗਤਾ ਨੂੰ PHP/DB ਦੀ ਪੂਰੀ ਰੈਂਡਰਿੰਗ ਲਾਗਤ ਚੁਕਾਉਣੀ ਪੈਂਦੀ ਹੈ।
ਪੂਰਵ-ਲੋਡਿੰਗ ਵਿਧੀਮਤਲਬ ਇਹ ਹੈ:“ਸ਼ੁਰੂਆਤੀ ਬਿਲਡ” ਦੀ ਲਾਗਤ ਪਹਿਲਾਂ ਹੀ ਅਦਾ ਕਰੋ।, ਇਸ ਤਰ੍ਹਾਂ ਪਹਿਲੀ ਵਾਰ ਆਉਣ ਵਾਲੇ ਮਹਿਮਾਨਾਂ ਨਾਲ ਗਿਨੀ ਪਿਗ ਵਾਂਗ ਵਿਹਾਰ ਕੀਤੇ ਜਾਣ ਦੀ ਸੰਭਾਵਨਾ ਘੱਟ ਹੋ ਜਾਂਦੀ ਹੈ।

• ਪਹਿਲਾਂ ਤੋਂ ਲੋਡ ਨਹੀਂ: ਜਿਹੜਾ ਪਹਿਲਾਂ ਆਵੇਗਾ, ਉਸਨੂੰ ਪਹਿਲਾਂ ਮਿਲੇਗਾ।
• ਪ੍ਰੀ-ਲੋਡਿੰਗ: ਸਿਸਟਮ ਬੈਕਗ੍ਰਾਊਂਡ ਵਿੱਚ ਕੇਂਦਰੀ ਤੌਰ 'ਤੇ ਕੈਸ਼ ਕੀਤੀ ਸਮੱਗਰੀ ਤਿਆਰ ਕਰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਪਹਿਲੀ ਵਾਰ ਆਉਣ ਵਾਲੇ ਵਿਜ਼ਿਟਰਾਂ ਨੂੰ ਇੱਕ ਵਧੇਰੇ ਸਥਿਰ ਅਨੁਭਵ ਮਿਲਦਾ ਹੈ।

B. ਜਾਵਾਸਕ੍ਰਿਪਟ ਦੇ ਚਲਾਉਣ ਵਿੱਚ ਦੇਰੀ: ਇਹ ਉਹ ਵਿਸ਼ੇਸ਼ਤਾ ਹੈ ਜੋ ਉਪਭੋਗਤਾ ਅਨੁਭਵ ਵਿੱਚ ਸਭ ਤੋਂ ਤੁਰੰਤ ਨਜ਼ਰ ਆਉਣ ਵਾਲੀ ਸੁਧਾਰ ਦਿੰਦੀ ਹੈ, ਪਰ ਇਹ ਸਭ ਤੋਂ ਵੱਡਾ ਖਤਰਾ ਵੀ ਲੈ ਕੇ ਆਉਂਦੀ ਹੈ।

WP Rocket ਅਧਿਕਾਰਕ ਤੌਰ “ਤੇ "ਜਾਵਾਸਕ੍ਰਿਪਟ ਚਲਾਉਣ ਵਿੱਚ ਦੇਰੀ ਕਰੋ”ਇਸਨੂੰ ਇਸਦੀ ਸਭ ਤੋਂ ਸ਼ਕਤੀਸ਼ਾਲੀ JavaScript ਅਨੁਕੂਲਨ ਵਜੋਂ ਵਰਣਨ ਕੀਤਾ ਗਿਆ ਹੈ: ਇਹ ਸਕ੍ਰਿਪਟ ਚਲਾਉਣ ਨੂੰ ਉਪਭੋਗਤਾ ਵੱਲੋਂ ਪੰਨੇ ਨਾਲ ਇੰਟਰੈਕਸ਼ਨ (ਮਾਊਸ ਹਿਲਾਉਣਾ, ਸਕ੍ਰੀਨ ਛੂਹਣਾ, ਸਕ੍ਰੋਲ ਕਰਨਾ, ਕਿਸੇ ਕੀ ਦਬਾਉਣਾ ਆਦਿ) ਕਰਨ ਤੱਕ ਟਾਲ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਜੋ ਪੰਨਾ ਪਹਿਲਾਂ ਰੈਂਡਰ ਹੋ ਜਾਵੇ।

ਇਹ ਵੈੱਬਸਾਈਟ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਕਿਉਂਕਿ ਸਕ੍ਰਿਪਟ ਲੋਡ ਹੋਣ ਅਤੇ ਇਸਦੇ ਚੱਲਣ 'ਤੇ ਰੋਕ ਲੱਗਣ ਨੂੰ ਮਹਾਦੀਪੀ ਨੈੱਟਵਰਕਾਂ 'ਤੇ ਆਸਾਨੀ ਨਾਲ ਵਧਾਇਆ ਜਾ ਸਕਦਾ ਹੈ:

• ਸਰੋਤ ਡਾਊਨਲੋਡ ਥੋੜ੍ਹੇ ਹੌਲੇ ਹਨ → ਮੁੱਖ ਥ੍ਰੈਡ ਸਕ੍ਰਿਪਟਾਂ ਕਾਰਨ ਜ਼ਿਆਦਾ ਭਾਰੀ ਹੋ ਸਕਦਾ ਹੈ
• ਤੀਜੀ-ਪੱਖੀ ਸਕ੍ਰਿਪਟਾਂ (ਜਿਵੇਂ ਕਿ ਵਿਸ਼ਲੇਸ਼ਣ, ਵਿਗਿਆਪਨ ਅਤੇ ਚੈਟ ਪਲੱਗਇਨ) INP ਅਤੇ ਪਰਸਪਰ ਕਿਰਿਆ ਦੇ ਵਿਲੰਬ ਨੂੰ ਹੋਰ ਵਧਾਉਣ ਦੀ ਜ਼ਿਆਦਾ ਸੰਭਾਵਨਾ ਰੱਖਦੀਆਂ ਹਨ।

ਹਾਲਾਂਕਿ, ਇਸ ਨਾਲ ਕੁਝ ਸਮੱਸਿਆਵਾਂ ਵੀ ਹੋ ਸਕਦੀਆਂ ਹਨ:

• ਜਾਵਾਸਕ੍ਰਿਪਟ ਵਿੱਚ ਦੇਰੀਆਂ ਦਾ ਪ੍ਰਭਾਵ ਮੈਨਿਊ, ਕੈਰੂਸਲ, ਪੌਪ-ਅੱਪ, ਫਾਰਮ ਵੈਲੀਡੇਸ਼ਨ, ਭੁਗਤਾਨ ਅਤੇ ਟ੍ਰੈਕਿੰਗ ਕੋਡ ਲਾਗੂ ਕਰਨ 'ਤੇ ਪੈ ਸਕਦਾ ਹੈ।
• ਇਸ ਲਈ ਇਹ “ਕਦਮ-ਦਰ-ਕਦਮ + ਬਲੈਕਲਿਸਟ ਬਾਹਰ ਰੱਖਣ” ਰਣਨੀਤੀ ਲਈ ਬਹੁਤ ਉਚਿਤ ਹੈ।

C. ਹੋਰ ਪਲੱਗਇਨਾਂ/ਥੀਮਾਂ ਨਾਲ ਅਨੁਕੂਲਤਾ: ਬਿਨਾਂ ਪਰੇਸ਼ਾਨੀ ਦਾ ਮਤਲਬ “ਸੰਘਰਸ਼ ਰਹਿਤ” ਨਹੀਂ ਹੁੰਦਾ।”

WP Rocket ਨੇ ਖਾਸ ਤੌਰ “ਤੇ ਸੂਚੀਬੱਧ ਕੀਤਾ ਹੈ "ਅਣ-ਅਨੁਕੂਲ ਪਲੱਗਇਨ/ਥੀਮ”ਸੂਚੀ, ਕਿਉਂਕਿ ਇਹ WP Rocket ਦੇ ਕੈਸ਼ਿੰਗ ਅਤੇ ਅਨੁਕੂਲਨ ਮਕੈਨਿਜ਼ਮਾਂ, ਜਿਵੇਂ ਕਿ ਆਉਟਪੁੱਟ ਬਫਰਿੰਗ, ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰ ਸਕਦਾ ਹੈ।

• ਜੇ ਤੁਹਾਡੀ ਵੈਬਸਾਈਟ “ਤੇ ਬਹੁਤ ਸਾਰੇ ਪਲੱਗਇਨ ਅਤੇ ਸਰੋਤ-ਭਾਰੀ ਥੀਮ ਹਨ, ਤਾਂ ”ਪ੍ਰਦਰਸ਼ਨ ਅਨੁਕੂਲਨ' ਨੂੰ ਇੱਕ ਛੋਟੇ ਪੈਮਾਨੇ ਦੇ ਡਿਪਲਾਇਮੈਂਟ ਪ੍ਰੋਜੈਕਟ ਵਜੋਂ ਲਓ: ਹਰ ਬਦਲਾਅ (ਫਾਰਮ, ਲੌਗਇਨ, ਭੁਗਤਾਨ, ਭਾਸ਼ਾ ਬਦਲਣਾ ਆਦਿ) ਤੋਂ ਬਾਅਦ ਰਿਗਰੈਸ਼ਨ ਟੈਸਟਿੰਗ ਕਰੋ।

1.3 WooCommerce ਅਤੇ ਡਾਇਨਾਮਿਕ ਵੈੱਬਸਾਈਟਾਂ ਬਾਰੇ ਵਿਸ਼ੇਸ਼ ਨੋਟਸ

ਕੈਸ਼ਿੰਗ ਪਲੱਗਇਨ ਨੂੰ ਕੌਂਫਿਗਰ ਕਰਦੇ ਸਮੇਂ ਅਧਿਕਾਰਕ WooCommerce ਦਸਤਾਵੇਜ਼ਾਂ ਵਿੱਚ ਉਜਾਗਰ ਕੀਤਾ ਗਿਆ ਮੁੱਖ ਨੁਕਤਾ ਹੈ:

• ਖਰੀਦਦਾਰੀ ਟੋਕਰੀ / ਚੈੱਕਆਊਟ / ਖਾਤਾ ਕੈਸ਼ ਨਾ ਕਰੋ
• ਅਤੇ ਸਿਫਾਰਸ਼ ਕਰਦਾ ਹੈਜਾਵਾਸਕ੍ਰਿਪਟ ਫਾਈਲਾਂ ਨੂੰ ਛੋਟਾ ਕਰਨ ਤੋਂ ਬਚੋ

ਕਿਉਂ?

• ਖਰੀਦਦਾਰੀ ਟੋਕਰੀ, ਚੈੱਕਆਊਟ ਅਤੇ ਖਾਤਾ ਪੰਨੇ cookie / ਸੈਸ਼ਨ / ਨਾਨਸ 'ਤੇ ਬਹੁਤ ਜ਼ਿਆਦਾ ਨਿਰਭਰ ਕਰਦੇ ਹਨ।
• ਜਦੋਂ ਕੈਸ਼ ਇਹਨਾਂ ਪੰਨਿਆਂ ਨੂੰ “ਸਥਿਰ ਪੰਨੇ” ਵਜੋਂ ਮੰਨ ਲੈਂਦਾ ਹੈ, ਤਾਂ ਨਤੀਜੇ ਬਟਨਾਂ ਦੇ ਕੰਮ ਨਾ ਕਰਨ ਤੋਂ ਲੈ ਕੇ, ਸਭ ਤੋਂ ਮਾੜੇ ਹਾਲਾਤਾਂ ਵਿੱਚ ਕੀਮਤਾਂ, ਸਟਾਕ ਪੱਧਰਾਂ ਅਤੇ ਖਾਤੇ ਦੀਆਂ ਜਾਣਕਾਰੀਆਂ ਵਿੱਚ ਉਲਝਣ ਤੱਕ ਹੋ ਸਕਦੇ ਹਨ।
• ਸਭ ਤੋਂ ਮਾੜੀ ਗੱਲ ਇਹ ਹੈ ਕਿ ਤੁਹਾਡੇ ਟੈਸਟ ਇੱਕ ਖੇਤਰ ਵਿੱਚ ਸੁਚਾਰੂ ਤਰੀਕੇ ਨਾਲ ਚੱਲ ਸਕਦੇ ਹਨ, ਪਰ CDN/cache ਹਿੱਟਸ ਵਿੱਚ ਫਰਕ ਹੋਣ ਕਾਰਨ ਦੂਜੇ ਖੇਤਰ ਵਿੱਚ ਸਮੱਸਿਆਵਾਂ ਆ ਸਕਦੀਆਂ ਹਨ।

1.4 ਕੈਸ਼ ਪਲੱਗਇਨ ਨੀਤੀਆਂ ਲਈ ਸਿਫ਼ਾਰਸ਼ਾਂ

ਪੱਧਰ 1: ਬੁਨਿਆਦੀ ਸੁਰੱਖਿਆ ਉਪਾਅ (ਜੋ ਲਗਭਗ ਹਰ ਵੈੱਬਸਾਈਟ ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ)

• ਪੰਨਾ ਕੈਸ਼ਿੰਗ ਚਾਲੂ ਕਰੋ
• ਖੋਲ੍ਹੋਕੈਸ਼ ਪ੍ਰੀਲੋਡਿੰਗ(ਪਹਿਲੀ ਵਾਰ ਆਉਣ ਵਾਲੇ ਮਹਿਮਾਨਾਂ ਲਈ ਸਥਿਰਤਾ ਵਿੱਚ ਸੁਧਾਰ)
• ਇੱਕ ਸਮਝਦਾਰ ਬ੍ਰਾਊਜ਼ਰ ਕੈਸ਼ਿੰਗ ਰਣਨੀਤੀ (ਕਿਸੇ ਵੀ ਪੱਧਰ 'ਤੇ ਲਾਗੂ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ: WP Rocket, ਸਰਵਰ, ਜਾਂ CDN)

ਟੀਅਰ 2: ਦਰਮਿਆਨਾ ਰਿਟਰਨ, ਦਰਮਿਆਨਾ ਜੋਖਮ (ਜ਼ਿਆਦਾਤਰ ਸਮੱਗਰੀ ਵਾਲੀਆਂ ਸਾਈਟਾਂ ਲਈ ਢੁਕਵਾਂ)

• ਲੇਜ਼ੀ-ਲੋਡਿੰਗ ਚਿੱਤਰ / iframe (ਚਿੱਤਰ ਅਨੁਕੂਲਨ 'ਤੇ ਇੱਕ ਡੂੰਘੀ ਨਜ਼ਰ)
• CSS ਫਾਈਲ ਦਾ ਆਕਾਰ ਕੰਟਰੋਲ ਕਰੋ (ਉਦਾਹਰਨ ਵਜੋਂ, ਅਣਵਰਤੇ CSS ਨੂੰ ਹਟਾ ਕੇ)

ਟੀਅਰ 3: ਉੱਚੀ ਵਾਪਸੀ ਪਰ ਉੱਚਾ ਜੋਖਮ (ਬੈਕ-ਟੈਸਟਿੰਗ ਚੈੱਕਲਿਸਟ ਸ਼ਾਮਲ ਹੋਣੀ ਲਾਜ਼ਮੀ ਹੈ)

• ਜਾਵਾਸਕ੍ਰਿਪਟ ਦੀ ਚਲਾਉਣ ਨੂੰ ਮੁਲਤਵੀ ਕਰੋ (ਰੈਂਡਰਿੰਗ ਨੂੰ ਤਰਜੀਹ ਦਿਓ, ਪਰ ਇਸ ਨਾਲ ਇੰਟਰਐਕਟਿਵਿਟੀ ਪ੍ਰਭਾਵਿਤ ਹੋ ਸਕਦੀ ਹੈ)
• JS/CSS ਮਿਨੀਫਿਕੇਸ਼ਨ/ਕੰਬੀਨੇਸ਼ਨ: ਈ-ਕਾਮਰਸ, ਮੈਂਬਰਸ਼ਿਪ ਅਤੇ ਬਹੁਭਾਸ਼ੀ ਸਾਈਟਾਂ ਨਾਲ ਖਾਸ ਸਾਵਧਾਨੀ ਵਰਤੋ (WooCommerce ਨੇ ਜਾਵਾਸਕ੍ਰਿਪਟ ਮਿਨੀਫਿਕੇਸ਼ਨ ਨਾਲ ਜੁੜੇ ਖਤਰਿਆਂ ਬਾਰੇ ਵੀ ਚੇਤਾਵਨੀ ਦਿੱਤੀ ਹੈ।）

1.5 ਕੀਮਤ ਅਤੇ ਲਾਇਸੈਂਸਿੰਗ

• WP Rocket ਇੱਕ ਭੁਗਤਾਨ-ਆਧਾਰਿਤ ਲਾਇਸੈਂਸ ਮਾਡਲ 'ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਵੱਖ-ਵੱਖ ਲਾਇਸੈਂਸ ਸਾਈਟਾਂ ਦੀ ਗਿਣਤੀ ਦੇ ਅਨੁਸਾਰ ਉਪਲਬਧ ਹੁੰਦੇ ਹਨ।

ਪਲੱਗਇਨ 2:ਲਾਈਟਸਪੀਡ ਕੈਸ਼ (LSCWP)“ਮੁਫ਼ਤ ਟੌਪ-ਟੀਅਰ” ਦੀ ਪੇਸ਼ਕਸ਼ ਸਿਰਫ਼ ਉਦੋਂ ਹੀ ਵੈਧ ਹੈ ਜੇਕਰ ਸਰਵਰ ਅਸਲ ਵਿੱਚ LiteSpeed ਚਲਾ ਰਿਹਾ ਹੋਵੇ।

LiteSpeed Cache ਬਾਰੇ ਇੱਕ ਆਮ ਗਲਤਫਹਮੀ ਇਹ ਹੈ ਕਿ ਇਹ ਸਿਰਫ਼ ਇੱਕ WordPress ਪਲੱਗਇਨ ਹੈ, ਜੋ ਇੰਸਟਾਲ ਹੋਣ 'ਤੇ ਕਿਸੇ ਵੀ ਹੋਸਟਿੰਗ ਪਲੇਟਫਾਰਮ 'ਤੇ WP Rocket ਵਾਂਗ ਹੀ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਤਰੀਕੇ ਨਾਲ ਕੰਮ ਕਰੇਗਾ। ਅਸਲ ਵਿੱਚ ਇਹ ਗੱਲ ਸਹੀ ਨਹੀਂ ਹੈ।

ਲਾਈਟਸਪੀਡ ਅਧਿਕਾਰਤ ਦਸਤਾਵੇਜ਼ਸਪਸ਼ਟ ਕਰਨ ਲਈ: LSCWP ਦੀ ਕੈਸ਼ਿੰਗ ਫੰਕਸ਼ਨਲਿਟੀ ਲਈ LiteSpeed Server ਦੀ ਲੋੜ ਇਸ ਲਈ ਹੈ ਕਿ ਇਹ LiteSpeed Web Server ਦੀ ਬਿਲਟ-ਇਨ ਪੇਜ ਕੈਸ਼ਿੰਗ ਫੀਚਰ (LSCache) ਨਾਲ ਸੰਚਾਰ ਕਰ ਸਕੇ; ਇਹ ਪਲੱਗਇਨ ਸਰਵਰ ਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਕਿਹੜੇ ਪੰਨੇ ਕੈਸ਼ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ, ਕਿੰਨੀ ਦੇਰ ਲਈ, ਅਤੇ ਟੈਗਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਪੁਰਜ ਟ੍ਰਿਗਰ ਕਰਨ ਲਈ।

LiteSpeed Cache ਦਾ ਮੁੱਖ ਫਾਇਦਾ “ ਵਿੱਚ ਹੈ।“ਸਰਵਰ-ਸਾਈਡ ਪੇਜ ਕੈਸ਼ਿੰਗ (LSCache)”LiteSpeed/OpenLiteSpeed ਸਰਵਰਾਂ ਦੇ ਬਿਨਾਂ, ਇਹ ਮੁੱਖ ਫਾਇਦਾ ਮੌਜੂਦ ਨਹੀਂ ਹੋਵੇਗਾ।

2.1 ਲਾਈਟਸਪੀਡ ਕੈਸ਼ਇਹ ਕਿਸ ਲਈ ਹੈ?

ਇਸ ਲਈ ਢੁਕਵਾਂ:

• ਤੁਹਾਡੇ ਹੋਸਟਿੰਗ ਕੰਟਰੋਲ ਪੈਨਲ ਵਿੱਚ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਦੱਸਿਆ ਗਿਆ ਹੈ ਲਾਈਟਸਪੀਡ / ਓਪਨਲਾਈਟਸਪੀਡ(ਉਦਾਹਰਨ ਵਜੋਂ, ਬਹੁਤ ਸਾਰੇ cPanel ਸਰਵਰ ਇਹ ਦਿਖਾਉਂਦੇ ਹਨ)
• ਤੁਸੀਂ ਮੁਫ਼ਤ ਯੋਜਨਾ ਤੋਂ ਸ਼ਾਨਦਾਰ TTFB ਅਤੇ ਸਮਵਰਤੀ ਪ੍ਰੋਸੈਸਿੰਗ ਸਮਰੱਥਾਵਾਂ ਦੀ ਉਮੀਦ ਕਰਦੇ ਹੋ।“
• ਕੀ ਤੁਸੀਂ ਇਹ ਸਵੀਕਾਰ ਕਰਨ ਲਈ ਤਿਆਰ ਹੋ ਕਿ, ਹਾਲਾਂਕਿ ਇਹ ਬਹੁਤ ਸ਼ਕਤੀਸ਼ਾਲੀ ਹੈ, ਇਸ ਵਿੱਚ ਬਹੁਤ ਸਾਰੇ ਤਕਨੀਕੀ ਸੰਕਲਪ (TTL, Tag, Purge, ESI, Crawler…) ਵੀ ਸ਼ਾਮਲ ਹਨ?

ਖਾਸ ਤੌਰ 'ਤੇ ਢੁਕਵਾਂ ਨਹੀਂ:

• ਤੁਸੀਂ ਪੱਕਾ ਨਹੀਂ ਜਾਣਦੇ ਕਿ ਹੋਸਟ ਕਿਹੜਾ ਵੈੱਬ ਸਰਵਰ ਵਰਤ ਰਿਹਾ ਹੈ, ਜਾਂ ਤੁਸੀਂ ਪੁਸ਼ਟੀ ਕਰ ਲਈ ਹੈ ਕਿ ਇਹ Nginx ਜਾਂ Apache ਹੈ (ਜੇ ਤੁਸੀਂ ਸਿਰਫ਼ ਇਸ ਦੀਆਂ ਕੁਝ ਫਰੰਟ-ਐਂਡ ਅਪਟੀਮਾਈਜ਼ੇਸ਼ਨ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਹੀ ਵਰਤਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਇਸ ਦੀ ਲਾਗਤ-ਪ੍ਰਭਾਵਸ਼ੀਲਤਾ ਅਤੇ ਜਟਿਲਤਾ ਸ਼ਾਇਦ ਲਾਭਦਾਇਕ ਨਾ ਹੋਵੇ)
• ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਜਟਿਲ ਈ-ਕਾਮਰਸ/ਮੈਂਬਰਸ਼ਿਪ/ਬਹੁਭਾਸ਼ੀ ਸਾਈਟ ਹੈ, ਪਰ ਕੋਈ ਟੈਸਟਿੰਗ ਪ੍ਰਕਿਰਿਆ ਨਹੀਂ ਹੈ (LSCWP ਸ਼ਕਤੀਸ਼ਾਲੀ ਹੈ, ਪਰ ਇਹ “ਗਲਤ ਸਮੱਗਰੀ ਕੈਸ਼ ਕਰਨ” ਲਈ ਵਧੇਰੇ ਸੰਵੇਦਨਸ਼ੀਲ ਹੈ)

2.2 ਇਸਦੀ ਕੈਸ਼ਿੰਗ ਵਿਧੀ: ਇਹ “ਸਰਵਰ ਦੀਆਂ ਸਮਰੱਥਾਵਾਂ ਦਾ ਹਿੱਸਾ” ਵਰਗੀ ਕਿਉਂ ਹੈ”

ਤੁਸੀਂ ਇੰਜੀਨੀਅਰਿੰਗ ਸ਼ਬਦਾਵਲੀ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇੱਕ ਵਾਕ ਵਿੱਚ LiteSpeed Cache ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ, ਇਸਦਾ ਸਾਰ ਦੱਸ ਸਕਦੇ ਹੋ:

• WP ਰਾਕੇਟ / ਡਬਲਯੂਪੀ ਸੁਪਰ ਕੈਸ਼ ਇਹ ਉਪਾਅ ਮੁੱਖ ਤੌਰ 'ਤੇ WordPress/PHP ਪਾਸੇ ਕੈਸ਼ਿੰਗ ਅਤੇ ਅਨੁਕੂਲਨ ਨਾਲ ਸਬੰਧਤ ਹਨ;
• ਐਲਐਸਸੀਡਬਲਯੂਪੀ ਇਹ “WordPress ਡੈਸ਼ਬੋਰਡ + LiteSpeed ਸਰਵਰ ਦੇ ਬਿਲਟ-ਇਨ LSCache” ਦਾ ਸੁਮੇਲ ਹੈ: ਪਲੱਗਇਨ ਨਿਯਮ ਜਾਰੀ ਕਰਨ ਅਤੇ ਸਿਗਨਲ ਸਾਫ਼ ਕਰਨ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੈ, ਜਦਕਿ ਅਸਲ ਤੇਜ਼-ਗਤੀ ਵਾਲੀ ਪੇਜ ਕੈਸ਼ਿੰਗ ਹੁੰਦੀ ਹੈਸਰਵਰ ਪਰਤ。

ਇਸਦਾ ਉਪਭੋਗਤਾ ਅਨੁਭਵ 'ਤੇ ਸਿੱਧਾ ਪ੍ਰਭਾਵ ਪੈਂਦਾ ਹੈ: ਸਰਵਰ-ਸਾਈਡ ਕੈਸ਼ਿੰਗ ਆਮ ਤੌਰ 'ਤੇ ਹਲਕੀ, ਤੇਜ਼ ਅਤੇ ਇੱਕੋ ਸਮੇਂ ਆਉਣ ਵਾਲੀਆਂ ਬੇਨਤੀਆਂ ਨੂੰ (ਖਾਸ ਕਰਕੇ ਟ੍ਰੈਫਿਕ ਵਿੱਚ ਅਚਾਨਕ ਵਾਧੇ ਜਾਂ ਖੋਜ ਇੰਜਣ ਕ੍ਰਾਲਰਾਂ ਵੱਲੋਂ ਵਾਰ-ਵਾਰ ਆਉਣ ਦੌਰਾਨ) ਬਿਹਤਰ ਢੰਗ ਨਾਲ ਸੰਭਾਲ ਸਕਦੀ ਹੈ।

2.3 ਵੈੱਬਸਾਈਟ ਉਪਭੋਗਤਾ ਸਥਿਤੀ ਵਿੱਚ LSCWP ਦੀ ਵਰਤੋਂ ਕਰਨ ਦਾ “ਸਹੀ ਤਰੀਕਾ”

ਅਸੀਂ “ਸਹੀ ਪਹੁੰਚ” ਨੂੰ ਚਾਰ ਪੱਧਰਾਂ ਵਿੱਚ ਵੰਡਿਆ ਹੈ:

ਪਰਤ 1: ਪੰਨਾ ਕੈਸ਼ਿੰਗ ਰਣਨੀਤੀ (ਇਹ ਨਿਰਧਾਰਤ ਕਰਦੀ ਹੈ ਕਿ TTFB ਨੂੰ ਅਸਲ ਵਿੱਚ ਘਟਾਇਆ ਜਾ ਸਕਦਾ ਹੈ ਜਾਂ ਨਹੀਂ)

• ਨਿਰਧਾਰਤ ਕਰੋ ਕਿ ਕਿਹੜੇ ਪੰਨੇ ਕੈਸ਼ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ (ਅਧਿਕਤਰ ਜਨਤਕ ਸਮੱਗਰੀ ਵਾਲੇ ਪੰਨੇ)
• ਪਛਾਣੋ ਕਿ ਕਿਹੜੇ ਪੰਨੇ ਕਦੇ ਵੀ ਕੈਸ਼ ਨਹੀਂ ਕੀਤੇ ਜਾਣੇ ਚਾਹੀਦੇ (ਲੌਗਇਨ, ਖਾਤਾ, ਖਰੀਦਦਾਰੀ ਟੋਕਰੀ, ਚੈੱਕਆਊਟ, ਅਤੇ ਉਹ ਪੰਨੇ ਜੋ ਭਾਸ਼ਾ/ਕਰੰਸੀ ਬਦਲਣ ਲਈ cookie 'ਤੇ ਬਹੁਤ ਜ਼ਿਆਦਾ ਨਿਰਭਰ ਕਰਦੇ ਹਨ)
• ਕੈਸ਼ ਲਈ ਇੱਕ ਵਾਜਬ TTL ਨਿਰਧਾਰਤ ਕਰੋ (ਜਿੰਨੀ ਵਾਰੀ ਸਮੱਗਰੀ ਅਪਡੇਟ ਹੁੰਦੀ ਹੈ, TTL ਓਨਾ ਹੀ ਘੱਟ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ; ਇਸਦੇ ਉਲਟ, ਇਹ ਓਨਾ ਹੀ ਵੱਧ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ)
• ਇੱਕ ਸਫਾਈ ਨੀਤੀ ਬਣਾਓ: ਸਮੱਗਰੀ ਅੱਪਡੇਟ ਹੋਣ ਤੋਂ ਬਾਅਦ ਸੰਬੰਧਤ ਟੈਗਾਂ ਨੂੰ ਸਾਫ਼ ਕਰੋ (ਸਾਈਟ-ਵਿਆਪੀ ਸਫਾਈ ਕਰਨ ਦੀ ਬਜਾਏ)

ਜੇ ਇਹ ਪਰਤ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਕੀਤੀ ਜਾਵੇ, ਤਾਂ ਵੈਬਸਾਈਟ ਲਈ ਸਭ ਤੋਂ ਤੁਰੰਤ ਲਾਭ ਹੈ TTFB ਘੱਟ ਹੋ ਗਿਆ ਹੈ, ਅਤੇ ਪਹਿਲੀ ਸਕ੍ਰੀਨ ਦਾ ਲੋਡ ਵਧੇਰੇ ਸਥਿਰ ਹੈ।。

ਪਰਤ 2: ਪ੍ਰੀ-ਲੋਡਿੰਗ/ਕ੍ਰਾਲਿੰਗ (ਇਹ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ ਕਿ “ਘੱਟ-ਟ੍ਰੈਫਿਕ ਵਾਲੇ ਪੰਨਿਆਂ” ਦੀ ਪਹਿਲੀ ਵਾਰੀ ਵਿਜ਼ਿਟ ਹੌਲੀ ਹੈ ਜਾਂ ਨਹੀਂ)

ਵੈੱਬਸਾਈਟਾਂ “ਤੇ ਜਾਣ ਸਮੇਂ ”ਅਸੰਗਤ ਯੂਜ਼ਰ ਅਨੁਭਵ“ ਦਾ ਇੱਕ ਆਮ ਕਾਰਨ ”ਗਰਮ-ਠੰਢੀ ਕੈਸ਼ ਅੰਤਰ' ਹੁੰਦਾ ਹੈ:

• ਲੋਕਪ੍ਰਿਯ ਪੰਨੇ ਲਗਾਤਾਰ ਵੇਖੇ ਜਾਂਦੇ ਹਨ, ਇਸ ਲਈ ਕੈਸ਼ ਹਮੇਸ਼ਾਂ ਤਾਜ਼ਾ ਰਹਿੰਦਾ ਹੈ।
• ਜਿਹੜੇ ਪੰਨੇ ਬਹੁਤ ਟ੍ਰੈਫਿਕ ਨਹੀਂ ਲੈਂਦੇ, ਉਹ ਲੰਮੇ ਸਮੇਂ ਤੋਂ ਨਜ਼ਰਅੰਦਾਜ਼ ਕੀਤੇ ਗਏ ਹਨ, ਇਸ ਲਈ ਉਹ ਪਹਿਲੀ ਵਾਰ ਆਉਣ ਵਾਲੇ ਵਿਜ਼ਿਟਰਾਂ ਲਈ ਬਹੁਤ ਹੌਲੀ ਲੋਡ ਹੁੰਦੇ ਹਨ।

ਪ੍ਰੀਲੋਡਿੰਗ ਸਿਰਫ਼ ਕੇਕ 'ਤੇ ਆਈਸਿੰਗ ਨਹੀਂ; ਇਹ ਵੈਬਸਾਈਟ 'ਤੇ ਇੱਕਸਾਰ ਯੂਜ਼ਰ ਅਨੁਭਵ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਬਹੁਤ ਜ਼ਰੂਰੀ ਹੈ।

ਪਰਤ 3: ਗਤੀਸ਼ੀਲ ਸਮੱਗਰੀ (ਈ-ਕਾਮਰਸ/ਮੈਂਬਰਸ਼ਿਪ/ਬਹੁਭਾਸ਼ੀ) ਲਈ ਸੁਰੱਖਿਆ ਹੱਲ

LSCWP ਦੀ ਤਾਕਤ ਇਸ ਗੱਲ ਵਿੱਚ ਹੈ ਕਿ ਇਹ ਤੁਹਾਨੂੰ “ਉੱਨਤ ਸੰਦਾਂ” ਦੀ ਇੱਕ ਵਿਆਪਕ ਸ਼੍ਰੇਣੀ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ, ਜਿਵੇਂ ਕਿ:

• ਲੌਗ-ਇਨ ਕੀਤੇ ਉਪਭੋਗਤਾਵਾਂ, ਟਿੱਪਣੀਕਾਰਾਂ ਆਦਿ ਲਈ ਵੱਖ-ਵੱਖ ਕੈਸ਼ਿੰਗ ਰਣਨੀਤੀਆਂ।
• Edge-Side Inclusion (ESI) ਦਾ ਮੁੱਖ ਸਿਧਾਂਤ ਇਹ ਹੈ ਕਿ ਇੱਕ ਪੰਨੇ ਨੂੰ 'ਕੈਸ਼ਯੋਗ ਸਾਂਝੀ ਬਾਡੀ' ਅਤੇ 'ਗੈਰ-ਕੈਸ਼ਯੋਗ ਗਤੀਸ਼ੀਲ ਟੁਕੜਿਆਂ' ਵਿੱਚ ਵੰਡਿਆ ਜਾਵੇ, ਉਨ੍ਹਾਂ ਨੂੰ ਵੱਖ-ਵੱਖ ਤਰੀਕੇ ਨਾਲ ਪ੍ਰਕਿਰਿਆ ਕੀਤਾ ਜਾਵੇ, ਅਤੇ ਫਿਰ ਐਜ ਨੋਡ 'ਤੇ ਮੁੜ ਜੋੜਿਆ ਜਾਵੇ।

ਪਰਤ 4: ਆਨਲਾਈਨ ਸੇਵਾਵਾਂ ਅਤੇ ਵਿਕਲਪਿਕ ਸੁਧਾਰ

ਕਈ ਵੈਬਸਾਈਟ ਪ੍ਰਬੰਧਕ LSCWP ਵਿੱਚ QUIC.cloud ਦੀਆਂ ਆਨਲਾਈਨ ਸੇਵਾਵਾਂ (ਜਿਵੇਂ ਕਿ ਪੇਜ ਅਪਟੀਮਾਈਜੇਸ਼ਨ ਟੂਲ) ਨਾਲ ਸਾਹਮਣਾ ਕਰਨਗੇ।QUIC.cloud ਦਸਤਾਵੇਜ਼ੀਕਰਨਇਸ ਵਿੱਚ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਦੱਸਿਆ ਗਿਆ ਹੈ ਕਿ ਇਹ LSCWP ਨੂੰ ਪੇਜ ਅਪਟੀਮਾਈਜ਼ੇਸ਼ਨ ਸੇਵਾਵਾਂ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ Critical CSS (CCSS), Unique CSS (UCSS) ਅਤੇ Viewport-Optimised Images (VPI) ਸ਼ਾਮਲ ਹਨ।

• ਇਹ ਸੇਵਾਵਾਂ ਵਿਕਲਪਿਕ ਹਨ।ਤੁਸੀਂ ਸਿਰਫ਼ ਸਰਵਰ-ਸਾਈਡ ਕੈਸ਼ਿੰਗ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ, ਬਿਨਾਂ ਆਨਲਾਈਨ ਅਨੁਕੂਲਨ ਨੂੰ ਚਾਲੂ ਕੀਤੇ।
• ਇੱਕ ਵਾਰ ਆਨਲਾਈਨ ਸੇਵਾਵਾਂ ਚਾਲੂ ਹੋ ਜਾਣ 'ਤੇ, ਤੁਹਾਡੀ ਸਾਈਟ ਦੇ ਸਰੋਤਾਂ ਅਤੇ ਪੰਨਿਆਂ ਲਈ ਪ੍ਰੋਸੈਸਿੰਗ ਪ੍ਰਵਾਹ ਬਦਲ ਜਾਵੇਗਾ (ਇਹ ਕਾਰੋਬਾਰਾਂ ਅਤੇ ਨਿੱਜਤਾ-ਸਚੇਤ ਗਾਹਕਾਂ ਲਈ ਮਹੱਤਵਪੂਰਨ ਜਾਣਕਾਰੀ ਹੈ)

2.4 LSCWP ਵਿੱਚ ਆਮ ਫਸਾਂ

1. ਸਰਵਰ LiteSpeed ਨਹੀਂ ਚਲਾ ਰਿਹਾ, ਫਿਰ ਵੀ ਇਹ LSCWP ਨੂੰ ਇੱਕ ਪੂਰੀ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਵਾਲਾ ਕੈਸ਼ਿੰਗ ਪਲੱਗਇਨ ਮੰਨਦਾ ਹੈ।
   ਨਤੀਜਾ: ਕੈਸ਼ਿੰਗ ਉਮੀਦ ਅਨੁਸਾਰ ਕੰਮ ਨਹੀਂ ਕੀਤਾ ਅਤੇ ਇਸ ਨਾਲ ਸੰਰਚਨਾ ਦੀ ਜਟਿਲਤਾ ਵੀ ਵਧ ਗਈ। ਹੱਲ: ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਹੋਸਟ ਸਟੈਕ ਦੀ ਜਾਂਚ ਕਰੋ; ਜੇ ਇਹ ਨਹੀਂ ਹੈ ਲਾਈਟਸਪੀਡ... WP Rocket ਜਾਂ WP Super Cache ਬਾਰੇ ਸੋਚੋ।
2. ਬਹੁਤ ਜ਼ਿਆਦਾ ਫਰੰਟ-ਐਂਡ ਅਪਟੀਮਾਈਜ਼ੇਸ਼ਨਾਂ ਨੂੰ ਚਾਲੂ ਕਰਨ ਨਾਲ ਕਾਰਜਕੁਸ਼ਲਤਾ ਸੰਬੰਧੀ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਹੋਈਆਂ ਹਨ।
   ਪੰਨਾ ਅਨੁਕੂਲਨ (CSS/JS) ਅਕਸਰ ਕੈਸ਼ਿੰਗ ਨਾਲੋਂ ਵੱਧ ਅਨੁਕੂਲਤਾ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਕਰਦਾ ਹੈ। ਸਿਫਾਰਸ਼: ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਪੰਨਾ ਕੈਸ਼ਿੰਗ ਸੁਚਾਰੂ ਤਰੀਕੇ ਨਾਲ ਚੱਲ ਰਹੀ ਹੈ, ਫਿਰ ਇੱਕ-ਇੱਕ ਕਰਕੇ ਅਨੁਕੂਲਨ ਚਾਲੂ ਕਰੋ, ਅਤੇ ਰਿਗ੍ਰੈਸ਼ਨ ਟੈਸਟ ਚੈੱਕਲਿਸਟ (ਫਾਰਮ, ਮੈਨੂ, ਭੁਗਤਾਨ, ਟ੍ਰੈਕਿੰਗ, ਭਾਸ਼ਾ ਬਦਲਣ ਆਦਿ) ਤਿਆਰ ਕਰੋ।
3. ਡਾਇਨਾਮਿਕ ਪੰਨਿਆਂ ਲਈ ਬਾਹਰ-ਰੱਖਣ/ਸ਼ਾਰਡਿੰਗ ਰਣਨੀਤੀਆਂ ਦੀ ਘਾਟ
   ਆਮ ਸਮੱਸਿਆਵਾਂ: ਸ਼ਾਪਿੰਗ ਕਾਰਟ, ਚੈੱਕਆਊਟ ਪੰਨੇ ਅਤੇ ਖਾਤਾ ਪੰਨੇ ਕੈਸ਼ ਹੋ ਰਹੇ ਹਨ; ਜਾਂ ਭਾਸ਼ਾਵਾਂ ਜਾਂ ਮੁਦਰਾਵਾਂ ਵਿੱਚ ਗਲਤ ਤਬਦੀਲੀ। ਈ-ਕਾਮਰਸ ਸਾਈਟਾਂ ਨੂੰ ਇਸਨੂੰ ਲਾਂਚ ਤੋਂ ਪਹਿਲਾਂ ਦੀ ਜਾਂਚ ਵਜੋਂ ਲੈਣਾ ਚਾਹੀਦਾ ਹੈ (ਜਿਵੇਂ WooCommerce ਵੀ ਜ਼ੋਰ ਦਿੰਦਾ ਹੈ)।ਮਹੱਤਵਪੂਰਨ ਪੰਨਿਆਂ ਨੂੰ ਕੈਸ਼ ਨਾ ਕਰੋ）。

ਪਲੱਗਇਨ 3:WP ਸੁਪਰ ਕੈਸ਼(ਮੁਫ਼ਤ) — ਸਮੱਗਰੀ ਵੈੱਬਸਾਈਟਾਂ ਲਈ ਕਲਾਸਿਕ “ਘੱਟ-ਖਤਰੇ, ਵੱਧ-ਲਾਭ” ਰਣਨੀਤੀ

WP ਸੁਪਰ ਕੈਸ਼ ਇਹ ਇੰਨਾ ਲੰਮਾ ਸਮਾਂ ਲੋਕਪ੍ਰਿਯ ਕਿਉਂ ਰਿਹਾ ਹੈ? ਕਿਉਂਕਿ ਇਹ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਬਹੁਤ ਹੀ ਸਿੱਧੇ, “ਸਰਵਰ-ਅਨੁਕੂਲ” ਤਰੀਕੇ ਨਾਲ ਹੱਲ ਕਰਦਾ ਹੈ:
ਡਾਇਨਾਮਿਕ ਵਰਡਪ੍ਰੈੱਸ ਪੰਨਿਆਂ ਨੂੰ ਸਥਿਰ HTML ਫਾਈਲਾਂ ਵਿੱਚ ਬਦਲੋ...ਜਿਸ ਤੋਂ ਬਾਅਦ ਇਹ HTML ਫਾਈਲਾਂ ਸਿੱਧੇ ਵੈੱਬ ਸਰਵਰ ਦੁਆਰਾ ਸਰਵ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਇਸ ਤਰ੍ਹਾਂ ਮਹਿੰਗੀ PHP ਪ੍ਰੋਸੈਸਿੰਗ ਨੂੰ ਬਾਈਪਾਸ ਕਰਕੇ।

ਪਲੱਗਇਨ ਪੰਨੇ “ਤੇ ਇਹ ਵੀ ਦੱਸਿਆ ਗਿਆ ਹੈ ਕਿ ਬਿਨਾਂ ਪ੍ਰਮਾਣਿਤ ਕੀਤੇ ਵੱਡੀ ਗਿਣਤੀ ਦੇ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਸਥਿਰ HTML ਸਰਵ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਜਿਸਨੂੰ ਇੱਕ ਬਹੁਤ ਹੀ ਸਪਸ਼ਟ ਉਦਾਹਰਨ ਨਾਲ ਦਰਸਾਇਆ ਗਿਆ ਹੈ: ”99% ਵਿਜ਼ਿਟਰਾਂ ਨੂੰ ਸਥਿਰ HTML ਫਾਈਲਾਂ ਸਰਵ ਕੀਤੀਆਂ ਜਾਣਗੀਆਂ", ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇੱਕ ਹੀ ਕੈਸ਼ ਕੀਤੀ ਫਾਈਲ ਹਜ਼ਾਰਾਂ ਵਾਰੀ ਸਰਵ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ।

3.1 WP ਸੁਪਰ ਕੈਸ਼ ਕਿਸ ਲਈ ਢੁਕਵਾਂ ਹੈ?

ਬਹੁਤ ਸਿਫਾਰਸ਼ ਕੀਤੀ ਜਾਂਦੀ ਹੈ:

• ਬਲੌਗ, ਸਮੱਗਰੀ ਵੈੱਬਸਾਈਟਾਂ, ਦਸਤਾਵੇਜ਼ੀ ਵੈੱਬਸਾਈਟਾਂ, ਕਾਰਪੋਰੇਟ ਵੈੱਬਸਾਈਟਾਂ, ਲੈਂਡਿੰਗ ਪੇਜ
• ਵਿਜ਼ਿਟਰ ਮੁੱਖ ਤੌਰ 'ਤੇ ਉਹ ਵਰਤੋਂਕਾਰ ਹੁੰਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਨੇ ਲੌਗ ਇਨ ਨਹੀਂ ਕੀਤਾ ਹੁੰਦਾ।
• ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ: ਮੁਫ਼ਤ, ਸਥਿਰ ਅਤੇ ਘੱਟ ਰੱਖ-ਰਖਾਅ ਦੇ ਖਰਚੇ

ਸਾਵਧਾਨੀ ਨਾਲ ਵਰਤੋਂ / ਇੱਕ ਵਧੇਰੇ ਮਜ਼ਬੂਤ ਰਣਨੀਤੀ ਦੀ ਲੋੜ ਹੈ:

• ਬਹੁਤ ਹੀ ਗਤੀਸ਼ੀਲ ਵੈੱਬਸਾਈਟਾਂ: ਵੱਡੀ ਮਾਤਰਾ ਵਿੱਚ ਵਿਅਕਤੀਗਤ ਸਮੱਗਰੀ ਵਾਲੀਆਂ ਵੈੱਬਸਾਈਟਾਂ ਅਤੇ ਉਪਭੋਗਤਾ ਦੀ ਸਥਿਤੀ ਅਨੁਸਾਰ ਬਦਲਣ ਵਾਲੇ ਪੰਨੇ।
• ਵੱਡੇ ਈ-ਕਾਮਰਸ ਪਲੇਟਫਾਰਮ: ਇਹ ਸਵੀਕਾਰਯੋਗ ਹੈ, ਪਰ ਇਹ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਮੁੱਖ ਪੰਨੇ ਕੈਸ਼ ਨਾ ਕੀਤੇ ਜਾਣ ਅਤੇ ਇਹ ਤੁਹਾਡੀ ਟੈਸਟਿੰਗ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤਾ ਗਿਆ ਹੋਵੇ।

3.2 ਇਸ ਦੀਆਂ ਤਿੰਨ ਕੈਸ਼ਿੰਗ ਵਿਧੀਆਂ:

WP Super Cache ਪਲੱਗਇਨ ਦੇ ਵੇਰਵੇ ਵਿੱਚ ਗਤੀ ਦੇ ਕ੍ਰਮ ਵਿੱਚ ਤਿੰਨ ਕੈਸ਼ਿੰਗ ਵਿਧੀਆਂ ਦਰਸਾਈਆਂ ਗਈਆਂ ਹਨ ਅਤੇ ਉਹਨਾਂ ਵਿਚਕਾਰ ਦੇ ਫਰਕ ਨੂੰ ਸਮਝਾਇਆ ਗਿਆ ਹੈ:

• ਮੋਡ_ਰਿਰਾਇਟ (ਮਾਹਰ): ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਾ, ਜੋ PHP ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬਾਈਪਾਸ ਕਰਦਾ ਹੈ, ਪਰ .htaccess ਫਾਈਲ ਵਿੱਚ ਸੋਧ ਕਰਨ ਦੀ ਲੋੜ ਹੈ; ਜੇ ਗਲਤ ਤਰੀਕੇ ਨਾਲ ਸੰਰਚਿਤ ਕੀਤਾ ਗਿਆ, ਤਾਂ ਸਾਈਟ ਦੇ ਉਪਲਬਧ ਨਾ ਹੋਣ ਦਾ ਵੱਧ ਖਤਰਾ ਹੈ।
• ਸਧਾਰਨ (ਸਿਫਾਰਸ਼ੀ ਤਰੀਕਾ)PHP ਸਥਿਰ ਫਾਈਲਾਂ ਲਈ ਇੱਕ “ਸੁਪਰ ਕੈਸ਼” ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ, ਜੋ mod_rewrite ਦੇ ਸਮਾਨ ਗਤੀ ਦਿੰਦਾ ਹੈ ਪਰ ਇਸਦੀ ਸੰਰਚਨਾ ਸਧਾਰਣ ਹੈ।
• WP-Cache ਕੈਸ਼ਿੰਗ: ਵਧੇਰੇ ਲਚਕੀਲਾ, ਜਾਣੇ-ਪਛਾਣੇ ਉਪਭੋਗਤਾਵਾਂ, ਪੈਰਾਮੀਟਰਾਂ ਵਾਲੇ URL, ਫੀਡਾਂ, ਆਦਿ ਲਈ ਢੁਕਵਾਂ, ਪਰ ਹੌਲੀ

ਸਿਫਾਰਸ਼ੀ ਵਿਕਲਪ:

• ਸ਼ੁਰੂਆਤੀ/ਸਥਿਰਤਾ ਦੀ ਤਲਾਸ਼ ਕਰਨ ਵਾਲੇ: ਸਿਫ਼ਾਰਸ਼ ਕੀਤੀ ਵਿਧੀ (ਸਧਾਰਣ) ਵਰਤੋਂ
• ਜੇ ਤੁਸੀਂ ਸਰਵਰ ਦੇ ਨਿਯਮਾਂ ਨਾਲ ਬਹੁਤ ਵਾਕਫ਼ ਹੋ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਮੁੜ ਲਿਖਣ ਦਾ ਖਤਰਾ ਉਠਾਉਣ ਲਈ ਤਿਆਰ ਹੋ, ਤਾਂ ਮਾਹਿਰ ਮੋਡ 'ਤੇ ਵਿਚਾਰ ਕਰੋ।
• ਤੁਹਾਨੂੰ “ਜਾਣਿਆ-ਪਛਾਣਿਆ ਉਪਭੋਗਤਾ/ਪੈਰਾਮੀਟਰਾਂ” ਦੀ ਵਧੇਰੇ ਲਚਕੀਲਾ ਸੰਭਾਲ ਦੀ ਲੋੜ ਹੈ: WP-Cache ਦੀ ਭੂਮਿਕਾ ਨੂੰ ਸਮਝਣਾ

3.3 WP ਸੁਪਰ ਕੈਸ਼ ਦੀਆਂ ਤਾਕਤਾਂ ਅਤੇ ਕਮਜ਼ੋਰੀਆਂ

ਫਾਇਦੇ:

1. CDN ਨਾਲ ਵਰਤੋਂ ਲਈ ਆਦਰਸ਼
   ਕਿਉਂਕਿ ਇਹ ਅਸਲ ਵਿੱਚ “ਸਟੈਟਿਕ HTML ਤਿਆਰ ਕਰਨ” ਨਾਲ ਸੰਬੰਧਿਤ ਹੈ, ਇਹ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ CDN/ਐਜ ਕੈਸ਼ਿੰਗ ਪਹੁੰਚ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ।
2. ਮੂਲ ਸਰਵਰ CPU ਅਤੇ ਡੇਟਾਬੇਸ 'ਤੇ ਲੋਡ ਵਿੱਚ ਸੁਧਾਰ ਬਹੁਤ ਹੀ ਨਜ਼ਰ ਆਉਂਦਾ ਹੈ।
   ਜਦੋਂ ਵੈਬਸਾਈਟ ਟ੍ਰੈਫਿਕ ਵਿਆਪਕ ਤੌਰ “ਤੇ ਫੈਲਿਆ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਖੋਜ ਇੰਜਣ ਅਤੇ ਸੋਸ਼ਲ ਮੀਡੀਆ ਦੇ ਕਰਾਲਰ ਵੀ ਦੁਨੀਆ ਭਰ ਤੋਂ ਆ ਸਕਦੇ ਹਨ। ਸਟੈਟਿਕਾਈਜ਼ੇਸ਼ਨ ”ਡੁਪਲੀਕੇਟ ਰੈਂਡਰਿੰਗ' ਦਾ ਮੁਕਾਬਲਾ ਕਰਨ ਵਿੱਚ ਬਹੁਤ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੈ।

ਕਮਜ਼ੋਰੀਆਂ:

1. ਇਹ ਇੱਕ “ਸਭ-ਇੱਕ-ਵਿੱਚ ਪ੍ਰਦਰਸ਼ਨ ਸੁਧਾਰ ਪੈਕੇਜ” ਨਹੀਂ ਹੈ।”
   ਇਸਦੀ ਮੁੱਖ ਤਾਕਤ ਪੇਜ ਕੈਸ਼ਿੰਗ ਵਿੱਚ ਹੈ; WP Rocket ਵਾਂਗ, ਇਹ CSS ਅਤੇ JavaScript ਲਈ ਵਿਸਤ੍ਰਿਤ ਅਨੁਕੂਲਨ ਦਾ ਇੱਕ ਸੰਪੂਰਨ ਪੈਕੇਜ ਨਹੀਂ ਦਿੰਦਾ। ਤੁਹਾਨੂੰ ਹੋਰ ਅਨੁਕੂਲਨ “Image Optimisation” ਅਤੇ “Front-end Optimisation” ਪੰਨਿਆਂ ਰਾਹੀਂ ਕਰਨਾ ਪੈ ਸਕਦਾ ਹੈ (ਜਾਂ ਹੋਰ ਪਲੱਗਇਨ ਜਾਂ ਥੀਮ-ਪੱਧਰੀ ਅਨੁਕੂਲਨ ਵਰਤੋ)।
2. ਸਾਨੂੰ “ਡਾਇਨਾਮਿਕ ਪਰਸਨਲਾਈਜ਼ੇਸ਼ਨ” ਬਾਰੇ ਵਧੇਰੇ ਸਾਵਧਾਨੀ ਵਰਤਣੀ ਚਾਹੀਦੀ ਹੈ।
   ਉਦਾਹਰਨ ਵਜੋਂ, ਖੇਤਰ ਦੇ ਆਧਾਰ 'ਤੇ ਵੱਖ-ਵੱਖ ਸਮੱਗਰੀ ਦਿਖਾਉਣਾ, ਜਾਂ ਉਪਭੋਗਤਾ ਦੀ ਸਥਿਤੀ ਦੇ ਆਧਾਰ 'ਤੇ ਵੱਖ-ਵੱਖ ਕੀਮਤਾਂ, ਭਾਸ਼ਾਵਾਂ ਜਾਂ ਸਿਫਾਰਸ਼ਾਂ ਦਿਖਾਉਣਾ। ਅਜਿਹੇ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਤੁਹਾਨੂੰ ਬਾਹਰ ਰੱਖਣ ਦੇ ਨਿਯਮ ਬਣਾਉਣੇ ਪੈਣਗੇ ਜਾਂ ਵਧੇਰੇ ਉਚਿਤ ਸ਼ਾਰਡਡ ਕੈਸ਼ਿੰਗ ਹੱਲ ਲਾਗੂ ਕਰਨਾ ਪਵੇਗਾ।

3.4 WooCommerce ਅਨੁਕੂਲਤਾ: ਇਹ ਕਿਉਂ ਵਧੇਰੇ “ਸੁਰੱਖਿਅਤ” ਹੈ”

ਆਧਿਕਾਰਕ WooCommerce ਦਸਤਾਵੇਜ਼ਇਹ ਗੱਲ ਧਿਆਨਯੋਗ ਹੈ ਕਿ WooCommerce ਮੂਲ ਰੂਪ ਵਿੱਚ WP Super Cache ਨਾਲ ਅਨੁਕੂਲ ਹੈ, ਅਤੇ WooCommerce WP Super Cache ਨੂੰ ਸੰਕੇਤ ਭੇਜਦਾ ਹੈ ਤਾਂ ਜੋ Cart, Checkout ਅਤੇ My Account ਪੰਨੇ ਡਿਫੌਲਟ ਤੌਰ 'ਤੇ ਕੈਸ਼ ਨਾ ਕੀਤੇ ਜਾਣ।

• ਭਾਵੇਂ ਤੁਸੀਂ ਨਵੇਂ ਹੋ, WP Super Cache ਅਤੇ WooCommerce ਦੇ ਸੁਮੇਲ ਨਾਲ ਇਹ ਸੰਭਾਵਨਾ ਘੱਟ ਹੋ ਜਾਂਦੀ ਹੈ ਕਿ ਤੁਸੀਂ “ਕ੍ਰਿਟੀਕਲ ਪੰਨਿਆਂ ਦੇ ਕੈਸ਼ ਹੋਣ” ਦੀ ਸਮੱਸਿਆ ਦਾ ਸਾਹਮਣਾ ਕਰੋ।
• ਹਾਲਾਂਕਿ, ਅਸੀਂ ਫਿਰ ਵੀ ਲਾਂਚ ਤੋਂ ਪਹਿਲਾਂ ਰਿਗਰੈਸ਼ਨ ਟੈਸਟਿੰਗ ਕਰਨ ਦੀ ਸਿਫਾਰਸ਼ ਕਰਦੇ ਹਾਂ (ਜਿਸ ਵਿੱਚ ਭੁਗਤਾਨ, ਵਾਊਚਰ, ਡਿਲੀਵਰੀ ਚਾਰਜ, ਟੈਕਸ ਦਰਾਂ, ਕਈ ਮੁਦਰਾਵਾਂ, ਆਦਿ ਸ਼ਾਮਲ ਹਨ)।

ਪਲੱਗਇਨ 4:ਡਬਲਯੂ3 ਟੋਟਲ ਕੈਸ਼ (ਡਬਲਯੂ3ਟੀਸੀ)— ਸਭ ਤੋਂ ਵਿਆਪਕ “ਪ੍ਰਦਰਸ਼ਨ ਢਾਂਚਾ”, ਇੰਜੀਨੀਅਰਿੰਗ ਟੀਮਾਂ ਲਈ ਆਦਰਸ਼

ਡਬਲਯੂ3 ਟੋਟਲ ਕੈਸ਼ WordPress.org “ਤੇ, ਇਸਨੂੰ ਇੱਕ ”ਸਿੰਗਲ ਕੈਸ਼ਿੰਗ ਪਲੱਗਇਨ“ ਵਜੋਂ ਨਹੀਂ, ਸਗੋਂ ਇੱਕ ”ਵੈੱਬਸਾਈਟ ਪ੍ਰਦਰਸ਼ਨ ਅਨੁਕੂਲਨ ਫਰੇਮਵਰਕ' ਵਜੋਂ ਪੇਸ਼ ਕੀਤਾ ਗਿਆ ਹੈ: ਇਹ CDN ਅਤੇ ਸਭ ਤੋਂ ਵਧੀਆ ਅਭਿਆਸਾਂ ਨਾਲ ਏਕੀਕਰਣ ਰਾਹੀਂ SEO, ਕੋਰ ਵੈੱਬ ਵਾਈਟਲਜ਼ ਅਤੇ ਸਮੁੱਚੇ ਉਪਭੋਗਤਾ ਅਨੁਭਵ ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਣ 'ਤੇ ਜ਼ੋਰ ਦਿੰਦਾ ਹੈ।

ਪਲੱਗਇਨ ਦੇ ਵੇਰਵੇ ਵਿੱਚ ਕਈ ਤਰ੍ਹਾਂ ਦੀਆਂ ਸਮਰੱਥਾਵਾਂ ਦਰਸਾਈਆਂ ਗਈਆਂ ਹਨ: ਪੇਜ/ ਪੰਨਾ/ਪੋਸਟ ਕੈਸ਼ਿੰਗ, CSS/JS ਕੈਸ਼ਿੰਗ, ਫੀਡ ਕੈਸ਼ਿੰਗ, ਖੋਜ ਨਤੀਜਾ ਕੈਸ਼ਿੰਗ, ਡੇਟਾਬੇਸ ਆਬਜੈਕਟ ਕੈਸ਼ਿੰਗ, ਆਬਜੈਕਟ ਕੈਸ਼ਿੰਗ, ਫ੍ਰੈਗਮੈਂਟ ਕੈਸ਼ਿੰਗ, ਅਤੇ Redis, Memcached ਅਤੇ APC ਵਰਗੀਆਂ ਵੱਖ-ਵੱਖ ਕੈਸ਼ਿੰਗ ਵਿਧੀਆਂ ਲਈ ਸਹਾਇਤਾ। ਇਸ ਵਿੱਚ ਯੂਜ਼ਰ-ਏਜੰਟ ਅਤੇ ਰੈਫਰਰ ਅਨੁਸਾਰ ਵੰਡੀ ਗਈ ਮੋਬਾਈਲ ਕੈਸ਼ਿੰਗ, AMP ਸਹਾਇਤਾ, ਅਤੇ ਰਿਵਰਸ ਪ੍ਰਾਕਸੀ (Nginx/Varnish) ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਵੀ ਸ਼ਾਮਿਲ ਹੈ।

4.1 W3 Total Cache ਕਿਸ ਲਈ ਢੁਕਵਾਂ ਹੈ?

ਇਸ ਲਈ ਆਦਰਸ਼:

• ਤੁਹਾਡੇ ਕੋਲ ਵਿਕਾਸ ਅਤੇ ਓਪਰੇਸ਼ਨ ਦੇ ਹੁਨਰ ਹਨ ਅਤੇ ਤੁਸੀਂ “ਕਦਮ-ਦਰ-ਕਦਮ ਤੈਨਾਤੀ, ਲੋਡ ਟੈਸਟਿੰਗ ਅਤੇ ਰਿਗ੍ਰੈਸ਼ਨ ਟੈਸਟਿੰਗ” ਕਰਨ ਲਈ ਤਿਆਰ ਹੋ।”
• ਤੁਹਾਡੀ ਵੈਬਸਾਈਟ ਜਟਿਲ ਹੈ: ਇਸ ਵਿੱਚ ਕਈ ਭਾਸ਼ਾਵਾਂ, ਥੀਮ ਬਦਲਣ ਦੀ ਸਹੂਲਤ, ਮੋਬਾਈਲ-ਖਾਸ ਅਨੁਕੂਲਨ ਅਤੇ ਇੱਕ ਜਟਿਲ ਸਮੱਗਰੀ ਸੰਰਚਨਾ ਸ਼ਾਮਲ ਹੈ।
• ਤੁਸੀਂ ਸਿਰਫ਼ ਪੇਜ ਕੈਸ਼ਿੰਗ ਲਾਗੂ ਕਰਨਾ ਹੀ ਨਹੀਂ ਚਾਹੁੰਦੇ, ਸਗੋਂ ਸਿਸਟਮ ਵਿੱਚ ਔਬਜੈਕਟ ਕੈਸ਼ਿੰਗ ਅਤੇ ਫ੍ਰੈਗਮੈਂਟ ਕੈਸ਼ਿੰਗ ਨੂੰ ਵੀ ਸ਼ਾਮਲ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ (ਖਾਸ ਕਰਕੇ ਡਾਇਨਾਮਿਕ ਵੈੱਬਸਾਈਟਾਂ ਲਈ)

ਇਸ ਲਈ ਢੁਕਵਾਂ ਨਹੀਂ:

• ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਇਹ ਬਾਕਸ ਤੋਂ ਬਾਹਰ ਹੀ ਤੇਜ਼ ਹੋਵੇ ਅਤੇ ਤੁਹਾਨੂੰ ਕੈਸ਼ ਟੀਅਰਿੰਗ ਨੂੰ ਸਮਝਣ ਦੀ ਲੋੜ ਨਾ ਪਵੇ।
• ਤੁਹਾਡੇ ਕੋਲ ਕੋਈ ਟੈਸਟਿੰਗ ਪ੍ਰਕਿਰਿਆ ਨਹੀਂ ਹੈ, ਫਿਰ ਵੀ ਤੁਸੀਂ ਇੱਕੋ ਸਮੇਂ ਉੱਚ-ਖਤਰੇ ਵਾਲੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਜਿਵੇਂ ਕਿ ਕੰਪ੍ਰੈਸ਼ਨ ਅਤੇ ਡਿਲੇਡ ਸਕ੍ਰਿਪਟਾਂ ਨੂੰ ਚਾਲੂ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ।

4.2 ਇਸਨੂੰ “ਸ਼ਕਤੀਸ਼ਾਲੀ ਪਰ ਜਟਿਲ” ਕਿਉਂ ਦੱਸਿਆ ਜਾਂਦਾ ਹੈ? ਵੈੱਬਸਾਈਟਾਂ “ਨਿਯੰਤਰਣਯੋਗਤਾ” ਨੂੰ ਤਰਜੀਹ ਦਿੰਦੀਆਂ ਹਨ।”

W3TC ਦੀ ਕੀਮਤ ਇਸ ਗੱਲ ਵਿੱਚ ਨਹੀਂ ਕਿ “ਇਹ ਜ਼ਰੂਰੀ ਤੌਰ ”ਤੇ ਦੂਜਿਆਂ ਨਾਲੋਂ ਤੇਜ਼ ਹੈ', ਸਗੋਂ ਇਸ ਗੱਲ ਵਿੱਚ ਹੈ ਕਿ ਇਹ ਤੁਹਾਨੂੰ ਕਾਫ਼ੀ ਨਿਯੰਤਰਣ ਵਿਕਲਪ ਦਿੰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਤੁਸੀਂ ਆਪਣੀ ਪ੍ਰਦਰਸ਼ਨ ਰਣਨੀਤੀ ਨੂੰ ਇੱਕ ਇੰਜੀਨੀਅਰ ਕੀਤੀ ਪ੍ਰਣਾਲੀ ਵਿੱਚ ਬਦਲ ਸਕਦੇ ਹੋ:

• ਪੰਨਾ ਕੈਸ਼: ਮੈਮੋਰੀ, ਡਿਸਕ ਜਾਂ 1 ਟੀਬੀ ਜਾਂ 219 ਟੀਬੀ ਵਿੱਚ ਸਟੋਰ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
• ਡੇਟਾਬੇਸ ਆਬਜੈਕਟ ਕੈਸ਼ਿੰਗ, ਆਬਜੈਕਟ ਕੈਸ਼ਿੰਗ: Redis, Memcached ਆਦਿ ਵਰਤੇ ਜਾ ਸਕਦੇ ਹਨ।
• ਫ੍ਰੈਗਮੈਂਟ ਕੈਸ਼ਿੰਗ: ਖਾਸ ਤੌਰ “ਤੇ ”ਅਰਧ-ਗਤੀਸ਼ੀਲ ਪੰਨਿਆਂ' ਲਈ ਲਾਭਦਾਇਕ
• ਮੋਬਾਈਲ ਸਹਾਇਤਾ: ਰੈਫਰਰ ਜਾਂ ਯੂਜ਼ਰ ਏਜੰਟ ਗਰੁੱਪ ਅਨੁਸਾਰ ਪੰਨਿਆਂ ਨੂੰ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਕੈਸ਼ ਕਰੋ
• CDN ਪ੍ਰਬੰਧਨ: ਮੀਡੀਆ ਲਾਇਬ੍ਰੇਰੀਆਂ, ਥੀਮ ਫਾਈਲਾਂ ਆਦਿ ਦਾ ਪਾਰਦਰਸ਼ੀ ਪ੍ਰਬੰਧਨ। CDN ਪ੍ਰਬੰਧਨ

ਇਹ ਸਮਰੱਥਾਵਾਂ ਵੈੱਬਸਾਈਟਾਂ ਲਈ ਖਾਸ ਤੌਰ 'ਤੇ ਕੀਮਤੀ ਹਨ, ਕਿਉਂਕਿ ਵਿਸ਼ਵ ਭਰ ਦੀ ਟ੍ਰੈਫਿਕ ਅਕਸਰ ਇਹਨਾਂ ਦਾ ਸਾਹਮਣਾ ਕਰਦੀ ਹੈ:

• ਵੱਖ-ਵੱਖ ਡਿਵਾਈਸਾਂ, ਖੇਤਰਾਂ ਅਤੇ ਭਾਸ਼ਾਵਾਂ ਵਿੱਚ ਇੱਕੋ ਪੰਨੇ ਦੇ ਵੱਖ-ਵੱਖ ਰੂਪ
• ਕੁਝ ਸਮੱਗਰੀ ਨੂੰ ਕੈਸ਼ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਜਦਕਿ ਹੋਰ ਸਮੱਗਰੀ ਨੂੰ ਅਸਲ ਸਮੇਂ ਵਿੱਚ ਅੱਪਡੇਟ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ (ਜਿਵੇਂ ਕਿ ਕੀਮਤਾਂ, ਸਟਾਕ ਪੱਧਰ, ਉਪਭੋਗਤਾ ਦੀ ਸਥਿਤੀ)

4.3 W3TC ਦਾ “ਸਿਫ਼ਾਰਸ਼ੀ ਸਮਰੱਥਾ ਆਦੇਸ਼”

ਸਿਫਾਰਸ਼ੀ ਕ੍ਰਮ:

1. ਫਿਲਹਾਲ, ਸਿਰਫ਼ ਪੇਜ ਕੈਸ਼ਿੰਗ ਨੂੰ ਚਾਲੂ ਕਰੋ।
   ਪੁਸ਼ਟੀ ਕਰੋ: TTFB ਘਟਿਆ ਹੈ ਜਾਂ ਨਹੀਂ, ਸਮੱਗਰੀ ਇਕਸਾਰ ਹੈ ਜਾਂ ਨਹੀਂ, ਅਤੇ ਲੌਗਇਨ ਸਥਿਤੀ, ਬਹੁਭਾਸ਼ੀ ਕਾਰਜਕੁਸ਼ਲਤਾ ਅਤੇ ਮੁੱਖ ਈ-ਕਾਮਰਸ ਵਰਕਫਲੋਜ਼ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਕੰਮ ਕਰ ਰਹੇ ਹਨ ਜਾਂ ਨਹੀਂ।
2. ਬ੍ਰਾਊਜ਼ਰ ਕੈਸ਼ ਨੂੰ ਦੁਬਾਰਾ ਚਾਲੂ ਕਰੋ
   ਉਦੇਸ਼: ਪੰਨਿਆਂ ਦੇ ਰੀਲੋਡ ਅਤੇ ਸਥਿਰ ਸਰੋਤਾਂ ਦੀ ਲੋਡਿੰਗ ਨੂੰ ਤੇਜ਼ ਕਰਨਾ, ਅਤੇ ਮਹਾਂਦੀਪਾਂ ਵਿੱਚ ਫਾਲਤੂ ਡਾਊਨਲੋਡ ਘਟਾਉਣਾ।
3. ਆਬਜੈਕਟ ਕੈਸ਼ / ਡੇਟਾਬੇਸ ਆਬਜੈਕਟ ਕੈਸ਼ ਦਾ ਮੁੜ-ਮੁਲਾਂਕਣ ਕਰੋ
   ਇਹ ਲਈ ਢੁਕਵਾਂ ਹੈ: ਗਤੀਸ਼ੀਲ ਵੈੱਬਸਾਈਟਾਂ (WooCommerce, ਮੈਂਬਰਸ਼ਿਪ ਸਿਸਟਮ, ਜਟਿਲ ਕੁਐਰੀਆਂ).
   ਲਾਗੂ ਨਹੀਂ: ਸ਼ੁੱਧ ਸਮੱਗਰੀ ਵਾਲੀਆਂ ਸਾਈਟਾਂ ਸੀਮਤ ਆਮਦਨ ਪੈਦਾ ਕਰ ਸਕਦੀਆਂ ਹਨ ਅਤੇ ਸਰੋਤਾਂ ਦੀ ਖਪਤ ਵੀ ਵਧਾ ਸਕਦੀਆਂ ਹਨ।
4. ਅਖੀਰ ਵਿੱਚ, ਕੰਪ੍ਰੈਸ਼ਨ, ਸਕ੍ਰਿਪਟ ਡਿਫਰਲ ਅਤੇ ਫਰੰਟ-ਐਂਡ ਅਪਟੀਮਾਈਜ਼ੇਸ਼ਨ ਸੰਭਾਲੋ।
   ਕਿਉਂਕਿ ਇਹ ਪਰਤ ਕਾਰਜਕੁਸ਼ਲਤਾ ਸੰਬੰਧੀ ਸਮੱਸਿਆਵਾਂ ਲਈ ਸਭ ਤੋਂ ਵੱਧ ਸੰਵੇਦਨਸ਼ੀਲ ਹੈ, ਇਸ ਲਈ ਇੱਕ ਰਿਗਰੈਸ਼ਨ ਟੈਸਟ ਚੈੱਕਲਿਸਟ ਤਿਆਰ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ (ਜਿਸ ਵਿੱਚ ਭੁਗਤਾਨ, ਫਾਰਮ, ਟਰੈਕਿੰਗ, ਪੌਪ-ਅੱਪ, ਮੀਨੂ, ਭਾਸ਼ਾ ਬਦਲਣ ਆਦਿ ਸ਼ਾਮਲ ਹੋਣ)।

“ਕੈਸ਼ ਪਲੱਗਇਨ ਸੰਰਚਨਾ” ਬਾਰੇ ਵੂ-ਕਾਮਰਸ ਯਾਦ-ਪੱਤਰ: ਮਹੱਤਵਪੂਰਨ ਪੰਨਿਆਂ ਨੂੰ ਕੈਸ਼ ਨਾ ਕਰੋ, ਅਤੇ ਇਹ ਸਿਫਾਰਸ਼ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਕਿ ਤੁਸੀਂ JavaScript ਫਾਈਲਾਂ ਨੂੰ ਛੋਟਾ ਕਰਨ ਤੋਂ ਬਚੋ।

ਚਾਰ ਪਲੱਗਇਨਾਂ ਦੀ ਤੁਲਨਾ ਮੈਟ੍ਰਿਕਸ

ਕਿਰਪਾ ਕਰਕੇ ਧਿਆਨ ਦਿਓ: ਇਹ “ਕੌਣ ਵੱਧ ਤਾਕਤਵਰ ਹੈ” ਬਾਰੇ ਨਹੀਂ, ਸਗੋਂ “ਤੁਹਾਡੀ ਸਥਿਤੀ ਲਈ ਕੌਣ ਵਧੀਆ ਹੈ” ਬਾਰੇ ਹੈ।

ਆਯਾਮ	ਡਬਲਯੂਪੀ ਰਾਕੇਟ	ਲਾਈਟਸਪੀਡ ਕੈਸ਼	WP ਸੁਪਰ ਕੈਸ਼	ਡਬਲਯੂ3 ਟੋਟਲ ਕੈਸ਼
ਮੁੱਖ ਸਥਿਤੀ	ਸਭ-ਇੱਕ-ਵਿੱਚ ਹੱਲ (ਕੈਸ਼ਿੰਗ + ਅਨੁਕੂਲਨ)	ਸਰਵਰ-ਪੱਧਰੀ ਕੈਸ਼ਿੰਗ (LSCache ਦੀ ਵਰਤੋਂ ਕਰਕੇ)	ਸਥਿਰ HTML ਕੈਸ਼ਿੰਗ	ਕਾਰਗੁਜ਼ਾਰੀ ਢਾਂਚਾ (ਬਹੁ-ਪੱਧਰੀ ਕੈਸ਼ਿੰਗ + CDN)
ਮੇਜ਼ਬਾਨ ਨਿਰਭਰਤਾ	ਘੱਟ (ਸਰਵ-ਵਿਆਪਕ)	ਉੱਚ (ਕੋਰ ਕੈਸ਼ਿੰਗ ਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ LiteSpeed/OpenLiteSpeed ਦੀ ਲੋੜ ਹੈ)	ਘੱਟ (ਸਰਵ-ਵਿਆਪਕ)	ਮੱਧਮ (ਸਾਰਵਜਨਿਕ, ਪਰ ਵਾਤਾਵਰਣ/ਕੌਨਫਿਗਰੇਸ਼ਨ ਸਮਰੱਥਾਵਾਂ 'ਤੇ ਵਧੇਰੇ ਨਿਰਭਰ)
ਸਿੱਖਣ ਦੀ ਲਾਗਤ	ਘੱਟ ਤੋਂ ਦਰਮਿਆਨਾ	ਦਰਮਿਆਨਾ	低	ਉੱਚ
ਸਮੱਗਰੀ ਸਾਈਟ ਸਿਫ਼ਾਰਸ਼ ਸਕੋਰ	ਬਹੁਤ ਉੱਚ	ਬਹੁਤ ਉੱਚਾ (ਸ਼ਰਤਾਂ ਪੂਰੀਆਂ ਹੋਣ 'ਤੇ)	ਬਹੁਤ ਉੱਚ	ਦਰਮਿਆਨਾ ਤੋਂ ਉੱਚਾ (ਟੀਮ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ)
ਈ-ਕਾਮਰਸ/ਮੈਂਬਰਸ਼ਿਪ ਸਾਈਟ	ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਪਰ ਸਾਵਧਾਨੀ ਵਰਤੋ (WooCommerce ਦੀਆਂ ਮੁੱਖ ਪੰਨੀਆਂ ਕੈਸ਼ ਨਹੀਂ ਹੁੰਦੀਆਂ)	ਉਪਲਬਧ ਹੈ, ਪਰ ਨਿਯਮਾਂ/ਸ਼ਾਰਡਿੰਗ ਰਣਨੀਤੀਆਂ ਦੀ ਲੋੜ ਹੈ।	ਉਪਲਬਧ ਹੈ, ਅਤੇ WooCommerce ਦੱਸਦਾ ਹੈ ਕਿ ਇਹ ਮੂਲ ਰੂਪ ਵਿੱਚ ਅਨੁਕੂਲ ਹੈ ਅਤੇ ਮੁੱਖ ਪੰਨਿਆਂ ਨੂੰ ਡਿਫੌਲਟ ਤੌਰ 'ਤੇ ਕੈਸ਼ ਨਹੀਂ ਕਰਦਾ।	ਉਪਲਬਧ; ਇੰਜੀਨੀਅਰਿੰਗ ਦੀਆਂ ਵਰਤੋਂ ਲਈ ਢੁਕਵਾਂ
ਬਜਟ	ਭੁਗਤਾਨ ਕਰੋ	ਮੁਫ਼ਤ	ਮੁਫ਼ਤ	ਮੁਫ਼ਤ + ਭੁਗਤਾਨੀ ਸੰਸਕਰਣ

“ਕੈਸ਼ ਘਟਨਾਵਾਂ” ਅਤੇ ਰੋਕਥਾਮ ਲਈ ਇੱਕ ਜਾਂਚ-ਸੂਚੀ

1. ਕੈਸ਼ਿੰਗ ਕਾਰਨ “ਗਲਤ ਸਮੱਗਰੀ” ਦੇ ਤਿੰਨ ਮੁੱਖ ਕਾਰਨ

A. “ਸਟੇਟ ਵਾਲੇ” ਪੰਨਿਆਂ ਨੂੰ “ਸਟੇਟ-ਰਹਿਤ ਸਥਿਰ ਪੰਨਿਆਂ” ਵਜੋਂ ਟ੍ਰੀਟ ਕਰਨਾ”

ਉਦਾਹਰਨ: ਖਾਤਾ ਪੰਨਾ, ਖਰੀਦਦਾਰੀ ਟੋਕਰੀ ਅਤੇ ਚੈੱਕਆਊਟ ਪੰਨਾ ਕੈਸ਼ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। WooCommerce ਅਧਿਕਾਰੀਆਂ ਨੇ ਵਾਰ-ਵਾਰ ਜ਼ੋਰ ਦਿੱਤਾ ਹੈ। ਸ਼ਾਪਿੰਗ ਕਾਰਟ / ਚੈੱਕਆਊਟ / ਖਾਤਾ ਪੰਨੇ ਕੈਸ਼ ਨਹੀਂ ਕੀਤੇ ਜਾਣੇ ਚਾਹੀਦੇ।

ਬੀ. ਕਈ ਭਾਸ਼ਾਵਾਂ, ਮੁਦਰਾਵਾਂ ਅਤੇ ਖੇਤਰੀ ਰੂਪਾਂ ਲਈ ਕੈਸ਼ਿੰਗ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਵੱਖਰਾ ਨਹੀਂ ਕੀਤਾ ਗਿਆ।

ਜੇ ਤੁਹਾਡੀ ਸਾਈਟ cookie, ਕਵੈਰੀ ਪੈਰਾਮੀਟਰਾਂ ਜਾਂ ਭੂਗੋਲਿਕ ਸਥਿਤੀ ਦੇ ਆਧਾਰ “ਤੇ ਵੱਖ-ਵੱਖ ਸਮੱਗਰੀ ਦਿਖਾਉਂਦੀ ਹੈ, ਤਾਂ ਕੈਸ਼ਿੰਗ ਨੂੰ ”ਵੈਰੀਐਂਟ ਡਾਇਮੈਂਸ਼ਨਜ਼' ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ। ਨਹੀਂ ਤਾਂ, ਖੇਤਰ A ਦੇ ਉਪਭੋਗਤਾ ਲਈ ਬਣਾਈ ਗਈ ਕੈਸ਼ ਖੇਤਰ B ਦੇ ਉਪਭੋਗਤਾ ਵੱਲੋਂ ਦੁਬਾਰਾ ਵਰਤੀ ਜਾ ਸਕਦੀ ਹੈ।

C. ਫਰੰਟ-ਐਂਡ ਅਪਟੀਮਾਈਜੇਸ਼ਨ (JS/CSS) ਨੂੰ ਮੁੜ ਲਿਖਣ ਨਾਲ ਕਾਰਜਕੁਸ਼ਲਤਾ ਸੰਬੰਧੀ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਹੋਈਆਂ ਹਨ।

ਖਾਸ ਕਰਕੇ JavaScript ਦੀ ਮਿਨੀਫਿਕੇਸ਼ਨ, ਬੰਡਲਿੰਗ ਅਤੇ ਲੇਜ਼ੀ ਲੋਡਿੰਗ। WooCommerce ਤਾਂ ਇਹ ਵੀ ਸਿਫਾਰਸ਼ ਕਰਦਾ ਹੈ।ਜਾਵਾਸਕ੍ਰਿਪਟ ਫਾਈਲਾਂ ਨੂੰ ਛੋਟਾ ਕਰਨ ਤੋਂ ਬਚੋ。

2. ਤੈਨਾਤੀ ਤੋਂ ਪਹਿਲਾਂ ਰਿਗਰੈਸ਼ਨ ਟੈਸਟ ਚੈੱਕਲਿਸਟ

• ਕੀ ਲੌਗਇਨ/ਲੌਗਆਊਟ ਫੰਕਸ਼ਨ ਠੀਕ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦਾ ਹੈ?
• ਕੀ ਫਾਰਮ ਭੇਜਣ (ਸੰਪਰਕ ਫਾਰਮ, ਸਬਸਕ੍ਰਿਪਸ਼ਨ, ਲੌਗਇਨ ਅਤੇ ਰਜਿਸਟ੍ਰੇਸ਼ਨ) ਠੀਕ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦੇ ਹਨ?
• ਈ-ਕਾਮਰਸ ਪ੍ਰਕਿਰਿਆ: ਟੋਕਰੀ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰੋ → ਵਾਊਚਰ → ਡਿਲਿਵਰੀ ਖਰਚੇ/ਟੈਕਸ → ਭੁਗਤਾਨ → ਆਰਡਰ ਪੰਨਾ
• ਕੀ ਭਾਸ਼ਾ ਬਦਲਣ ਦੀ ਵਿਸ਼ੇਸ਼ਤਾ ਸਥਿਰ ਹੈ (ਬਦਲਣ ਤੋਂ ਬਾਅਦ ਸਮੱਗਰੀ, URL, hreflang ਅਤੇ ਮੁਦਰਾ ਦੇ ਸੰਦਰਭ ਵਿੱਚ)?
• ਕੀ ਮੋਬਾਈਲ ਮੀਨੂ, ਪੌਪ-ਅੱਪ, ਸਕ੍ਰੋਲਿੰਗ ਅਤੇ ਲੇਜ਼ੀ ਲੋਡਿੰਗ ਠੀਕ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰ ਰਹੇ ਹਨ?
• ਜਾਂਚੋ ਕਿ ਕੀ ਟ੍ਰੈਕਿੰਗ ਸਕ੍ਰਿਪਟਾਂ (GA, ਮੈਟਾ ਪਿਕਸਲ, ਕਨਵਰਜ਼ਨ ਈਵੈਂਟਸ) ਅਜੇ ਵੀ ਟ੍ਰਿਗਰ ਹੋ ਰਹੀਆਂ ਹਨ।

ਅਕਸਰ ਪੁੱਛੇ ਜਾਣ ਵਾਲੇ ਸਵਾਲ

Q1: ਮੈਂ ਇੱਕ ਕੈਸ਼ਿੰਗ ਪਲੱਗਇਨ ਇੰਸਟਾਲ ਕੀਤਾ ਹੋਇਆ ਹੈ, ਫਿਰ ਵੀ ਵਿਦੇਸ਼ਾਂ ਤੋਂ ਐਕਸੈਸ ਕਰਨ 'ਤੇ ਸਾਈਟ ਹਾਲੇ ਵੀ ਸੁਸਤ ਕਿਉਂ ਹੈ?

ਸਭ ਤੋਂ ਆਮ ਕਾਰਨ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਸਿਰਫ਼ “ਮੂਲ ਸਰਵਰ ”ਤੇ ਡੁਪਲੀਕੇਟ ਰੈਂਡਰਿੰਗ“ ਨੂੰ ਹੀ ਹੱਲ ਕੀਤਾ ਹੈ, ਪਰ ”ਮਹਾਦੀਪੀ ਨੈੱਟਵਰਕ ਦੇਰੀ' ਨੂੰ ਹੱਲ ਨਹੀਂ ਕੀਤਾ।
ਕੈਸ਼ਿੰਗ ਪਲੱਗਇਨ ਸਰਵਰ ਨੂੰ ਸਮੱਗਰੀ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਪਹੁੰਚਾਉਣ ਯੋਗ ਬਣਾਉਂਦੇ ਹਨ (TTFB ਘਟਾਉਂਦੇ ਹੋਏ), ਪਰ ਸਥਿਰ ਸਰੋਤ (ਚਿੱਤਰ, CSS, JS, ਫੋਂਟ) ਅਤੇ ਗਲੋਬਲ ਕਨੈਕਸ਼ਨਾਂ ਦੀ RTT ਅਜੇ ਵੀ ਲੋੜੀਂਦੀ ਹੈ। ਇੱਕ ਟੀਪੀ273ਟੀ ਫ਼ਾਸਲਾ ਪੂਰਾ ਕਰਨ ਲਈ
👉 ਇਸ ਲਈ ਸਹੀ ਤਰੀਕਾ ਇਹ ਹੈ:ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਇਹ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਓਰਿਜਿਨ ਸਰਵਰ ਕੈਸ਼ਿੰਗ ਸਹੀ ਢੰਗ ਨਾਲ ਕੰਮ ਕਰ ਰਹੀ ਹੈ,ਵਿਸ਼ਵ-ਵਿਆਪੀ ਵੰਡ ਲਈ CDN 'ਤੇ ਅੱਪਲੋਡ ਕਰੋ。

Q2: ਮੈਂ ਸਮੱਗਰੀ ਨੂੰ ਕੈਸ਼ ਕਰਨ ਤੋਂ ਬਾਅਦ ਵੀ ਇਹ ਅੱਪਡੇਟ ਕਿਉਂ ਨਹੀਂ ਹੋ ਰਹੀ?

ਇਹ ਇਸ ਲਈ ਹੈ ਕਿ ਤੁਸੀਂ ਇੱਕ “ਪੁਰਾਣਾ ਕੈਸ਼” ਵੇਖ ਰਹੇ ਹੋ। ਹੱਲ:

• ਇੱਕ ਕੈਸ਼ ਸਾਫ਼ ਕਰਨ ਦੀ ਨੀਤੀ ਬਣਾਓ: ਕਿਸੇ ਲੇਖ ਜਾਂ ਪੰਨੇ ਨੂੰ ਅੱਪਡੇਟ ਕਰਨ ਤੋਂ ਬਾਅਦ ਸਬੰਧਤ ਕੈਸ਼ ਸਾਫ਼ ਕਰੋ (ਪੂਰੀ ਸਾਈਟ ਨੂੰ ਸਾਫ਼ ਕਰਨ ਦੀ ਬਜਾਏ)
• ਪ੍ਰੀ-ਵਾਰਮਿੰਗ ਜਾਂ ਕ੍ਰਾਲਿੰਗ ਨਾਲ ਸੰਬੰਧਿਤ ਹੱਲਾਂ ਲਈ: ਸਫਾਈ ਕਰਨ ਤੋਂ ਬਾਅਦ ਤੁਹਾਨੂੰ ਮੁੜ ਪ੍ਰੀ-ਵਾਰਮਿੰਗ ਕਰਨੀ ਪਵੇਗੀ, ਨਹੀਂ ਤਾਂ ਪਹਿਲੀ ਵਾਰੀ ਆਉਣ ਵਿੱਚ ਦੇਰੀ ਹੋਵੇਗੀ।
• CDN ਬਾਰੇ: ਇਹ ਧਿਆਨ ਵਿੱਚ ਰੱਖਣਾ ਜ਼ਰੂਰੀ ਹੈ ਕਿ CDN ਐਜ ਨੇ ਪੁਰਾਣੇ ਸਰੋਤ ਵੀ ਕੈਸ਼ ਕੀਤੇ ਹੋ ਸਕਦੇ ਹਨ।

Q3: ਕੀ ਮੈਂ WP Rocket ਅਤੇ WP Super Cache ਇਕੱਠੇ ਇੰਸਟਾਲ ਕਰ ਸਕਦਾ ਹਾਂ?

ਇਹ ਸਿਫਾਰਸ਼ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ। ਸਭ ਤੋਂ ਸਥਿਰ ਪ੍ਰਦਰਸ਼ਨ ਲਈ ਇੱਕ ਵਾਰ ਵਿੱਚ ਸਿਰਫ਼ ਇੱਕ ਪੇਜ ਕੈਸ਼ਿੰਗ ਪਲੱਗਇਨ ਵਰਤਣਾ ਸਭ ਤੋਂ ਵਧੀਆ ਹੈ। ਤੁਸੀਂ “ਕੈਸ਼ਿੰਗ ਲਈ ਇੱਕ ਅਤੇ ਅਪਟੀਮਾਈਜ਼ੇਸ਼ਨ ਲਈ ਇੱਕ” ਦੇ ਵਿਚਾਰ ਨੂੰ “ਕੰਮ ਦੀ ਵੰਡ” ਵਜੋਂ ਸਮਝ ਸਕਦੇ ਹੋ, ਪਰ ਅਮਲੀ ਤੌਰ “ਤੇ ਇਹ ਅਕਸਰ ਪੇਜ ਕੈਸ਼ਿੰਗ ਜਾਂ ਸਰੋਤ ਮੁੜ-ਲਿਖਣ ਵਿੱਚ ਦਖਲਅੰਦਾਜ਼ੀ ਕਰਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਟਕਰਾਅ ਦੀ ਉੱਚ ਸੰਭਾਵਨਾ ਹੁੰਦੀ ਹੈ। ਇਹ ਬਿਹਤਰ ਹੈ ਕਿ ਤੁਸੀਂ ਇੱਕ ”ਮੁੱਖ ਕੈਸ਼ਿੰਗ ਪਲੱਗਇਨ' ਚੁਣੋ ਅਤੇ ਕਿਸੇ ਵੀ ਵਾਧੂ ਲੋੜ ਲਈ ਹੋਰ ਵਿਸ਼ੇਸ਼, ਇਕ-ਉਦੇਸ਼ੀ ਟੂਲ ਵਰਤੋਂ।

Q4: ਕੀ ਈ-ਕਾਮਰਸ ਸਾਈਟਾਂ 'ਤੇ ਕੈਸ਼ਿੰਗ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਜੋਖਮ ਭਰਿਆ ਹੈ?

ਇਹ ਖਤਰਨਾਕ ਨਹੀਂ ਹੈ; ਖਤਰਨਾਕ ਤਾਂ “ਨਿਯਮਾਂ ਦੀ ਗੈਰਹਾਜ਼ਰੀ” ਹੈ।ਵੂ-ਕਾਮਰਸ ਸਿਫ਼ਾਰਸ਼ਾਂਕਿਰਪਾ ਕਰਕੇ ਧਿਆਨ ਦਿਓ: ਖਰੀਦਦਾਰੀ ਟੋਕਰੀ, ਚੈੱਕਆਊਟ ਅਤੇ ਖਾਤਾ ਪੰਨਿਆਂ ਨੂੰ ਕੈਸ਼ ਨਹੀਂ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ, ਅਤੇ JavaScript ਸੰਕੋਚਨ ਤੋਂ ਬਚਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।
ਇਸ ਤੋਂ ਇਲਾਵਾ, WooCommerce ਇਹ ਵੀ ਦੱਸਦਾ ਹੈ ਕਿ ਇਹ ਨਾਲ ਅਨੁਕੂਲ ਹੈ। WP ਸੁਪਰ ਕੈਸ਼ ਨਾਲ ਮੂਲ ਅਨੁਕੂਲਤਾ, ਅਤੇ ਡਿਫੌਲਟ ਤੌਰ 'ਤੇ ਕੈਸ਼ ਕੀ ਪੰਨਿਆਂ ਤੋਂ ਬਚਦਾ ਹੈ।
ਇਸ ਲਈ, ਹਾਲਾਂਕਿ ਈ-ਕਾਮਰਸ ਸਾਈਟਾਂ ਨੂੰ ਨਿਸ਼ਚਿਤ ਤੌਰ “ਤੇ ਕੈਸ਼ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਜੇ ਤੁਸੀਂ ਇਸਨੂੰ ”ਲਾਈਵ ਚੇਂਜ' ਵਜੋਂ ਲੈਂਦੇ ਹੋ, ਤਾਂ ਇਸਦੀ ਜਾਂਚ ਕਰਨੀ ਲਾਜ਼ਮੀ ਹੈ।

Q5: ਕੀ ਮੈਨੂੰ LiteSpeed Cache ਜਾਂ WP Rocket ਚੁਣਨਾ ਚਾਹੀਦਾ ਹੈ?

• ਕੀ ਤੁਸੀਂ ਪੁਸ਼ਟੀ ਕੀਤੀ ਹੈ ਕਿ ਸਰਵਰ LiteSpeed/OpenLiteSpeed 'ਤੇ ਚੱਲ ਰਿਹਾ ਹੈ?: LiteSpeed Cache ਨੂੰ ਤਰਜੀਹ ਦਿਓ (ਮੁਫ਼ਤ ਅਤੇ ਸ਼ਕਤੀਸ਼ਾਲੀ, ਜਿਸਦੀਆਂ ਮੁੱਖ ਤਾਕਤਾਂ ਸਰਵਰ-ਗ੍ਰੇਡ LSCache ਤੋਂ ਪ੍ਰਾਪਤ ਹਨ)
• ਤੁਸੀਂ ਸਰਵਰ ਸਟੈਕ ਬਾਰੇ ਅਨਿਸ਼ਚਿਤ ਹੋ / ਪਰੇਸ਼ਾਨੀ ਨਹੀਂ ਚਾਹੁੰਦੇ / ਇੱਕ ਬਿਨਾਂ ਕਿਸੇ ਪਰੇਸ਼ਾਨੀ ਵਾਲਾ, ਸਭ-ਇੱਕ-ਵਿੱਚ ਹੱਲ ਚਾਹੁੰਦੇ ਹੋWP Rocket ਵਧੇਰੇ ਸਥਿਰ ਹੈ।
• ਤੁਸੀਂ ਇੱਕ ਸਮੱਗਰੀ ਵੈੱਬਸਾਈਟ ਚਲਾਉਂਦੇ ਹੋ ਅਤੇ ਬਜਟ-ਸਚੇਤ ਹੋ।WP ਸੁਪਰ ਕੈਸ਼ ਵਧੇਰੇ ਸਥਿਰ ਅਤੇ ਹਲਕਾ ਹੈ।

CDN ਨਾਲ ਜੋੜਿਆ ਗਿਆ ਕੈਸ਼ਿੰਗ ਪਲੱਗਇਨ

ਕੈਸ਼ਿੰਗ ਪਲੱਗਇਨ “ਮੂਲ ਸਰਵਰ ਤੋਂ ਸਮੱਗਰੀ ਦੀ ਘੱਟ ਸੇਵਾ” ਅਤੇ “ਉੱਚ TTFB” ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਦਾ ਹੈ; CDN ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ 'ਸਥਿਰ ਸਰੋਤ ਦੁਨੀਆ ਭਰ ਦੇ ਉਪਭੋਗਤਿਆਂ ਦੇ ਨੇੜੇ ਹੋਣ'। ਕੇਵਲ ਜਦੋਂ ਇਹ ਦੋਵੇਂ ਮਿਲ ਕੇ ਵਰਤੇ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਇਹ ਗਲੋਬਲ ਪਹੁੰਚ ਲਈ ਸਭ ਤੋਂ ਆਮ ਅਤੇ ਸਰਵੋਤਮ ਹੱਲ ਮੁਹੱਈਆ ਕਰਦੇ ਹਨ।

• ਕੰਟੈਂਟ ਸਾਈਟਾਂ ਲਈ ਆਮ ਸੰਯੋਜਨ:ਪੰਨਾ ਕੈਸ਼ਿੰਗ + CDN ਸਥਿਰ ਵੰਡ
• ਡਾਇਨਾਮਿਕ ਵੈੱਬਸਾਈਟਾਂ ਲਈ ਆਮ ਸੰਯੋਜਨ:ਪੰਨਾ ਕੈਸ਼ਿੰਗ (ਸਖ਼ਤ ਨਿਯੰਤਰਿਤ ਅਤੇ ਬਾਹਰ ਰੱਖਿਆ) + ਆਬਜੈਕਟ ਕੈਸ਼ਿੰਗ (ਮੰਗ 'ਤੇ) + CDN ਸਥਿਰ ਵੰਡ

👉 ਪੜ੍ਹੋ:CDN ਤੇਜ਼ੀ (ਗਲੋਬਲ ਨੋਡਸ ਅਤੇ ਕੈਸ਼ਿੰਗ ਨੀਤੀ)

ਸਿਫਾਰਸ਼ੀ ਵੈੱਬਸਾਈਟ ਕੈਸ਼ਿੰਗ ਸੰਰਚਨਾਵਾਂ

1. ਸਮੱਗਰੀ ਵਾਲੀਆਂ ਸਾਈਟਾਂ / ਬਲੌਗ / ਦਸਤਾਵੇਜ਼ੀ ਸਾਈਟਾਂ

ਉਦੇਸ਼: TTFB ਨੂੰ ਘਟਾਓ, ਪਹਿਲੀ ਸਕ੍ਰੀਨ ਦਾ ਅਨੁਭਵ ਹੋਰ ਸੁਚਾਰੂ ਬਣਾਓ, ਸਰਵਰ ਦੇ ਭਾਰ ਨੂੰ ਘਟਾਓ, ਅਤੇ ਵਿਸ਼ਵ-ਵਿਆਪੀ ਵੰਡ ਲਈ CDN ਦੀ ਵਰਤੋਂ ਕਰੋ।

1.1 ਸਭ ਤੋਂ ਝੰਜਟ-ਰਹਿਤ ਵਪਾਰਕ ਪੈਕੇਜ

• WP ਰਾਕਟ (ਪੇਜ ਕੈਸ਼ਿੰਗ + ਪ੍ਰੀਲੋਡਿੰਗ + ਫਰੰਟ-ਐਂਡ ਅਪਟੀਮਾਈਜ਼ੇਸ਼ਨ)
  • CDN (CDN ਪੰਨੇ 'ਤੇ ਕਵਰ ਕੀਤਾ ਜਾਵੇਗਾ)

ਇਹਨਾਂ 'ਤੇ ਲਾਗੂ:

• ਤੁਸੀਂ ਕੁਝ ਐਸਾ ਚਾਹੁੰਦੇ ਹੋ ਜਿਸ ਲਈ ਘੱਟੋ-ਘੱਟ ਸੈੱਟਅੱਪ ਦੀ ਲੋੜ ਹੋਵੇ, ਜੋ ਤੇਜ਼ ਨਤੀਜੇ ਦੇਵੇ ਅਤੇ ਜਿਸ ਵਿੱਚ ਘੱਟ ਜੋਖਮ ਹੋਵੇ।“
• ਬਹੁਤ ਸਾਰੇ ਥੀਮ ਅਤੇ ਪਲੱਗਇਨ ਹਨ, ਅਤੇ ਮੈਂ ਅਨੁਕੂਲਤਾ ਸੰਬੰਧੀ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਘੱਟ ਤੋਂ ਘੱਟ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹਾਂ।

ਧਿਆਨਯੋਗ ਗੱਲਾਂ:

• ਫਰੰਟ-ਐਂਡ ਅਪਟੀਮਾਈਜੇਸ਼ਨ (ਖਾਸ ਕਰਕੇ ਜਾਵਾਸਕ੍ਰਿਪਟ ਡਿਫਰਲ) ਕਾਰਜਕੁਸ਼ਲਤਾ ਸੰਬੰਧੀ ਸਮੱਸਿਆਵਾਂ (ਜਿਵੇਂ ਕਿ ਮੀਨੂ, ਫਾਰਮ ਅਤੇ ਟ੍ਰੈਕਿੰਗ) ਤੋਂ ਬਚਣ ਲਈ ਕਈ ਪੜਾਵਾਂ ਵਿੱਚ ਚਾਲੂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ।
• ਜੋ ਸਾਈਟਾਂ ਅਕਸਰ ਡਿਜ਼ਾਈਨ ਬਦਲਦੀਆਂ ਹਨ ਜਾਂ ਨਿਯਮਤ ਤੌਰ “ਤੇ ਸਮੱਗਰੀ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦੀਆਂ ਹਨ, ਉਹਨਾਂ ਨੂੰ ”ਸਫਾਈ ਅਤੇ ਗਰਮਾਉਣ' ਰਣਨੀਤੀ ਅਪਣਾਉਣੀ ਚਾਹੀਦੀ ਹੈ; ਨਹੀਂ ਤਾਂ ਘੱਟ-ਟ੍ਰੈਫਿਕ ਵਾਲੇ ਪੰਨਿਆਂ 'ਤੇ ਪਹਿਲੀ ਵਾਰੀ ਜਾਣ ਸਮੇਂ ਸੁਸਤ ਹੋਵੇਗਾ।

1.2 ਇੱਕ ਕਲਾਸਿਕ ਸੁਮੇਲ ਜੋ ਮੁਫ਼ਤ ਅਤੇ ਭਰੋਸੇਯੋਗ ਦੋਵੇਂ ਹੈ

• WP ਸੁਪਰ ਕੈਸ਼ (ਸਥਿਰ HTML ਕੈਸ਼ਿੰਗ)ਡਾਇਨਾਮਿਕ ਪੰਨਿਆਂ ਤੋਂ ਸਟੈਟਿਕ HTML ਤਿਆਰ ਕਰੋ, ਮੁੱਖ ਤੌਰ 'ਤੇ ਉਹਨਾਂ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਸੇਵਾ ਦੇਣ ਲਈ ਜੋ ਲੌਗ ਇਨ ਨਹੀਂ ਹੋਏ ਹਨ।
  • ਇੱਕ ਟੀਪੀ273ਟੀ

ਇਹਨਾਂ 'ਤੇ ਲਾਗੂ:

• ਬਜਟ-ਸਚੇਤ ਪਰ ਸਥਿਰਤਾ ਦੀ ਭਾਲ ਵਿੱਚ
• ਮਹਿਮਾਨ ਘੱਟ ਹੀ ਲੌਗ ਇਨ ਕਰਦੇ ਹਨ
• ਸੰਭਾਲਣਯੋਗ ਸਮੱਗਰੀ ਅੱਪਡੇਟ ਸ਼ਡਿਊਲ

ਧਿਆਨਯੋਗ ਗੱਲਾਂ:

• ਇਹ “ਪੇਜ ਕੈਸ਼ ਫਰਸਟ” ਪਹੁੰਚ ਹੈ; ਇਸ ਤੋਂ ਸਾਰੇ ਜਟਿਲ CSS ਅਤੇ JavaScript ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਸਾਈਡ ਇਫੈਕਟ ਵਜੋਂ ਹੱਲ ਕਰਨ ਦੀ ਉਮੀਦ ਨਾ ਰੱਖੋ।

---

2. ਕਾਰਪੋਰੇਟ ਵੈੱਬਸਾਈਟਾਂ / ਬ੍ਰਾਂਡ ਵੈੱਬਸਾਈਟਾਂ / ਲੈਂਡਿੰਗ ਪੇਜ

ਉਦੇਸ਼: ਗਤੀ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਪਰ ਇਹ ਹੋਰ ਵੀ ਜ਼ਰੂਰੀ ਹੈ ਕਿ ਅਨੁਕੂਲਨ ਕਨਵਰਜ਼ਨ ਪ੍ਰਵਾਹ ਨੂੰ ਵਿਘਟਿਤ ਨਾ ਹੋਣ ਦੇਵੇ।

2.1 ਮਜ਼ਬੂਤ ਅਤੇ ਕਾਬੂ ਵਿੱਚ ਰਹਿਣ ਵਾਲਾ (ਗਲੋਬਲ ਮੁਹਿੰਮਾਂ/ਕਨਵਰਜ਼ਨ ਲੈਂਡਿੰਗ ਪੰਨਿਆਂ ਲਈ ਸਿਫ਼ਾਰਸ਼ੀ)

• ਡਬਲਯੂਪੀ ਰਾਕੇਟ
• + (ਵਿਕਲਪਿਕ) ਹਲਕੇ-ਫੁਲਕੇ ਚਿੱਤਰਾਂ ਦੀ ਅਨੁਕੂਲਤਾ (ਤੁਹਾਡੇ ਕੋਲ “ਚਿੱਤਰ ਅਨੁਕੂਲਤਾ” ਪੰਨਾ ਹੈ)
  • ਇੱਕ ਟੀਪੀ273ਟੀ

ਇਹ ਇੱਕ ਪਰਿਵਰਤਨ ਸਾਈਟ ਲਈ ਕਿਉਂ ਢੁਕਵਾਂ ਹੈ:

• ਕਨਵਰਜ਼ਨ ਪਲੇਟਫਾਰਮ ਸਭ ਤੋਂ ਵੱਧ ਸੰਵੇਦਨਸ਼ੀਲ ਹੁੰਦੇ ਹਨ ਜਦੋਂ ਆਪਟੀਮਾਈਜ਼ੇਸ਼ਨ ਕਾਰਨ ਫਾਰਮ, ਪੌਪ-ਅੱਪ ਅਤੇ ਟ੍ਰੈਕਿੰਗ ਸਕ੍ਰਿਪਟਾਂ ਵਿੱਚ ਵਿਘਨ ਪੈਂਦਾ ਹੈ।“
• WP Rocket ਇੱਕ ਵਧੇਰੇ “ਇੰਟੀਗ੍ਰੇਟਿਡ” ਪਹੁੰਚ ਅਪਣਾਉਂਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਤੁਸੀਂ ਇੱਕੋ ਸਿਸਟਮ ਦੇ ਅੰਦਰ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਇੱਕ-ਇੱਕ ਕਰਕੇ ਚਾਲੂ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਰਿਗ੍ਰੈਸ਼ਨ ਟੈਸਟਿੰਗ ਕਰ ਸਕਦੇ ਹੋ।

ਕਾਰਪੋਰੇਟ ਵੈੱਬਸਾਈਟ ਸ਼ੁਰੂ ਕਰਨ ਲਈ ਸਿਧਾਂਤ:

• ਪ੍ਰਦਰਸ਼ਨ ਅਨੁਕੂਲਨ ਇੱਕ “ਡਿਪਲਾਇਮੈਂਟ ਬਦਲਾਅ” ਹੈ ਅਤੇ ਇਸਦੇ ਨਾਲ ਇੱਕ ਰਿਗ੍ਰੈਸ਼ਨ ਟੈਸਟ ਚੈੱਕਲਿਸਟ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ।
• ਜਾਵਾਸਕ੍ਰਿਪਟ ਦੇ ਡਿਫਰ, ਬੰਡਲਿੰਗ ਜਾਂ ਮਿਨੀਫਿਕੇਸ਼ਨ ਨਾਲ ਸਬੰਧਤ ਕੋਈ ਵੀ ਸੈਟਿੰਗਾਂ ਨੂੰ ਡਿਪਲੌਏ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਪ੍ਰੀ-ਪ੍ਰੋਡਕਸ਼ਨ ਵਾਤਾਵਰਣ ਵਿੱਚ ਵੈਲੀਡੇਟ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।

---

3. WooCommerce ਈ-ਕਾਮਰਸ ਸਾਈਟ (ਆਰਡਰ ਪ੍ਰਬੰਧਨ + ਗਤੀਸ਼ੀਲ ਪੰਨਾ ਸੁਰੱਖਿਆ)

ਉਦੇਸ਼: ਇਹ ਜ਼ਰੂਰੀ ਹੈ ਕਿ ਖਰੀਦਦਾਰੀ ਟੋਕਰੀ, ਚੈੱਕਆਊਟ ਅਤੇ ਖਾਤਾ ਵਰਗੇ ਪੰਨੇ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਹੀ ਹੋਣ, ਅਤੇ ਨਾਲ ਹੀ ਉਹਨਾਂ ਦੀ ਗਤੀ ਵੀ ਬਰਕਰਾਰ ਰਹੇ।

WooCommerce ਦੀ ਕੈਸ਼ਿੰਗ ਪਲੱਗਇਨਾਂ ਬਾਰੇ ਅਧਿਕਾਰਕ ਰਾਏ ਬਹੁਤ ਸਪਸ਼ਟ ਹੈ:ਸ਼ਾਪਿੰਗ ਕਾਰਟ / ਚੈੱਕਆਊਟ / ਖਾਤਾ ਪੰਨਿਆਂ ਨੂੰ ਕੈਸ਼ ਨਾ ਕਰੋ।ਇਹ ਵੀ ਸਿਫਾਰਸ਼ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਕਿ ਤੁਸੀਂ ਅਨੁਕੂਲਤਾ ਸੰਬੰਧੀ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਘੱਟ ਤੋਂ ਘੱਟ ਕਰਨ ਲਈ JavaScript ਫਾਈਲਾਂ ਨੂੰ ਮਿਨੀਫਾਈ ਕਰਨ ਤੋਂ ਬਚੋ।

3.1 ਇੱਕ ਵਧੇਰੇ “ਸ਼ੁਰੂਆਤੀ-ਅਨੁਕੂਲ” ਮੁਫ਼ਤ ਸੁਰੱਖਿਆ ਰਸਤਾ

• WP ਸੁਪਰ ਕੈਸ਼ + ਵੂ-ਕਾਮਰਸ
  • ਇੱਕ ਟੀਪੀ273ਟੀ

ਇਸਨੂੰ “ਸ਼ੁਰੂਆਤੀਆਂ ਲਈ ਸੁਰੱਖਿਅਤ ਵਿਕਲਪ” ਵਜੋਂ ਕਿਉਂ ਸੂਚੀਬੱਧ ਕੀਤਾ ਗਿਆ ਹੈ?

• WooCommerce ਦੱਸਦਾ ਹੈ ਕਿ ਇਹ ਮੂਲ ਰੂਪ ਵਿੱਚ WP Super Cache ਨਾਲ ਅਨੁਕੂਲ ਹੈ ਅਤੇ ਨੋਟ ਕਰਦਾ ਹੈ ਕਿ WP Super Cache ਆਟੋਮੈਟਿਕ ਤੌਰ 'ਤੇ ਸ਼ਾਪਿੰਗ ਕਾਰਟ, ਚੈੱਕਆਊਟ ਅਤੇ ਖਾਤਾ ਵਰਗੇ ਮੁੱਖ ਪੰਨਿਆਂ ਨੂੰ ਕੈਸ਼ ਨਹੀਂ ਕਰਦਾ।
• ਈ-ਕਾਮਰਸ ਵਿੱਚ ਨਵੀਂ ਸ਼ੁਰੂਆਤ ਕਰਨ ਵਾਲੀਆਂ ਵੈੱਬਸਾਈਟਾਂ ਲਈ, “ਡਾਊਨਟਾਈਮ ਤੋਂ ਬਚਣਾ” “ਵੱਧ ਤੋਂ ਵੱਧ ਕਾਰਗੁਜ਼ਾਰੀ” ਨਾਲੋਂ ਵੱਧ ਮਹੱਤਵਪੂਰਨ ਹੈ।

3.2 ਜੇ ਤੁਸੀਂ LiteSpeed ਹੋਸਟਿੰਗ (ਮੁਫ਼ਤ ਪਰ ਬਹੁਤ ਸ਼ਕਤੀਸ਼ਾਲੀ) ਦੀ ਵਰਤੋਂ ਕਰ ਰਹੇ ਹੋ

• ਲਾਈਟਸਪੀਡ ਕੈਸ਼ (ਮੁੱਖ ਸਰਵਰ ਕੈਸ਼ਿੰਗ ਸਮਰੱਥਾਵਾਂ ਦੀ ਪੂਰੀ ਵਰਤੋਂ ਕਰਨ ਲਈ ਲਾਈਟਸਪੀਡ/ਓਪਨਲਾਈਟਸਪੀਡ ਹੋਸਟਿੰਗ ਵਾਤਾਵਰਣ ਦੀ ਲੋੜ ਹੈ)
• + (ਵਿਕਲਪਿਕ) ਆਬਜੈਕਟ ਕੈਸ਼ਿੰਗ (ਸਰਵਰ ਦੀ ਸਮਰੱਥਾ ਅਤੇ ਸਾਈਟ ਦੇ ਆਕਾਰ ਦੇ ਅਧਾਰ 'ਤੇ, ਰੈਡਿਸ/ਮੈਮਕੇਸ਼ਡ)
  • ਇੱਕ ਟੀਪੀ273ਟੀ

ਇਹਨਾਂ 'ਤੇ ਲਾਗੂ:

• ਹੋਸਟ ਸਟੈਕ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤਾ ਗਿਆ ਹੈ, ਅਤੇ ਤੁਸੀਂ ਕੈਸ਼ਿੰਗ ਨਿਯਮਾਂ ਅਤੇ ਬਾਹਰ ਰੱਖਣ ਦੀਆਂ ਰਣਨੀਤੀਆਂ ਸੈੱਟ ਕਰਨ ਲਈ ਤਿਆਰ ਹੋ।
• ਬਹੁਤ ਸਾਰੇ ਆਰਡਰਾਂ ਅਤੇ ਉਤਪਾਦਾਂ ਦੇ ਨਾਲ, ਮੂਲ ਸਰਵਰ ਨੂੰ ਵੱਧ ਭਾਰ ਸੰਭਾਲਣ ਦੇ ਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।

3.3 ਇੰਜੀਨੀਅਰਿੰਗ ਟੀਮਾਂ / ਜਟਿਲ ਈ-ਕਾਮਰਸ ਪਲੇਟਫਾਰਮ (ਕਈ ਨਿਯੰਤਰਣਯੋਗ ਮਾਡਿਊਲਾਂ ਨਾਲ)

• W3 ਟੋਟਲ ਕੈਸ਼ (ਪ੍ਰਦਰਸ਼ਨ ਫਰੇਮਵਰਕ, CDN ਨਾਲ ਏਕੀਕ੍ਰਿਤ ਬਹੁ-ਪੱਧਰੀ ਕੈਸ਼ਿੰਗ)
  • ਆਬਜੈਕਟ ਕੈਸ਼ਿੰਗ (ਲੋੜ ਅਨੁਸਾਰ)
  • ਇੱਕ ਟੀਪੀ273ਟੀ

ਇਹਨਾਂ 'ਤੇ ਲਾਗੂ:

• ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ DevOps ਟੀਮ ਹੈ, ਤਾਂ ਤੁਸੀਂ “ਮੋਡਿਊਲ-ਦਰ-ਮੋਡਿਊਲ ਰੋਲ-ਆਊਟ, ਲੋਡ ਟੈਸਟਿੰਗ ਅਤੇ ਰਿਗ੍ਰੈਸ਼ਨ ਟੈਸਟਿੰਗ” ਸ਼ਾਮਲ ਕਰਨ ਵਾਲੇ ਇੱਕ ਪੜਾਅ-ਵਾਰ ਤਰੀਕੇ ਨਾਲ ਸਿਸਟਮ ਨੂੰ ਤੈਨਾਤ ਕਰ ਸਕਦੇ ਹੋ।
• ਫ੍ਰੈਗਮੈਂਟ ਕੈਸ਼ਿੰਗ ਜਾਂ ਹੋਰ ਜਟਿਲ ਵੇਰੀਐਂਟ ਰਣਨੀਤੀਆਂ (ਜਿਵੇਂ ਕਿ ਡਿਵਾਈਸ, ਖੇਤਰ ਜਾਂ ਭਾਸ਼ਾ ਅਨੁਸਾਰ ਬਾਰੀਕ-ਗ੍ਰੇਨ ਕੈਸ਼ਿੰਗ) ਦੀ ਲੋੜ ਹੈ।

---

4. ਮੈਂਬਰਸ਼ਿਪ ਸਾਈਟਾਂ / ਭਾਈਚਾਰੇ / ਔਨਲਾਈਨ ਕੋਰਸ (ਜਿਨ੍ਹਾਂ ਲਈ ਵਾਰ-ਵਾਰ ਲੌਗਇਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਅਤੇ ਜੋ ਉੱਚ ਪੱਧਰ ਦੀ ਨਿੱਜੀਕਰਨ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰਦੇ ਹਨ)

ਉਦੇਸ਼: ਇਹ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਜਨਤਕ ਸਮੱਗਰੀ ਤੇਜ਼ੀ ਨਾਲ ਲੋਡ ਹੋਵੇ, ਅਤੇ ਇਹ ਵੀ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਲੌਗ-ਇਨ ਕੀਤੇ ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਸਮੱਗਰੀ ਵੱਖਰੀ ਰਹੇ।

4.1 ਬਿਨਾਂ ਪਰੇਸ਼ਾਨੀ ਦਾ ਪਰ ਇਸ ਲਈ ਇੱਕ ਸਖ਼ਤ ਬਾਹਰ-ਰੱਖਣ ਦੀ ਰਣਨੀਤੀ ਦੀ ਲੋੜ ਹੈ।

• ਡਬਲਯੂਪੀ ਰਾਕੇਟ
• + (ਵਿਕਲਪਿਕ) ਆਬਜੈਕਟ ਕੈਸ਼ਿੰਗ (ਜੇਕਰ ਬਹੁਤ ਸਾਰੀਆਂ ਡਾਇਨਾਮਿਕ ਕੁਐਰੀਆਂ ਹਨ)
  • ਇੱਕ ਟੀਪੀ273ਟੀ

ਮੁੱਖ ਨੁਕਤੇ:

• ਤੁਹਾਨੂੰ ਹੇਠ ਲਿਖੇ ਪੰਨਿਆਂ ਨੂੰ ਕੈਸ਼ਿੰਗ ਤੋਂ ਬਾਹਰ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਵਰਤੋਂਕਾਰ ਅਨੁਸਾਰ ਵੱਖ-ਵੱਖ ਹੁੰਦੇ ਹਨ: ਮੇਰਾ ਖਾਤਾ, ਆਰਡਰ, ਸਿੱਖਣ ਦੀ ਤਰੱਕੀ, ਸੁਨੇਹੇ, ਖਰੀਦਦਾਰੀ ਦੀ ਟੋਕਰੀ, ਆਦਿ।
• ਇਹ ਤਰ੍ਹਾਂ ਦੀਆਂ ਸਾਈਟਾਂ “ਹੋਰ ਉਪਭੋਗਤਾਵਾਂ ਦੀ ਸਮੱਗਰੀ ਵੇਖਣ” ਜਾਂ 'ਅਨੁਮਤੀ ਦੀਆਂ ਗਲਤੀਆਂ' ਵਰਗੀਆਂ ਸਮੱਸਿਆਵਾਂ ਲਈ ਸਭ ਤੋਂ ਵੱਧ ਸੰਵੇਦਨਸ਼ੀਲ ਹੁੰਦੀਆਂ ਹਨ; ਖਤਰਿਆਂ ਨੂੰ ਸਫ਼ੇ 'ਤੇ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਵਿਆਖਿਆ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।

4.2 ਲਾਈਟਸਪੀਡ ਹੋਸਟਿੰਗ + ਉੱਨਤ ਨੀਤੀਆਂ

• ਲਾਈਟਸਪੀਡ ਕੈਸ਼ (ਸਰਵਰ ਕੈਸ਼ਿੰਗ + ਹੋਰ ਉੱਨਤ ਨੀਤੀ ਸੰਦ)
• + (ਮੰਗ 'ਤੇ) ਆਬਜੈਕਟ ਕੈਸ਼ਿੰਗ
  • ਇੱਕ ਟੀਪੀ273ਟੀ

ਮੁੱਖ ਨੁਕਤੇ:

• ਮੈਂਬਰਸ਼ਿਪ ਸਾਈਟਾਂ ਅਕਸਰ “ਕੈਸ਼ ਕਰਨ ਯੋਗ ਬਾਡੀ + ਕੈਸ਼ ਨਾ ਕਰਨ ਯੋਗ ਫ੍ਰੈਗਮੈਂਟ” ਪਹੁੰਚ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।
• ਪ੍ਰੀ-ਲੋਡਿੰਗ ਅਤੇ ਕਲੀਅਰਿੰਗ ਦੀਆਂ ਰਣਨੀਤੀਆਂ ਨੂੰ ਹੋਰ ਸੁਧਾਰਨ ਦੀ ਲੋੜ ਹੈ; ਨਹੀਂ ਤਾਂ, ਅੱਪਡੇਟ ਤੋਂ ਬਾਅਦ ਵੀ ਉਪਭੋਗਤਾ ਅਕਸਰ ਪੁਰਾਣੀ ਸਮੱਗਰੀ ਹੀ ਵੇਖਦੇ ਰਹਿਣਗੇ।

ਵੈੱਬਸਾਈਟ ਕੈਸ਼: “ਫੰਦਿਆਂ ਤੋਂ ਬਚਣ ਲਈ ਕੇਸ ਅਧਿਐਨ”

ਕੇਸ 1: ਇੱਕ ਕੈਸ਼ਿੰਗ ਪਲੱਗਇਨ ਇੰਸਟਾਲ ਕੀਤਾ, ਪਰ ਗਤੀ ਵਿੱਚ ਲਗਭਗ ਕੋਈ ਬਦਲਾਅ ਨਹੀਂ ਆਇਆ।

ਲੱਛਣ:

• ਸਥਾਨਕ ਖੇਤਰ ਜਾਂ ਇੱਕੋ ਇਲਾਕੇ ਵਿੱਚ ਸਪੀਡ ਟੈਸਟ ਸਵੀਕਾਰਯੋਗ ਹਨ, ਪਰ ਵਿਦੇਸ਼ਾਂ (ਮਹਾਂਦੀਪਾਂ ਪਾਰ) ਵਿੱਚ ਗਤੀ ਹੌਲੀ ਰਹਿੰਦੀ ਹੈ।
• TTFB ਵਿੱਚ ਸੁਧਾਰ ਹੋਇਆ ਹੈ, ਪਰ ਕੁੱਲ ਲੋਡ ਹੋਣ ਦੇ ਸਮੇਂ ਵਿੱਚ ਕੋਈ ਮਹੱਤਵਪੂਰਨ ਕਮੀ ਨਹੀਂ ਆਈ।

ਸਾਂਝੇ ਕਾਰਨ:

• ਤੁਸੀਂ ਸਿਰਫ਼ ਮੂਲ ਸਰਵਰ ਕੈਸ਼ਿੰਗ (TTFB) ਲਾਗੂ ਕੀਤੀ ਹੈ, ਪਰ ਸਥਿਰ ਸਰੋਤ (ਚਿੱਤਰ, JavaScript, CSS ਅਤੇ ਫੌਂਟ) ਅਜੇ ਵੀ ਮਹਾਂਦੀਪਾਂ ਪਾਰ ਮੂਲ ਸਰਵਰ ਤੋਂ ਲੋਡ ਕੀਤੇ ਜਾ ਰਹੇ ਹਨ।
• ਤੀਜੀ-ਪੱਖੀ ਸਕ੍ਰਿਪਟਾਂ (ਇਸ਼ਤਿਹਾਰ, ਚੈਟ, ਵਿਸ਼ਲੇਸ਼ਣ) ਰੈਂਡਰਿੰਗ ਅਤੇ ਇੰਟਰਐਕਟਿਵਿਟੀ ਨੂੰ ਹੌਲੀ ਕਰ ਦਿੰਦੀਆਂ ਹਨ।
• ਤਸਵੀਰ ਬਹੁਤ ਵੱਡੀ ਹੈ, ਜਿਸ ਕਾਰਨ ਡਾਊਨਲੋਡ ਦੀ ਗਤੀ ਹੌਲੀ ਹੋ ਜਾਂਦੀ ਹੈ (ਕੈਸ਼ਿੰਗ “ਸ਼ੁਰੂਆਤੀ ਡਾਊਨਲੋਡ” ਦੌਰਾਨ ਵੱਡੇ ਫਾਈਲ ਆਕਾਰ ਦੀ ਸਮੱਸਿਆ ਦਾ ਹੱਲ ਨਹੀਂ ਕਰ ਸਕਦੀ)

ਪਹੁੰਚ:

• ਕੈਸ਼ਿੰਗ ਪਲੱਗਇਨ ਮੁੱਖ ਤੌਰ “ਤੇ ਸਰਵਰ ਦੇ ਬੋਝ ਨੂੰ ਘਟਾਉਣ ਅਤੇ ਹਿੱਟ ਦਰਾਂ ਨੂੰ ਸੁਧਾਰਨ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੈ।”
• CDN ਰਾਹੀਂ ਸਥਿਰ ਸਰੋਤ
• ਚਿੱਤਰ ਅਨੁਕੂਲਨ
• ਦੇਰੀ/ਵੰਡਣ ਰਣਨੀਤੀਆਂ ਲਈ ਤੀਜੀ-ਪੱਖੀ ਸਕ੍ਰਿਪਟਾਂ

ਪੜ੍ਹੋ:

• CDN ਐਕਸਲਰੇਸ਼ਨ: ਗਲੋਬਲ ਨੋਡਸ ਅਤੇ ਕੈਸ਼ਿੰਗ ਰਣਨੀਤੀਆਂ
• ਚਿੱਤਰ ਅਨੁਕੂਲਨ: ਫਾਰਮੈਟਿੰਗ/ਕੰਪਰੈਸ਼ਨ/ਲੇਜ਼ੀ ਲੋਡਿੰਗ

---

ਕੇਸ 2: ਕੈਸ਼ਿੰਗ ਚਾਲੂ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਪੰਨਾ ਸੋਧਿਆ ਗਿਆ ਪਰ ਫਰੰਟ-ਐਂਡ ਅੱਪਡੇਟ ਨਹੀਂ ਹੋਇਆ।

ਲੱਛਣ:

• ਐਡਮਿਨ ਪੈਨਲ ਵਿੱਚ ਸਮੱਗਰੀ/ਲੇਆਉਟ ਅੱਪਡੇਟ ਕੀਤਾ ਗਿਆ ਹੈ, ਪਰ ਫਰੰਟ-ਐਂਡ ਅਜੇ ਵੀ ਪੁਰਾਣਾ ਵਰਜਨ ਦਿਖਾ ਰਿਹਾ ਹੈ।
• ਜਾਂ ਸ਼ਾਇਦ ਸਿਰਫ ਕੁਝ ਖੇਤਰ ਹੀ ਅੱਪਡੇਟ ਕੀਤੇ ਗਏ ਹਨ, ਜਦਕਿ ਹੋਰ ਬਦਲੇ ਨਹੀਂ ਗਏ (ਜੋ ਕਿ ਗਲੋਬਲ ਸਾਈਟ 'ਤੇ ਕਾਫ਼ੀ ਆਮ ਹੈ)

ਸਾਂਝੇ ਕਾਰਨ:

• ਪੇਜ ਕੈਸ਼ ਸਾਫ਼ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਹੈ, ਜਾਂ ਸਾਫ਼ ਕਰਨ ਦੀ ਕਾਰਵਾਈ ਦਾ ਦਾਇਰਾ ਗਲਤ ਹੈ।
• ਪ੍ਰੀ-ਵਾਰਮਿੰਗ/ਕ੍ਰਾਲਿੰਗ ਨਹੀਂ ਚੱਲੀ; ਕੈਸ਼ ਸਾਫ਼ ਕਰਨ ਨਾਲ ਇਹ 'ਕੋਲਡ' ਹੋ ਗਿਆ, ਜਿਸ ਕਾਰਨ ਪਹਿਲੀ ਵਾਰੀ ਲੋਡ ਹੌਲੀ ਹੋ ਰਹੀ ਹੈ, ਜਦਕਿ ਤੁਸੀਂ ਗਲਤਫ਼ਹਮੀ ਵਿੱਚ ਸੋਚਦੇ ਹੋ ਕਿ ਕੋਈ ਅਪਡੇਟ ਨਹੀਂ ਕੀਤਾ ਗਿਆ।
• ਜੇ ਤੁਸੀਂ CDN ਐਜ ਕੈਸ਼ ਚਾਲੂ ਕੀਤਾ ਹੈ, ਤਾਂ ਐਜ ਪੁਰਾਣੇ ਸਰੋਤ ਵੀ ਰੱਖ ਸਕਦਾ ਹੈ।

ਪਹੁੰਚ:

• ਪ੍ਰਕਾਸ਼ਨ/ਸੰਸ਼ੋਧਨ ਤੋਂ ਬਾਅਦ “ਸਫਾਈ ਨੀਤੀ” ਬਣਾਓ: ਪੂਰੀ ਸਾਈਟ ਦੀ ਸਖ਼ਤ ਸਫਾਈ ਕਰਨ ਦੀ ਬਜਾਏ ਸਿਰਫ਼ ਸੰਬੰਧਤ ਪੰਨਿਆਂ ਦੀ ਸਫਾਈ ਕਰੋ।
• ਮੁੱਖ ਪੰਨਿਆਂ (ਹੋਮਪੇਜ, ਮੁੱਖ ਲੈਂਡਿੰਗ ਪੰਨੇ) ਲਈ ਪਹਿਲਾਂ ਤੋਂ ਲੋਡ ਕਰਨ ਦੀ ਰਣਨੀਤੀ ਵਿਕਸਿਤ ਕਰੋ, ਤਾਂ ਜੋ “ਸਫਾਈ” ਕਰਨ ਨਾਲ ਪ੍ਰਦਰਸ਼ਨ ਹੌਲੀ ਨਾ ਹੋਵੇ।”
• ਜਿੱਥੇ ਲੋੜ ਹੋਵੇ, ਪਰਤ CDN 'ਤੇ ਕਿਨਾਰਿਆਂ ਦੀ ਸਫਾਈ ਕਰੋ।

---

ਕੇਸ 3: ਭਾਸ਼ਾਵਾਂ ਅਤੇ ਮੁਦਰਾਵਾਂ ਵਿਚਕਾਰ ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ ਸਮੱਗਰੀ ਪ੍ਰਦਰਸ਼ਨ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ

ਲੱਛਣ:

• ਭਾਸ਼ਾ ਬਦਲਣ ਤੋਂ ਬਾਅਦ ਵੀ ਪੰਨਾ ਪਿਛਲੀ ਭਾਸ਼ਾ ਦਿਖਾਉਂਦਾ ਹੈ।
• ਵਿਕਲਪਕ ਤੌਰ 'ਤੇ, ਕੁਝ ਖੇਤਰਾਂ ਵਿੱਚ ਉਪਭੋਗਤਾ ਗਲਤ ਮੁਦਰਾ ਜਾਂ ਗਲਤ ਸਮੱਗਰੀ ਦੇਖ ਸਕਦੇ ਹਨ।

ਸਾਂਝੇ ਕਾਰਨ:

• ਕੈਸ਼ “ਵੈਰੀਐਂਟ ਡਾਇਮੈਂਸ਼ਨਜ਼” (cookie / ਪੈਰਾਮੀਟਰ / ਭਾਸ਼ਾ ਪ੍ਰੀਫਿਕਸ / ਸਬਡੋਮੇਨ) ਵਿੱਚ ਫਰਕ ਨਹੀਂ ਕਰਦਾ।
• ਕੈਸ਼ ਹਿੱਟ ਨੇ ਭਾਸ਼ਾ A ਦੀ ਇੱਕ ਪੰਨਾ ਭਾਸ਼ਾ B ਦੇ ਉਪਭੋਗਤਾ ਨੂੰ ਸੇਵਾ ਕੀਤਾ।

ਪਹੁੰਚ:

• ਆਪਣੀ ਬਹੁਭਾਸ਼ੀ ਰਣਨੀਤੀ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ: ਡਾਇਰੈਕਟਰੀ/ਸਬਡੋਮੇਨ/ਪੈਰਾਮੀਟਰ/cookie
• ਕੈਸ਼ਿੰਗ ਨਿਯਮਾਂ “ਤੇ ”ਵੈਰੀਐਂਟ ਨੀਤੀ' ਲਾਗੂ ਕਰੋ ਜਾਂ ਮੁੱਖ ਪੰਨਿਆਂ ਨੂੰ ਬਾਹਰ ਰੱਖੋ।
• ਕੁਝ ਸਾਈਟਾਂ ਨੂੰ ਵਧੇਰੇ ਉੱਨਤ “ਸ਼ਾਰਡਡ ਕੈਸ਼ਿੰਗ” ਪਹੁੰਚ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ (W3TC ਇੰਜੀਨੀਅਰਿੰਗ-ਅਗਵਾਈ ਵਾਲੇ ਨਿਯੰਤਰਣ ਲਈ ਵਧੇਰੇ ਢੁਕਵਾਂ ਹੈ)

---

ਕੇਸ 4: ਈ-ਕਾਮਰਸ ਸਾਈਟ 'ਤੇ ਕੈਸ਼ਿੰਗ ਚਾਲੂ ਕਰਨ ਤੋਂ ਬਾਅਦ ਸ਼ਾਪਿੰਗ ਬਾਸਕਟ ਅਤੇ ਚੈੱਕਆਊਟ ਨਾਲ ਸਮੱਸਿਆਵਾਂ

ਲੱਛਣ:

• ਖਰੀਦਦਾਰੀ ਟੋਕਰੀ ਵਿੱਚ ਮਾਤਰਾ ਗਲਤ ਹੈ, ਕੀਮਤ ਗਲਤ ਹੈ, ਅਤੇ ਚੈੱਕਆਊਟ ਬਟਨ ਕੰਮ ਨਹੀਂ ਕਰ ਰਿਹਾ।
• ਲੌਗਇਨ ਕਰਨ ਤੋਂ ਬਾਅਦ ਮੇਰੀ ਨਹੀਂ ਵਾਲੀ ਸਮੱਗਰੀ ਦੇਖਣਾ (ਗੰਭੀਰ)

ਸਾਂਝੇ ਕਾਰਨ:

• ਕਾਰਟ, ਚੈੱਕਆਊਟ ਅਤੇ ਮਾਈ ਅਕਾਊਂਟ ਵਰਗੇ ਮੁੱਖ ਪੰਨੇ ਕੈਸ਼ ਕੀਤੇ ਜਾਂਦੇ ਹਨ।
• JS ਮਿਨੀਫਿਕੇਸ਼ਨ/ਕਨਕੈਟਨੇਸ਼ਨ ਭੁਗਤਾਨ/ਡਾਇਨਾਮਿਕ ਕੰਪੋਨੈਂਟਾਂ ਨਾਲ ਅਸੰਗਤਤਾ ਦਾ ਕਾਰਨ ਬਣਦਾ ਹੈ।

ਪਹੁੰਚ:

• WooCommerce ਅਧਿਕਾਰਕ ਤੌਰ 'ਤੇ ਦੱਸਦਾ ਹੈ ਕਿ ਸ਼ਾਪਿੰਗ ਕਾਰਟ, ਚੈੱਕਆਊਟ ਅਤੇ ਖਾਤਾ ਪੰਨੇ ਕੈਸ਼ ਨਹੀਂ ਕੀਤੇ ਜਾਣੇ ਚਾਹੀਦੇ, ਅਤੇ JavaScript ਫਾਈਲਾਂ ਦੀ ਸੰਕੋਚਨ ਤੋਂ ਬਚਣ ਦੀ ਸਿਫਾਰਸ਼ ਕਰਦਾ ਹੈ।
• ਸਭ ਤੋਂ ਪਹਿਲਾਂ “ਪੇਜ ਕੈਸ਼ਿੰਗ + ਬਾਹਰ ਰੱਖਣ” ਨੂੰ ਠੀਕ ਤਰ੍ਹਾਂ ਚਾਲੂ ਕਰੋ, ਫਿਰ ਫਰੰਟ-ਐਂਡ ਅਪਟੀਮਾਈਜ਼ੇਸ਼ਨ ਬਾਰੇ ਸੋਚੋ।
• ਜੇ ਤੁਸੀਂ WP Super Cache ਵਰਤਦੇ ਹੋ, ਤਾਂ WooCommerce ਦੱਸਦਾ ਹੈ ਕਿ ਇਹ ਮੂਲ ਰੂਪ ਵਿੱਚ ਅਨੁਕੂਲ ਹੈ ਅਤੇ ਡਿਫੌਲਟ ਤੌਰ 'ਤੇ ਮੁੱਖ ਪੰਨਿਆਂ ਨੂੰ ਕੈਸ਼ਿੰਗ ਤੋਂ ਬਾਹਰ ਰੱਖੇਗਾ।

---

ਕੇਸ 5: “Defer JS/Combine Scripts” ਚਾਲੂ ਕਰਨ ਤੋਂ ਬਾਅਦ ਮੈਨਿਊ, ਫਾਰਮ ਅਤੇ ਪੌਪ-ਅੱਪ ਠੀਕ ਤਰ੍ਹਾਂ ਕੰਮ ਨਹੀਂ ਕਰ ਰਹੇ ਸਨ।

ਲੱਛਣ:

• ਨੈਵੀਗੇਸ਼ਨ ਮੀਨੂ ਨਹੀਂ ਖੁਲ ਰਿਹਾ।
• ਫਾਰਮ ਦੀ ਵੈਰੀਫਿਕੇਸ਼ਨ ਅਸਫਲ ਹੋ ਗਈ ਹੈ ਜਾਂ ਫਾਰਮ ਸਬਮਿਟ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ।
• ਪੌਪ-ਅੱਪ/ਕਾਰੋਸਲ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ
• ਸਟੈਟਿਸਟਿਕਸ/ਕਨਵਰਜ਼ਨ ਈਵੈਂਟਸ ਟ੍ਰਿਗਰ ਨਹੀਂ ਹੋ ਰਹੇ (ਪ੍ਰਕਾਸ਼ਕਾਂ ਲਈ ਸਭ ਤੋਂ ਵੱਡੀ ਸਿਰਦਰਦ)

ਸਾਂਝੇ ਕਾਰਨ:

• ਜਾਵਾਸਕ੍ਰਿਪਟ ਦੇ ਬਦਲਾਅ ਨੂੰ ਲਾਗੂ ਹੋਣ ਵਿੱਚ ਦੇਰੀ ਕਰਨਾ: ਸਕ੍ਰਿਪਟ ਉਦੋਂ ਤੱਕ ਨਹੀਂ ਚਲਦੀ ਜਦ ਤੱਕ ਉਪਭੋਗਤਾ ਇਸ ਨਾਲ ਇੰਟਰੈਕਟ ਨਹੀਂ ਕਰਦਾ, ਜਦਕਿ ਕੁਝ ਹਿੱਸੇ ਪੰਨਾ ਲੋਡ ਹੁੰਦੇ ਹੀ ਸ਼ੁਰੂ ਹੋਣ “ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ।”
• ਮਿਲਾਉਣ ਜਾਂ ਸੰਕੁਚਿਤ ਕਰਨ ਨਾਲ ਸਕ੍ਰਿਪਟਾਂ ਦਾ ਕ੍ਰਮ ਬਦਲ ਸਕਦਾ ਹੈ ਜਾਂ ਨਿਰਭਰਤਾਵਾਂ ਟੁੱਟ ਸਕਦੀਆਂ ਹਨ।

WP Rocket ਅਧਿਕਾਰਕ ਤੌਰ “ਤੇ ”JS ਚਲਾਉਣ ਦੀ ਟਾਲ' ਨੂੰ ਆਪਣੀਆਂ ਸਭ ਤੋਂ ਸ਼ਕਤੀਸ਼ਾਲੀ JS ਅਨੁਕੂਲਨ ਵਿਧੀਆਂ ਵਿੱਚੋਂ ਇੱਕ ਵਜੋਂ ਵਰਣਨ ਕਰਦਾ ਹੈ: ਸਕ੍ਰਿਪਟਾਂ ਨੂੰ ਯੂਜ਼ਰ ਦੀ ਇੰਟਰੈਕਸ਼ਨ ਤੱਕ ਰੋਕਿਆ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਜੋ ਪੰਨਾ ਪਹਿਲਾਂ ਰੈਂਡਰ ਹੋ ਸਕੇ। ਇਹ ਇੱਕ ਸ਼ਕਤੀਸ਼ਾਲੀ ਫੀਚਰ ਹੈ, ਪਰ ਇਸ ਨਾਲ ਅਨੁਕੂਲਤਾ ਸੰਬੰਧੀ ਸਮੱਸਿਆਵਾਂ ਦਾ ਵੱਧ ਖਤਰਾ ਵੀ ਹੁੰਦਾ ਹੈ।

ਪਹੁੰਚ:

• ਪੜਾਵਾਂ ਵਿੱਚ ਲਾਗੂ ਕਰੋ: ਪਹਿਲਾਂ ਕੈਸ਼, ਫਿਰ ਚਿੱਤਰ, ਫਿਰ CSS, ਅਤੇ ਆਖ਼ਿਰ ਵਿੱਚ JavaScript
• ਮੁੱਖ ਸਕ੍ਰਿਪਟਾਂ ਨੂੰ ਬਾਹਰ ਰੱਖੋ (ਭੁਗਤਾਨ, ਫਾਰਮ, ਮੀਨੂ, ਟ੍ਰੈਕਿੰਗ)
• ਹਰ ਬਦਲਾਅ ਲਈ ਇੱਕ ਰਿਗ੍ਰੈਸ਼ਨ ਟੈਸਟ ਚੈੱਕਲਿਸਟ ਤਿਆਰ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ।

---

ਕੇਸ 6: ਮੈਂ ਸਿਰਫ਼ LiteSpeed Cache ਇੰਸਟਾਲ ਕੀਤਾ ਹੈ, ਪਰ ਇਹ ਜ਼ਿਆਦਾ ਕੁਝ ਨਹੀਂ ਕਰ ਰਿਹਾ।

ਲੱਛਣ:

• ਮੈਂ LiteSpeed Cache ਚਾਲੂ ਕਰ ਦਿੱਤਾ ਹੈ, ਪਰ TTFB ਵਿੱਚ ਬਹੁਤ ਸੁਧਾਰ ਨਹੀਂ ਆਇਆ।
• ਹਿੱਟ ਦਰ ਵੀ ਖਾਸ ਤੌਰ 'ਤੇ ਉੱਚੀ ਨਹੀਂ ਹੈ।

ਸਾਂਝੇ ਕਾਰਨ:

• ਤੁਹਾਡਾ ਸਰਵਰ LiteSpeed ਜਾਂ OpenLiteSpeed 'ਤੇ ਨਹੀਂ ਚੱਲ ਰਿਹਾ, ਇਸ ਲਈ ਤੁਸੀਂ LSCache ਦੀਆਂ ਮੁੱਖ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰ ਸਕਦੇ।
• ਜਾਂ ਸ਼ਾਇਦ ਤੁਸੀਂ ਬਹੁਤ ਸਾਰੀਆਂ ਅਨੁਕੂਲਤਾਵਾਂ ਚਾਲੂ ਕਰ ਲਈਆਂ ਹਨ, ਪਰ “ਪੇਜ ਕੈਸ਼ ਨੀਤੀ/ਪ੍ਰੀਹੀਟਿੰਗ/ਬਾਹਰ ਰੱਖਣ ਵਾਲੀਆਂ ਚੀਜ਼ਾਂ” ਸੈੱਟਅੱਪ ਨਹੀਂ ਕੀਤੀਆਂ ਗਈਆਂ।

ਪਹੁੰਚ:

• ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਵੈੱਬ ਸਰਵਰ ਸਟੈਕ ਦੀ ਜਾਂਚ ਕਰੋ: ਕੀ ਇਹ LiteSpeed ਹੈ ਜਾਂ OpenLiteSpeed? (ਇਹ ਇੱਕ ਪੂਰਵ-ਸ਼ਰਤ ਹੈ।)
• ਪੰਨਾ ਕੈਸ਼ਿੰਗ ਰਣਨੀਤੀਆਂ + ਪ੍ਰੀਲੋਡਿੰਗ + ਸਮੱਸਿਆ-ਨਿਵਾਰਣ + ਅਨੁਕੂਲਨ “ਤੇ ਕੋਸ਼ਿਸ਼ਾਂ ਨੂੰ ਮੁੜ ਕੇਂਦਰਿਤ ਕਰੋ।”
• ਜੇ ਤੁਸੀਂ LiteSpeed ਹੋਸਟਿੰਗ ਨਹੀਂ ਵਰਤ ਰਹੇ ਹੋ: WP Rocket ਜਾਂ WP Super Cache ਬਾਰੇ ਸੋਚੋ।