ਸਵੈ-ਹੋਸਟਿੰਗ ਤੀਜੀ-ਧਿਰ ਦੇ ਸਰੋਤ: ਚੰਗਾ, ਬੁਰਾ, ਬਦਸੂਰਤ

ਹਾਲ ਹੀ ਦੇ ਸਾਲਾਂ ਵਿੱਚ, ਫਰੰਟ-ਐਂਡ ਪ੍ਰੋਜੈਕਟਾਂ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਉਣ ਲਈ ਵੱਧ ਤੋਂ ਵੱਧ ਪਲੇਟਫਾਰਮ ਸਵੈ-ਹੋਸਟਿੰਗ ਜਾਂ ਤੀਜੀ-ਧਿਰ ਦੇ ਸਰੋਤਾਂ ਨੂੰ ਪ੍ਰੌਕਸੀ ਕਰਨ ਦੇ ਮੌਕੇ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ। Akamai ਤੁਹਾਨੂੰ ਸੈੱਟ ਕਰਨ ਲਈ ਸਹਾਇਕ ਹੈ ਖਾਸ ਪੈਰਾਮੀਟਰ ਸਵੈ-ਤਿਆਰ URL ਲਈ। Cloudflare ਕੋਲ Edge Workers ਤਕਨਾਲੋਜੀ ਹੈ। Fasterzine ਕਰ ਸਕਦਾ ਹੈ ਮੁੜ ਲਿਖਣਾ ਪੰਨਿਆਂ 'ਤੇ URLs ਤਾਂ ਜੋ ਉਹ ਸਾਈਟ ਦੇ ਮੁੱਖ ਡੋਮੇਨ 'ਤੇ ਸਥਿਤ ਤੀਜੀ-ਧਿਰ ਦੇ ਸਰੋਤਾਂ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੇ ਹਨ।

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

ਚੰਗਾ: ਬਿਹਤਰ ਪ੍ਰਦਰਸ਼ਨ

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

ਤੀਜੀ ਧਿਰ ਦੇ ਸਰੋਤ ਬਾਹਰੀ ਸਰੋਤਾਂ ਤੋਂ ਡਾਊਨਲੋਡ ਕੀਤੇ ਜਾਂਦੇ ਹਨ (ਇਸ ਤੋਂ ਲਏ ਗਏ ਹਨ ਇੱਥੋਂ)

ਤੀਜੀ-ਧਿਰ ਦੇ ਸਰੋਤ ਉਸੇ ਥਾਂ ਤੇ ਸਟੋਰ ਕੀਤੇ ਜਾਂਦੇ ਹਨ ਜਿਵੇਂ ਕਿ ਬਾਕੀ ਸਾਈਟ ਸਮੱਗਰੀ (ਤੋਂ ਲਿਆ ਗਿਆ ਹੈ ਇੱਥੋਂ)

ਸਥਿਤੀ ਇਸ ਤੱਥ ਦੁਆਰਾ ਵੀ ਸੁਧਾਰੀ ਗਈ ਹੈ ਕਿ ਬ੍ਰਾਊਜ਼ਰ ਮਲਟੀਪਲੈਕਸ ਕਰਨ ਦੀ ਸਮਰੱਥਾ ਦੀ ਵਰਤੋਂ ਕਰੇਗਾ ਅਤੇ HTTP/2 ਕਨੈਕਸ਼ਨ ਤੋਂ ਡੇਟਾ ਨੂੰ ਤਰਜੀਹ ਦੇਵੇਗਾ ਜੋ ਪਹਿਲਾਂ ਹੀ ਮੁੱਖ ਡੋਮੇਨ ਨਾਲ ਸਥਾਪਿਤ ਕੀਤਾ ਗਿਆ ਹੈ।

ਜੇਕਰ ਤੁਸੀਂ ਤੀਜੀ-ਧਿਰ ਦੇ ਸਰੋਤਾਂ ਦੀ ਮੇਜ਼ਬਾਨੀ ਨਹੀਂ ਕਰਦੇ ਹੋ, ਤਾਂ ਕਿਉਂਕਿ ਉਹਨਾਂ ਨੂੰ ਮੁੱਖ ਤੋਂ ਵੱਖਰੇ ਡੋਮੇਨ ਤੋਂ ਲੋਡ ਕੀਤਾ ਜਾਵੇਗਾ, ਉਹਨਾਂ ਨੂੰ ਤਰਜੀਹ ਨਹੀਂ ਦਿੱਤੀ ਜਾ ਸਕਦੀ। ਇਹ ਉਹਨਾਂ ਨੂੰ ਗਾਹਕ ਦੀ ਬੈਂਡਵਿਡਥ ਲਈ ਇੱਕ ਦੂਜੇ ਨਾਲ ਮੁਕਾਬਲਾ ਕਰਨ ਦਾ ਕਾਰਨ ਬਣੇਗਾ. ਇਸ ਦੇ ਨਤੀਜੇ ਵਜੋਂ ਇੱਕ ਪੰਨਾ ਬਣਾਉਣ ਲਈ ਮਹੱਤਵਪੂਰਨ ਸਮੱਗਰੀ ਲਈ ਲੋਡ ਹੋਣ ਦਾ ਸਮਾਂ ਹੋ ਸਕਦਾ ਹੈ ਜੋ ਕਿ ਆਦਰਸ਼ ਸਥਿਤੀਆਂ ਵਿੱਚ ਪ੍ਰਾਪਤ ਕੀਤੇ ਜਾਣ ਤੋਂ ਬਹੁਤ ਲੰਬਾ ਹੈ। ਇੱਥੇ HTTP/2 ਤਰਜੀਹ 'ਤੇ ਗੱਲ ਕਰੋ ਜੋ ਇਸ ਸਭ ਨੂੰ ਚੰਗੀ ਤਰ੍ਹਾਂ ਸਮਝਾਉਂਦਾ ਹੈ।

ਇਹ ਮੰਨਿਆ ਜਾ ਸਕਦਾ ਹੈ ਕਿ ਬਾਹਰੀ ਸਰੋਤਾਂ ਦੇ ਲਿੰਕਾਂ ਵਿੱਚ ਗੁਣਾਂ ਦੀ ਵਰਤੋਂ preconnect ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰੇਗਾ। ਹਾਲਾਂਕਿ, ਜੇਕਰ ਵੱਖ-ਵੱਖ ਡੋਮੇਨਾਂ ਲਈ ਇਹਨਾਂ ਵਿੱਚੋਂ ਬਹੁਤ ਸਾਰੇ ਲਿੰਕ ਹਨ, ਤਾਂ ਇਹ ਅਸਲ ਵਿੱਚ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਪਲ 'ਤੇ ਸੰਚਾਰ ਲਾਈਨ ਨੂੰ ਓਵਰਲੋਡ ਕਰ ਸਕਦਾ ਹੈ.

ਜੇਕਰ ਤੁਸੀਂ ਖੁਦ ਤੀਜੀ-ਧਿਰ ਦੇ ਸਰੋਤਾਂ ਦੀ ਮੇਜ਼ਬਾਨੀ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਨਿਯੰਤਰਣ ਕਰ ਸਕਦੇ ਹੋ ਕਿ ਇਹ ਸਰੋਤ ਕਲਾਇੰਟ ਨੂੰ ਕਿਵੇਂ ਦਿੱਤੇ ਜਾਣ। ਅਰਥਾਤ, ਅਸੀਂ ਹੇਠਾਂ ਦਿੱਤੇ ਬਾਰੇ ਗੱਲ ਕਰ ਰਹੇ ਹਾਂ:

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

ਤੁਸੀਂ ਆਪਣੀ ਕੈਚਿੰਗ ਪ੍ਰਬੰਧਨ ਰਣਨੀਤੀ (URL ਹੈਸ਼, ਸੰਸਕਰਣ, ਆਦਿ) ਵਿੱਚ ਸੰਬੰਧਿਤ ਸਮੱਗਰੀ ਨੂੰ ਸ਼ਾਮਲ ਕਰਕੇ, ਇੱਕ ਸਾਲ ਲਈ ਇੱਕ ਸਰੋਤ ਲਈ TTL ਨੂੰ ਵਧਾ ਸਕਦੇ ਹੋ। ਅਸੀਂ ਹੇਠਾਂ ਇਸ ਬਾਰੇ ਗੱਲ ਕਰਾਂਗੇ।

▍ ਤੀਜੀ-ਧਿਰ ਸੇਵਾਵਾਂ ਦੇ ਸੰਚਾਲਨ ਜਾਂ ਉਹਨਾਂ ਦੇ ਬੰਦ ਹੋਣ ਵਿੱਚ ਰੁਕਾਵਟਾਂ ਤੋਂ ਸੁਰੱਖਿਆ

ਸਵੈ-ਹੋਸਟਿੰਗ ਥਰਡ-ਪਾਰਟੀ ਸਰੋਤਾਂ ਦਾ ਇੱਕ ਹੋਰ ਦਿਲਚਸਪ ਪਹਿਲੂ ਇਹ ਹੈ ਕਿ ਇਹ ਤੁਹਾਨੂੰ ਤੀਜੀ-ਧਿਰ ਦੀਆਂ ਸੇਵਾਵਾਂ ਦੇ ਆਊਟੇਜ ਨਾਲ ਜੁੜੇ ਜੋਖਮਾਂ ਨੂੰ ਘਟਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। ਚਲੋ ਇਹ ਮੰਨ ਲਓ ਕਿ ਤੁਹਾਡੇ ਦੁਆਰਾ ਵਰਤੇ ਜਾ ਰਹੇ ਤੀਜੀ-ਧਿਰ A/B ਟੈਸਟਿੰਗ ਹੱਲ ਨੂੰ ਇੱਕ ਬਲੌਕਿੰਗ ਸਕ੍ਰਿਪਟ ਵਜੋਂ ਲਾਗੂ ਕੀਤਾ ਗਿਆ ਹੈ ਜੋ ਪੰਨੇ ਦੇ ਮੁੱਖ ਭਾਗ ਵਿੱਚ ਲੋਡ ਹੁੰਦਾ ਹੈ। ਇਹ ਸਕ੍ਰਿਪਟ ਹੌਲੀ-ਹੌਲੀ ਲੋਡ ਹੁੰਦੀ ਹੈ। ਜੇਕਰ ਸੰਬੰਧਿਤ ਸਕ੍ਰਿਪਟ ਲੋਡ ਕਰਨ ਵਿੱਚ ਅਸਫਲ ਰਹਿੰਦੀ ਹੈ, ਤਾਂ ਪੰਨਾ ਖਾਲੀ ਹੋ ਜਾਵੇਗਾ। ਜੇਕਰ ਇਸਨੂੰ ਲੋਡ ਹੋਣ ਵਿੱਚ ਬਹੁਤ ਲੰਮਾ ਸਮਾਂ ਲੱਗਦਾ ਹੈ, ਤਾਂ ਪੰਨਾ ਇੱਕ ਲੰਬੀ ਦੇਰੀ ਨਾਲ ਦਿਖਾਈ ਦੇਵੇਗਾ। ਜਾਂ, ਮੰਨ ਲਓ ਕਿ ਪ੍ਰੋਜੈਕਟ ਕਿਸੇ ਤੀਜੀ-ਧਿਰ CDN ਸਰੋਤ ਤੋਂ ਡਾਊਨਲੋਡ ਕੀਤੀ ਲਾਇਬ੍ਰੇਰੀ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। ਚਲੋ ਕਲਪਨਾ ਕਰੀਏ ਕਿ ਇਸ ਸਰੋਤ ਨੂੰ ਅਸਫਲਤਾ ਦਾ ਅਨੁਭਵ ਕੀਤਾ ਗਿਆ ਸੀ ਜਾਂ ਕਿਸੇ ਖਾਸ ਦੇਸ਼ ਵਿੱਚ ਬਲੌਕ ਕੀਤਾ ਗਿਆ ਸੀ। ਅਜਿਹੀ ਸਥਿਤੀ ਸਾਈਟ ਦੇ ਤਰਕ ਦੀ ਉਲੰਘਣਾ ਵੱਲ ਲੈ ਜਾਵੇਗੀ.

ਇਹ ਪਤਾ ਲਗਾਉਣ ਲਈ ਕਿ ਤੁਹਾਡੀ ਸਾਈਟ ਕਿਵੇਂ ਕੰਮ ਕਰਦੀ ਹੈ ਜਦੋਂ ਕੁਝ ਬਾਹਰੀ ਸੇਵਾ ਉਪਲਬਧ ਨਹੀਂ ਹੁੰਦੀ ਹੈ, ਤੁਸੀਂ SPOF ਸੈਕਸ਼ਨ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ webpagetest.org.

webpagetest.org 'ਤੇ SPOF ਸੈਕਸ਼ਨ

▍ਬ੍ਰਾਊਜ਼ਰਾਂ ਵਿੱਚ ਸਮੱਗਰੀ ਦੀ ਕੈਸ਼ਿੰਗ ਨਾਲ ਸਮੱਸਿਆਵਾਂ ਬਾਰੇ ਕੀ? (ਸੰਕੇਤ: ਇਹ ਇੱਕ ਮਿੱਥ ਹੈ)

ਤੁਸੀਂ ਸੋਚ ਸਕਦੇ ਹੋ ਕਿ ਜਨਤਕ CDNs ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਆਪਣੇ ਆਪ ਬਿਹਤਰ ਸਰੋਤ ਪ੍ਰਦਰਸ਼ਨ ਵੱਲ ਲੈ ਜਾਵੇਗਾ, ਕਿਉਂਕਿ ਇਹਨਾਂ ਸੇਵਾਵਾਂ ਵਿੱਚ ਉੱਚ-ਗੁਣਵੱਤਾ ਵਾਲੇ ਨੈਟਵਰਕ ਹਨ ਅਤੇ ਦੁਨੀਆ ਭਰ ਵਿੱਚ ਵੰਡੇ ਜਾਂਦੇ ਹਨ। ਪਰ ਸਭ ਕੁਝ ਅਸਲ ਵਿੱਚ ਥੋੜਾ ਹੋਰ ਗੁੰਝਲਦਾਰ ਹੈ.

ਮੰਨ ਲਓ ਕਿ ਸਾਡੇ ਕੋਲ ਕਈ ਵੱਖਰੀਆਂ ਸਾਈਟਾਂ ਹਨ: website1.com, website2.com, website3.com। ਇਹ ਸਾਰੀਆਂ ਸਾਈਟਾਂ jQuery ਲਾਇਬ੍ਰੇਰੀ ਦੀ ਵਰਤੋਂ ਕਰਦੀਆਂ ਹਨ। ਅਸੀਂ ਇਸਨੂੰ ਇੱਕ CDN ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਉਹਨਾਂ ਨਾਲ ਜੋੜਦੇ ਹਾਂ, ਉਦਾਹਰਨ ਲਈ - googleapis.com. ਤੁਸੀਂ ਉਮੀਦ ਕਰ ਸਕਦੇ ਹੋ ਕਿ ਬ੍ਰਾਊਜ਼ਰ ਇੱਕ ਵਾਰ ਲਾਇਬ੍ਰੇਰੀ ਨੂੰ ਡਾਉਨਲੋਡ ਅਤੇ ਕੈਸ਼ ਕਰੇਗਾ, ਅਤੇ ਫਿਰ ਇਸਨੂੰ ਸਾਰੀਆਂ ਤਿੰਨ ਸਾਈਟਾਂ ਵਿੱਚ ਵਰਤ ਸਕਦਾ ਹੈ। ਇਸ ਨਾਲ ਨੈੱਟਵਰਕ 'ਤੇ ਲੋਡ ਘੱਟ ਹੋ ਸਕਦਾ ਹੈ। ਸ਼ਾਇਦ ਇਹ ਤੁਹਾਨੂੰ ਕਿਤੇ ਪੈਸੇ ਬਚਾਉਣ ਅਤੇ ਸਰੋਤ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰੇਗਾ। ਵਿਹਾਰਕ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ, ਸਭ ਕੁਝ ਵੱਖਰਾ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ. ਉਦਾਹਰਨ ਲਈ, Safari ਕਹਿੰਦੇ ਹਨ ਇੱਕ ਵਿਸ਼ੇਸ਼ਤਾ ਹੈ ਸੂਝਵਾਨ ਟਰੈਕਿੰਗ ਰੋਕਥਾਮ: ਕੈਸ਼ ਦਸਤਾਵੇਜ਼ ਦੇ ਸਰੋਤ ਅਤੇ ਤੀਜੀ-ਧਿਰ ਦੇ ਸਰੋਤ ਦੇ ਸਰੋਤ ਦੇ ਆਧਾਰ 'ਤੇ ਦੋਹਰੀ ਕੁੰਜੀਆਂ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। ਇੱਥੇ ਇਸ ਵਿਸ਼ੇ 'ਤੇ ਵਧੀਆ ਲੇਖ.

ਪੁਰਾਣੀ ਪੜ੍ਹਾਈ ਯਾਹੂ и ਫੇਸਬੁੱਕ, ਨਾਲ ਹੀ ਹੋਰ ਹਾਲੀਆ ਖੋਜ ਪੌਲ ਕੈਲਵਾਨੋ, ਦਿਖਾਉਂਦੇ ਹਨ ਕਿ ਸਰੋਤਾਂ ਨੂੰ ਬ੍ਰਾਊਜ਼ਰ ਕੈਚਾਂ ਵਿੱਚ ਉਦੋਂ ਤੱਕ ਸਟੋਰ ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ ਜਿੰਨਾ ਚਿਰ ਅਸੀਂ ਉਮੀਦ ਕਰ ਸਕਦੇ ਹਾਂ: “ਕਿਸੇ ਪ੍ਰੋਜੈਕਟ ਦੇ ਆਪਣੇ ਅਤੇ ਤੀਜੀ-ਧਿਰ ਦੇ ਸਰੋਤਾਂ ਦੇ ਕੈਚਿੰਗ ਸਮੇਂ ਵਿੱਚ ਇੱਕ ਗੰਭੀਰ ਪਾੜਾ ਹੈ। ਅਸੀਂ CSS ਅਤੇ ਵੈਬ ਫੌਂਟਾਂ ਬਾਰੇ ਗੱਲ ਕਰ ਰਹੇ ਹਾਂ। ਅਰਥਾਤ, 95% ਮੂਲ ਫੌਂਟਾਂ ਦੀ ਕੈਸ਼ ਲਾਈਫ ਇੱਕ ਹਫ਼ਤੇ ਤੋਂ ਵੱਧ ਹੁੰਦੀ ਹੈ, ਜਦੋਂ ਕਿ 50% ਥਰਡ-ਪਾਰਟੀ ਫੌਂਟਾਂ ਦੀ ਕੈਸ਼ ਲਾਈਫ ਇੱਕ ਹਫ਼ਤੇ ਤੋਂ ਘੱਟ ਹੁੰਦੀ ਹੈ! ਇਹ ਵੈੱਬ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਫੌਂਟ ਫਾਈਲਾਂ ਦੀ ਮੇਜ਼ਬਾਨੀ ਕਰਨ ਦਾ ਇੱਕ ਮਜਬੂਰ ਕਾਰਨ ਦਿੰਦਾ ਹੈ!

ਨਤੀਜੇ ਵਜੋਂ, ਜੇਕਰ ਤੁਸੀਂ ਦੂਜੇ ਲੋਕਾਂ ਦੀ ਸਮਗਰੀ ਦੀ ਮੇਜ਼ਬਾਨੀ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਬ੍ਰਾਊਜ਼ਰ ਕੈਚਿੰਗ ਦੇ ਕਾਰਨ ਕੋਈ ਵੀ ਪ੍ਰਦਰਸ਼ਨ ਸਮੱਸਿਆਵਾਂ ਨਹੀਂ ਦੇਖ ਸਕੋਗੇ।

ਹੁਣ ਜਦੋਂ ਅਸੀਂ ਤੀਜੀ-ਧਿਰ ਦੀ ਸਵੈ-ਹੋਸਟਿੰਗ ਦੀਆਂ ਸ਼ਕਤੀਆਂ ਨੂੰ ਕਵਰ ਕਰ ਲਿਆ ਹੈ, ਆਓ ਇਸ ਬਾਰੇ ਗੱਲ ਕਰੀਏ ਕਿ ਇਸ ਪਹੁੰਚ ਨੂੰ ਇੱਕ ਮਾੜੇ ਤੋਂ ਵਧੀਆ ਲਾਗੂ ਕਰਨ ਬਾਰੇ ਕਿਵੇਂ ਦੱਸਿਆ ਜਾਵੇ।

ਬੁਰਾ: ਸ਼ੈਤਾਨ ਵੇਰਵੇ ਵਿੱਚ ਹੈ

ਤੀਜੀ-ਧਿਰ ਦੇ ਸਰੋਤਾਂ ਨੂੰ ਤੁਹਾਡੇ ਆਪਣੇ ਡੋਮੇਨ ਵਿੱਚ ਤਬਦੀਲ ਕਰਨਾ ਇਹ ਯਕੀਨੀ ਬਣਾਏ ਬਿਨਾਂ ਆਪਣੇ ਆਪ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਕਿ ਅਜਿਹੇ ਸਰੋਤ ਸਹੀ ਢੰਗ ਨਾਲ ਕੈਸ਼ ਕੀਤੇ ਗਏ ਹਨ।

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

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

ਇਹ ਸੱਚ ਹੈ, ਜੇਕਰ ਅਸੀਂ ਉਹਨਾਂ ਸਮੱਗਰੀਆਂ ਬਾਰੇ ਗੱਲ ਕਰਦੇ ਹਾਂ ਜੋ ਅਕਸਰ ਅੱਪਡੇਟ ਹੁੰਦੀਆਂ ਹਨ (ਟੈਗ ਮੈਨੇਜਰ, A/B ਟੈਸਟਿੰਗ ਲਈ ਹੱਲ), ਤਾਂ ਉਹਨਾਂ ਨੂੰ CDN ਟੂਲਸ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਕੈਚ ਕਰਨਾ ਇੱਕ ਅਜਿਹਾ ਕੰਮ ਹੈ ਜੋ ਹੱਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਬਹੁਤ ਜ਼ਿਆਦਾ ਗੁੰਝਲਦਾਰ ਹੈ। ਕਮਾਂਡਰ ਐਕਟ ਵਰਗੀਆਂ ਸੇਵਾਵਾਂ, ਇੱਕ ਟੈਗ ਪ੍ਰਬੰਧਨ ਹੱਲ, ਨਵੇਂ ਸੰਸਕਰਣਾਂ ਨੂੰ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨ ਵੇਲੇ ਵੈਬਹੁੱਕ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ। ਇਹ ਤੁਹਾਨੂੰ CDN 'ਤੇ ਇੱਕ ਕੈਸ਼ ਫਲੱਸ਼ ਨੂੰ ਜ਼ਬਰਦਸਤੀ ਕਰਨ ਦੀ ਸਮਰੱਥਾ ਦਿੰਦਾ ਹੈ, ਜਾਂ, ਬਿਹਤਰ ਅਜੇ ਤੱਕ, ਇੱਕ ਹੈਸ਼ ਜਾਂ URL ਅੱਪਡੇਟ ਨੂੰ ਮਜਬੂਰ ਕਰਨ ਦੀ ਸਮਰੱਥਾ ਦਿੰਦਾ ਹੈ।

▍ ਗਾਹਕਾਂ ਨੂੰ ਸਮੱਗਰੀ ਦੀ ਅਨੁਕੂਲ ਡਿਲੀਵਰੀ

ਇਸ ਤੋਂ ਇਲਾਵਾ, ਜਦੋਂ ਅਸੀਂ ਕੈਚਿੰਗ ਬਾਰੇ ਗੱਲ ਕਰਦੇ ਹਾਂ, ਤਾਂ ਸਾਨੂੰ ਇਸ ਤੱਥ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਣ ਦੀ ਜ਼ਰੂਰਤ ਹੁੰਦੀ ਹੈ ਕਿ CDN 'ਤੇ ਵਰਤੀਆਂ ਗਈਆਂ ਕੈਚਿੰਗ ਸੈਟਿੰਗਾਂ ਕੁਝ ਤੀਜੀ-ਧਿਰ ਦੇ ਸਰੋਤਾਂ ਲਈ ਢੁਕਵੀਂ ਨਹੀਂ ਹੋ ਸਕਦੀਆਂ ਹਨ। ਉਦਾਹਰਨ ਲਈ, ਅਜਿਹੇ ਸਰੋਤ ਉਪਭੋਗਤਾ ਏਜੰਟ ਸੁੰਘਣ (ਅਡੈਪਟਿਵ ਸਰਵਿੰਗ) ਤਕਨਾਲੋਜੀ ਦੀ ਵਰਤੋਂ ਉਹਨਾਂ ਬ੍ਰਾਊਜ਼ਰਾਂ ਲਈ ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਅਨੁਕੂਲਿਤ ਸਮੱਗਰੀ ਦੇ ਸੰਸਕਰਣਾਂ ਦੇ ਨਾਲ ਖਾਸ ਬ੍ਰਾਊਜ਼ਰਾਂ ਨੂੰ ਸੇਵਾ ਦੇਣ ਲਈ ਕਰ ਸਕਦੇ ਹਨ। ਇਹ ਤਕਨਾਲੋਜੀਆਂ ਬ੍ਰਾਊਜ਼ਰ ਸਮਰੱਥਾਵਾਂ ਦਾ ਪਤਾ ਲਗਾਉਣ ਲਈ ਨਿਯਮਤ ਸਮੀਕਰਨ, ਜਾਂ HTTP ਸਿਰਲੇਖ ਜਾਣਕਾਰੀ ਦੇ ਇੱਕ ਡੇਟਾਬੇਸ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀਆਂ ਹਨ। User-Agent. ਇੱਕ ਵਾਰ ਜਦੋਂ ਉਹਨਾਂ ਨੂੰ ਪਤਾ ਲੱਗ ਜਾਂਦਾ ਹੈ ਕਿ ਉਹ ਕਿਸ ਬ੍ਰਾਊਜ਼ਰ ਨਾਲ ਕੰਮ ਕਰ ਰਹੇ ਹਨ, ਤਾਂ ਉਹ ਇਸਨੂੰ ਇਸਦੇ ਲਈ ਤਿਆਰ ਕੀਤੀ ਸਮੱਗਰੀ ਦਿੰਦੇ ਹਨ।

ਇੱਥੇ ਤੁਸੀਂ ਦੋ ਸੇਵਾਵਾਂ ਨੂੰ ਯਾਦ ਕਰ ਸਕਦੇ ਹੋ। ਪਹਿਲਾ googlefonts.com ਹੈ। ਦੂਜਾ polyfill.io ਹੈ। ਗੂਗਲ ਫੌਂਟਸ ਸੇਵਾ ਬ੍ਰਾਊਜ਼ਰ ਦੀਆਂ ਸਮਰੱਥਾਵਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹੋਏ, ਕਿਸੇ ਖਾਸ ਸਰੋਤ ਲਈ, ਵੱਖ-ਵੱਖ CSS ਕੋਡ ਪ੍ਰਦਾਨ ਕਰਦੀ ਹੈ (ਵਰਤਦੇ ਹੋਏ woff2 ਸਰੋਤਾਂ ਨੂੰ ਲਿੰਕ ਦੇਣਾ unicode-range).

ਇੱਥੇ ਵੱਖ-ਵੱਖ ਬ੍ਰਾਉਜ਼ਰਾਂ ਤੋਂ ਬਣਾਏ ਗਏ ਕੁਝ ਗੂਗਲ ਫੌਂਟ ਸਵਾਲਾਂ ਦੇ ਨਤੀਜੇ ਹਨ।

ਕ੍ਰੋਮ ਤੋਂ ਗੂਗਲ ਫੌਂਟਸ ਦੀ ਪੁੱਛਗਿੱਛ ਦਾ ਨਤੀਜਾ

IE10 ਤੋਂ ਚਲਾਈ ਗਈ ਗੂਗਲ ਫੌਂਟ ਪੁੱਛਗਿੱਛ ਦਾ ਨਤੀਜਾ

Polyfill.io ਬ੍ਰਾਊਜ਼ਰ ਨੂੰ ਸਿਰਫ਼ ਉਹੀ ਪੌਲੀਫਿਲ ਦਿੰਦਾ ਹੈ ਜਿਸਦੀ ਇਸਨੂੰ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਇਹ ਪ੍ਰਦਰਸ਼ਨ ਕਾਰਨਾਂ ਕਰਕੇ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

ਉਦਾਹਰਨ ਲਈ, ਆਓ ਦੇਖੀਏ ਕਿ ਕੀ ਹੁੰਦਾ ਹੈ ਜੇਕਰ ਤੁਸੀਂ ਵੱਖ-ਵੱਖ ਬ੍ਰਾਊਜ਼ਰਾਂ ਤੋਂ ਹੇਠਾਂ ਦਿੱਤੀ ਬੇਨਤੀ ਨੂੰ ਚਲਾਉਂਦੇ ਹੋ: https://polyfill.io/v3/polyfill.js?features=default

IE10 ਤੋਂ ਲਾਗੂ ਕੀਤੀ ਅਜਿਹੀ ਬੇਨਤੀ ਦੇ ਜਵਾਬ ਵਿੱਚ, 34 KB ਡੇਟਾ ਪ੍ਰਾਪਤ ਕੀਤਾ ਜਾਵੇਗਾ। ਅਤੇ ਇਸਦਾ ਜਵਾਬ, ਕ੍ਰੋਮ ਤੋਂ ਚਲਾਇਆ ਗਿਆ, ਖਾਲੀ ਹੋਵੇਗਾ।

ਗੁੱਸੇ: ਕੁਝ ਗੋਪਨੀਯਤਾ ਵਿਚਾਰ

ਇਹ ਬਿੰਦੂ ਕ੍ਰਮ ਵਿੱਚ ਆਖਰੀ ਹੈ, ਪਰ ਘੱਟੋ ਘੱਟ ਮਹੱਤਵਪੂਰਨ ਨਹੀਂ ਹੈ. ਬਿੰਦੂ ਇਹ ਹੈ ਕਿ ਪ੍ਰੋਜੈਕਟ ਦੇ ਮੁੱਖ ਡੋਮੇਨ ਜਾਂ ਇਸਦੇ ਸਬਡੋਮੇਨ 'ਤੇ ਤੀਜੀ-ਧਿਰ ਦੇ ਸਰੋਤਾਂ ਦੀ ਸਵੈ-ਹੋਸਟਿੰਗ ਉਪਭੋਗਤਾਵਾਂ ਦੀ ਗੋਪਨੀਯਤਾ ਨੂੰ ਖਤਰੇ ਵਿੱਚ ਪਾ ਸਕਦੀ ਹੈ ਅਤੇ ਮੁੱਖ ਵੈਬ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਨਕਾਰਾਤਮਕ ਤੌਰ 'ਤੇ ਪ੍ਰਭਾਵਿਤ ਕਰ ਸਕਦੀ ਹੈ।

ਜੇਕਰ ਤੁਹਾਡਾ CDN ਸਿਸਟਮ ਸਹੀ ਢੰਗ ਨਾਲ ਕੌਂਫਿਗਰ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਆਪਣੀ ਡੋਮੇਨ ਦੀਆਂ ਕੂਕੀਜ਼ ਨੂੰ ਤੀਜੀ-ਧਿਰ ਦੀ ਸੇਵਾ ਨੂੰ ਭੇਜਣਾ ਬੰਦ ਕਰ ਸਕਦੇ ਹੋ। ਜੇਕਰ CDN ਪੱਧਰ 'ਤੇ ਸਹੀ ਫਿਲਟਰਿੰਗ ਦਾ ਆਯੋਜਨ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਹੈ, ਤਾਂ ਤੁਹਾਡੀ ਸੈਸ਼ਨ ਕੂਕੀਜ਼, ਜੋ ਆਮ ਤੌਰ 'ਤੇ JavaScript ਵਿੱਚ ਨਹੀਂ ਵਰਤੀਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ (ਨਾਲ httponly), ਕਿਸੇ ਵਿਦੇਸ਼ੀ ਮੇਜ਼ਬਾਨ ਨੂੰ ਭੇਜਿਆ ਜਾ ਸਕਦਾ ਹੈ।

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

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

ਹਾਲਾਂਕਿ ਵੈੱਬਸਾਈਟ ਕੂਕੀਜ਼ ਨੂੰ ਸਾਰੇ ਸਬਡੋਮੇਨਾਂ (ਉਦਾਹਰਨ ਲਈ - *.website.com) ਲਈ ਉਪਲਬਧ ਕਰਵਾਉਣ ਦੀ ਸਿਫ਼ਾਰਸ਼ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਬਹੁਤ ਸਾਰੀਆਂ ਸਾਈਟਾਂ ਅਜਿਹਾ ਕਰਦੀਆਂ ਹਨ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਅਜਿਹੀਆਂ ਕੂਕੀਜ਼ ਆਪਣੇ ਆਪ ਹੀ ਕਿਸੇ ਭੇਸ ਵਾਲੇ ਥਰਡ-ਪਾਰਟੀ ਟਰੈਕਰ ਨੂੰ ਭੇਜੀਆਂ ਜਾਂਦੀਆਂ ਹਨ। ਨਤੀਜੇ ਵਜੋਂ, ਅਸੀਂ ਹੁਣ ਕਿਸੇ ਗੋਪਨੀਯਤਾ ਬਾਰੇ ਗੱਲ ਨਹੀਂ ਕਰ ਸਕਦੇ ਹਾਂ।

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

ਨਤੀਜੇ

ਜੇਕਰ ਤੁਸੀਂ ਛੇਤੀ ਹੀ ਤੀਜੀ-ਧਿਰ ਦੇ ਸਰੋਤਾਂ ਦੀ ਸਵੈ-ਹੋਸਟਿੰਗ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੀ ਯੋਜਨਾ ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ ਮੈਨੂੰ ਤੁਹਾਨੂੰ ਕੁਝ ਸਲਾਹ ਦੇਣ ਦਿਓ:

• ਆਪਣੀਆਂ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ JS ਲਾਇਬ੍ਰੇਰੀਆਂ, ਫੌਂਟਾਂ ਅਤੇ CSS ਫਾਈਲਾਂ ਦੀ ਮੇਜ਼ਬਾਨੀ ਕਰੋ। ਇਹ ਕਿਸੇ ਤੀਜੀ-ਧਿਰ ਦੀ ਸੇਵਾ ਦੇ ਨੁਕਸ ਕਾਰਨ ਸਾਈਟ ਲਈ ਮਹੱਤਵਪੂਰਨ ਸਰੋਤ ਦੇ ਅਣਉਪਲਬਧ ਹੋਣ ਕਾਰਨ ਸਾਈਟ ਦੀ ਅਸਫਲਤਾ ਜਾਂ ਪ੍ਰਦਰਸ਼ਨ ਵਿੱਚ ਗਿਰਾਵਟ ਦੇ ਜੋਖਮ ਨੂੰ ਘਟਾ ਦੇਵੇਗਾ।
• ਕਿਸੇ CDN 'ਤੇ ਤੀਜੀ-ਧਿਰ ਦੇ ਸਰੋਤਾਂ ਨੂੰ ਕੈਸ਼ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਇਹ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਉਹਨਾਂ ਦੀਆਂ ਫਾਈਲਾਂ ਨੂੰ ਨਾਮ ਦੇਣ ਵੇਲੇ ਕਿਸੇ ਕਿਸਮ ਦਾ ਸੰਸਕਰਣ ਸਿਸਟਮ ਵਰਤਿਆ ਗਿਆ ਹੈ, ਜਾਂ ਇਹ ਕਿ ਤੁਸੀਂ ਇਹਨਾਂ ਸਰੋਤਾਂ ਦੇ ਜੀਵਨ ਚੱਕਰ ਨੂੰ ਮੈਨੂਅਲੀ ਜਾਂ ਸਵੈਚਲਿਤ ਤੌਰ 'ਤੇ ਰੀਸੈਟ ਕਰਕੇ CDN ਕੈਸ਼ ਦਾ ਨਵਾਂ ਸੰਸਕਰਣ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰ ਸਕਦੇ ਹੋ। ਸਕ੍ਰਿਪਟ.
• ਆਪਣੇ CDN, ਪ੍ਰੌਕਸੀ ਸਰਵਰ, ਅਤੇ ਕੈਸ਼ ਸੈਟਿੰਗਾਂ ਬਾਰੇ ਬਹੁਤ ਸਾਵਧਾਨ ਰਹੋ। ਇਹ ਤੁਹਾਨੂੰ ਤੁਹਾਡੇ ਪ੍ਰੋਜੈਕਟ ਜਾਂ ਸਿਰਲੇਖਾਂ ਨੂੰ ਕੂਕੀਜ਼ ਭੇਜਣ ਤੋਂ ਰੋਕਣ ਦੀ ਆਗਿਆ ਦੇਵੇਗਾ Client-Hints ਤੀਜੀ ਧਿਰ ਦੀਆਂ ਸੇਵਾਵਾਂ।

ਪਿਆਰੇ ਪਾਠਕ! ਕੀ ਤੁਸੀਂ ਆਪਣੇ ਸਰਵਰਾਂ 'ਤੇ ਹੋਰ ਲੋਕਾਂ ਦੀਆਂ ਸਮੱਗਰੀਆਂ ਦੀ ਮੇਜ਼ਬਾਨੀ ਕਰਦੇ ਹੋ ਜੋ ਤੁਹਾਡੇ ਪ੍ਰੋਜੈਕਟਾਂ ਦੇ ਸੰਚਾਲਨ ਲਈ ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਹਨ?

ਸਰੋਤ: www.habr.com