ਜੇ ਅਸੀਂ ਵਰਡਪ੍ਰੈੱਸ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਸੁਧਾਰ ਨੂੰ ਤਿੰਨ ਪਰਤਾਂ ਵਿੱਚ ਵੰਡੀਏ:
- ਮੂਲ ਸਰਵਰ ਪਰਤ: ਸਰਵਰ / PHP / ਡੇਟਾਬੇਸ / ਕੈਸ਼ਿੰਗ ਪਲੱਗਇਨ —— TTFB ਅਤੇ ਬੈਕਐਂਡ ਲੋਡ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ
- ਸਰੋਤ ਪਰਤ: ਚਿੱਤਰ ਅਨੁਕੂਲਨ — ਪਹਿਲੀ ਸਕ੍ਰੀਨ 'ਤੇ ਵੱਡੀਆਂ ਚਿੱਤਰਾਂ ਦੀ ਡਾਊਨਲੋਡ ਆਕਾਰ ਅਤੇ ਲੋਡ ਹੋਣ ਦੀ ਗਤੀ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ
- ਡਿਲਿਵਰੀ ਪਰਤ: CDN — ਸਰੋਤਾਂ ਨੂੰ ਉਪਭੋਗਤਾਵਾਂ ਦੇ ਨੇੜੇ ਲਿਆਉਣਾ, ਵਧੇਰੇ ਭਰੋਸੇਯੋਗ ਹਿੱਟਾਂ, ਅਤੇ ਮੂਲ ਸਰਵਰ 'ਤੇ ਘੱਟ ਬੋਝ
ਇਹ ਲੇਖ ਚਰਚਾ ਕਰਦਾ ਹੈ CDN ਤੇਜ਼ੀ:
- CDN ਕੀ ਹੱਲ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਕੀ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਇਹ ਸਮਝਣਾ
- ਆਪਣੇ ਲਈ ਸਭ ਤੋਂ ਵਧੀਆ CDN ਯੋਜਨਾ ਅਤੇ ਪ੍ਰਦਾਤਾ ਚੁਣੋ (ਅਤੇ ਮੁਫ਼ਤ ਅਤੇ ਸਟਾਰਟਰ ਸੰਸਕਰਣਾਂ ਵਿਚਕਾਰ ਅੰਤਰ ਨੂੰ ਸਮਝੋ)
- ਸਭ ਤੋਂ ਘੱਟ ਜੋਖਮ ਦੇ ਕ੍ਰਮ ਵਿੱਚ ਤੈਨਾਤ ਕਰੋ, ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦੇ ਹੋਏ ਕਿ ਸਾਈਟ ਕਰੈਸ਼ ਨਾ ਹੋਵੇ ਅਤੇ ਈ-ਕਾਮਰਸ ਜਾਂ ਮੈਂਬਰ ਕੈਸ਼ਿੰਗ ਨਾਲ ਕੋਈ ਸਮੱਸਿਆ ਨਾ ਆਵੇ।
- ਇੱਕ ਵਾਰ ਤੈਨਾਤ ਹੋਣ “ਤੇ, ਅਸੀਂ ਇਹ ਪੁਸ਼ਟੀ ਕਰ ਸਕਦੇ ਹਾਂ ਕਿ ਇਹ ਵਾਕਈ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ ਅਤੇ ਜਾਂਚ ਕਰ ਸਕਦੇ ਹਾਂ ਕਿ ਇਹ ਕਿਉਂ ਅਪਡੇਟ ਨਹੀਂ ਹੋਇਆ, ਕਿਉਂ ਇਹ ਹੌਲੀ ਚੱਲ ਰਿਹਾ ਹੈ, ਜਾਂ ਸਮੱਗਰੀ ਕਿਉਂ ਕ੍ਰਮ ਤੋਂ ਬਾਹਰ ਹੈ।”
1. ਆਓ ਧਾਰਨਾ ਨੂੰ ਸਪੱਸ਼ਟ ਕਰਕੇ ਸ਼ੁਰੂ ਕਰੀਏ: CDN ਕੀ ਸੰਬੋਧਿਤ ਕਰਦਾ ਹੈ ਅਤੇ ਕੀ ਨਹੀਂ।
1.1 CDN ਮੁੱਖ ਤੌਰ 'ਤੇ ਤਿੰਨ ਮੁੱਖ ਮੁੱਦਿਆਂ ਨੂੰ ਸੰਬੋਧਿਤ ਕਰਦਾ ਹੈ।
1.1.1 ਸਥਿਰ ਸਰੋਤਾਂ ਦੀ ਤੇਜ਼ ਡਿਲੀਵਰੀ
ਚਿੱਤਰ, CSS, JavaScript, ਫੌਂਟ ਅਤੇ ਆਈਕਨ ਵਰਗੀਆਂ ਸਥਿਰ ਸੰਸਾਧਨਾਂ ਨੂੰ ਵਿਜ਼ਿਟਰ ਦੇ ਨੇੜੇ ਸਰਵ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਡਾਊਨਲੋਡ ਸਮਾਂ ਤੇਜ਼ ਹੁੰਦਾ ਹੈ ਅਤੇ ਪੰਨਾ ਹੋਰ ਸਥਿਰ ਢੰਗ ਨਾਲ ਰੈਂਡਰ ਹੁੰਦਾ ਹੈ।
WordPress ਲਈ, ਖਾਸ ਕਰਕੇ ਜਦੋਂ ਥੀਮਾਂ ਅਤੇ ਪਲੱਗਇਨਾਂ ਦੀ ਗੱਲ ਆਉਂਦੀ ਹੈ (wp-content/themes/、wp-content/plugins/) ਅਤੇ ਮੀਡੀਆ ਲਾਇਬ੍ਰੇਰੀ ਤੋਂ ਤਸਵੀਰਾਂ (wp-content/uploads/) ਆਮ ਤੌਰ “ਤੇ ਸਭ ਤੋਂ ਭਾਰੀ ਚੀਜ਼ਾਂ ਹੁੰਦੀਆਂ ਹਨ।
1.1.2 ਮੂਲ ਸਰਵਰ 'ਤੇ ਬੋਝ ਘਟਾਉਣਾ
ਜਦੋਂ ਕੋਈ ਬੇਨਤੀ ਐਜ ਕੈਸ਼ ਤੱਕ ਪਹੁੰਚ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਵਾਰ-ਵਾਰ ਮੂਲ ਸਰਵਰ ਤੋਂ ਡਾਟਾ ਲੈਣ ਦੀ ਲੋੜ ਨਹੀਂ ਰਹਿੰਦੀ, ਜਿਸ ਨਾਲ ਮੂਲ ਸਰਵਰ ਦੀ ਬੈਂਡਵਿਡਥ, ਸਮਵਰਤੀ ਕਨੈਕਸ਼ਨਾਂ, ਡਿਸਕ I/O ਅਤੇ CPU ਉਤਾਰ-ਚੜ੍ਹਾਵਾਂ 'ਤੇ ਦਬਾਅ ਘੱਟ ਹੁੰਦਾ ਹੈ।
ਇਹ ਖਾਸ ਤੌਰ “ਤੇ ਚਰਮ ਸਥਿਤੀਆਂ ਵਿੱਚ ਸਪਸ਼ਟ ਹੁੰਦਾ ਹੈ, ਜਿਵੇਂ ਕਿ ”ਅਭਿਆਨ ਪੰਨੇ, ਵਾਇਰਲ ਲੇਖ ਅਤੇ ਉਤਪਾਦ ਪੰਨੇ ਜਿਨ੍ਹਾਂ ਨੂੰ ਉੱਚ ਮਾਤਰਾ ਵਿੱਚ ਟ੍ਰੈਫਿਕ ਮਿਲਦਾ ਹੈ'।
1.1.3 ਸਥਿਰਤਾ ਵਿੱਚ ਸੁਧਾਰ (��ਫ਼ਲਕਤਾਂ ਪ੍ਰਤੀ ਵਧੇਰੇ ਲਚਕੀਲਾਪਣ)
ਟ੍ਰੈਫਿਕ ਦੇ ਸਿਖਰ ਦੌਰਾਨ, ਐਜ ਨੋਡ ਵੱਡੀ ਮਾਤਰਾ ਵਿੱਚ ਨਕਲ ਕੀਤੀਆਂ ਬੇਨਤੀਆਂ ਨੂੰ ਸੋਖ ਲੈਂਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਮੂਲ ਸਰਵਰ ਦੇ ਓਵਰਲੋਡ ਹੋਣ ਦੀ ਸੰਭਾਵਨਾ ਘੱਟ ਹੋ ਜਾਂਦੀ ਹੈ।
ਤੁਸੀਂ “ਸਮੂਦਰ ਪਹੁੰਚ” ਮਹਿਸੂਸ ਕਰੋਗੇ: ਭਾਵੇਂ ਮੂਲ ਸਰਵਰ 'ਤੇ ਟ੍ਰੈਫਿਕ ਵਿੱਚ ਅਚਾਨਕ ਵਾਧਾ ਹੋ ਜਾਵੇ, ਐਜ ਕੈਸ਼ ਸਮੱਗਰੀ ਸਰਵ ਕਰਨਾ ਜਾਰੀ ਰੱਖੇਗਾ।
1.2 ਤਿੰਨ ਤਰ੍ਹਾਂ ਦੇ ਮੁੱਦੇ ਜਿਨ੍ਹਾਂ ਨੂੰ CDN ਆਪਣੇ ਆਪ ਹੱਲ ਨਹੀਂ ਕਰ ਸਕਦਾ
1.2.1 ਮੂਲ ਸਰਵਰ ਖੁਦ ਹੀ ਹੌਲੀ ਹੈ
ਡੇਟਾਬੇਸ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਹੌਲੀ, ਪਲੱਗਇਨ ਦੀ ਲੋਜਿਕ ਹੌਲੀ, PHP ਦੀਆਂ ਗਣਨਾਵਾਂ ਹੌਲੀ — ਇਹ ਮੂਲ ਸਰਵਰ ਪੱਧਰ 'ਤੇ ਮਸਲੇ ਹਨ।
CDN ਸਥਿਰ ਸਰੋਤਾਂ ਦੀ ਗਤੀ ਵਧਾ ਸਕਦਾ ਹੈ, ਪਰ ਜੇ ਹੋਮਪੇਜ ਦਾ HTML ਤਿਆਰ ਕਰਨ ਵਿੱਚ ਵੀ ਲੰਮਾ ਸਮਾਂ ਲੱਗੇ, ਤਾਂ ਵਰਤੋਂਕਾਰ ਫਿਰ ਵੀ ਸੋਚਣਗੇ ਕਿ ਸਾਈਟ “ਲੋਡ ਹੋਣ ਵਿੱਚ ਹੌਲੀ” ਹੈ। ਇਸ ਹਾਲਤ ਵਿੱਚ, ਤੁਹਾਨੂੰ ਇਹਨਾਂ ਨੂੰ ਤਰਜੀਹ ਦੇਣੀ ਚਾਹੀਦੀ ਹੈ: ਹੋਸਟਿੰਗ / ਕੈਸ਼ਿੰਗ ਪਲੱਗਇਨ / ਡੇਟਾਬੇਸ ਅਪਟੀਮਾਈਜੇਸ਼ਨ।
1.2.2 ਤਸਵੀਰ ਆਪਣੇ ਆਪ ਵਿੱਚ ਬਹੁਤ ਵੱਡੀ ਹੈ
CDN ਵੱਡੀ ਤਸਵੀਰ 3MB ਨੂੰ ਜਾਦੂ ਨਾਲ ਛੋਟੀ ਨਹੀਂ ਕਰ ਸਕਦਾ।
ਤੁਹਾਨੂੰ ਆਪਣੀਆਂ ਤਸਵੀਰਾਂ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਉਣ ਨਾਲ ਸ਼ੁਰੂਆਤ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ: ਆਕਾਰ ਪ੍ਰਬੰਧਨ (ਬਹੁਤ ਵੱਡੀਆਂ ਤਸਵੀਰਾਂ ਡਾਊਨਲੋਡ ਕਰਨ ਤੋਂ ਬਚੋ), ਕੰਪਰੈਸ਼ਨ, WebP/AVIF, ਲੇਜ਼ੀ ਲੋਡਿੰਗ ਰਣਨੀਤੀਆਂ, ਆਦਿ।
1.2.3 ਹੌਲੀ ਤੀਜੀ-ਧਿਰ ਦੀਆਂ ਸਕ੍ਰਿਪਟਾਂ
ਇਸ਼ਤਿਹਾਰਬਾਜ਼ੀ, ਵਿਸ਼ਲੇਸ਼ਣ, ਗਾਹਕ ਸੇਵਾ ਅਤੇ ਸੋਸ਼ਲ ਮੀਡੀਆ ਦੇ ਘਟਕ ਆਦਿ ਤੀਜੀ-ਪੱਖੀ ਡੋਮੇਨਾਂ ਤੋਂ ਆਉਂਦੇ ਹਨ।
CDN ਆਮ ਤੌਰ “ਤੇ ਉਹਨਾਂ ਨੂੰ ਤੇਜ਼ ਨਹੀਂ ਕਰ ਸਕਦਾ; ਤੁਸੀਂ ਸਿਰਫ਼ ਲੋਡ ਘਟਾ ਕੇ ਜਾਂ ਲੋਡਿੰਗ ਨੂੰ ਮੁਲਤਵੀ ਕਰਕੇ, ਸਪਲਾਇਰ ਬਦਲ ਕੇ, ਜਾਂ ਸਕ੍ਰਿਪਟ ਨੀਤੀਆਂ ਨੂੰ ਅਨੁਕੂਲਿਤ ਕਰਕੇ ਹੀ ਇਸਨੂੰ ਹੱਲ ਕਰ ਸਕਦੇ ਹੋ।
ਸਿਫ਼ਾਰਸ਼ਾਂ
ਜੇ ਤੁਸੀਂ ਪਹਿਲਾਂ ਓਰਿਜਿਨ ਸਰਵਰ ਲੇਅਰ ਅਤੇ ਰਿਸੋਰਸ ਲੇਅਰ ਨੂੰ ਠੀਕ ਕਰ ਲੈਂਦੇ ਹੋ, ਫਿਰ CDN 'ਤੇ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ, ਤਾਂ ਨਤੀਜੇ ਹੋਰ ਵਧੇਰੇ ਸਪਸ਼ਟ ਹੋਣਗੇ ਅਤੇ ਸਮੱਸਿਆਵਾਂ ਘੱਟ ਹੋਣਗੀਆਂ।
2. 30-ਸਕਿੰਟ ਗਾਈਡ: ਤੁਹਾਨੂੰ ਕਿਹੜੀ CDN ਕੌਂਫਿਗਰੇਸ਼ਨ ਦੀ ਲੋੜ ਹੈ?
ਜਦੋਂ ਗੱਲ WordPress ਦੀ ਆਉਂਦੀ ਹੈ, ਤਾਂ ਦੋ ਮੁੱਖ ਸ਼੍ਰੇਣੀਆਂ ਹੁੰਦੀਆਂ ਹਨ। ਜੇ ਤੁਸੀਂ ਪਹਿਲਾਂ “ਕਿਸਮ” ਚੁਣੋ ਅਤੇ ਫਿਰ “ਪ੍ਰਦਾਤਾ”, ਤਾਂ ਇਹ ਪ੍ਰਕਿਰਿਆ ਬਹੁਤ ਸਪਸ਼ਟ ਹੋ ਜਾਵੇਗੀ।
2.1 ਏਕੀਕ੍ਰਿਤ “ਰਿਵਰਸ ਪ੍ਰਾਕਸੀ” ਕਿਸਮ (ਵਧੇਰੇ ਬਿਨਾਂ ਝੰਝਟ, ਜ਼ਿਆਦਾਤਰ ਵੈੱਬਸਾਈਟਾਂ ਲਈ ਢੁਕਵਾਂ)
**特点:**它不仅是 CDN,还把 DNS / SSL / ਬੁਨਿਆਦੀ ਸੁਰੱਖਿਆ ਸੁਰੱਖਿਆ (ਜਿਵੇਂ ਕਿ DDoS/WAF) ਇੱਕੱਠੇ ਪੈਕੇਜ ਕੀਤਾ ਗਿਆ। ਇੱਕ ਵਾਰੀ ਜਦੋਂ ਤੁਸੀਂ ਇਸਨੂੰ ਇੰਟੀਗ੍ਰੇਟ ਕਰ ਲੈਂਦੇ ਹੋ, ਇਹ ਤੁਹਾਡੀ ਵੈਬਸਾਈਟ ਦੇ ਸਾਹਮਣੇ ਇੱਕ ਪ੍ਰਾਕਸੀ ਵਜੋਂ ਕੰਮ ਕਰਦਾ ਹੈ।
ਤੁਹਾਨੂੰ ਕੀ ਮਿਲੇਗਾ:
- HTTPS ਨਾਲ ਸਰਟੀਫਿਕੇਟ ਅਤੇ TLS ਦਾ ਸੌਖਾ ਪ੍ਰਬੰਧਨ
- ਇੱਕ ਏਕੀਕ੍ਰਿਤ ਸੁਰੱਖਿਆ ਗੇਟਵੇ (ਮੂਲ DDoS ਸੁਰੱਖਿਆ, ਪਹੁੰਚ ਨਿਯੰਤਰਣ, WAF, ਆਦਿ)
- ਐਜ ਕੈਸ਼ਿੰਗ ਅਤੇ ਰੂਲ ਇੰਜਣ (ਵਧੇਰੇ ਬਾਰੀਕ ਕੈਸ਼ਿੰਗ ਰਣਨੀਤੀਆਂ ਅਤੇ ਬਾਈਪਾਸ ਨਿਯਮਾਂ ਨੂੰ ਸਮਰੱਥ ਬਣਾਉਂਦਾ ਹੈ)
- “ਵਧੇਰੇ ਪੈਮਾਨੇਯੋਗਤਾ”: ਜੇ ਤੁਸੀਂ ਭਵਿੱਖ ਵਿੱਚ ਸੁਰੱਖਿਆ, ਗਤੀ ਸੀਮਾਵਾਂ ਜਾਂ ਬੋਟ ਸੁਰੱਖਿਆ ਸ਼ਾਮਲ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਇਹਨਾਂ ਨੂੰ ਆਮ ਤੌਰ 'ਤੇ ਉਸੇ ਸਿਸਟਮ ਵਿੱਚ ਏਕੀਕ੍ਰਿਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
ਨੁਮਾਇੰਦੇ: Cloudflare / Tencent Cloud International EdgeOne / Alibaba Cloud International ESA
ਜੇ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ:
- ਤੁਸੀਂ ਆਸ ਕਰਦੇ ਹੋ ਕਿ HTTPS + CDN + ਬੁਨਿਆਦੀ ਸੁਰੱਖਿਆ ਇੱਕੋ ਵਾਰੀ ਸਭ ਕੁਝ
- ਕੀ ਤੁਸੀਂ ਆਪਣੇ ਡੋਮੇਨ ਨਾਮ ਰੈਜ਼ੋਲੂਸ਼ਨ ਅਤੇ ਪ੍ਰਾਕਸੀ ਪਰਤਾਂ ਦੇ ਪ੍ਰਬੰਧਨ ਨੂੰ ਇੱਕ ਹੀ ਪਲੇਟਫਾਰਮ ਨੂੰ ਸੌਂਪਣ ਲਈ ਤਿਆਰ ਹੋ?
- ਤੁਸੀਂ “ਕੁੱਲ ਅਨੁਭਵ ਅਤੇ ਭਵਿੱਖੀ ਵਿਸਥਾਰਯੋਗਤਾ” 'ਤੇ ਵੱਧ ਜ਼ੋਰ ਦਿੰਦੇ ਹੋ, ਅਤੇ DNS, ਸਰਟੀਫਿਕੇਟ, CDN ਅਤੇ ਸੁਰੱਖਿਆ ਨੂੰ ਕਈ ਸੈੱਟਾਂ ਵਿੱਚ ਵੰਡਣਾ ਨਹੀਂ ਚਾਹੁੰਦੇ।
2.2 ਸ਼ੁੱਧ “ਸਟੈਟਿਕ ਪੁੱਲ CDN” (ਘੱਟ-ਜੋਖਮ ਵਾਲੀ ਸ਼ੁਰੂਆਤੀ ਬਿੰਦੂ, ਮੁੱਖ ਤੌਰ 'ਤੇ ਚਿੱਤਰਾਂ/CSS/JS ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਉਂਦਾ ਹੈ)
ਖਾਸੀਅਤ: ਤੁਸੀਂ ਸਿਰਫ਼ ਸਟੈਟਿਕ ਰਸੋਂਸ ਨੂੰ CDN ਐੱਜ ਕੈਸ਼ ਵਿੱਚ ਪਾਉਂਦੇ ਹੋ; HTML ਪੰਨੇ ਹਾਲੇ ਵੀ ਸਰੋਤ ਸਟੈਸ਼ਨ (ਅਤੇ ਸਰੋਤ ਸਟੈਸ਼ਨ ਕੈਸ਼ ਪਲਗਿਨ) ਦੁਆਰਾ ਸੰਭਾਲੇ ਜਾਂਦੇ ਹਨ।
ਤੁਹਾਨੂੰ ਕੀ ਮਿਲੇਗਾ:
- ਬਹੁਤ ਘੱਟ ਸੰਚਾਲਨ ਜੋਖਮ: ਜੇ ਤੁਸੀਂ HTML ਨੂੰ ਛੇੜਦੇ ਨਹੀਂ, ਤਾਂ ਸਮੱਗਰੀ ਜਾਂ ਖਰੀਦਦਾਰੀ ਟੋਕਰੀ ਦੇ ਡੇਟਾ ਦੇ ਮਿਲਣ-ਜੁਲਣ ਦਾ ਲਗਭਗ ਕੋਈ ਖਤਰਾ ਨਹੀਂ।“
- ਲਾਗਤ ਮਾਡਲ ਵਧੇਰੇ ਸਹਿਜ ਹੈ: ਬਿਲਿੰਗ ਆਮ ਤੌਰ 'ਤੇ ਟ੍ਰੈਫਿਕ, ਬੇਨਤੀਆਂ ਜਾਂ ਖੇਤਰ ਦੇ ਆਧਾਰ 'ਤੇ ਹੁੰਦੀ ਹੈ।
- ਇੱਕ ਸਧਾਰਨ ਆਰਕੀਟੈਕਚਰ: ਇੱਕ “ਸਥਿਰ ਸਰੋਤ ਡਿਲਿਵਰੀ ਸੇਵਾ” ਦੇ ਵਧੇਰੇ ਸਮਾਨ”
ਪ੍ਰਤੀਨਿਧੀ: bunny.net (ਸਾਫ਼ ਵਰਤੋਂ-ਅਨੁਸਾਰ ਭੁਗਤਾਨ ਮਾਡਲ)
ਜੇ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ:
- ਤੁਸੀਂ “ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਵਿਕਲਪ” ਨਾਲ ਸ਼ੁਰੂਆਤ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ—ਸਥਿਰ ਸਰੋਤਾਂ ਨੂੰ ਤੇਜ਼ ਕਰਨਾ
- ਕੀ ਤੁਸੀਂ ਪ੍ਰਾਕਸੀ-ਅਧਾਰਿਤ ਜਾਂ ਪੂਰੀ-ਸਾਈਟ ਕੈਸ਼ਿੰਗ ਵਿੱਚੋਂ ਕਿਸੇ ਇੱਕ ਨੂੰ ਚੁਣਨ ਤੋਂ ਪਹਿਲਾਂ ਆਪਣੀ ਨਿਵੇਸ਼ 'ਤੇ ਤੇਜ਼ ਵਾਪਸੀ ਦੇਖਣਾ ਚਾਹੁੰਦੇ ਹੋ?
- ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਖਰਚੇ “ਪੇ-ਐਜ਼-ਯੂ-ਗੋ” ਮਾਡਲ ਦੇ ਨੇੜੇ ਹੋਣ।”
3. ਇਹ ਕਿਵੇਂ ਕਰਨਾ ਹੈ
- ਪੱਧਰ 1: ਏਕੀਕ੍ਰਿਤ ਏਜੰਸੀ ਮਾਡਲ (ਤਰਜੀਹੀ): ਕਲਾਊਡਫਲੇਅਰ / ਐਜਵਨ / ਈ.ਐਸ.ਏ.
- ਪੱਧਰ 2: ਸਟੈਟਿਕ ਪੁੱਲ CDN (ਇੱਕ ਸੁਰੱਖਿਅਤ ਸ਼ੁਰੂਆਤ): bunny.net / Cloudways / CDN, ਆਦਿ।
4. ਸਿਫ਼ਾਰਸ਼ ਕੀਤੇ ਸੇਵਾ ਪ੍ਰਦਾਤਾ
4.1 ਕਲਾਊਡਫਲੇਅਰ: ਏਕੀਕ੍ਰਿਤ ਰਿਵਰਸ ਪ੍ਰਾਕਸੀ (ਸ਼ੁਰੂ ਕਰਨ ਲਈ ਮੁਫ਼ਤ, ਵਿਕਸਤ ਈਕੋਸਿਸਟਮ)

ਇਹ ਕੀ ਹੈ?
ਜਦੋਂ ਤੁਸੀਂ ਆਪਣਾ ਡੋਮੇਨ ਕਨੈਕਟ ਕਰ ਲੈਂਦੇ ਹੋ, ਤਾਂ ਇਹ ਤੁਹਾਡੀ ਵੈਬਸਾਈਟ ਦੇ ਸਾਹਮਣੇ ਇੱਕ ਪ੍ਰਾਕਸੀ ਸਰਵਰ ਵਜੋਂ ਕੰਮ ਕਰਦਾ ਹੈ, ਜੋ CDN, ਸਰਟੀਫਿਕੇਟ, ਬੁਨਿਆਦੀ ਸੁਰੱਖਿਆ ਸੁਰੱਖਿਆ ਅਤੇ ਕੈਸ਼ਿੰਗ ਨਿਯਮ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।
ਇਹ ਕਿਸ ਲਈ ਹੈ?
- ਬਿਨਾਂ ਕਿਸੇ ਪਰੇਸ਼ਾਨੀ ਦੇ ਹੱਲ ਦੀ ਤਲਾਸ਼: HTTPS + CDN + ਵਿਆਪਕ ਬੁਨਿਆਦੀ ਸੁਰੱਖਿਆ ਪੈਕੇਜ
- ਇੱਕ ਪਰਿਪੱਕ ਈਕੋਸਿਸਟਮ ਬਣਾਉਣ ਲਈ: ਸਾਨੂੰ WAF, ਰੇਟ-ਲਿਮਿਟਿੰਗ, ਐਜ ਨਿਯਮ ਆਦਿ ਸ਼ਾਮਲ ਕਰਨੇ ਪੈਣਗੇ; ਅੱਗੇ ਦਾ ਰਸਤਾ ਸਾਫ਼ ਹੈ।
ਖਤਰੇ ਦੇ ਕਾਰਕ
- ਅੱਪਡੇਟ ਲਾਗੂ ਨਹੀਂ ਹੋਇਆ ਹੈ।CDN ਦੀ ਤੈਨਾਤੀ ਤੋਂ ਬਾਅਦ, ਕੈਸ਼ਿੰਗ ਚੇਨ ਲੰਬੀ ਹੋ ਗਈ ਹੈ (ਬ੍ਰਾਊਜ਼ਰ ਕੈਸ਼ + CDN ਕੈਸ਼ + ਮੂਲ ਸਰਵਰ ਕੈਸ਼); ਨਿਯੰਤਰਿਤ ਅੱਪਡੇਟਾਂ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਇੱਕ “ਵਰਜਨ ਨੀਤੀ” ਦੀ ਲੋੜ ਹੈ (ਹੇਠਾਂ ਦਿੱਤਾ ਗਿਆ ਸਮੱਸਿਆ-ਨਿਪਟਾਰਾ ਟ੍ਰੀ)
- HTML ਨੂੰ ਕੈਸ਼ ਕਰਦੇ ਸਮੇਂ ਸਾਵਧਾਨੀ ਵਰਤੋ।ਜੇ HTML ਕੈਸ਼ ਕੀਤਾ ਗਿਆ ਹੈ, ਤਾਂ ਈ-ਕਾਮਰਸ, ਮੈਂਬਰ ਅਤੇ ਵਿਅਕਤੀਗਤ ਪੰਨਿਆਂ ਨੂੰ ਸਖ਼ਤੀ ਨਾਲ ਬਾਹਰ ਰੱਖਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ; ਨਹੀਂ ਤਾਂ ਗੰਭੀਰ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਹੋ ਸਕਦੀਆਂ ਹਨ (ਹੇਠਾਂ ਦਿੱਤੀ ਸਥਿਤੀਆਂ ਦੀ ਸੂਚੀ ਵੇਖੋ)।
ਨੋਟਸ:
- ਕੌਂਫਿਗਰੇਸ਼ਨ: ਏਕੀਕ੍ਰਿਤ ਰਿਵਰਸ ਪ੍ਰਾਕਸੀ (SSL + CDN + ਬੁਨਿਆਦੀ ਸੁਰੱਖਿਆ)
- ਇਹ ਉਚਿਤ ਹੈ: ਬਿਨਾਂ ਕਿਸੇ ਪਰੇਸ਼ਾਨੀ ਦੇ ਸ਼ੁਰੂਆਤ ਲਈ, ਭਵਿੱਖ ਵਿੱਚ ਵਿਸਥਾਰ ਲਈ ਕਾਫੀ ਸੰਭਾਵਨਾਵਾਂ ਨਾਲ
- ਮੁੱਖ ਮੁੱਲ: ਸਰਟੀਫਿਕੇਟਾਂ, ਸੁਰੱਖਿਆ ਅਤੇ ਕੈਸ਼ਿੰਗ ਲਈ ਇੱਕਸਾਰ ਐਂਟਰੀ ਪੁਆਇੰਟ
- ਖਤਰਾ: ਅੱਪਡੇਟ ਵਰਜਨਿੰਗ ਨੀਤੀਆਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ; HTML ਕੈਸ਼ਿੰਗ ਨੂੰ ਸਖ਼ਤੀ ਨਾਲ ਬਾਈਪਾਸ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।
4.2 ਟੈਂਸੈਂਟ ਕਲਾਊਡ ਇੰਟਰਨੈਸ਼ਨਲ ਐਜਵਨਏਕੀਕ੍ਰਿਤ ਰਿਵਰਸ ਪ੍ਰਾਕਸੀ

ਇਹ ਕੀ ਹੈ?
ਇਹ ਪਲੇਟਫਾਰਮ ਵੀ “ਤੇਜ਼ੀ + ਸੁਰੱਖਿਆ + ਸਰਟੀਫਿਕੇਟ” ਇਕੀਕ੍ਰਿਤ ਮਾਡਲ ਦੀ ਪਾਲਣਾ ਕਰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਇਹ ਇੱਕ ਏਕੀਕ੍ਰਿਤ ਪ੍ਰਾਕਸੀ ਪਰਤ ਰਾਹੀਂ ਵੈੱਬਸਾਈਟਾਂ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨ ਲਈ ਆਦਰਸ਼ ਬਣ ਜਾਂਦਾ ਹੈ।
- Cloudflare ਵਾਂਗ, ਇਹ ਇੱਕ ਮੁਫ਼ਤ ਸੰਸਕਰਣ ਪੇਸ਼ ਕਰਦਾ ਹੈ, ਪਰ ਆਮ ਤੌਰ 'ਤੇ ਕੋਟਾ/ਕਾਰਜਕਾਰੀ ਸੀਮਾ(ਨਿਯਮਾਂ ਦੀ ਗਿਣਤੀ, ਲੌਗ ਟਾਸਕਾਂ ਦੀ ਗਿਣਤੀ, ਆਦਿ), ਪਰ DNS ਨੂੰ ਸੋਧਣ ਦੀ ਕੋਈ ਲੋੜ ਨਹੀਂ; ਸਿਰਫ CNAME ਰਿਕਾਰਡ ਨੂੰ ਕੌਂਫਿਗਰ ਕਰੋ।ਵਪਾਰਕ ਵੈੱਬਸਾਈਟਾਂ ਲਈ ਮੁਫ਼ਤ ਸੰਸਕਰਣ ਦੀ ਸਿਫ਼ਾਰਸ਼ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ।!
- ਇਸੇ ਸਮੇਂ, ਮੁਫ਼ਤ ਯੋਜਨਾਵਾਂ ਦਾ ਅਕਸਰ ਮਤਲਬ ਹੁੰਦਾ ਹੈ ਐਸ.ਐਲ.ਏ. ਗਾਰੰਟੀ ਨਹੀਂ ਦਿੰਦਾ
ਇਹ ਕੰਮ ਕਰਦਾ ਹੈ, ਪਰ ਇਸਨੂੰ “ਵਪਾਰਕ SLA ਪੈਕੇਜ” ਵਾਂਗ ਨਾ ਸਮਝੋ।
- ਜੇ ਤੁਸੀਂ ਮੇਨਲੈਂਡ ਚੀਨ ਵਿੱਚ ਹੋਣ ਦੌਰਾਨ ਆਪਣੇ ਆਪ ਮੇਨਲੈਂਡ ਚੀਨ ਦੇ ਕਨੈਕਸ਼ਨ 'ਤੇ ਸਵਿੱਚ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਆਮ ਤੌਰ 'ਤੇ ਤੁਹਾਨੂੰ ਪਹਿਲਾਂ ਪੂਰਾ ਕਰਨਾ ਪੈਂਦਾ ਹੈ।ਚੀਨੀ ਆਈਸੀਪੀ ਰਜਿਸਟ੍ਰੇਸ਼ਨ; ਜੇਕਰ ਰਜਿਸਟਰਡ ਨਹੀਂ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਸਿਰਫ਼ ਅੰਤਰਰਾਸ਼ਟਰੀ ਰੂਟਾਂ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ।
ਨੋਟ:
- ਸਥਿਤੀ: ਏਕੀਕ੍ਰਿਤ ਰਿਵਰਸ ਪ੍ਰਾਕਸੀ (ਤੇਜ਼ੀ + ਸੁਰੱਖਿਆ + ਸਰਟੀਫਿਕੇਟ)
- ਉਹਨਾਂ ਲਈ ਉਚਿਤ: ਜੋ ਏਕੀਕ੍ਰਿਤ ਕਨੈਕਟੀਵਿਟੀ ਦੀ ਤਲਾਸ਼ ਕਰ ਰਹੇ ਹਨ ਅਤੇ ਮੈਨਲੈਂਡ ਚੀਨ ਵਿੱਚ ਨੋਡ ਸਮਰੱਥਾ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖ ਰਹੇ ਹਨ
- ਮੁਫ਼ਤ: ਇੱਕ ਮੁਫ਼ਤ ਯੋਜਨਾ ਜਾਂ ਮੁਫ਼ਤ ਸੰਸਕਰਣ ਉਪਲਬਧ ਹੈ, ਪਰ ਸੀਮਤ ਕੋਟਾ ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਕੋਈ SLA ਗਾਰੰਟੀ ਨਹੀਂ ਹੁੰਦੀ।
- ਖਤਰੇ: ਨਿਯਮ, ਲੌਗ ਅਤੇ ਸਬਡੋਮੇਨ ਕੋਟਾ ਪਹਿਲਾਂ ਤੋਂ ਯੋਜਨਾਬੱਧ ਕਰਨੇ ਲਾਜ਼ਮੀ ਹਨ; HTML ਕੈਸ਼ਿੰਗ ਨਾਲ ਵੀ ਸਾਵਧਾਨੀ ਬਰਤਣ ਦੀ ਲੋੜ ਹੈ।
4.3 ਅਲੀਬਾਬਾ ਕਲਾਊਡ ਇੰਟਰਨੈਸ਼ਨਲ ESAਏਕੀਕ੍ਰਿਤ ਰਿਵਰਸ ਪ੍ਰਾਕਸੀ

- Cloudflare ਵਾਂਗ, ਇਹ ਇੱਕ ਮੁਫ਼ਤ ਸੰਸਕਰਣ ਪੇਸ਼ ਕਰਦਾ ਹੈ, ਪਰ ਆਮ ਤੌਰ 'ਤੇ ਕੋਟਾ/ਕਾਰਜਕਾਰੀ ਸੀਮਾ(ਨਿਯਮਾਂ ਦੀ ਗਿਣਤੀ, ਲੌਗ ਟਾਸਕਾਂ ਦੀ ਗਿਣਤੀ, ਆਦਿ), ਪਰ DNS ਨੂੰ ਸੋਧਣ ਦੀ ਕੋਈ ਲੋੜ ਨਹੀਂ; ਸਿਰਫ CNAME ਰਿਕਾਰਡ ਨੂੰ ਕੌਂਫਿਗਰ ਕਰੋ।ਵਪਾਰਕ ਵੈੱਬਸਾਈਟਾਂ ਲਈ ਮੁਫ਼ਤ ਸੰਸਕਰਣ ਦੀ ਸਿਫ਼ਾਰਸ਼ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ।!
- ਸ਼ੁਰੂ ਕਰਨ ਲਈ ਸਿਰਫ਼ ਇੱਕ ਅੰਤਰਰਾਸ਼ਟਰੀ ਸਾਈਟ ਖਾਤੇ ਲਈ ਰਜਿਸਟਰ ਕਰੋ।
- ESA ਕੰਸੋਲ ਵਿੱਚ ਲੌਗ ਇਨ ਕਰੋ, ਇੱਕ ਸਾਈਟ ਸ਼ਾਮਲ ਕਰੋ ਅਤੇ ਮੁਫ਼ਤ ਯੋਜਨਾ ਚੁਣੋ। ਦਾਖਲਾ ਪੈਕੇਜ ਸਾਈਨ-ਅੱਪ
- ਜੇ ਤੁਸੀਂ ਮੇਨਲੈਂਡ ਚੀਨ ਵਿੱਚ ਹੋਣ ਦੌਰਾਨ ਆਪਣੇ ਆਪ ਮੇਨਲੈਂਡ ਚੀਨ ਦੇ ਰੂਟਾਂ 'ਤੇ ਸਵਿੱਚ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਆਮ ਤੌਰ 'ਤੇ ਤੁਹਾਨੂੰ ਪਹਿਲਾਂ ICP ਰਜਿਸਟ੍ਰੇਸ਼ਨ ਪੂਰੀ ਕਰਨੀ ਪੈਂਦੀ ਹੈ; ਰਜਿਸਟ੍ਰੇਸ਼ਨ ਤੋਂ ਬਿਨਾਂ, ਤੁਸੀਂ ਸਿਰਫ਼ ਅੰਤਰਰਾਸ਼ਟਰੀ ਰੂਟਾਂ ਹੀ ਵਰਤ ਸਕੋਗੇ।
- ਮੁਫ਼ਤ ਸੰਸਕਰਣ ਵਿਕਾਸ, ਟੈਸਟਿੰਗ ਅਤੇ ਮੁਲਾਂਕਣ ਲਈ ਵਧੇਰੇ ਢੁਕਵਾਂ ਹੈ, ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਵਪਾਰਕ SLA ਪੈਕੇਜ ਦੇ ਬਰਾਬਰ ਨਹੀਂ ਹੁੰਦਾ।
- ਮੁਫ਼ਤ ਯੋਜਨਾਵਾਂ ਅਕਸਰ ਗਤੀ ਸੀਮਾਵਾਂ ਜਾਂ ਸਹਾਇਤਾ ਵਿਕਲਪਾਂ (ਜਿਵੇਂ ਕਿ SLAs ਆਦਿ) 'ਤੇ ਪਾਬੰਦੀਆਂ ਦੇ ਨਾਲ ਆਉਂਦੀਆਂ ਹਨ।
ਮੁੱਖ ਭੂਮੀ ਚੀਨ ਦੇ ਰਸਤਿਆਂ ਬਾਰੇ:
- ਮੁੱਖ ਭੂਮੀ ਚੀਨ ਦਾ ਨੋਡ ਚਾਲੂ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਆਮ ਤੌਰ 'ਤੇ ICP ਰਜਿਸਟ੍ਰੇਸ਼ਨ ਅਤੇ ਭੂਗੋਲਿਕ ਸਥਿਤੀ ਸੰਬੰਧੀ ਲੋੜਾਂ ਪੂਰੀਆਂ ਕਰਨੀਆਂ ਪੈਂਦੀਆਂ ਹਨ।
- ਮੁਫ਼ਤ ਐਂਟਰੈਂਸ ਸੇਵਾ ਆਪਣੇ ਆਪ ਅੰਤਰਰਾਸ਼ਟਰੀ ਰਸਤੇ 'ਤੇ ਚੱਲਦੀ ਹੈ; ਮੇਨਲੈਂਡ ਚੀਨ ਰਸਤੇ ਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਪੂਰਾ ਕਰਨਾ ਪਵੇਗਾਚੀਨ ਵਿੱਚ ਆਈਸੀਪੀ ਫਾਈਲਿੰਗ ਦੀਆਂ ਲੋੜਾਂ
ਨੋਟ:
- ਸਥਿਤੀਕਰਨ: ਏਕੀਕ੍ਰਿਤ ਰਿਵਰਸ ਪ੍ਰਾਕਸੀ (ਵੈੱਬਸਾਈਟ ਤੇਜ਼ੀ + ਸੁਰੱਖਿਆ)
- ਮੁਫ਼ਤ: ਅੰਤਰਰਾਸ਼ਟਰੀ ਸਾਈਟ ਖਾਤਿਆਂ ਨੂੰ ਐਨਟ੍ਰੈਂਸ ਰਾਹੀਂ ਬਿਨਾਂ ਕਿਸੇ ਖਰਚੇ ਦੇ ਜੋੜਿਆ ਜਾ ਸਕਦਾ ਹੈ; ਮੁੱਖ ਭੂਮੀ ਚੀਨ ਦੀ ਤੇਜ਼ੀ ਡਿਫੌਲਟ ਵਿੱਚ ਸ਼ਾਮਿਲ ਨਹੀਂ ਹੈ।
- ਇਹ ਉਚਿਤ ਹੈ: ਮੁਲਾਂਕਣ/ਟੈਸਟਿੰਗ ਅਤੇ ਹਲਕੇ ਉਪਯੋਗ ਲਈ; ਜਾਂ ਬਾਅਦ ਵਿੱਚ ਉੱਚ ਪੱਧਰ 'ਤੇ ਅੱਪਗ੍ਰੇਡ ਕਰਨ ਲਈ
- ਖਤਰੇ: ਮੁਫ਼ਤ ਟੀਅਰ ਦੀਆਂ ਸੀਮਾਵਾਂ (SLA, ਗਤੀ ਸੀਮਾਵਾਂ, ਸਹਾਇਤਾ ਵਿਕਲਪ) ਬਾਰੇ ਸਪਸ਼ਟ ਰਹੋ; ਆਪਣੇ ਖੇਤਰ ਅਤੇ ICP ਰਜਿਸਟ੍ਰੇਸ਼ਨ ਦੀ ਪਹਿਲਾਂ ਤੋਂ ਯੋਜਨਾ ਬਣਾਓ।
4.4 ਇੱਕ ਟੀਪੀ 30ਟੀ: ਸਟੈਟਿਕ ਪੁੱਲ CDN (ਘੱਟ-ਖਤਰੇ ਵਾਲਾ ਦਾਖਲਾ ਬਿੰਦੂ, ਸਪੱਸ਼ਟ ਪੇ-ਐਜ਼-ਯੂ-ਗੋ ਕੀਮਤ)

ਜੇ ਤੁਸੀਂ “ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਸਭ ਤੋਂ ਸਥਿਰ ਰਿਟਰਨਜ਼ ਸੁਰੱਖਿਅਤ” ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ bunny 'ਤੇ 'Pull CDN' ਵਰਗੀ ਰਣਨੀਤੀ ਆਦਰਸ਼ ਹੈ:
ਇਹ ਵਧੇਰੇ ਇੱਕ “ਸਰੋਤ ਵੰਡਣ ਸੇਵਾ” ਵਾਂਗ ਹੈ: ਤੁਸੀਂ ਆਪਣੇ ਸਥਿਰ ਸਰੋਤ ਇਸਨੂੰ ਵੰਡਣ ਲਈ ਸੌਂਪਦੇ ਹੋ, ਅਤੇ ਖਰਚੇ ਆਮ ਤੌਰ 'ਤੇ ਟ੍ਰੈਫਿਕ, ਬੇਨਤੀਆਂ ਜਾਂ ਖੇਤਰ ਦੇ ਆਧਾਰ 'ਤੇ ਹੁੰਦੇ ਹਨ; ਮਾਡਲ ਸਪਸ਼ਟ ਅਤੇ ਸੰਭਾਲਣਯੋਗ ਹੈ।
ਇਸ ਲਈ ਢੁਕਵਾਂ:
- ਪਹਿਲਾਂ ਕਰੋ ਚਿੱਤਰ / ਸੀਐਸਐਸ / ਜੈਵਾਸਕ੍ਰਿਪਟ / ਫੌਂਟ ਸਥਿਰ ਤੇਜ਼ੀ
- ਤੁਸੀਂ ਪਹਿਲਾਂ “ਘੱਟ-ਖਤਰੇ ਵਾਲੇ, ਸਥਿਰ ਰਿਟਰਨ” ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਅਤੇ ਪੂਰੀ ਸਾਈਟ ਨੂੰ ਏਜੰਸੀ-ਸਟਾਈਲ ਪਲੇਟਫਾਰਮ (DNS/SSL/WAF ਆਲ-ਇਨ-ਵਨ ਸਲਿਊਸ਼ਨ) ਨੂੰ ਸੌਂਪਣ ਵਿੱਚ ਕੋਈ ਜਲਦੀ ਨਹੀਂ ਕਰ ਰਹੇ।
- ਤੁਸੀਂ ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਇੱਕ ਜਟਿਲ ਪੈਕੇਜ ਸਿਸਟਮ ਅਪਣਾਉਣ ਦੀ ਬਜਾਏ “ਪੇ-ਐਜ਼-ਯੂ-ਗੋ” ਵਰਗੇ ਕੀਮਤ ਮਾਡਲ ਨੂੰ ਤਰਜੀਹ ਦਿਓਗੇ।
ਖਤਰੇ ਦੇ ਕਾਰਕ
ਸਟੈਟਿਕ ਸਰੋਤਾਂ ਦੇ “ਅੱਪਡੇਟਸ ਪ੍ਰਭਾਵ ਵਿੱਚ ਨਾ ਆਉਣ” ਦਾ ਮੁੱਦਾ CDN ਵਿੱਚ ਲਗਭਗ ਕਦੇ ਵੀ ਬੱਗ ਨਹੀਂ ਹੁੰਦਾ।... ਸਗੋਂ ਕੈਸ਼ਿੰਗ ਸਿਸਟਮ ਦਾ ਇੱਕ ਆਮ ਵਿਵਹਾਰ:
ਜਦੋਂ ਤੁਸੀਂ ਬੈਕਐਂਡ ਵਿੱਚ CSS, JavaScript ਜਾਂ ਚਿੱਤਰ ਅੱਪਡੇਟ ਕਰਦੇ ਹੋ, ਪਰਸਰੋਤ URL ਨਹੀਂ ਬਦਲਿਆ ਹੈ।(ਉਹੀ ਪਤਾ/ਫਾਈਲ-ਨਾਮ/ਪਾਥ), CDN ਅਤੇ ਬ੍ਰਾਊਜ਼ਰ ਦੋਹਾਂ ਕੁਦਰਤੀ ਤੌਰ “ਤੇ ਪੁਰਾਣੀ ਕੈਸ਼ ਸਰਵ ਕਰਦੇ ਰਹਿਣਗੇ, ਇਸ ਲਈ ਤੁਸੀਂ ਸੋਚੋਗੇ, ”ਇਹ ਅਪਡੇਟ ਕਿਉਂ ਨਹੀਂ ਹੋਇਆ?"
ਇੱਕ ਸਪਸ਼ਟ, ਕਾਰਗਰ ਸਿਧਾਂਤ:
ਵਰਜਨ ਨੰਬਰਾਂ ਨੂੰ ਤਰਜੀਹ ਦਿਓ; ਬੈਕਅੱਪ ਵਜੋਂ `Purge` ਦੀ ਵਰਤੋਂ ਕਰੋ।
ਇਹ ਸਭ ਤੋਂ ਭਰੋਸੇਯੋਗ ਤਰੀਕਾ ਕਿਉਂ ਹੈ?
- ਵਰਜਨ ਨੰਬਰਾਂ/ਫਾਈਲ ਨਾਮਾਂ ਵਿੱਚ ਤਬਦੀਲੀਆਂ → URL ਬਦਲਾਅ → CDN ਇੱਕ ਨਵੇਂ ਸਰੋਤ ਵਜੋਂ ਕੈਸ਼ ਕੀਤਾ ਗਿਆ → ਨਵਾਂ ਸੰਸਕਰਣ ਲਗਭਗ ਤੁਰੰਤ ਲਾਗੂ ਹੁੰਦਾ ਹੈ
- **Purge(清缓存)**需要你主动触发,容易范围不准、节点传播有延迟;频繁 Purge 还会导致命中率下降、回源增加、波动变大
ਸਮਝਣ ਵਿੱਚ ਆਸਾਨ ਉਦਾਹਰਨ:
style.cssਸਮੱਗਰੀ ਬਦਲ ਗਈ ਹੈ, ਪਰ URL ਅਜੇ ਵੀ ਉਹੀ ਹੈ।style.css→ CDN ਪੁਰਾਣੇ ਕੈਸ਼ ਦੀ ਵਰਤੋਂ ਜਾਰੀ ਰੱਖੋ (ਵਾਜਬ)- ਯੂਆਰਐਲ ਬਦਲ ਕੇ ਹੋ ਗਿਆ ਹੈ
style.css?ver=20260103ਜਾਂstyle.abc123.css→ CDN ਨੂੰ ਇੱਕ ਨਵਾਂ ਸਰੋਤ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ → ਨਵਾਂ ਸੰਸਕਰਣ ਤੁਰੰਤ ਲਾਗੂ ਹੁੰਦਾ ਹੈ
“Step 1 CDN” ਲਈ ਇੱਕ ਸਰਵੋਤਮ ਅਭਿਆਸ ਵਜੋਂ ਬਨੀ
- ਫਿਲਹਾਲ, ਸਿਰਫ ਸਥਿਰ ਸਰੋਤ ਹੀ ਸ਼ਾਮਲ ਕੀਤੇ ਜਾਣਗੇ।(ਚਿੱਤਰ/CSS/JS/ਫੌਂਟ); HTML ਨੂੰ ਸਿੱਧਾ ਤੌਰ 'ਤੇ ਕੈਸ਼ ਨਾ ਕਰੋ
- ਫਾਇਦਾ: ਉਪਭੋਗਤਾਵਾਂ ਵੱਲੋਂ ਦੂਜਿਆਂ ਦੀ ਸਮੱਗਰੀ ਜਾਂ ਖਰੀਦਦਾਰੀ ਟੋਕਰੀ ਦੇ ਵੇਰਵੇ ਵੇਖਣ ਵਰਗੀਆਂ ਗੰਭੀਰ ਘਟਨਾਵਾਂ ਦਾ ਲਗਭਗ ਕੋਈ ਖਤਰਾ ਨਹੀਂ ਹੈ।
- ਤੁਹਾਡੇ ਲਈ ਲਾਭਾਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨਾ ਵੀ ਆਸਾਨ ਹੈ: ਸਥਿਰ ਸਰੋਤ ਤੇਜ਼ੀ ਨਾਲ ਲੋਡ ਹੁੰਦੇ ਹਨ ਅਤੇ ਮੂਲ ਸਰਵਰ ਘੱਟ ਸਰੋਤ-ਖਪਤ ਕਰਦਾ ਹੈ।
- ਇੱਕ ਚੰਗੀ ਅੱਪਡੇਟ ਰਣਨੀਤੀ ਤਿਆਰ ਕਰੋ
- CSS/JS: ਜਿੱਥੇ ਸੰਭਵ ਹੋਵੇ, ਵਰਜਨ ਨੰਬਰ ਜਾਂ ਫਾਈਲ-ਨਾਮ ਬਦਲਾਅ ਵਰਤੋ।
- ਚਿੱਤਰ: ਕਿਰਪਾ ਕਰਕੇ ਲੰਬੇ ਸਮੇਂ ਲਈ ਮੌਜੂਦਾ ਫਾਈਲਾਂ ਨੂੰ ਉਹੀ ਨਾਮ ਨਾਲ ਓਵਰਰਾਈਟ ਕਰਨ ਤੋਂ ਬਚੋ; ਨਵੇਂ ਫਾਈਲ ਨਾਮ ਜਾਂ ਪਾਥ ਵਰਤਣਾ ਵਧੀਆ ਹੈ (ਖਾਸ ਕਰਕੇ ਹੋਮਪੇਜ ਬੈਨਰਾਂ ਅਤੇ ਪ੍ਰਚਾਰਕ ਚਿੱਤਰਾਂ ਲਈ)।
- ਤੈਨਾਤੀ ਤੋਂ ਬਾਅਦ, ਇਹ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ ਪ੍ਰਮਾਣਿਕਤਾ ਚੈੱਕਲਿਸਟ ਦੀ ਵਰਤੋਂ ਕਰੋ ਕਿ ਲੋੜਾਂ ਪੂਰੀਆਂ ਹੋ ਗਈਆਂ ਹਨ।
- ਕੀ ਸਥਿਰ ਸਰੋਤ CDN ਤੋਂ ਆਉਂਦੇ ਹਨ?
- ਕੀ ਹਿੱਟ ਰੇਟ ਹੌਲੀ-ਹੌਲੀ ਵੱਧ ਰਹੀ ਹੈ? ਕੀ ਮੂਲ ਸਰਵਰ ਦੀ ਬੈਂਡਵਿਡਥ/ਬੇਨਤੀਆਂ ਦੀ ਮਾਤਰਾ ਵਧੇਰੇ ਸਥਿਰ ਹੈ? (ਹੇਠਾਂ ਦਿੱਤੀ ਪੁਸ਼ਟੀਕਰਨ ਚੈੱਕਲਿਸਟ ਵੇਖੋ)
ਕਿਰਪਾ ਕਰਕੇ ਧਿਆਨ ਦਿਓ
ਜੇ ਤੁਹਾਡਾ ਕਾਰੋਬਾਰ ਮੈਨਲੈਂਡ ਚੀਨ ਵਿੱਚ ਚੱਲਦਾ ਹੈ, ਜਾਂ ਜੇ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਤੁਹਾਡੀ ਵੈਬਸਾਈਟ ਮੈਨਲੈਂਡ ਚੀਨ ਵਿੱਚ ਤੇਜ਼ੀ ਨਾਲ ਲੋਡ ਹੋਵੇ।
ਅਲੀਬਾਬਾ ਕਲਾਊਡ ਚਾਈਨਾ ਅਤੇ ਟੈਂਸੈਂਟ ਕਲਾਊਡ ਚਾਈਨਾ ਦੋਵੇਂ ਯੋਗ ਵਿਕਲਪ ਹਨ। ਜੇ ਤੁਹਾਡਾ ਡੋਮੇਨ ਪਹਿਲਾਂ ਹੀ ਮੈਨਲੈਂਡ ਚੀਨ ਵਿੱਚ ICP ਨਾਲ ਰਜਿਸਟਰਡ ਹੈ, ਤਾਂ EdgeOne ਜਾਂ ESA ਦੀ ਵਰਤੋਂ ਕਰਦਿਆਂ, ਜਦੋਂ ਮੈਨਲੈਂਡ ਚੀਨ ਤੋਂ ਪਹੁੰਚ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਕਨੈਕਸ਼ਨ ਆਪਣੇ ਆਪ ਮੈਨਲੈਂਡ ਚੀਨ ਦੇ ਰੂਟਾਂ 'ਤੇ ਸਵਿੱਚ ਹੋ ਜਾਵੇਗਾ।
“ਮੁੱਖ ਭੂਮੀ ਚੀਨ ਦਾ ਸਰਵਰ ਵਰਤੋ”ਇਸ ਵਿੱਚ ਆਮ ਤੌਰ 'ਤੇ ICP ਰਜਿਸਟ੍ਰੇਸ਼ਨ ਸ਼ਾਮਲ ਹੁੰਦੀ ਹੈ।
ਹਵਾਲੇ ਲਈ
- ਟੈਂਸੈਂਟ ਕਲਾਊਡ ਇੰਟਰਨੈਸ਼ਨਲ ਐਜਵਨ ਆਈਸੀਪੀ ਫਾਈਲਿੰਗ ਦਿਸ਼ਾ-ਨਿਰਦੇਸ਼
- ਅਲੀਬਾਬਾ ਕਲਾਊਡ ਇੰਟਰਨੈਸ਼ਨਲ ESA ICP ਫਾਈਲਿੰਗ ਦਿਸ਼ਾ-ਨਿਰਦੇਸ਼
“ਸਰਹੱਦ-ਪਾਰ ਵੈੱਬਸਾਈਟ ਬ੍ਰਾਊਜ਼ਿੰਗ ਦੇ ਤਜਰਬੇ ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਣਾ”ਇਹ ਇੱਕ ਵੱਖਰੀ ਵਿਸ਼ੇਸ਼ਤਾ ਹੋ ਸਕਦੀ ਹੈ, ਜੋ ਆਮ ਤੌਰ “ਤੇ ਮੁੱਖ ਭੂਮੀ ਚੀਨ ਦੇ ਨੋਡਾਂ ਤੱਕ ਮੁਫ਼ਤ ਪਹੁੰਚ ਦੇ ਬਰਾਬਰ ਨਹੀਂ ਹੁੰਦੀ।”
5. ਰੋਡਮੈਪ: ਤਿੰਨ ਪੜਾਵਾਂ ਵਿੱਚ ਲਾਗੂ ਕੀਤਾ ਜਾਵੇਗਾ (ਸਥਿਰ ਤੋਂ ਮਜ਼ਬੂਤ ਤੱਕ)
CDN ਜਦੋਂ ਪਹਿਲੀ ਵਾਰੀ ਲਾਂਚ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਤਾਂ ਇਹ ਬੇਕਾਬੂ ਹੋਣ ਦਾ ਮੁੱਖ ਕਾਰਨ ਇਹ ਹੈ ਕਿ ਲੋਕ ਇਸ ਦੀਆਂ ਸਾਰੀਆਂ ਸਮਰੱਥਾਵਾਂ ਨੂੰ ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਪੂਰੀ ਤਰ੍ਹਾਂ ਵਰਤਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ।
ਪੜਾਅ 1: ਸਿਰਫ਼ ਸਥਿਰ ਸਰੋਤ (CDN) (ਪਹਿਲਾਂ ਪੂਰਾ ਕਰਨ ਦੀ ਜ਼ੋਰਦਾਰ ਸਿਫਾਰਸ਼ ਕੀਤੀ ਜਾਂਦੀ ਹੈ)
ਉਦੇਸ਼: ਚਿੱਤਰ, CSS, JS ਅਤੇ ਫੌਂਟਸ ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਸਰਵ ਕੀਤੇ ਜਾਂਦੇ ਹਨ (CDN); HTML ਨੂੰ CDN ਵਿੱਚ ਕੈਸ਼ ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ (ਜਾਂ ਅਸਥਾਈ ਤੌਰ 'ਤੇ ਬਿਨਾਂ ਬਦਲਾਅ ਦੇ ਛੱਡਿਆ ਜਾਂਦਾ ਹੈ).
ਇਹ ਸ਼ੁਰੂ ਕਰਨ ਲਈ ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਵਿਕਲਪ ਕਿਉਂ ਹੈ?
- ਸਭ ਤੋਂ ਘੱਟ ਜੋਖਮ: ਜੇ ਸਥਿਰ ਸਰੋਤ ਗਲਤ ਤਰੀਕੇ ਨਾਲ ਕੈਸ਼ ਕੀਤੇ ਜਾਣ, ਤਾਂ ਸਭ ਤੋਂ ਮਾੜੀ ਗੱਲ ਇਹ ਹੋ ਸਕਦੀ ਹੈ ਕਿ “ਸਟਾਈਲ ਜਾਂ ਚਿੱਤਰ ਅੱਪਡੇਟ ਨਹੀਂ ਹੁੰਦੇ”—ਇੱਕ ਸੰਭਾਲਣਯੋਗ ਸਮੱਸਿਆ।
- ਲੌਗਇਨ ਸਥਿਤੀ, ਈ-ਕਾਮਰਸ ਪ੍ਰਕਿਰਿਆਵਾਂ ਜਾਂ ਖਾਤਾ ਜਾਣਕਾਰੀ ਦੀ ਸ਼ੁੱਧਤਾ 'ਤੇ ਅਸਰ ਨਹੀਂ ਪਵੇਗਾ।
- ਤੁਸੀਂ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਫਾਇਦੇ ਵੇਖ ਸਕਦੇ ਹੋ: ਸਥਿਰ ਸਰੋਤਾਂ ਦੀ ਤੇਜ਼ ਡਾਊਨਲੋਡ ਅਤੇ ਇੱਕ ਹੋਰ ਸਥਿਰ ਓਰਿਜਿਨ ਸਰਵਰ।
ਇਸ ਪੜਾਅ 'ਤੇ ਆਮ ਸਮੱਸਿਆਵਾਂ (ਟ੍ਰਬਲਸ਼ੂਟਿੰਗ ਟ੍ਰੀ ਬਾਅਦ ਵਿੱਚ ਦਿੱਤਾ ਜਾਵੇਗਾ)
- ਮਿਸ਼ਰਤ ਸਮੱਗਰੀ (HTTPS ਪੰਨਾ ਲੋਡ, HTTP ਸਰੋਤ)
- ਸਥਿਰ ਸਰੋਤਾਂ ਵਿੱਚ ਕੀਤੀਆਂ ਤਬਦੀਲੀਆਂ ਲਾਗੂ ਨਹੀਂ ਹੋ ਰਹੀਆਂ (URL ਬਦਲੀ ਨਹੀਂ ਗਈ)
ਪੜਾਅ 2: ਰੈਫਰੈਸ਼ ਰਣਨੀਤੀ (ਵਰਜਨ ਨੰਬਰ ਨੂੰ ਤਰਜੀਹ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ, ਪੁਰਜ/ਮਿਆਦ ਪੁੱਗਣ ਨੂੰ ਬੈਕਅੱਪ ਵਜੋਂ)
ਇਹ “CDN” ਪੇਸ਼ੇਵਰ ਤਰੀਕੇ ਨਾਲ ਕੀਤਾ ਗਿਆ ਹੈ ਜਾਂ ਨਹੀਂ, ਇਸ ਵਿਚਕਾਰ ਦੀ ਵੰਡਣ ਵਾਲੀ ਲਕੀਰ ਹੈ।
ਇੱਕ ਲਾਓ-ਪਾਓ ਨਿਯਮ:
ਜਿਨ੍ਹਾਂ ਅੱਪਡੇਟਾਂ ਨੂੰ ਵਰਜਨ ਨੰਬਰ ਜਾਂ ਫਾਈਲ ਨਾਮ ਬਦਲ ਕੇ ਹੱਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਉਹਨਾਂ ਲਈ Purge 'ਤੇ ਨਿਰਭਰ ਨਾ ਕਰੋ।
ਜਦੋਂ ਚੇਨ ਲੰਬੀ ਹੋ ਜਾਂਦੀ ਹੈ ਤਾਂ ਕੈਸ਼ਿੰਗ ਇੰਨੀ ਰਹੱਸਮਈ ਕਿਉਂ ਹੋ ਜਾਂਦੀ ਹੈ?
- ਬ੍ਰਾਊਜ਼ਰ ਕੈਸ਼: ਤੁਹਾਡੇ ਕੋਲ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਪੁਰਾਣੀਆਂ CSS/JS ਫਾਈਲਾਂ ਕੈਸ਼ ਕੀਤੀਆਂ ਹੋ ਸਕਦੀਆਂ ਹਨ।
- CDN ਕੈਸ਼: ਐਜ ਨੋਡ ਨੇ ਇੱਕ ਪੁਰਾਣੀ ਹੋ ਚੁੱਕੀ ਸਰੋਤ ਨੂੰ ਕੈਸ਼ ਕੀਤਾ ਹੋ ਸਕਦਾ ਹੈ।
- ਓਰਿਜਿਨ ਸਰਵਰ ਕੈਸ਼ਿੰਗ: ਕੈਸ਼ਿੰਗ ਪਲੱਗਇਨ ਜਾਂ ਸਰਵਰ ਕੈਸ਼ ਅਜੇ ਵੀ ਪੁਰਾਣੀ ਸਮੱਗਰੀ ਸਰਵ ਕਰ ਰਿਹਾ ਹੋ ਸਕਦਾ ਹੈ।
ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਵਰਜਨਿੰਗ ਰਣਨੀਤੀ ਨਹੀਂ ਹੈ, ਤਾਂ ਰਿਲੀਜ਼ ਹੋ ਜਾਵੇਗੀ:
“ਕੁਝ ਬਦਲਾਅ ਕੀਤੇ → ਰਿਫਰੈਸ਼ ਕੀਤਾ → ਕੰਮ ਨਹੀਂ ਕੀਤਾ → ਕੈਸ਼ ਫਿਰ ਸਾਫ਼ ਕੀਤਾ → ਫਿਰ ਵੀ ਕੰਮ ਨਹੀਂ ਕੀਤਾ → ਕੈਸ਼ ਦੀ ਇੱਕ ਹੋਰ ਪਰਤ ਸਾਫ਼ ਕੀਤੀ”
ਇਹ CDN ਨਾਲ ਬਹੁਤ ਸਾਰੇ ਲੋਕਾਂ ਦੀ ਮੁੱਖ ਸਮੱਸਿਆ ਹੈ।
ਪੜਾਅ 3 (ਉੱਨਤ): HTML ਨੂੰ ਕੈਸ਼ ਕਰਨ ਬਾਰੇ (ਸਭ ਤੋਂ ਵੱਧ ਲਾਭ, ਪਰ ਸਭ ਤੋਂ ਵੱਧ ਜੋਖਮ)
HTML ਕੈਸ਼ਿੰਗ (ਪੂਰੀ-ਸਾਈਟ ਕੈਸ਼ਿੰਗ/ਐਜ ਕੈਸ਼ਿੰਗ) TTFB ਨੂੰ ਕਾਫ਼ੀ ਘਟਾ ਸਕਦੀ ਹੈ, ਪਰ ਇਹ WordPress ਵਾਤਾਵਰਣ ਵਿੱਚ ਸਮੱਸਿਆਵਾਂ ਦਾ ਇੱਕ ਆਮ ਸਰੋਤ ਵੀ ਹੈ।
ਜੇ ਤੁਸੀਂ ਅਨਿਸ਼ਚਿਤ ਹੋ, ਤਾਂ HTML ਨੂੰ ਕੈਸ਼ ਨਾ ਕਰੋ। ਸਥਿਰ CDN + ਮੂਲ ਸਰਵਰ ਕੈਸ਼ਿੰਗ ਪਲੱਗਇਨ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ।
HTML ਨੂੰ ਕੈਸ਼ ਕਰਦੇ ਸਮੇਂ, ਦੋ ਸਿਧਾਂਤ ਹਨ:
- ਸਿਰਫ਼ ਇੱਕ “ਮਹਿਮਾਨ ਦੀ ਸੋਚ” ਅਪਣਾ ਕੇ ਸ਼ੁਰੂ ਕਰੋ।: ਸਿਰਫ਼ ਅਣ-ਰਜਿਸਟਰਡ ਵਿਜ਼ਿਟਰਾਂ ਲਈ ਪੰਨੇ ਕੈਸ਼ ਕਰੋ
- ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਬਾਈਪਾਸ ਸੂਚੀ ਲਿਖੋ।ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਸਹੀਅਤ, ਫਿਰ ਹਿੱਟ ਦਰ
6. ਸਾਈਟ-ਵਿਸ਼ੇਸ਼ ਨਿਯਮਾਂ ਦੀ ਚੈੱਕਲਿਸਟ: ਵੱਖ-ਵੱਖ ਕਿਸਮਾਂ ਦੀਆਂ ਸਾਈਟਾਂ 'ਤੇ ਹਾਦਸਿਆਂ ਨੂੰ ਕਿਵੇਂ ਰੋਕਿਆ ਜਾਵੇ
6.1 ਸਮੱਗਰੀ ਵਾਲੀਆਂ ਸਾਈਟਾਂ / ਬਲੌਗ (ਮੁੱਖ ਤੌਰ 'ਤੇ ਲੇਖ, ਉੱਚ ਵਿਜ਼ਿਟਰ ਟ੍ਰੈਫਿਕ)
ਸਿਫ਼ਾਰਸ਼ੀ
- ਸਥਿਰ ਸਰੋਤ: ਪੂਰੀ ਕੈਸ਼ਿੰਗ
- HTML: ਅਣ-ਰਜਿਸਟਰਡ ਵਿਜ਼ਿਟਰਾਂ ਲਈ ਪੰਨੇ ਨੂੰ ਕੈਸ਼ ਕਰਨ ਬਾਰੇ ਵਿਚਾਰ ਕਰੋ।“
ਆਮ ਤੌਰ 'ਤੇ ਘੁੰਮ ਕੇ ਜਾਣਾ ਜ਼ਰੂਰੀ ਹੁੰਦਾ ਹੈ।
- ਬੈਕਐਂਡ ਅਤੇ ਲੌਗਇਨ:
/wp-admin/*、/wp-login.php - ਪੂਰਵ-ਝਲਕ/ਮਸੌਦਾ
- ਖੋਜ ਨਤੀਜਿਆਂ ਦਾ ਪੰਨਾ (ਕਿਉਂਕਿ ਪੈਰਾਮੀਟਰ ਕਾਫੀ ਵੱਖਰੇ ਹੁੰਦੇ ਹਨ, ਇਸ ਲਈ ਇਸਨੂੰ ਫਿਲਹਾਲ ਕੈਸ਼ ਨਾ ਕਰਨੀ ਸਭ ਤੋਂ ਆਸਾਨ ਹੈ)
- POST ਫਾਰਮ ਜਮ੍ਹਾਂ ਕਰਨ/ਟਿੱਪਣੀ ਜਮ੍ਹਾਂ ਕਰਨ ਲਈ ਬੇਨਤੀ
ਇੱਕ ਕੈਸ਼ ਕੀ ਨੂੰ, ਘੱਟੋ-ਘੱਟ, ਵਿਚਕਾਰ ਫਰਕ ਕਰਨ ਦੇ ਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
- ਕੀ ਉਪਭੋਗਤਾ ਲੌਗ ਇਨ ਹੈ? (cookie ਮਾਪ)
- ਭਾਸ਼ਾ (ਬਹੁ-ਭਾਸ਼ੀ ਸਾਈਟ)
6.2 ਕਾਰਪੋਰੇਟ ਵੈੱਬਸਾਈਟਾਂ / ਮਾਰਕੀਟਿੰਗ ਲੈਂਡਿੰਗ ਪੰਨੇ (ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਕਈ ਫਾਰਮ ਅਤੇ ਮੁਹਿੰਮਾਂ ਸ਼ਾਮਲ ਹਨ)
ਸਿਫ਼ਾਰਸ਼ੀ
- ਸਥਿਰ ਸਰੋਤ: ਪੂਰੀ ਕੈਸ਼ਿੰਗ
- HTML: ਜਨਤਕ ਲੈਂਡਿੰਗ ਪੰਨੇ (ਵਿਜ਼ਿਟਰ ਮੋਡ ਵਿੱਚ) ਕੈਸ਼ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ, ਪਰ ਫਾਰਮ ਨਤੀਜੇ ਵਾਲੇ ਪੰਨਿਆਂ ਨੂੰ ਸੰਭਾਲਣ ਵੇਲੇ ਸਾਵਧਾਨੀ ਵਰਤਣੀ ਚਾਹੀਦੀ ਹੈ।
ਸਭ ਤੋਂ ਆਮ ਫੰਦ: ਕੈਸ਼ ਵਿਖੰਡਨ ਪੈਦਾ ਕਰਨ ਵਾਲੇ ਪੈਰਾਮੀਟਰਾਂ ਦੀ ਟ੍ਰੈਕਿੰਗ
ਆਮ ਲੈਂਡਿੰਗ ਪੰਨੇ utm_* ਪੈਰਾਮੀਟਰ:
- ਸਾਰੀਆਂ ਕੁੰਜੀਆਂ ਕੈਸ਼ ਵਿੱਚ ਸ਼ਾਮਿਲ ਹਨ → ਕੈਸ਼ ਟੁਕੜਿਆਂ ਵਿੱਚ ਵੰਡਿਆ ਹੋਇਆ ਹੈ, ਜਿਸ ਨਾਲ ਹਿੱਟ ਦਰ ਘੱਟ ਹੈ
- ਸਭ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰੋ → ਕੁਝ ਘੱਟ ਪੰਨੇ ਜੋ ਰੈਂਡਰਿੰਗ ਲਈ ਪੈਰਾਮੀਟਰਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ, ਉਹ ਸੰਭਵ ਤੌਰ 'ਤੇ ਉਮੀਦ ਅਨੁਸਾਰ ਨਹੀਂ ਦਿਖਾਈ ਦੇ ਸਕਦੇ।
6.3 ਮੈਂਬਰ ਸਾਈਟਾਂ / ਕੋਰਸ ਪਲੇਟਫਾਰਮ / ਕਮਿਊਨਿਟੀਆਂ (ਲੌਗ-ਇਨ ਕੀਤੇ ਉਪਭੋਗਤਾਵਾਂ ਦਾ ਵੱਡਾ ਅਨੁਪਾਤ)
ਸਿੱਟਾਤੁਹਾਨੂੰ HTML ਕੈਸ਼ਿੰਗ ਨਾਲ ਬਹੁਤ ਸਾਵਧਾਨੀ ਵਰਤਣੀ ਚਾਹੀਦੀ ਹੈ।
ਮਿਆਰੀ ਪਹੁੰਚ ਆਮ ਤੌਰ 'ਤੇ ਹੁੰਦੀ ਹੈ: ਸਟੈਟਿਕ CDN + ਮੂਲ ਕੈਸ਼ਿੰਗ/ਆਬਜੈਕਟ ਕੈਸ਼ਿੰਗ; HTML ਸਿਰਫ਼ ਵਿਜ਼ਿਟਰ ਲਈ ਕੈਸ਼ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
ਬਾਈਪਾਸ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ
- ਲੌਗ ਇਨ / ਰਜਿਸਟਰ / ਆਪਣਾ ਪਾਸਵਰਡ ਭੁੱਲ ਗਏ?
- ਖਾਤਾ ਕੇਂਦਰ, ਆਰਡਰ/ਸਬਸਕ੍ਰਿਪਸ਼ਨਾਂ, ਪ੍ਰੋਫਾਈਲ
- ਕੋਈ ਵੀ ਪੰਨੇ ਅਤੇ ਇੰਟਰਫੇਸ ਜੋ “ਮਜ਼ਬੂਤੀ ਨਾਲ ਉਪਭੋਗਤਾ-ਨਿਰਭਰ” ਹਨ
6.4 ਈ-ਕਾਮਰਸ ਸਾਈਟ (ਵੂ-ਕਾਮਰਸ)
ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਬਾਈਪਾਸ ਸੂਚੀ
- ਖਰੀਦਦਾਰੀ ਟੋਕਰੀ, ਚੈੱਕਆਊਟ, ਖਾਤਾ ਪੰਨਾ
- ਆਰਡਰ ਦੀ ਪੁਸ਼ਟੀ ਅਤੇ ਭੁਗਤਾਨ ਕਾਲਬੈਕਸ ਨਾਲ ਸਬੰਧਤ ਪੰਨੇ
- ਲੌਗਇਨ/ਰਜਿਸਟਰ, ਕੂਪਨ/ਇਨਾਮ ਅਤੇ ਹੋਰ ਉਪਭੋਗਤਾ-ਸਬੰਧੀ ਲਿੰਕ
ਈ-ਕਾਮਰਸ ਵਿੱਚ ਦੁਰਘਟਨਾਵਾਂ ਵਾਪਰਨ ਦੀ ਸੰਭਾਵਨਾ ਵੱਧ ਕਿਉਂ ਹੁੰਦੀ ਹੈ?
- ਜਦੋਂ ਕਿਸੇ ਉਪਭੋਗਤਾ ਕੋਲ ਖਰੀਦਦਾਰੀ ਦੀ ਟੋਕਰੀ, ਇੱਕ ਸੈਸ਼ਨ ਜਾਂ ਲੌਗ-ਇਨ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਪੰਨਾ ਬਹੁਤ ਹੀ ਵਿਅਕਤੀਗਤ ਹੋ ਜਾਂਦਾ ਹੈ।
- ਜੇ HTML ਕੈਸ਼ਿੰਗ ਨੂੰ ਬਾਈਪਾਸ ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ ਜਾਂ ਇਹ ਸਥਿਤੀਆਂ ਵਿੱਚ ਫਰਕ ਨਹੀਂ ਕਰਦੀ, ਤਾਂ ਸਭ ਤੋਂ ਆਮ ਨਤੀਜੇ ਹੁੰਦੇ ਹਨ: ਖਰੀਦਦਾਰੀ ਟੋਕਰੀ ਦੀਆਂ ਗਲਤੀਆਂ, ਖਾਤਿਆਂ ਵਿੱਚ ਉਲਝਣਾਂ ਅਤੇ ਗਲਤ ਕੀਮਤਾਂ ਦੀ ਪ੍ਰਦਰਸ਼ਨੀ।
ਸਹੀਤਾ ਸਭ ਤੋਂ ਪਹਿਲਾਂ; ਹਿੱਟ ਦਰਾਂ ਲਈ ਸਹੀਤਾ ਨੂੰ ਕੁਰਬਾਨ ਨਾ ਕਰੋ।
6.5 ਬਹੁ-ਭਾਸ਼ੀ / ਬਹੁ-ਕਰੰਸੀ ਵੈੱਬਸਾਈਟਾਂ
ਸਿਫ਼ਾਰਸ਼ੀ
- ਸਥਿਰ ਸਰੋਤ: ਪੂਰੀ ਕੈਸ਼ਿੰਗ
- HTML: ਵਿਜ਼ਿਟਰ ਸਥਿਤੀ ਨੂੰ ਕੈਸ਼ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਪਰ ਕੈਸ਼ ਕੀ ਨੂੰ ਭਾਸ਼ਾ ਅਤੇ ਮੁਦਰਾ ਵੇਰੀਐਂਟਾਂ ਵਿੱਚ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਫਰਕ ਕਰਨ ਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
ਕੈਸ਼ ਕੀ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ।
- ਭਾਸ਼ਾ (ਪਾਥ)
/en//zh/ਜਾਂ ਉਪ-ਡੋਮੇਨen.) - ਕੀ ਤੁਸੀਂ ਲੌਗ ਇਨ ਹੋਏ ਹੋ? (cookie)
- ਕਰੰਸੀ/ਟੈਕਸ ਦਰ (ਜੇ ਲਾਗੂ ਹੋਵੇ)
੭. ਜੋਖਮ ਦਾ ਖੁਲਾਸਾ
ਖਤਰਾ 1: ਗਲਤ ਕੈਸ਼ ਕੀਤੀ ਸਮੱਗਰੀ (ਸਭ ਤੋਂ ਗੰਭੀਰ)
- ਸਥਿਰ ਸਰੋਤ ਕੈਸ਼ਿੰਗ ਦੀ ਗਲਤੀ: ਆਮ ਤੌਰ 'ਤੇ ਪੁਰਾਣੀਆਂ ਸਟਾਈਲਸ਼ੀਟਾਂ ਜਾਂ ਤਸਵੀਰਾਂ ਕਾਰਨ ਹੁੰਦੀ ਹੈ।
- HTML ਕੈਸ਼ਿੰਗ ਦੀ ਗਲਤੀ: ਸਮੱਗਰੀ, ਖਰੀਦਦਾਰੀ ਦੀਆਂ ਟੋਕਰੀਆਂ ਜਾਂ ਖਾਤਿਆਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰ ਸਕਦੀ ਹੈ — ਇਹ ਇੱਕ ਗੰਭੀਰ ਸਮੱਸਿਆ ਹੈ।
ਖਤਰਾ 2: ਅੱਪਡੇਟ ਲਾਗੂ ਨਹੀਂ ਹੁੰਦੇ (ਸਭ ਤੋਂ ਆਮ)
ਜਦੋਂ ਕੈਸ਼ ਚੇਨ ਲੰਬੀ ਹੋ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਉਹ ਮਾਮਲੇ ਜਿੱਥੇ ਤਬਦੀਲੀਆਂ ਲਾਗੂ ਨਹੀਂ ਹੁੰਦੀਆਂ, ਵਧੇਰੇ ਆਮ ਹੋ ਜਾਣਗੇ:
- ਵਰਜਨ ਨੰਬਰ/ਫਾਈਲ ਨਾਮ ਬਦਲਾਵਾਂ ਨੂੰ ਤਰਜੀਹ ਦਿਓ
- ਪੁਰਜ/ਫਾਲਬੈਕ
- ਰਿਲੀਜ਼ ਪ੍ਰਕਿਰਿਆ ਦੁਹਰਾਈ ਜਾਣਯੋਗ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ (ਤਾਂ ਜੋ ਸਾਨੂੰ ਪਤਾ ਹੋਵੇ ਕਿ ਹਰ ਰਿਲੀਜ਼ ਵਿੱਚ ਕਿਹੜੇ URL ਬਦਲੇ ਗਏ ਹਨ)
ਖਤਰਾ 3: ਮੁਫ਼ਤ/ਬੁਨਿਆਦੀ ਸੰਸਕਰਣ ਦਾ ਦਾਇਰਾ
- ਮੁਫ਼ਤ ਯੋਜਨਾਵਾਂ ਦੀਆਂ ਆਮ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ: ਸੀਮਤ ਕੋਟਾ, ਕੁਝ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਬਾਹਰ ਰੱਖਿਆ ਗਿਆ, ਅਤੇ SLA/ਸਹਾਇਤਾ ਵਿਕਲਪ ਜੋ ਪੂਰੇ ਵਪਾਰਕ ਸੰਸਕਰਣ ਤੋਂ ਵੱਖਰੇ ਹਨ।
ਖਤਰਾ 4: ਮੁੱਖ ਭੂਮੀ ਚੀਨ ਦੀਆਂ ਸਮਰੱਥਾਵਾਂ ਨੂੰ ਆਸਾਨੀ ਨਾਲ ਗਲਤ ਸਮਝਿਆ ਜਾਂਦਾ ਹੈ।
- ESA: ਮੁੱਖ ਭੂਮੀ ਚੀਨ ਵਿੱਚ ਕੰਮ ਕਰਨ ਲਈ, ਚੀਨੀ ਅਧਿਕਾਰੀਆਂ ਕੋਲ ICP ਰਜਿਸਟ੍ਰੇਸ਼ਨ ਲਾਜ਼ਮੀ ਹੈ।
- EdgeOne: ਮੇਨਲੈਂਡ ਚੀਨ ਰੂਟ ਵਰਤਣ ਲਈ, ਤੁਹਾਨੂੰ ਚੀਨੀ ICP ਨਾਲ ਰਜਿਸਟਰ ਕਰਨਾ ਲਾਜ਼ਮੀ ਹੈ।
8 ਪੜਤਾਲ ਸੂਚੀ: ਲਾਂਚ ਤੋਂ ਬਾਅਦ ਕਿਵੇਂ ਪੁਸ਼ਟੀ ਕਰੀਏ ਕਿ “ਇਹ ਅਸਲ ਵਿੱਚ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ”
8.1 ਕੀ ਸਟੈਟਿਕ ਸਰੋਤਾਂ ਨੇ ਵਾਕਈ 1 ਟੀਬੀ ਅਤੇ 219 ਟੀਬੀ ਘੇਰ ਲਏ ਸਨ?
- ਕੀ ਚਿੱਤਰ, CSS ਅਤੇ JavaScript ਫਾਈਲਾਂ CDN ਡੋਮੇਨ ਤੋਂ ਆਉਂਦੀਆਂ ਹਨ ਜਾਂ ਕਿਸੇ ਐਜ ਨੋਡ ਤੋਂ?
- ਕੀ ਤੁਸੀਂ ਕੈਸ਼ ਹਿੱਟ ਦੇ ਸਪਸ਼ਟ ਨਿਸ਼ਾਨ ਵੇਖ ਸਕਦੇ ਹੋ (ਪਲੇਟਫਾਰਮਾਂ ਅਨੁਸਾਰ ਇਸ਼ਾਰੇ ਵੱਖ-ਵੱਖ ਹੁੰਦੇ ਹਨ)?
8.2 ਕੀ ਮੂਲ ਸਰਵਰ 'ਤੇ ਲੋਡ ਘੱਟ ਗਿਆ ਹੈ?
- ਕੀ ਮੂਲ ਸਰਵਰ ਦੀ ਬੈਂਡਵਿਡਥ ਵਧੇਰੇ ਸਥਿਰ ਹੈ?
- ਕੀ ਮੂਲ ਸਰਵਰ ਨੂੰ ਭੇਜੀਆਂ ਗਈਆਂ ਬੇਨਤੀਆਂ ਦੀ ਗਿਣਤੀ ਜਾਂ ਕੁਨੈਕਸ਼ਨਾਂ ਦੀ ਗਿਣਤੀ (ਖਾਸ ਕਰਕੇ ਦੁਹਰਾਈਆਂ ਗਈਆਂ ਸਰੋਤਾਂ ਲਈ ਬੇਨਤੀਆਂ) ਵਿੱਚ ਕਮੀ ਆਈ ਹੈ?
8.3 ਕੀ ਅੱਪਡੇਟ ਕੰਟਰੋਲਯੋਗ ਹਨ?
- CSS ਜਾਂ JavaScript ਵਿੱਚ ਇੱਕ ਤਬਦੀਲੀ ਕਰੋ, ਜਾਂ ਇੱਕ ਚਿੱਤਰ ਨੂੰ ਬਦਲੋ
- ਕੀ ਨਵਾਂ ਵਰਜਨ ਵਰਜਨ ਨੰਬਰ ਜਾਂ ਫਾਈਲ ਨਾਮ ਬਦਲ ਕੇ ਤੇਜ਼ੀ ਨਾਲ ਜਾਰੀ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ?
- ਜੇ ਤੁਸੀਂ ਸਿਰਫ਼ `Purge` ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਹੀ ਅੱਪਡੇਟ ਕਰ ਸਕਦੇ ਹੋ, ਤਾਂ ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਹਾਡੀ ਵਰਜਨਿੰਗ ਨੀਤੀ ਅਜੇ ਠੀਕ ਤਰ੍ਹਾਂ ਸੈੱਟ ਨਹੀਂ ਕੀਤੀ ਗਈ (ਆਪਣੀ ਨੀਤੀ ਨੂੰ ਸੁਧਾਰਨ ਨੂੰ ਤਰਜੀਹ ਦਿਓ; `Purge` ਨੂੰ ਰੁਟੀਨ ਅਭਿਆਸ ਵਜੋਂ ਨਾ ਵਰਤੋ)।
8.4 ਕੀ ਗਤੀਸ਼ੀਲ ਕੁੰਜੀ ਪੰਨੇ ਸਹੀ ਹਨ?
(ਈ-ਕਾਮਰਸ ਅਤੇ ਮੈਂਬਰਸ਼ਿਪ ਸਾਈਟਾਂ ਲਈ ਜ਼ਰੂਰੀ)
- ਲੌਗਇਨ ਜਾਂ ਲੌਗਆਊਟ ਕਰਨ ਤੋਂ ਬਾਅਦ ਕੀ ਪੰਨੇ ਦੀ ਸਮੱਗਰੀ ਸਹੀ ਹੈ?
- ਕੀ ਸ਼ਾਪਿੰਗ ਬਾਸਕਟ, ਚੈੱਕਆਊਟ ਅਤੇ ਖਾਤਾ ਵਾਲੇ ਪੰਨੇ ਹਮੇਸ਼ਾਂ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਦਿਖਾਈ ਦੇ ਰਹੇ ਹਨ?
- ਕੀ ਕੋਈ ਅਸਧਾਰਣਤਾ (ਉੱਚ-ਜੋਖਮ) ਹੋਈ ਹੈ ਜਿੱਥੇ ਵੱਖ-ਵੱਖ ਉਪਭੋਗਤਾਵਾਂ ਨੇ ਇੱਕੋ ਉਪਭੋਗਤਾ-ਵਿਸ਼ੇਸ਼ ਸਮੱਗਰੀ ਵੇਖੀ ਹੋਵੇ?
8.5 ਕੀ ਗਲਤੀ ਦੀ ਦਰ ਵਧੀ ਹੈ?
- ਮੂਲ ਸਥਾਨ 'ਤੇ ਵਾਪਸੀ ਵਿੱਚ ਟਾਈਮਆਊਟ, 5xx ਗਲਤੀਆਂ, ਰੁਕ-ਰੁਕ ਕੇ ਪਹੁੰਚ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ
- ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਦਰਸਾਉਂਦੇ ਹਨ: ਮੂਲ ਸਰਵਰ 'ਤੇ ਅਪਰਯਾਪਤ ਸਮਰੱਥਾ, ਗਲਤ ਨਿਯਮ, ਰੇਟ-ਲਿਮਿਟਿੰਗ ਲਾਗੂ ਹੋਣਾ, ਜਾਂ ਮੂਲ ਸਰਵਰ ਨਾਲ ਕਨੈਕਸ਼ਨ ਵਿੱਚ ਸਮੱਸਿਆਵਾਂ।
9. ਜਦੋਂ ਅੱਪਡੇਟਸ ਅਸਰ ਨਹੀਂ ਕਰਦੇ ਤਾਂ ਸਮੱਸਿਆ-ਨਿਵਾਰਣ (“ਕਾਲੀ ਜਾਦੂ” ਨੂੰ ਕਦਮ-ਦਰ-ਕਦਮ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਬਦਲਣਾ)
ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਇਹ ਨਿਰਧਾਰਤ ਕਰੋ ਕਿ ਤੁਸੀਂ ਕਿਸ ਕਿਸਮ ਦੀ ਸਮੱਸਿਆ ਦਾ ਸਾਹਮਣਾ ਕਰ ਰਹੇ ਹੋ:
9.1 ਸਥਿਰ ਸਰੋਤ ਅੱਪਡੇਟ ਨਹੀਂ ਕੀਤੇ ਗਏ ਹਨ (CSS, JavaScript ਅਤੇ ਚਿੱਤਰ ਅਜੇ ਵੀ ਪੁਰਾਣੇ ਸੰਸਕਰਣ ਹਨ)
ਸਥਿਤੀ A: ਸਿਰਫ ਤੁਸੀਂ ਹੀ ਪੁਰਾਣਾ ਸੰਸਕਰਣ ਵੇਖ ਸਕਦੇ ਹੋ; ਜਦੋਂ ਤੁਸੀਂ ਇੰਕੋਗਨਿਟੋ ਮੋਡ ਵਿੱਚ ਜਾਂਦੇ ਹੋ ਜਾਂ ਡਿਵਾਈਸ ਬਦਲਦੇ ਹੋ, ਤਾਂ ਨਵਾਂ ਸੰਸਕਰਣ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ।
ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਜਾਂਚਣ ਵਾਲੀ ਚੀਜ਼: ਬ੍ਰਾਊਜ਼ਰ ਕੈਸ਼
- ਹੱਲ: ਜਦੋਂ ਵਰਜਨ ਨੰਬਰ ਜਾਂ ਫਾਈਲ ਨਾਮ ਬਦਲਣ, ਤਾਂ ਨਵੇਂ ਸਰੋਤ ਜਾਰੀ ਕਰੋ।
ਸਥਿਤੀ ਬੀ: ਹਰ ਕੋਈ ਪੁਰਾਣਾ ਸੰਸਕਰਣ ਵੇਖਦਾ ਹੈ (ਜਿਨ੍ਹਾਂ ਨੇ ਇੰਕੋਗਨਿਟੋ ਮੋਡ ਵਰਤਿਆ ਹੋਇਆ ਹੈ ਜਾਂ ਵੱਖਰੇ ਡਿਵਾਈਸ ਦੀ ਵਰਤੋਂ ਕਰ ਰਹੇ ਹਨ, ਉਹ ਵੀ)
ਮੁੱਖ ਸ਼ੱਕ: CDN ਅਜੇ ਵੀ ਪੁਰਾਣੇ ਕੈਸ਼ ਨੂੰ ਹੀ ਹਿੱਟ ਕਰ ਰਿਹਾ ਹੈ।
- 99% ਕਾਰਨ: ਸਰੋਤ URL ਨਹੀਂ ਬਦਲਿਆ
- ਤਰਜੀਹੀ ਹੱਲ: ਸੰਸਕਰਣ ਰਣਨੀਤੀ
- ਬੈਕਅੱਪ: ਸਾਫ਼-ਸਫਾਈ (ਅਸਥਾਈ ਉਪਾਇ)
ਸਥਿਤੀ C: ਇੱਕੋ ਫਾਈਲ-ਨਾਮ ਵਾਲੀ ਤਸਵੀਰ ਨੂੰ ਓਵਰਰਾਈਟ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਪੁਰਾਣੀ ਤਸਵੀਰ ਦਿਖਾਈ ਦਿੰਦੀ ਰਹਿੰਦੀ ਹੈ।
ਇਹ ਇੱਕ ਕਲਾਸਿਕ ਸਮੱਸਿਆ ਹੈ ਜੋ ਬ੍ਰਾਊਜ਼ਰ ਕੈਸ਼ ਅਤੇ CDN ਕੈਸ਼ ਦੇ ਮਿਲਾਪ ਕਾਰਨ ਹੁੰਦੀ ਹੈ।
- ਅਮਲੀ ਸਲਾਹ: ਨਵਾਂ ਫਾਈਲ ਨਾਮ, ਪਾਥ ਜਾਂ ਵਰਜਨ ਨੰਬਰ ਵਰਤ ਕੇ ਲੰਬੇ ਸਮੇਂ ਲਈ “ਫਾਈਲ ਨਾਮ ਓਵਰਰਾਈਟਿੰਗ” ਤੋਂ ਬਚਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋ।
9.2 HTML ਅੱਪਡੇਟ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਹੈ (ਪੰਨੇ ਦੀ ਸਮੱਗਰੀ/ਮਾਡਿਊਲ ਅਜੇ ਵੀ ਪੁਰਾਣੇ ਹਨ)
ਸਥਿਤੀ A: ਬੈਕਐਂਡ/ਪੋਸਟ-ਲੌਗਇਨ ਦ੍ਰਿਸ਼ ਨਵਾਂ ਹੈ, ਪਰ ਵਿਜ਼ਿਟਰ ਪੁਰਾਣਾ ਸੰਸਕਰਣ ਵੇਖਦੇ ਹਨ।
ਸਭ ਤੋਂ ਸੰਭਾਵਿਤ ਕਾਰਨ: ਵਿਜ਼ਿਟਰ ਦੇ ਸੈਸ਼ਨ ਲਈ HTML ਕੈਸ਼ ਕੀਤਾ ਗਿਆ ਹੈ।
- ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਜਾਂਚੋ ਕਿ ਕੀ ਇਸ ਕਿਸਮ ਦੇ ਪੰਨੇ ਦਾ HTML ਕੈਸ਼ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।
- ਜੇ ਕੈਸ਼ਿੰਗ ਦੀ ਲੋੜ ਹੈ: ਇੱਕ ਨਿਯੰਤਰਿਤ ਰਿਫ੍ਰੈਸ਼ ਰਣਨੀਤੀ ਦੀ ਲੋੜ ਹੈ; ਨਹੀਂ ਤਾਂ ਰਿਲੀਜ਼ ਅਨਿਯੰਤਰਿਤ ਹੋ ਜਾਵੇਗੀ।
ਸਥਿਤੀ ਬੀ: ਸਿਰਫ ਕੁਝ ਖੇਤਰ ਜਾਂ ਨੈੱਟਵਰਕ ਹੀ ਪੁਰਾਣੀ ਸਮੱਗਰੀ ਦਿਖਾ ਰਹੇ ਹਨ।
ਮੁੱਖ ਸ਼ੱਕ: ਐਜ ਨੋਡਾਂ 'ਤੇ ਵੱਖ-ਵੱਖ ਕੈਸ਼ਿੰਗ ਸਥਿਤੀਆਂ
- ਪਹੁੰਚ: ਅੰਤਰਾਂ ਨੂੰ ਸੁਲਝਾਉਣ ਲਈ ਵਰਜਨਿੰਗ/ਰੀਫਰੈਸ਼ ਨੀਤੀਆਂ ਦੀ ਵਰਤੋਂ ਕਰੋ; ਜਿੱਥੇ ਲੋੜ ਹੋਵੇ ਉੱਥੇ ਹੋਰ ਸਪੱਸ਼ਟ ਰੱਦ ਕਰਨ ਦੀ ਪ੍ਰਕਿਰਿਆ ਲਾਗੂ ਕਰੋ।
ਸਥਿਤੀ C: ਲੌਗ-ਇਨ ਕੀਤੇ ਉਪਭੋਗਤਾਵਾਂ ਜਾਂ ਖਰੀਦਦਾਰੀ ਟੋਕਰੀ ਨਾਲ ਸੰਬੰਧਤ ਸਮੱਸਿਆਵਾਂ
ਚੇਤਾਵਨੀ: ਕੈਸ਼ ਵਿੱਚ ਗਲਤ ਡਾਟਾ ਹੋ ਸਕਦਾ ਹੈ।
- ਤੁਰੰਤ ਜਾਂਚੋ ਕਿ ਕੀ ਯੂਜ਼ਰ-ਮੋਡ ਪੰਨੇ (ਜਿਵੇਂ ਕਿ ਸ਼ਾਪਿੰਗ ਬਾਸਕਟ, ਚੈੱਕਆਊਟ ਅਤੇ ਖਾਤਾ ਪੰਨੇ) ਕੈਸ਼ ਕੀਤੇ ਗਏ ਹਨ।
- ਜਾਂਚੋ ਕਿ ਕੀ ਕੈਸ਼ ਕੀ “User Mode cookie/Language/Currency” ਵਰਗੇ ਕੀ ਵੈਰੀਐਂਟਾਂ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦੀ ਹੈ।
10. ਸਿਫ਼ਾਰਸ਼ਾਂ
ਕਲਾਊਡਫਲੇਅਰ
- ਏਕੀਕ੍ਰਿਤ ਰਿਵਰਸ ਪ੍ਰਾਕਸੀ
- ਇਹ ਇਸ ਲਈ ਆਦਰਸ਼ ਹੈ: ਇੱਕ ਬਿਨਾਂ ਝੰਜਟ ਵਾਲੀ ਸ਼ੁਰੂਆਤ
- ਮੁੱਖ ਨੁਕਤੇ: ਅੱਪਡੇਟਾਂ ਨੂੰ ਸੰਬੋਧਨ ਕਰਨ ਲਈ ਵਰਜਨਿੰਗ ਰਣਨੀਤੀ; ਵਿਜ਼ਿਟਰ ਦੇ ਨਜ਼ਰੀਏ ਤੋਂ HTML ਕੈਸ਼ਿੰਗ
- ਖਤਰਾ: ਗਤੀਸ਼ੀਲ ਪੰਨਿਆਂ ਨੂੰ ਬਾਈਪਾਸ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।
ਟੈਂਸੈਂਟ ਕਲਾਊਡ ਇੰਟਰਨੈਸ਼ਨਲ ਐਜਵਨ
- ਏਕੀਕ੍ਰਿਤ ਰਿਵਰਸ ਪ੍ਰਾਕਸੀ
- ਇਹ ਉਨ੍ਹਾਂ ਸੰਸਥਾਵਾਂ ਲਈ ਉਚਿਤ ਹੈ ਜੋ ਮੈਨਲੈਂਡ ਚੀਨ ਵਿੱਚ ਡਾਟਾ ਸੈਂਟਰ ਦੀ ਸਮਰੱਥਾ ਦੀ ਵਰਤੋਂ ਕਰਨ ਅਤੇ ਏਕੀਕ੍ਰਿਤ ਕਨੈਕਟਿਵਿਟੀ ਪ੍ਰਾਪਤ ਕਰਨ ਦੀ ਇੱਛਾ ਰੱਖਦੀਆਂ ਹਨ।
- ਮੁਫ਼ਤ: ਇੱਕ ਮੁਫ਼ਤ ਯੋਜਨਾ/ਮੁਫ਼ਤ ਸੰਸਕਰਣ ਉਪਲਬਧ ਹੈ, ਪਰ ਵਰਤੋਂ ਦੀਆਂ ਸੀਮਾਵਾਂ ਅਤੇ ਨਿਯਮਾਂ ਅਤੇ ਸ਼ਰਤਾਂ ਨੂੰ ਧਿਆਨ ਨਾਲ ਦੇਖੋ।
- ਖਤਰੇ: ਨਿਯਮਾਂ, ਲੌਗਾਂ ਅਤੇ ਸਬਡੋਮੇਨ ਕੋਟਾ ਲਈ ਸਾਵਧਾਨ ਯੋਜਨਾਬੰਦੀ ਦੀ ਲੋੜ ਹੈ; HTML ਕੈਸ਼ਿੰਗ ਨਾਲ ਸਾਵਧਾਨੀ ਵਰਤੋ।
ਅਲੀਬਾਬਾ ਕਲਾਊਡ ਇੰਟਰਨੈਸ਼ਨਲ ESA
- ਏਕੀਕ੍ਰਿਤ ਰਿਵਰਸ ਪ੍ਰਾਕਸੀ
- ਮੁਫ਼ਤ: ਅੰਤਰਰਾਸ਼ਟਰੀ ਸਾਈਟ ਖਾਤਿਆਂ ਨੂੰ ਐਂਟਰੈਂਸ ਨਾਲ ਮੁਫ਼ਤ ਵਿੱਚ ਜੋੜਿਆ ਜਾ ਸਕਦਾ ਹੈ।
- ਖਤਰੇ: ਮੁਫ਼ਤ ਟੀਅਰ ਦਾ ਦਾਇਰਾ (SLA, ਸਹਾਇਤਾ ਅਤੇ ਗਤੀ ਸੀਮਾਵਾਂ) ਅਤੇ ਖੇਤਰੀ/ਰਜਿਸਟ੍ਰੇਸ਼ਨ ਦੀਆਂ ਲੋੜਾਂ ਨੂੰ ਪਹਿਲਾਂ ਤੋਂ ਪੁਸ਼ਟੀ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।
- ਇਹ ਉਚਿਤ ਹੈ: ਮੁਲਾਂਕਣ/ਟੈਸਟਿੰਗ ਅਤੇ ਹਲਕੇ ਪਹੁੰਚ ਲਈ; ਜਾਂ ਬਾਅਦ ਵਿੱਚ ਉੱਚ-ਪੱਧਰੀ ਪੈਕੇਜ ਵਿੱਚ ਅਪਗ੍ਰੇਡ ਕਰਨ ਲਈ; ਜਾਂ ਉਹਨਾਂ ਲਈ ਜੋ ਮੈਨਲੈਂਡ ਚੀਨ ਵਿੱਚ ਨੋਡ ਸਮਰੱਥਾ ਅਤੇ ਇੰਟੀਗ੍ਰੇਟਿਡ ਪਹੁੰਚ ਬਾਰੇ ਵਿਚਾਰ ਕਰ ਰਹੇ ਹਨ।
ਇੱਕ ਟੀਪੀ 30ਟੀ
- ਸਥਿਰ ਖਿੱਚ CDN
- ਸਿਫਾਰਸ਼ੀ: ਘੱਟ-ਖਤਰੇ ਵਾਲੀ ਸਥਿਰ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ
- ਮੁੱਖ ਨੁਕਤੇ: ਵਰਜਨ ਨੰਬਰਾਂ ਨੂੰ ਤਰਜੀਹ ਦਿਓ; ਬੈਕਅੱਪ ਵਜੋਂ `Purge` ਦੀ ਵਰਤੋਂ ਕਰੋ; ਇੱਕੋ ਨਾਮ ਵਾਲੀਆਂ ਫਾਈਲਾਂ ਨੂੰ ਓਵਰਰਾਈਟ ਕਰਨ ਤੋਂ ਬਚੋ
- ਖਤਰਾ: ਜੇ ਅੱਪਡੇਟ ਰਣਨੀਤੀ ਠੀਕ ਤਰੀਕੇ ਨਾਲ ਲਾਗੂ ਨਾ ਕੀਤੀ ਗਈ, ਤਾਂ ਤੁਹਾਨੂੰ ਅਕਸਰ “ਪੁਰਾਣੇ ਸਰੋਤ” ਮਿਲਣਗੇ।”
11. ਕਾਰਵਾਈ ਲਈ ਸਿਫ਼ਾਰਸ਼ਾਂ
- ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਆਰਕੀਟੈਕਚਰ ਚੁਣੋ: ਰਿਵਰਸ ਪ੍ਰਾਕਸੀ ਇੰਟੀਗ੍ਰੇਸ਼ਨ (Cloudflare/EdgeOne/ESA) ਜਾਂ ਸਟੈਟਿਕ Pull CDN (bunny)
- ਕਦਮ-ਦਰ-ਕਦਮ ਲਾਗੂਕਰਨ:ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਸਥਿਰ ਸਮੱਗਰੀ → ਫਿਰ ਵਰਜਨਿੰਗ ਨੀਤੀ → ਅਤੇ ਅੰਤ ਵਿੱਚ, HTML ਕੈਸ਼ਿੰਗ 'ਤੇ ਵਿਚਾਰ ਕਰੋ।
- ਡਿਪਲਾਇਮੈਂਟ ਤੋਂ ਬਾਅਦ, ਵੈਲੀਡੇਸ਼ਨ ਚੈੱਕਲਿਸਟ ਦੇ ਖਿਲਾਫ ਜਾਂਚ ਕਰੋ: ਹਿੱਟਸ, ਮੂਲ ਬੇਨਤੀਆਂ, ਅਪਡੇਟਸ, ਡਾਇਨਾਮਿਕ ਬਾਈਪਾਸ, ਗਲਤੀ ਦਰ
- ਜੇ ਤੁਹਾਨੂੰ ਇਹ ਹੋਰ ਤੇਜ਼ ਚਾਹੀਦਾ ਹੈ: “Cache Plugin” > “Image Optimisation” 'ਤੇ ਵਾਪਸ ਜਾਓ ਅਤੇ ਮੂਲ ਸਰਵਰ ਪਰਤ ਅਤੇ ਸਰੋਤ ਪਰਤ ਦੋਹਾਂ 'ਤੇ ਦਬਾਅ ਦੀ ਇੱਕ ਹੋਰ ਵਾਰੀ ਚਲਾਓ।
ਵਰਡਪ੍ਰੈੱਸ CDN ਅਕਸਰ ਪੁੱਛੇ ਜਾਣ ਵਾਲੇ ਸਵਾਲ
1. ਮੈਂ CDN ਵਰਤ ਰਿਹਾ ਹਾਂ, ਫਿਰ ਵੀ ਇਹ ਹੌਲੀ ਕਿਉਂ ਹੈ?
ਸਭ ਤੋਂ ਆਮ ਕਾਰਨ ਇਹ ਨਹੀਂ ਹੈ ਕਿ CDN ਅਕਾਰਗ ਹੈ, ਬਲਕਿ ਇਹ ਹੈ ਕਿ ਰੁਕਾਵਟ “ਡਿਲਿਵਰੀ ਲੇਅਰ” ਵਿੱਚ ਨਹੀਂ ਹੈ।
ਤੁਸੀਂ ਇਸਦਾ ਮੁਲਾਂਕਣ ਹੇਠ ਲਿਖੀ ਕ੍ਰਮਵਾਰ ਕਰ ਸਕਦੇ ਹੋ:
- TTFB ਅਜੇ ਵੀ ਉੱਚਾ ਹੈ।: ਇਹ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਮੂਲ ਸਰਵਰ HTML ਤਿਆਰ ਕਰਨ ਵਿੱਚ ਹੌਲੀ ਹੈ (ਡੇਟਾਬੇਸ/ਪਲੱਗਇਨ/ਕੈਸ਼ ਪਲੱਗਇਨ ਸੰਰਚਨਾ/ਸਰਵਰ ਪ੍ਰਦਰਸ਼ਨ) → ਅਨੁਕੂਲਨ ਲਈ ਮੂਲ ਸਰਵਰ ਪਰਤ 'ਤੇ ਵਾਪਸ ਜਾਓ
- ਪਹਿਲੀ ਸਕ੍ਰੀਨ 'ਤੇ ਵੱਡੀ ਤਸਵੀਰ ਬਹੁਤ ਹੌਲੀ ਲੋਡ ਹੁੰਦੀ ਹੈ।: ਜੇਕਰ ਚਿੱਤਰ ਫਾਈਲ ਦਾ ਆਕਾਰ, ਮਾਪ ਜਾਂ ਫਾਰਮੈਟ ਗਲਤ ਹੈ → ਪਹਿਲਾਂ ਚਿੱਤਰ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਓ (ਕੰਪਰੈਸ਼ਨ, WebP/AVIF, ਆਕਾਰ ਬਦਲਣ ਦੀ ਰਣਨੀਤੀ)
- ਤੀਜੀ-ਧਿਰ ਦੀਆਂ ਸਕ੍ਰਿਪਟਾਂ ਚੀਜ਼ਾਂ ਨੂੰ ਹੌਲੀ ਕਰ ਰਹੀਆਂ ਹਨ।: ਵਿਗਿਆਪਨ/ਸੰਖਿਆ-ਸ਼ਾਸਤਰ/ਗਾਹਕ ਸੇਵਾ ਸਕ੍ਰਿਪਟਾਂ ਨਾਲ ਆਮ ਸਮੱਸਿਆਵਾਂ → CDN ਆਮ ਤੌਰ 'ਤੇ ਮਦਦ ਨਹੀਂ ਕਰਦਾ; ਤੁਹਾਨੂੰ ਲੋਡਿੰਗ ਘਟਾਉਣ ਜਾਂ ਦੇਰੀ ਕਰਨ ਦੀ ਲੋੜ ਹੈ
- ਇਹ ਸਿਰਫ ਕੁਝ ਖੇਤਰਾਂ ਵਿੱਚ ਹੀ ਹੌਲੀ ਹੈ।ਇਹ ਨੋਡ ਕਵਰੇਜ, ਬੈਕਹਾਲ ਕਨੈਕਸ਼ਨ, ਜਾਂ ਕੈਸ਼ ਮਿਸ (ਘੱਟ ਹਿੱਟ ਦਰ) ਕਾਰਨ ਹੋ ਸਕਦਾ ਹੈ → ਹਿੱਟ ਦਰ ਅਤੇ ਬੈਕਹਾਲ ਸਥਿਤੀ ਦੀ ਜਾਂਚ ਕਰੋ
CDN “ਸੁਧਾਰੇ ਹੋਏ ਸਰੋਤ” ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਪਹੁੰਚਾਉਣ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੈ; ਹੌਲੀ ਮੂਲ ਸਰਵਰ, ਵੱਡੀਆਂ ਤਸਵੀਰਾਂ ਅਤੇ ਹੌਲੀ ਸਕ੍ਰਿਪਟਾਂ ਨੂੰ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਹੱਲ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।
2. ਮੈਂ CSS, JavaScript ਅਤੇ ਚਿੱਤਰਾਂ ਨੂੰ ਅੱਪਡੇਟ ਕਰਨ ਦੇ ਬਾਵਜੂਦ ਵੀ ਉਪਭੋਗਤਾ ਅਜੇ ਵੀ ਪੁਰਾਣਾ ਸੰਸਕਰਣ ਕਿਉਂ ਦੇਖ ਰਹੇ ਹਨ?
ਇਹ CDN ਸਥਿਤੀ ਨਾਲ ਸਬੰਧਤ ਸਭ ਤੋਂ ਆਮ ਸਮੱਸਿਆ ਹੈ; ਇਸਦਾ ਮੂਲ ਕਾਰਨ ਆਮ ਤੌਰ 'ਤੇ ਹੁੰਦਾ ਹੈ:ਸਰੋਤ URL ਨਹੀਂ ਬਦਲਿਆ ਹੈ।...ਕੈਸ਼ ਸਿਸਟਮ ਉਚਿਤ ਤੌਰ 'ਤੇ ਪੁਰਾਣੇ ਕੈਸ਼ ਤੋਂ ਹਿੱਟਸ ਸਰਵ ਕਰਨਾ ਜਾਰੀ ਰੱਖੇਗਾ।
ਸਭ ਤੋਂ ਭਰੋਸੇਯੋਗ ਤਰੀਕਾ:
- ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਵਰਜਨ ਨੰਬਰ: ਸਰੋਤ URL ਨੂੰ ਬਦਲਣ ਦੀ ਆਗਿਆ ਦਿਓ (ਉਦਾਹਰਨ ਵਜੋਂ)
style.css?ver=xxxx(ਜਾਂ ਫਾਈਲ ਨਾਮ ਹੈਸ਼) - ਪੁਰਜ: ਇੱਕ ਸੁਰੱਖਿਆ ਜਾਲ: ਕੈਸ਼ ਸਾਫ਼ ਕਰਨਾ ਸਿਰਫ਼ ਇੱਕ ਅਸਥਾਈ ਉਪਾਅ ਵਜੋਂ ਵਰਤਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਜਦੋਂ ਤੱਕ ਤੁਸੀਂ ਇੱਕ ਵਰਜਨਿੰਗ ਨੀਤੀ ਸਥਾਪਤ ਨਹੀਂ ਕਰ ਲੈਂਦੇ।
ਜੇ ਤੁਸੀਂ ਅਕਸਰ ਹੋਮਪੇਜ ਬੈਨਰ ਜਾਂ ਪ੍ਰਚਾਰਕ ਚਿੱਤਰ ਅਪਡੇਟ ਕਰਦੇ ਹੋ, ਤਾਂ ਅਸੀਂ ਸਿਫਾਰਸ਼ ਕਰਦੇ ਹਾਂ ਕਿ ਤੁਸੀਂ “ਇੱਕੋ ਨਾਮ ਵਾਲੀਆਂ ਫਾਈਲਾਂ ਨੂੰ ਓਵਰਰਾਈਟ ਕਰਨ” ਤੋਂ ਬਚੋ; ਇਸ ਦੀ ਥਾਂ ਨਵਾਂ ਫਾਈਲ ਨਾਮ ਜਾਂ ਨਵਾਂ ਡਾਇਰੈਕਟਰੀ ਪਾਥ ਵਰਤੋ (ਜੋ ਵਧੇਰੇ ਨਿਯੰਤਰਣ ਦਿੰਦਾ ਹੈ)।
3. ਕੀ ਮੈਨੂੰ HTML ਨੂੰ ਕੈਸ਼ ਕਰਨ ਦੀ ਲੋੜ ਹੈ? ਜੇ ਅਜਿਹਾ ਨਾ ਕੀਤਾ ਤਾਂ ਕੀ ਇਹ ਬੇਕਾਰ ਨਹੀਂ ਹੋਵੇਗਾ?
ਇਹ ਜ਼ਰੂਰੀ ਨਹੀਂ ਹੈ।
ਕਈ ਵੈੱਬਸਾਈਟਾਂ ਲਈ, CDN ਦੀ ਸਭ ਤੋਂ ਵੱਡੀ ਕੀਮਤ ਇਸ ਵਿੱਚ ਹੈ:
- ਸਥਿਰ ਸਰੋਤਾਂ (ਚਿੱਤਰ, CSS, JavaScript ਅਤੇ ਫੌਂਟ) ਦੀ ਤੇਜ਼ ਲੋਡਿੰਗ
- ਮੂਲ ਸਰਵਰ 'ਤੇ ਘੱਟ ਬੋਝ ਅਤੇ ਬਿਹਤਰ ਸਥਿਰਤਾ
HTML ਕੈਸ਼ ਲਾਭ ਵਾਕਈ ਵੱਧ ਹੋ ਸਕਦੇ ਹਨ (ਘੱਟ TTFB ਨਾਲ), ਪਰ ਖਤਰੇ ਵੀ ਸਭ ਤੋਂ ਵੱਧ ਹੁੰਦੇ ਹਨ: ਈ-ਕਾਮਰਸ, ਮੈਂਬਰਸ਼ਿਪ ਸੇਵਾਵਾਂ, ਵਿਅਕਤੀਗਤ ਸਮੱਗਰੀ, ਅਤੇ ਬਹੁ-ਭਾਸ਼ਾ/ਬਹੁ-ਮੁਦਰਾ ਪ੍ਰਣਾਲੀਆਂ ਸਾਰੀਆਂ ਗਲਤ ਸਮੱਗਰੀ ਨੂੰ ਕੈਸ਼ ਕਰਨ ਦੇ ਜੋਖਮ ਹੇਠ ਹਨ।
ਸੁਰੱਖਿਅਤ ਤਰੀਕਾ:
- ਇੱਕ ਸਥਿਰ ਸਥਿਤੀ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ: CDN (ਘੱਟ ਜੋਖਮ, ਉੱਚ ਵਾਪਸੀ)
- ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਵਰਜਨਿੰਗ ਨੀਤੀ ਅਤੇ ਵੈਲੀਡੇਸ਼ਨ ਚੈੱਕਲਿਸਟ ਪੂਰੀ ਤਰ੍ਹਾਂ ਕਾਰਗਰ ਹਨ।
- HTML ਨੂੰ ਕੈਸ਼ ਕਰਨ ਬਾਰੇ ਮੁੜ-ਮੁਲਾਂਕਣ ਕਰੋ (ਵਿਜ਼ਿਟਰ ਮੋਡ ਤੋਂ ਸ਼ੁਰੂ ਕਰਕੇ)
4. ਕੀ ਈ-ਕਾਮਰਸ ਸਾਈਟ CDN ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੀ ਹੈ? ਕੀ ਇਹ ਸ਼ਾਪਿੰਗ ਬਾਸਕਟ ਨੂੰ ਗੜਬੜ ਕਰ ਦੇਵੇਗਾ?
ਇਸਨੂੰ ਸਰਵ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਅਤੇ ਅਸਲ ਵਿੱਚ (ਘੱਟੋ-ਘੱਟ ਸਥਿਰ ਸਰੋਤਾਂ ਲਈ) ਸਰਵ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਪਰ ਉਪਭੋਗਤਾ-ਸਾਹਮਣੇ ਵਾਲੇ ਪੰਨਿਆਂ ਨੂੰ ਕੈਸ਼ ਕਰਨ ਤੋਂ ਬਚਣਾ ਚਾਹੀਦਾ ਹੈ।
- ਸਥਿਰ ਸਰੋਤਾਂ ਨੂੰ ਕੈਸ਼ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।: ਚਿੱਤਰ, ਸੀਐਸਐਸ, ਜੇਐਸ
- ਯੂਜ਼ਰ-ਮੋਡ ਪੇਜ ਨੂੰ ਬਾਈਪਾਸ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।ਖਰੀਦਦਾਰੀ ਟੋਕਰੀ, ਚੈੱਕਆਊਟ ਅਤੇ ਖਾਤੇ ਨਾਲ ਸਬੰਧਤ ਪੰਨਿਆਂ 'ਤੇ HTML ਨੂੰ ਕੈਸ਼ ਨਾ ਕਰੋ।
- ਜਦ ਤੱਕ ਤੁਸੀਂ ਇਹਨਾਂ ਪੰਨਿਆਂ ਨੂੰ HTML ਵਿੱਚ ਕੈਸ਼ ਨਹੀਂ ਕਰਦੇ, “ਕ੍ਰਾਸ-ਸ਼ਾਪਿੰਗ ਬਾਸਕਟ/ਕ੍ਰਾਸ-ਅਕਾਊਂਟ” ਸਮੱਸਿਆਵਾਂ ਦਾ ਖਤਰਾ ਕਾਫੀ ਘੱਟ ਹੋ ਜਾਵੇਗਾ।
5. ਮੈਂ CDN ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇੱਕ ਬਹੁ-ਭਾਸ਼ੀ/ਬਹੁ-ਮੁਦਰਾ ਸਾਈਟ ਕਿਵੇਂ ਸੈੱਟਅੱਪ ਕਰਾਂ ਤਾਂ ਜੋ ਭਾਸ਼ਾਵਾਂ ਅਤੇ ਕੀਮਤਾਂ ਆਪਸ ਵਿੱਚ ਨਾ ਮਿਲਣ?
ਮੁੱਦੇ ਦਾ ਸਾਰ ਇਹ ਹੈ ਕੈਸ਼ ਕੀ ਕੀ ਇਹ ਸਹੀ ਹੈ?
- ਭਾਸ਼ਾ (ਪਾਥ ਜਾਂ ਸਬਡੋਮੇਨ)
- ਕਰੰਸੀ (ਜੇ ਇਹ ਕੀਮਤ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੀ ਹੈ)
- ਕੀ ਤੁਸੀਂ ਲੌਗ ਇਨ ਹੋਏ ਹੋ? (cookie)
- ਖੇਤਰ/ਟੈਕਸ ਦਰ (ਜੇ ਪੰਨਾ ਖੇਤਰ ਅਨੁਸਾਰ ਵੱਖਰਾ ਹੋਵੇ)
ਜੇ ਇਹ ਮਾਪਦੰਡ ਕੈਸ਼ਿੰਗ ਲਾਜਿਕ ਵਿੱਚ ਸ਼ਾਮਿਲ ਨਾ ਕੀਤੇ ਗਏ, ਤਾਂ ਬਹੁਤ ਸੰਭਾਵਨਾ ਹੈ ਕਿ ਭਾਸ਼ਾ A ਦੇ ਉਪਭੋਗਤਾ ਭਾਸ਼ਾ B ਲਈ ਨਿਰਧਾਰਤ ਸਮੱਗਰੀ ਵੇਖਣਗੇ, ਜਾਂ ਕੀਮਤਾਂ ਅਸੰਗਤ ਹੋਣਗੀਆਂ।
6. ਕੀ ਮੈਨੂੰ ਇੱਕ ਰਿਵਰਸ ਪ੍ਰਾਕਸੀ ਹੱਲ (Cloudflare/EdgeOne/ESA) ਜਾਂ ਇੱਕ ਸਟੈਟਿਕ ਪੁੱਲ ਸਰਵਰ (bunny) ਚੁਣਨਾ ਚਾਹੀਦਾ ਹੈ?
ਤੁਸੀਂ ਆਪਣੇ “ਲਕਸ਼” ਅਤੇ “ਜੋਖਮ ਸਹਿਣਸ਼ੀਲਤਾ” ਦੇ ਆਧਾਰ 'ਤੇ ਚੁਣ ਸਕਦੇ ਹੋ:
- ਮੈਂ ਇੱਕੋ ਵਾਰੀ HTTPS + CDN + ਬੁਨਿਆਦੀ ਸੁਰੱਖਿਆ ਨੂੰ ਕਵਰ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹਾਂ, ਬਾਅਦ ਵਿੱਚ ਨਿਯਮਾਂ ਅਤੇ WAF ਤੱਕ ਵਿਸਥਾਰ ਕਰਨ ਦਾ ਵਿਕਲਪ ਨਾਲ:ਏਕੀਕ੍ਰਿਤ ਰਿਵਰਸ ਪ੍ਰਾਕਸੀ
- ਮੈਂ ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਪਹਿਲਾ ਕਦਮ (ਸਥਿਰ ਸਰੋਤ ਤੇਜ਼ੀ ਨਾਲ ਲੋਡ ਹੁੰਦੇ ਹਨ) ਨਾਲ ਸ਼ੁਰੂ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹਾਂ ਅਤੇ ਪੂਰੀ ਸਾਈਟ ਲਈ ਪ੍ਰਾਕਸੀ ਸੈੱਟਅੱਪ ਨਹੀਂ ਕਰਨਾ ਚਾਹੁੰਦਾ:ਸਥਿਰ ਖਿੱਚ CDN(ਜਿਵੇਂ ਖਰਗੋਸ਼)
ਜੇ ਤੁਸੀਂ ਅਨਿਸ਼ਚਿਤ ਹੋ, ਤਾਂ ਡਿਫੌਲਟ ਸਿਫਾਰਸ਼ ਇਹ ਹੈ:ਪਹਿਲਾ ਸਟੈਟਿਕ CDN → ਵਰਜਨਿੰਗ ਨੀਤੀ ਅਤੇ ਵੈਲੀਡੇਸ਼ਨ ਚੈੱਕਲਿਸਟ ਦੀ ਜਾਂਚ ਕਰੋ → ਫਿਰ ਇਹ ਫੈਸਲਾ ਕਰੋ ਕਿ ਪ੍ਰਾਕਸੀ-ਅਧਾਰਿਤ ਜਾਂ HTML ਕੈਸ਼ਿੰਗ ਹੱਲ ਲਾਗੂ ਕਰਨਾ ਹੈ।
7. ਕੀ ਮੁਫ਼ਤ ਵਰਜਨ ਨੂੰ ਸਿੱਧਾ ਲਾਈਵ ਵੈੱਬਸਾਈਟ 'ਤੇ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ?
ਇਸਨੂੰ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਪਰ ਤੁਹਾਨੂੰ “ਮੁਫ਼ਤ” ਨੂੰ “ਪੂਰੇ ਪੈਮਾਨੇ ਦਾ ਵਪਾਰਕ SLA ਵਾਲਾ ਹੱਲ” ਵਜੋਂ ਨਹੀਂ, ਸਗੋਂ “ਸ਼ੁਰੂਆਤੀ/ਟ੍ਰਾਇਲ/ਹਲਕੇ ਵਰਤੋਂ” ਵਜੋਂ ਹੀ ਸਮਝਣਾ ਚਾਹੀਦਾ ਹੈ।
- ਕੀ ਤੁਸੀਂ ਮੁਫ਼ਤ ਵਿਕਲਪ ਸਵੀਕਾਰ ਕਰਨ ਲਈ ਤਿਆਰ ਹੋਵੋਗੇ?ਕੋਟਾ ਸੀਮਾਵਾਂ, ਗੁੰਮ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ, ਸਹਾਇਤਾ ਵਿਕਲਪਾਂ ਵਿੱਚ ਅੰਤਰ, ਅਤੇ SLA ਵਚਨਬੱਧਤਾ ਦੀ ਸੰਭਾਵਿਤ ਗੈਰ-ਮੌਜੂਦਗੀ?
- ਜੇ ਇਹ ਸੰਭਵ ਨਹੀਂ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਮੁਫ਼ਤ ਵਰਜਨ ਨੂੰ ਇੱਕ ਟ੍ਰਾਇਲ ਵਜੋਂ ਲੈਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਇੱਕ ਵਧੇਰੇ ਉਚਿਤ ਯੋਜਨਾ ਵਿੱਚ ਅਪਗ੍ਰੇਡ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।
8. ਮੈਂ ਇਹ ਕਿਵੇਂ ਯਕੀਨੀ ਬਣਾ ਸਕਦਾ ਹਾਂ ਕਿ CDN ਅਸਲ ਵਿੱਚ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ, ਨਾ ਕਿ ਸਿਰਫ਼ ਪਲੇਸੀਬੋ ਪ੍ਰਭਾਵ ਹੈ?
ਜਾਂਚਣ ਲਈ ਇਹ ਤਿੰਨ ਕਦਮਾਂ ਦੀ ਪਾਲਣਾ ਕਰੋ (ਕੋਈ ਜਟਿਲ ਸੰਦਾਂ ਦੀ ਲੋੜ ਨਹੀਂ):
- ਜਾਂਚੋ ਕਿ ਕੀ CDN ਤੋਂ ਸਥਿਰ ਸਰੋਤ ਵਾਪਸ ਕੀਤੇ ਜਾ ਰਹੇ ਹਨ।(ਕੀ ਚਿੱਤਰਾਂ/CSS/JS ਦਾ ਸਰੋਤ ਬਦਲ ਗਿਆ ਹੈ?)
- ਜਾਂਚੋ ਕਿ ਹਿੱਟ ਦਰ ਅਤੇ ਵਾਪਸੀ ਦਰ ਵਿੱਚ ਸੁਧਾਰ ਆਇਆ ਹੈ ਜਾਂ ਨਹੀਂ।(ਸਿਰਫ਼ ਹਿੱਟ ਰੇਟ ਵਿੱਚ ਵਾਧਾ ਅਤੇ ਸਰੋਤ ਖਪਤ ਵਿੱਚ ਕਮੀ ਹੀ ਅਸਲੀ ਲਾਭ ਵਜੋਂ ਗਿਣੀ ਜਾਂਦੀ ਹੈ)
- CSS/ਚਿੱਤਰ ਪ੍ਰਮਾਣਿਕਤਾ ਲਈ ਨੀਤੀ ਨੂੰ ਅੱਪਡੇਟ ਕਰੋ।(ਲਾਗੂ ਸੰਸਕਰਣ ਨੰਬਰ, ਜੋ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਲਿੰਕ ਕੰਟਰੋਲ ਹੇਠ ਹੈ)
ਜੇ ਤੁਸੀਂ ਬਿੰਦੂ 3 ਦੀ ਪਾਲਣਾ ਨਹੀਂ ਕਰਦੇ, ਤਾਂ ਜਿੰਨਾ ਜ਼ਿਆਦਾ ਤੁਸੀਂ ਆਪਣੀ ਸਾਈਟ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਉਂਦੇ ਹੋ, ਉਤਨਾ ਹੀ ਜ਼ਿਆਦਾ ਸੰਭਾਵਨਾ ਹੈ ਕਿ ਅਪਡੇਟਸ ਲਾਗੂ ਨਹੀਂ ਹੋਣਗੀਆਂ; ਇਸ ਲਈ ਅਸੀਂ ਸਿਫਾਰਸ਼ ਕਰਦੇ ਹਾਂ ਕਿ ਤੁਸੀਂ ਆਪਣੀ ਵਰਜਨਿੰਗ ਰਣਨੀਤੀ ਨੂੰ ਮਿਆਰੀ ਬਣਾਉਣ ਨੂੰ ਤਰਜੀਹ ਦਿਓ।
9. ਮੇਨਲੈਂਡ ਚੀਨ ਐਕਸਲੇਸ਼ਨ ਫੀਚਰ ਅਕਸਰ ਫ੍ਰੀਜ਼ ਕਿਉਂ ਹੋ ਜਾਂਦਾ ਹੈ?
ਸਭ ਤੋਂ ਆਮ ਕਾਰਨ ਹਨ:ਚੁਣਿਆ ਗਿਆ ਖੇਤਰ ਰਜਿਸਟ੍ਰੇਸ਼ਨ ਦੀਆਂ ਲੋੜਾਂ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ।。
- ਜੇ ਤੁਸੀਂ ਇੱਕ ਪ੍ਰਾਕਸੀ ਖੇਤਰ ਚੁਣਨਾ ਚਾਹੁੰਦੇ ਹੋ ਜਿਸ ਵਿੱਚ ਮੁੱਖ ਭੂਮੀ ਚੀਨ ਸ਼ਾਮਲ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਆਮ ਤੌਰ 'ਤੇ ਪਹਿਲਾਂ ਪੂਰਾ ਕਰਨਾ ਪਵੇਗਾ। ਆਈਸੀਪੀ ਫਾਈਲਿੰਗ; ਜੇ ਤੁਸੀਂ ਰਜਿਸਟਰ ਨਹੀਂ ਕੀਤਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਸਿਰਫ ਉਹ ਖੇਤਰ ਚੁਣ ਸਕਦੇ ਹੋ ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਮੁੱਖ ਭੂਮੀ ਚੀਨ ਸ਼ਾਮਲ ਨਹੀਂ ਹੈ।
10. ਕੀ ਮੈਨੂੰ ਪਹਿਲਾਂ ਕੈਸ਼ ਪਲੱਗਇਨ ਇੰਸਟਾਲ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਜਾਂ ਪਹਿਲਾਂ CDN ਸੈੱਟਅੱਪ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ?
ਆਮ ਤੌਰ 'ਤੇ ਸਿਫਾਰਸ਼ ਕੀਤਾ ਗਿਆ ਕ੍ਰਮ ਹੈ:
- ਮੂਲ ਸਰਵਰ ਪਰਤ: ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਕੈਸ਼ਿੰਗ ਪਲੱਗਇਨ ਅਤੇ ਹੋਸਟਿੰਗ ਢਾਂਚਾ ਸਥਿਰ ਹੋਵੇ (TTFB ਘੱਟ, ਸਰਵਰ ਲੋਡ ਘੱਟ)
- ਸਰੋਤ ਪਰਤ: ਚਿੱਤਰਾਂ ਦਾ ਫਾਈਲ ਆਕਾਰ ਘਟਾਉਣ ਲਈ ਉਹਨਾਂ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਓ
- ਡਿਲਿਵਰੀ ਪਰਤ: CDN – ਸਰੋਤਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਅਤੇ ਵਧੇਰੇ ਭਰੋਸੇਯੋਗ ਢੰਗ ਨਾਲ ਪਹੁੰਚਾਉਣਾ
ਜੇਕਰ ਤੁਸੀਂ ਇਸ ਵੇਲੇ ਸਿਰਫ਼ ਇੱਕ ਹੀ ਕੰਮ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਪਰ ਤੁਹਾਨੂੰ ਚਿੰਤਾ ਹੈ ਕਿ ਇਹ ਗਲਤ ਹੋ ਸਕਦਾ ਹੈ:ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਸਥਿਰ ਸੰਰਚਨਾ: CDN (ਪੜਾਅ 1), ਸਥਿਰ ਵਾਪਸੀ ਅਤੇ ਸਭ ਤੋਂ ਘੱਟ ਜੋਖਮ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰਦਾ ਹੈ।