ਹੋਸਟਿੰਗ ਅਤੇ ਕਾਰਗੁਜ਼ਾਰੀ
ਅਸੀਂ WordPress ਨੂੰ ਕਿਵੇਂ ਤੇਜ਼ ਬਣਾਉਂਦੇ ਹਾਂ: LiteSpeed Enterprise, LSCache ਅਤੇ ਪ੍ਰਤੀ-ਸਾਈਟ Redis
ਸਭ ਤੋਂ ਤੇਜ਼ WordPress ਬੇਨਤੀ ਉਹ ਹੁੰਦੀ ਹੈ ਜੋ ਕਦੇ ਨਹੀਂ ਚੱਲਦੀ — ਇੱਥੇ ਦੱਸਿਆ ਗਿਆ ਹੈ ਕਿ ਸਾਡਾ ਸਟੈਕ PHP ਜਾਂ MySQL ਦੇ ਚਲਾਏ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ ਕੈਸ਼ ਤੋਂ ਜ਼ਿਆਦਾਤਰ ਵਿਜ਼ਿਟਾਂ ਦਾ ਜਵਾਬ ਕਿਵੇਂ ਦਿੰਦਾ ਹੈ, ਅਤੇ Core Web Vitals ਲਈ ਇਸਦਾ ਕੀ ਮਤਲਬ ਹੈ।
ਸਭ ਤੋਂ ਤੇਜ਼ ਬੇਨਤੀ ਉਹ ਹੈ ਜੋ ਕਦੇ ਨਹੀਂ ਚੱਲਦੀ
ਇੱਕ ਸਟੈਂਡਰਡ WordPress ਬੇਨਤੀ ਮਹਿੰਗੀ ਹੁੰਦੀ ਹੈ। ਵੈੱਬ ਸਰਵਰ PHP ਨੂੰ ਕੰਮ ਸੌਂਪਦਾ ਹੈ, PHP WordPress ਨੂੰ ਬੂਟ ਕਰਦਾ ਹੈ, ਪਲੱਗਇਨ ਚਲਾਉਂਦਾ ਹੈ, MySQL ਤੋਂ ਦਰਜਨਾਂ ਵਾਰ ਸਵਾਲ ਕਰਦਾ ਹੈ, HTML ਤਿਆਰ ਕਰਦਾ ਹੈ, ਅਤੇ ਉਸ ਤੋਂ ਬਾਅਦ ਹੀ ਬਾਈਟਾਂ ਵਾਪਸ ਭੇਜਦਾ ਹੈ। ਕਿਸੇ ਵਿਅਸਤ ਸਾਈਟ 'ਤੇ ਇਹ ਸਾਰੀ ਪ੍ਰਕਿਰਿਆ ਹਰ ਵਿਜ਼ਟਰ ਲਈ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਇਸੇ ਵਿੱਚ ਤੁਹਾਡਾ ਲਗਭਗ ਸਾਰਾ time-to-first-byte ਸਮਾਂ ਲੱਗ ਜਾਂਦਾ ਹੈ।
ਸਾਡਾ ਜਵਾਬ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣਾ ਹੈ ਕਿ, ਜ਼ਿਆਦਾਤਰ ਵਿਜ਼ਿਟਾਂ ਲਈ, ਇਸ ਵਿੱਚੋਂ ਕੁਝ ਵੀ ਨਾ ਵਾਪਰੇ। ਸਾਡੇ ਦੁਆਰਾ ਹੋਸਟ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਸਾਈਟਾਂ — 100,000 ਤੋਂ ਵੱਧ PBN ਸਾਈਟਾਂ ਅਤੇ ਮੁੱਖ ਧਾਰਾ ਦੀਆਂ ਮੈਨੇਜਡ WordPress — ਵਿੱਚ ਫ੍ਰੰਟ-ਐਂਡ ਪੇਜ ਦੇ ਜ਼ਿਆਦਾਤਰ ਵੀਊ PHP ਨੂੰ ਲਾਗੂ ਕੀਤੇ ਬਿਨਾਂ ਜਾਂ ਡਾਟਾਬੇਸ ਨੂੰ ਛੂਹੇ ਬਿਨਾਂ, ਸਿੱਧੇ ਕੈਸ਼ ਤੋਂ ਪ੍ਰੀ-ਰੈਂਡਰ ਕੀਤੇ ਪੂਰੇ ਪੇਜ ਵਜੋਂ ਸਰਵ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। ਇਸ ਪੋਸਟ ਦਾ ਬਾਕੀ ਹਿੱਸਾ ਇਸ ਬਾਰੇ ਹੈ ਕਿ ਇਸਨੂੰ ਸੱਚ ਬਣਾਉਣ ਵਾਲੀਆਂ ਪਰਤਾਂ ਇੱਕ ਨਾਲ ਕਿਵੇਂ ਫਿੱਟ ਹੁੰਦੀਆਂ ਹਨ, ਅਤੇ ਹਰੇਕ ਆਪਣੀ ਜਗ੍ਹਾ ਕਿਵੇਂ ਬਣਾਉਂਦੀ ਹੈ।
ਮਹੱਤਵਪੂਰਨ ਨੁਕਤਾ ਇਹ ਹੈ ਕਿ ਇਹ ਕੋਈ ਮੁਕਾਬਲਾ ਕਰਨ ਵਾਲੀਆਂ ਕੈਸ਼ ਨਹੀਂ ਹਨ ਜਿਨ੍ਹਾਂ ਵਿੱਚੋਂ ਤੁਸੀਂ ਕਿਸੇ ਇੱਕ ਨੂੰ ਚੁਣਨਾ ਹੈ। ਪੂਰੇ-ਪੇਜ ਦੀ ਕੈਸ਼, ਆਬਜੈਕਟ ਕੈਸ਼ ਅਤੇ CDN ਐਜ ਹਰ ਇੱਕ ਵੱਖਰੀ ਕਿਸਮ ਦੀ ਬੇਨਤੀ ਨੂੰ ਸੰਭਾਲਦੇ ਹਨ, ਅਤੇ ਅਸਲ ਫ਼ਾਇਦਾ ਇਸ ਗੱਲ ਵਿੱਚ ਹੈ ਕਿ ਉਹ ਇੱਕ-ਦੂਜੇ ਨੂੰ ਕੰਮ ਕਿਵੇਂ ਸੌਂਪਦੇ ਹਨ।
LiteSpeed Enterprise + LSCache: ਫੁੱਲ-ਪੇਜ ਲੇਅਰ
ਹ हर ਸਾਈਟ ਸਰਵਰ-ਪੱਧਰ ਦੇ LSCache ਨਾਲ LiteSpeed Enterprise 'ਤੇ ਚੱਲਦੀ ਹੈ। ਜਦੋਂ ਇੱਕ ਫਰੰਟ-ਐਂਡ ਰਿਸਪਾਂਸ ਕੈਸ਼ ਕਰਨ ਯੋਗ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਵੈੱਬ ਸਰਵਰ ਇਸ ਨੂੰ LiteSpeed ਕੈਸ਼-ਕੰਟਰੋਲ ਅਤੇ ਟੈਗ ਹੈਡਰਾਂ ਨਾਲ ਸਟੈਂਪ ਕਰਦਾ ਹੈ, ਅਤੇ LiteSpeed ਅਗਲੀ ਹਿੱਟ 'ਤੇ ਪੂਰੇ ਪੰਨੇ ਨੂੰ ਸਿੱਧਾ ਸਰਵ ਕਰਦਾ ਹੈ — ਕੋਈ PHP ਪ੍ਰਕਿਰਿਆ ਸਪਾਨ ਨਹੀਂ ਹੁੰਦੀ, ਕੋਈ MySQL ਕਵਰੀ ਜਾਰੀ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ। ਇਹ WordPress TTFB 'ਤੇ ਸਭ ਤੋਂ ਵੱਡਾ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਕਦਮ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਹੌਟ ਪਾਥ ਤੋਂ ਪੂਰੇ ਐਪਲੀਕੇਸ਼ਨ ਬੂਟ ਨੂੰ ਹਟਾ ਦਿੰਦਾ ਹੈ।
ਕਿਉਂਕਿ LSCache PHP ਪਲੱਗਇਨ ਦੀ ਬਜਾਏ ਵੈੱਬ ਸਰਵਰ ਦੇ ਅੰਦਰ ਰਹਿੰਦਾ ਹੈ, ਇਹ ਬੇਨਤੀ ਲਾਈਫਸਾਈਕਲ ਵਿੱਚ ਪਹਿਲਾਂ ਕੰਮ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ ਅਤੇ ਪੰਨਿਆਂ ਨੂੰ ਅਜਿਹੇ ਰੂਪ ਵਿੱਚ ਰੱਖਦਾ ਹੈ ਜਿਸਨੂੰ ਸਰਵਰ ਤੁਰੰਤ ਫਲੱਸ਼ ਕਰ ਸਕਦਾ ਹੈ। ਇੱਕ ਕੈਸ਼ ਕਰੌਲਰ ਪ੍ਰਸਿੱਧ ਪੰਨਿਆਂ ਨੂੰ ਵਾਰਮ ਰੱਖਦਾ ਹੈ, ਤਾਂ ਜੋ ਪਰਜ (purge) ਤੋਂ ਬਾਅਦ ਆਉਣ ਵਾਲਾ ਪਹਿਲਾ ਵਿਜ਼ਿਟਰ ਉਹ ਨਾ ਹੋਵੇ ਜਿਸਨੂੰ ਪੰਨੇ ਨੂੰ ਮੁੜ ਜਨਰੇਟ ਕਰਨ ਦੀ ਕੀਮਤ ਚੁਕਾਉਣੀ ਪਵੇ। ਇਸਦਾ ਨਤੀਜਾ ਇੱਕ ਜਨਰਿਕ ਸਟੈਕ 'ਤੇ ਬੋਲਟ ਕੀਤੇ ਪਲੱਗਇਨ-ਓਨਲੀ ਕੈਸ਼, ਜਿੱਥੇ ਕੈਸ਼ ਅਜੇ ਵੀ PHP ਦੇ ਪਿੱਛੇ ਹੁੰਦਾ ਹੈ, ਦੀ ਤੁਲਨਾ ਵਿੱਚ ਕਾਫ਼ੀ ਘੱਟ ਅਤੇ ਵਧੇਰੇ ਨਿਰੰਤਰ TTFB ਹੁੰਦਾ ਹੈ।
ਸਾਡਾ ਆਪਣਾ ਰੇਪੋ-ਗ੍ਰੇਡ ਕੈਸ਼ ਪਲੱਗਇਨ ਹਰ ਸਾਈਟ 'ਤੇ ਪਹਿਲਾਂ ਤੋਂ ਹੀ ਇੰਸਟਾਲ ਅਤੇ ਆਟੋ-ਅੱਪਡੇਟ ਹੁੰਦਾ ਹੈ, ਜੋ WordPress ਨੂੰ LSCache ਨਾਲ ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਸਹੀ ਢੰਗ ਨਾਲ ਕਨੈਕਟ ਕਰਦਾ ਹੈ। ਗ਼ੈਰ-LiteSpeed ਓਰਿਜਨ 'ਤੇ ਇਹ ਸਿਰਫ਼ ਕੋਈ ਫੁੱਲ-ਪੇਜ ਹੈਡਰ ਜਾਰੀ ਨਹੀਂ ਕਰਦਾ ਅਤੇ ਰਸਤੇ ਤੋਂ ਹੱਟ ਜਾਂਦਾ ਹੈ, ਜਦਕਿ ਆਬਜੈਕਟ ਕੈਸ਼ ਅਤੇ ਐਕਸਕਲੂਜ਼ਨ ਨਿਯਮ ਆਪਣਾ ਕੰਮ ਕਰਦੇ ਰਹਿੰਦੇ ਹਨ—ਇਸ ਲਈ ਮਾਈਗ੍ਰੇਟ ਕੀਤੀ ਗਈ ਸਾਈਟ ਕਦੇ ਵੀ ਅਧੂਰੀ ਕੌਂਫ਼ਿਗਰ ਕੀਤੀ ਜਾਂ ਟੁੱਟੀ ਹੋਈ ਹਾਲਤ ਵਿੱਚ ਨਹੀਂ ਰਹਿੰਦੀ।
ਸਪੀਡ ਬਣਾਈ ਰੱਖਣਾ ਬਿਨਾਂ ਪੁਰਾਣਾ ਡਾਟਾ ਦਿਖਾਏ: ESI ਅਤੇ ਸਮਾਰਟ ਆਟੋ-ਪਰਜ
ਪੂਰੇ ਪੇਜ ਦੀ ਹਮਲਾਵਰ ਕੈਚਿੰਗ ਦੇ ਦੋ ਕਲਾਸਿਕ ਫੇਲ੍ਹ ਹੋਣ ਦੇ ਤਰੀਕੇ ਹਨ: ਲੌਗ-ਇਨ ਕੀਤੇ ਉਪਭੋਗਤਾ ਨੂੰ ਕਿਸੇ ਹੋਰ ਦਾ ਪੇਜ ਦਿਖਾਉਣਾ, ਅਤੇ ਕਿਸੇ ਨੂੰ ਵੀ ਅਜਿਹਾ ਪੇਜ ਦਿਖਾਉਣਾ ਜੋ ਬਦਲਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਸੀ। ਇਹ ਦੋਵੇਂ ਘੱਟ ਕੈਚ ਕਰਨ ਦੀ ਬਜਾਏ ਕੈਚਿੰਗ ਪਰਤ 'ਤੇ ਹੱਲ ਕੀਤੇ ਜਾਂਦੇ ਹਨ।
ESI (Edge Side Includes) ਸਾਨੂੰ ਪੰਨੇ ਨੂੰ ਕੈਸ਼ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ ਜਦੋਂ ਕਿ ਉਹਨਾਂ ਹਿੱਸਿਆਂ ਲਈ ਹੋਲ ਪੰਚ ਕੀਤੇ ਜਾਂਦੇ ਹਨ ਜੋ ਲਾਈਵ ਰਹਿਣੇ ਚਾਹੀਦੇ ਹਨ। ਇੱਕ WooCommerce ਸਟੋਰ 'ਤੇ ਕੈਟਾਲੌਗ, ਉਤਪਾਦ ਅਤੇ ਕੈਟਾਗਰੀ ਪੰਨੇ ਸਭ ਤੋਂ ਤੇਜ਼ ਸੰਭਵ TTFB ਲਈ ਫੁੱਲ-ਪੇਜ ਕੈਸ਼ ਵਜੋਂ ਪ੍ਰਦਾਨ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਜਦੋਂ ਕਿ ESI ਪ੍ਰਤੀ ਬੇਨਤੀ ਕਾਰਟ ਫ੍ਰੈਗਮੈਂਟ, ਮਿਨੀ-ਕਾਰਟ ਟੋਟਲ ਅਤੇ ਅਕਾਊਂਟ ਸਟੇਟ ਨੂੰ ਰੈਂਡਰ ਕਰਦਾ ਹੈ। Cart, checkout, my-account ਅਤੇ ਕੋਈ ਵੀ nonce ਜਾਂ ਸੈਸ਼ਨ ਪੰਨੇ ਡਿਫੌਲਟ ਰੂਪ ਵਿੱਚ ਬਾਹਰ ਰੱਖੇ ਜਾਂਦੇ ਹਨ। ਖਰੀਦਦਾਰ ਹਮੇਸ਼ਾਂ ਆਪਣੀ ਬਾਸਕੇਟ ਅਤੇ ਕੰਮ ਕਰਦਾ ਹੋਇਆ ਚੈੱਕਆਉਟ ਦੇਖਦੇ ਹਨ; ਹਰ ਕਿਸੇ ਨੂੰ ਅਜੇ ਵੀ ਕੈਸ਼ ਤੋਂ ਹੀ ਸਟੋਰਫ੍ਰੰਟ ਮਿਲਦਾ ਹੈ।
ਤਾਜ਼ਗੀ ਨੂੰ ਸਮਾਰਟ ਆਟੋ-ਪਰਜ ਦੁਆਰਾ ਸੰਭਾਲਿਆ ਜਾਂਦਾ ਹੈ। ਪਰਜ ਹੁੱਕ ਆਪਣੇ ਆਪ ਚਲਦੇ ਹਨ ਜਦੋਂ ਸਮੱਗਰੀ, ਉਤਪਾਦ, ਕੀਮਤਾਂ ਜਾਂ ਆਰਡਰ ਬਦਲਦੇ ਹਨ, ਤਾਂ ਜੋ ਸੰਬੰਧਿਤ ਕੈਸ਼ ਕੀਤੇ ਪੇਜ ਟਾਈਮਰ ਦੀ ਬਜਾਏ ਤੁਰੰਤ ਰਿਫ੍ਰੈਸ਼ ਹੋ ਜਾਣ, ਅਤੇ ਤੁਸੀਂ ਡੈਸ਼ਬੋਰਡ ਤੋਂ ਜਾਂ WordPress ਦੇ ਅੰਦਰੋਂ ਵੀ ਮੰਗ 'ਤੇ ਪਰਜ ਕਰ ਸਕਦੇ ਹੋ। ਟੈਗ-ਅਧਾਰਿਤ ਪਰਜ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇੱਕ ਪੋਸਟ ਨੂੰ ਸੰਪਾਦਿਤ ਕਰਨ ਨਾਲ ਉਹ ਪੋਸਟ ਅਤੇ ਇਸਦੇ ਆਰਕਾਈਵ ਸਾਫ਼ ਹੋ ਜਾਂਦੇ ਹਨ - ਪੂਰਾ ਕੈਸ਼ ਨਹੀਂ - ਤਾਂ ਜੋ ਇੱਕੋ ਸੰਪਾਦਨ ਨਾਲ ਪੂਰੀ ਸਾਈਟ ਕੋਲਡ-ਸਟਾਰ ਨਾ ਹੋਵੇ।
ਪਰ-ਸਾਈਟ Redis ਆਬਜੈਕਟ ਕੈਸ਼: ਜਿਹੜੀ ਚੀਜ਼ ਪੂਰਾ ਪੰਨਾ ਨਹੀਂ ਹੋ ਸਕਦੀ
ਹਰ ਬੇਨਤੀ ਇੱਕ ਸਟੈਟਿਕ ਪੂਰਾ ਪੰਨਾ ਨਹੀਂ ਹੋ ਸਕਦੀ। ਲੌਗ-ਇਨ ਕੀਤੇ ਸੈਸ਼ਨ, WordPress ਐਡਮਿਨ, WooCommerce ਕਾਰਟ, ਖੋਜ, ਅਤੇ ESI ਦੁਆਰਾ ਛੱਡੇ ਗਏ ਡਾਇਨਾਮਿਕ ਭਾਗਾਂ ਸਾਰਿਆਂ ਨੂੰ PHP ਚਲਾਉਣਾ ਪੈਂਦਾ ਹੈ। ਉਹਨਾਂ ਲਈ, ਟੀਚਾ 'ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਛੱਡਣ' ਤੋਂ 'ਡੇਟਾਬੇਸ ਨੂੰ ਛੱਡਣ' ਵਿੱਚ ਬਦਲ ਜਾਂਦਾ ਹੈ।
ਹਰ ਸਾਈਟ ਨੂੰ ਆਪਣਾ ਖੁਦ ਦਾ ਸਮਰਪਿਤ Redis ਆਬਜੈਕਟ ਕੈਸ਼ ਮਿਲਦਾ ਹੈ। WordPress ਵਾਰ-ਵਾਰ ਪੜ੍ਹੇ ਜਾਣ ਵਾਲੇ ਡਾਟਾਬੇਸ ਨਤੀਜਿਆਂ—ਵਿਕਲਪਾਂ, ਟਰਾਂਜ਼ੀਐਂਟਸ, ਪੋਸਟ ਅਤੇ ਟਰਮ ਲੁੱਕਅੱਪ, WooCommerce ਉਤਪਾਦ ਅਤੇ ਸੈਸ਼ਨ ਡਾਟਾ—ਨੂੰ ਮੈਮੋਰੀ ਵਿੱਚ ਕੈਸ਼ ਕਰਦਾ ਹੈ, ਤਾਂ ਜੋ ਉਹੀ ਕਿਊਰੀ ਹਰ ਹਿੱਟ 'ਤੇ MySQL ਵਿਰੁੱਧ ਨਾ ਚੱਲੇ। ਇਸ ਦਾ ਪ੍ਰਭਾਵ ਬਿਲਕੁਲ ਉੱਥੇ ਸਭ ਤੋਂ ਵੱਧ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ ਜਿੱਥੇ ਪੂਰੇ ਪੰਨੇ ਦਾ ਕੈਸ਼ ਮਦਦ ਨਹੀਂ ਕਰ ਸਕਦਾ: ਤੇਜ਼ ਡੈਸ਼ਬੋਰਡ, ਤੇਜ਼ ਕਾਰਟ, ਅਤੇ ਟ੍ਰੈਫਿਕ ਅਧੀਨ ਬਹੁਤ ਘੱਟ ਡਾਟਾਬੇਸ ਲੋਡ।
ਆਬਜੈਕਟ ਕੈਸ਼ ਪ੍ਰਤੀ-ਸਾਈਟ ਹੁੰਦਾ ਹੈ, ਸਾਂਝਾ ਨਹੀਂ, ਜੋ ਕਿ ਕਾਰਗੁਜ਼ਾਰੀ ਅਤੇ ਅਲੱਗ-ਥਲੱਗਤਾ ਦੋਵਾਂ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਪ੍ਰਤੀ-ਸਾਈਟ ਡਾਟਾਬੇਸ ਥ੍ਰੋਟਲਿੰਗ ਦੇ ਨਾਲ ਮਿਲ ਕੇ, ਕਿਸੇ ਇੱਕ ਸਾਈਟ ਦੀਆਂ ਭਾਰੀ ਜਾਂ ਮਾੜੀਆਂ ਲਿਖੀਆਂ ਗਈਆਂ ਕਿਊਰੀਆਂ ਇਸਦੇ ਗੁਆਂਢੀਆਂ ਲਈ ਡਾਟਾਬੇਸ ਨੂੰ ਭੁੱਖਾ ਨਹੀਂ ਰੱਖ ਸਕਦੀਆਂ। ਤੁਸੀਂ ਸਾਡੇ ਕੈਸ਼ਿੰਗ ਫੀਚਰ ਪੇਜ 'ਤੇ ਇਸ ਬਾਰੇ ਹੋਰ ਪੜ੍ਹ ਸਕਦੇ ਹੋ ਕਿ ਪੂਰਾ ਮਲਟੀ-ਲੇਅਰ ਸੈੱਟਅੱਪ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ, ਅਤੇ ਅਲੱਗ-ਥਲੱਗਤਾ ਦੇ ਤਹਿਤ ਟੈਨੈਂਟਾਂ ਵਿਚਕਾਰ ਸੀਮਾਵਾਂ ਬਾਰੇ ਵੀ ਜਾਣ ਸਕਦੇ ਹੋ।
ਕਿਨਾਰਾ ਅਤੇ ਇਸ ਦੇ ਹੇਠਾਂ ਦਿੱਤਾ ਟਰਾਂਸਪੋਰਟ
ਉਤਪੱਤੀ 'ਤੇ ਮੌਜੂਦ ਕੈਸ਼ ਨੂੰ ਅਜੇ ਵੀ ਨੈੱਟਵਰਕ ਨੂੰ ਪਾਰ ਕਰਨਾ ਪੈਂਦਾ ਹੈ। ਸਰਵਰ ਦੇ ਸਾਹਮਣੇ CDN ਐੱਜ ਮੌਜੂਦ ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ ਸਟੈਤਿਕ ਅਸੈੱਟ ਅਤੇ ਕੈਸ਼ ਕੀਤੇ ਜਾ ਸਕਣ ਵਾਲੇ ਪੰਨੇ ਵਿਜ਼ਟਰ ਦੇ ਨੇੜੇ ਮੌਜੂਦ ਕਿਸੇ ਪੁਆਇੰਟ ਆਫ਼ ਪ੍ਰੈਜ਼ੈਂਸ ਤੋਂ ਸਰਵ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਲੋਡ ਹੋਣ 'ਤੇ ਵੀ ਉਤਪੱਤੀ ਸ਼ਾਂਤ ਰਹਿੰਦੀ ਹੈ। ਸਾਡੀ ਫੁੱਟਪ੍ਰਿੰਟ-ਮੁਕਤ ਹੋਸਟਿੰਗ ਲਾਈਨ ਲਈ ਉਹੀ ਐੱਜ ਕਈ ਪ੍ਰਦਾਤਾਵਾਂ ਵਿੱਚ ਫੈਲਿਆ ਹੋਇਆ ਇੱਕ ਮਲਟੀ-CDN ਪੂਲ ਹੈ, ਜੋ ਪ੍ਰਦਰਸ਼ਨ ਦੇ ਟੀਚੇ ਦੇ ਨਾਲ-ਨਾਲ ਇੱਕ ਫੁੱਟਪ੍ਰਿੰਟ ਦੇ ਟੀਚੇ ਨੂੰ ਵੀ ਪੂਰਾ ਕਰਦਾ ਹੈ; ਮੁੱਖ ਧਾਰਾ WordPress 'ਤੇ ਇਹ ਸਿਰਫ਼ ਇੱਕ ਤੇਜ਼, ਚੰਗੀ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਨ ਵਾਲੀ ਪਰਤ ਹੈ ਜੋ ਉਤਪੱਤੀ ਨੂੰ ਵਿਹਲਾ ਰੱਖਦੀ ਹੈ।
ਇਸ ਦੇ ਤਹਿਤ, ਬੁਨਿਆਦੀ ਚੀਜ਼ਾਂ ਨਾਲ ਕੋਈ ਸਮਝੌਤਾ ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ। ਸਾਈਟਾਂ HTTP/3 ਵਾਲੀ NVMe ਸਟੋਰੇਜ 'ਤੇ ਚੱਲਦੀਆਂ ਹਨ, ਇਸ ਲਈ ਕੈਸ਼ ਵੱਲੋਂ ਭੇਜੇ ਜਾਣ ਵਾਲੇ ਬਾਈਟ ਇੱਕ ਆਧੁਨਿਕ, ਮਲਟੀਪਲੈਕਸਡ ਟਰਾਂਸਪੋਰਟ ਰਾਹੀਂ ਪਹੁੰਚਦੇ ਹਨ ਜਿਸ ਵਿੱਚ ਕਿਸੇ ਵੀ ਕੈਸ਼ ਮਿਸ (cache miss) ਦੇ ਪਿੱਛੇ ਤੇਜ਼ ਸਟੋਰੇਜ ਹੁੰਦੀ ਹੈ। ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਪਰਤ ਇੱਕ ਐਡ-ਆਨ ਨਹੀਂ ਹੈ: LiteSpeed, LSCache, ਪ੍ਰਤੀ-ਸਾਈਟ Redis, NVMe ਅਤੇ HTTP/3 ਹਰ ਪਲਾਨ ਵਿੱਚ ਮੂਲ ਰੂਪ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ, ਨਾ ਕਿ ਕੋਈ ਮਹਿੰਗਾ ਅੱਪਸੈੱਲ ਟੀਅਰ।
ਕਿਹੜੀ ਚੀਜ਼ ਅਸਲ ਵਿੱਚ Core Web Vitals ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੀ ਹੈ
ਸਟੀਕ ਹੋਣਾ ਲਾਭਦਾਇਕ ਹੈ, ਕਿਉਂਕਿ ਹੋਸਟਿੰਗ ਨੂੰ ਅਕਸਰ Core Web Vitals 'ਤੇ ਵਧਾ-ਚੜ੍ਹਾ ਕੇ ਵੇਚਿਆ ਜਾਂਦਾ ਹੈ। TTFB ਸਮੀਕਰਨ ਦਾ ਉਹ ਹਿੱਸਾ ਹੈ ਜੋ ਸਰਵਰ ਦੇ ਅਧੀਨ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਇਸਦੇ ਉੱਪਰਲਾ ਕੈਚਿੰਗ ਸਟੈਕ ਉਹ ਹੈ ਜੋ ਇਸਨੂੰ ਘਟਾਉਂਦਾ ਹੈ — ਐਜ (edge) ਤੋਂ HTTP/3 'ਤੇ ਸਰਵ ਕੀਤਾ ਗਿਆ ਇੱਕ ਕੈਚ ਕੀਤਾ ਪੂਰਾ ਪੰਨਾ ਲਗਭਗ ਉੰਨਾ ਹੀ ਘੱਟ TTFB ਦਿੰਦਾ ਹੈ ਜਿੰਨਾ ਹੋ ਸਕਦਾ ਹੈ। ਕਿਉਂਕਿ TTFB Largest Contentful Paint ਦਾ ਪ੍ਰਮੁੱਖ ਹਿੱਸਾ ਹੈ, ਇੱਕ ਤੇਜ਼ ਓਰੀਜਨ ਹਰੇਕ ਡਾਊਨਸਟ੍ਰੀਮ ਮੈਟ੍ਰਿਕ ਨੂੰ ਅਜਿਹੀ ਸ਼ੁਰੂਆਤੀ ਬੜ੍ਹਤ ਦਿੰਦਾ ਹੈ ਜੋ ਇਸਨੂੰ ਹੋਰ ਕਿਸੇ ਤਰੀਕੇ ਨਾਲ ਨਹੀਂ ਮਿਲ ਸਕਦੀ।
ਪ پر LCP, CLS ਅਤੇ INP ਦਾ ਫ਼ੈਸਲਾ ਜ਼ਿਆਦਾਤਰ ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ, ਖ਼ੁਦ ਪੇਜ ਵੱਲੋਂ ਹੀ ਕੀਤਾ ਜਾਂਦਾ ਹੈ: ਇੱਕ ਬਿਨਾਂ ਅਨੁਕੂਲਿਤ ਕੀਤੀ ਹੀਰੋ ਇਮੇਜ, ਰੈਂਡਰ ਨੂੰ ਰੋਕਣ ਵਾਲੀ CSS ਅਤੇ JavaScript, ਫੌਂਟਾਂ ਅਤੇ ਇਸ਼ਤਿਹਾਰਾਂ ਦੇ ਲੋਡ ਹੋਣ 'ਤੇ ਲੇਆਉਟ ਦਾ ਹਿੱਲਣਾ, ਅਤੇ ਪਲੱਗਇਨਾਂ ਵੱਲੋਂ ਮੇਨ-ਥ੍ਰੈਡ 'ਤੇ ਭਾਰੀ ਕੰਮ। ਸਰਵਰ ਦੀ ਕੋਈ ਵੀ ਕੈਚਿੰਗ 2 MB ਦੀ ਹੀਰੋ ਇਮੇਜ ਜਾਂ ਮੇਗਾਬਾਈਟਾਂ ਦੀ JavaScript ਭੇਜਣ ਵਾਲੀ ਥੀਮ ਨੂੰ ਠੀਕ ਨਹੀਂ ਕਰ ਸਕਦੀ। ਇਮਾਨਦਾਰ ਹੌਸਟਿੰਗ ਸਰਵਰ ਦੇ ਯੋਗਦਾਨ ਨੂੰ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਢੰਗ ਨਾਲ ਮੁਫ਼ਤ ਅਤੇ ਸਥਿਰ ਬਣਾਉਂਦੀ ہے, ਫਿਰ ਫਰੰਟ ਐਂਡ ਨੂੰ ਹਲਕਾ ਰੱਖਣਾ ਸਾਈਟ ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਹੁੰਦਾ ਹੈ।
ਕੰਮ ਦੀ ਇਹ ਵੰਡ ਇੱਕ ਉਪਯੋਗੀ ਮਾਨਸਿਕ ਮਾਡਲ ਹੈ। ਅਸੀਂ ਗਾਰੰਟੀ ਦਿੰਦੇ ਹਾਂ ਕਿ ਬੇਨਤੀ ਬ੍ਰਾਊਜ਼ਰ ਤੱਕ ਤੇਜ਼ੀ ਨਾਲ ਪਹੁੰਚਦੀ ਹੈ ਅਤੇ ਟ੍ਰੈਫਿਕ ਅਧੀਨ ਤੇਜ਼ ਰਹਿੰਦੀ ਹੈ; ਤੁਸੀਂ ਪੇਲੋਡ ਨੂੰ ਛੋਟਾ ਅਤੇ ਸਥਿਰ ਰੱਖਦੇ ਹੋ। ਜਿੱਥੇ ਇਹ ਦੋਵੇਂ ਮਿਲਦੇ ਹਨ — ਕੈਸ਼ ਵਾਰਮ-ਅੱਪ, ਐਜ ਡਿਲੀਵਰੀ, ਅਤੇ ਡੇਟਾਬੇਸ ਨੂੰ ਜਵਾਬਦੇਹ ਰੱਖਣਾ ਤਾਂ ਜੋ ਡਾਇਨਾਮਿਕ ਪੇਜ ਰੁਕਣ ਨਾ — ਬਿਲਕੁਲ ਉੱਥੇ ਹੀ ਸਾਡਾ ਸਟੈਕ ਟਿਊਨ ਕੀਤਾ ਗਿਆ ਹੈ, ਅਤੇ ਇਹ ਇਸ ਪਲੇਟਫਾਰਮ 'ਤੇ ਮੈਨੇਜਡ WordPress ਨੂੰ ਕਿਸੇ ਆਮ ਹੋਸਟ 'ਤੇ ਉਸੇ ਸਾਈਟ ਨਾਲੋਂ ਤੇਜ਼ ਬਣਾਉਂਦਾ ਹੈ।
ਅਕਸਰ ਪੁੱਛੇ ਜਾਂਦੇ ਸਵਾਲ
ਕ ਕੀ ਮੈਨੂੰ ਹੁਣ ਵੀ WP Rocket ਵਰਗੇ ਕੈਚਿੰਗ ਪਲੱਗਇਨ ਦੀ ਲੋੜ ਹੈ?
ਨਹੀਂ। ਪੂਰੇ-ਪੇਸ਼ ਦੀ ਕੈਸ਼ਿੰਗ ਵੈੱਬ ਸਰਵਰ ਉੱਤੇ LiteSpeed ਦੇ LSCache ਅਤੇ ਸਾਡੇ ਆਪਣੇ ਕੈਸ਼ ਪਲੱਗਨ — ਜੋ ਕਿ ਪਹਿਲਾਂ ਤੋਂ ਸਥਾਪਿਤ ਅਤੇ ਸਵੈ-ਅੱਪਡੇਟ ਹੁੰਦਾ ਹੈ — ਰਾਹੀਂ ਸਹੀ ਢੰਗ ਨਾਲ WordPress ਨਾਲ ਜੁੜੀ ਹੁੰਦੀ ਹੈ, ਜਿਸ ਦੇ ਪਿੱਛੇ ਪ੍ਰਤੀ-ਸਾਈਟ Redis ਆਬਜੈਕਟ ਕੈਸ਼ ਹੁੰਦਾ ਹੈ। ਇਸ ਉੱਤੇ ਦੂਜਾ ਪੂਰੇ-ਪੇਸ਼ ਦੀ ਕੈਸ਼ਿੰਗ ਪਲੱਗਨ ਲਗਾਉਣ ਨਾਲ ਮਦਦ ਹੋਣ ਦੀ ਬਜਾਏ ਆਮ ਤੌਰ 'ਤੇ ਸਰਵਰ-ਪੱਧਰ ਦੇ ਕੈਸ਼ ਨਾਲ ਟਕਰਾਅ ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ ਇਸ ਦੀ ਕੋਈ ਲੋੜ ਨਹੀਂ ਹੈ ਅਤੇ ਇਹ ਸਿਫਾਰਸ਼ਯੋਗ ਵੀ ਨਹੀਂ ਹੈ।
ਕੀ ਕੈਚਿੰਗ ਮੇਰੀ WooCommerce ਕਾਰਟ ਜਾਂ ਲੌਗ-ਇਨ ਕੀਤੇ ਪੰਨਿਆਂ ਨੂੰ ਤੋੜ ਦੇਵੇਗੀ?
ਨੰ. ਕਾਰਟ, ਚੈੱਕਆਉਟ, ਮਾਈ-ਅਕਾਊਂਟ ਅਤੇ ਕੋਈ ਵੀ ਨੌਂਸ ਜਾਂ ਸੈਸ਼ਨ ਪੰਨੇ ਮੂਲ ਰੂਪ ਵਿੱਚ ਕੈਸ਼ ਤੋਂ ਬਾਹਰ ਰੱਖੇ ਜਾਂਦੇ ਹਨ, ਅਤੇ ESI ਕੈਸ਼ ਕੀਤੇ ਗਏ ਪੰਨਿਆਂ 'ਤੇ ਵੀ ਕਾਰਟ ਫਰਗਮੈਂਟ ਅਤੇ ਕੁੱਲ ਜੋੜ ਨੂੰ ਲਾਈਵ ਰੱਖਦਾ ਹੈ। ਖਰੀਦਦਾਰ ਹਮੇਸ਼ਾ ਆਪਣੀ ਟੋਕਰੀ ਅਤੇ ਕੰਮ ਕਰਨ ਵਾਲਾ ਚੈੱਕਆਉਟ ਦੇਖਦੇ ਹਨ ਜਦੋਂ ਕਿ ਸਟੋਰਫਰੰਟ ਅਜੇ ਵੀ ਕੈਸ਼ ਤੋਂ ਲੋਡ ਹੁੰਦਾ ਹੈ।
ਜਦੋਂ ਮੈਂ ਪ੍ਰਕਾਸ਼ਤ ਜਾਂ ਸੰਪਾਦਨ ਕਰਦਾ ਹਾਂ, ਤਾਂ ਕੈਸ਼ (cache) ਤਾਜ਼ਾ ਕਿਵੇਂ ਰਹਿੰਦਾ ਹੈ?
ਸਮਾਰਟ ਆਟੋ-ਪਰਜ ਢੁਕਵੇਂ WordPress ਹੂਕਾਂ 'ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਸਮੱਗਰੀ ਨੂੰ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨ, ਸੰਪਾਦਿਤ ਕਰਨ, ਜਾਂ ਕਿਸੇ ਉਤਪਾਦ, ਕੀਮਤ ਜਾਂ ਆਰਡਰ ਨੂੰ ਬਦਲਣ ਨਾਲ ਸਿਰਫ਼ ਪ੍ਰਭਾਵਿਤ ਪੰਨੇ ਅਤੇ ਉਹਨਾਂ ਦੇ ਆਰਕਾਈਵ ਕਲੀਅਰ ਹੁੰਦੇ ਹਨ — ਨਾ ਕਿ ਪੂਰੀ ਕੈਸ਼ੇ — ਅਤੇ ਇੱਕ ਕ੍ਰਾਲਰ ਉਹਨਾਂ ਨੂੰ ਦੁਬਾਰਾ ਵਾਰਮ ਕਰ ਦਿੰਦਾ ਹੈ। ਤੁਸੀਂ ਡੈਸ਼ਬੋਰਡ ਤੋਂ ਜਾਂ WordPress ਦੇ ਅੰਦਰੋਂ ਵੀ ਮੰਗ ਅਨੁਸਾਰ ਪਰਜ ਕਰ ਸਕਦੇ ਹੋ।
ਕੀ ਸਿਰਫ਼ ਹੋਸਟਿੰਗ ਹੀ ਮੈਨੂੰ ਪਰਫੈਕਟ Core Web Vitals ਦੇ ਸਕਦੀ ਹੈ?
ਇਹ ਤੁਹਾਨੂੰ ਸਭ ਤੋਂ ਵਧੀਆ ਸੰਭਵ TTFB ਦਿੰਦਾ ਹੈ, ਜੋ ਕਿ ਸਰਵਰ ਦਾ ਹਿੱਸਾ ਹੈ ਅਤੇ Largest Contentful Paint ਲਈ ਇੱਕ ਸ਼ੁਰੂਆਤੀ ਬੜ੍ਹਤ ਹੈ। ਪਰ LCP, CLS ਅਤੇ INP ਮੁੱਖ ਤੌਰ 'ਤੇ ਪੰਨੇ ਦੁਆਰਾ ਹੀ ਤੈਅ ਕੀਤੇ ਜਾਂਦੇ ਹਨ — ਚਿੱਤਰ ਆਕਾਰ, ਰੈਂਡਰ-ਬਲਾਕਿੰਗ ਸੰਪਤੀਆਂ, ਲੇਆਉਟ ਸਥਿਰਤਾ ਅਤੇ ਮੁੱਖ-ਥ੍ਰੈਡ JavaScript। ਸਾਡਾ ਸਟੈਕ ਸਰਵਰ ਦੇ ਯੋਗਦਾਨ ਨੂੰ ਤੇਜ਼ ਅਤੇ ਨਿਰੰਤਰ ਬਣਾਉਂਦਾ ਹੈ; ਫਰੰਟ-ਐਂਡ ਪੇਲੋਡ ਨੂੰ ਹਲਕਾ ਰੱਖਣਾ ਹੀ ਬਾਕੀ ਦੇ ਅੰਤਰ ਨੂੰ ਮਿਟਾਉਂਦਾ ਹੈ।
ਸੰਬੰਧਿਤ
14 ਦਿਨਾਂ ਲਈ ਇਸ ਨੂੰ ਮੁਫ਼ਤ ਅਜ਼ਮਾਓ
ਆਪਣੀਆਂ ਪਹਿਲੀਆਂ ਸਾਈਟਾਂ 14 ਦਿਨਾਂ ਲਈ ਮੁਫ਼ਤ ਸ਼ੁਰੂ ਕਰੋ — ਕੋਈ ਕਾਰਡ ਨਹੀਂ। ਕੋਈ ਮੌਜੂਦਾ ਨੈੱਟਵਰਕ ਮੂਵ ਕਰ ਰਹੇ ਹੋ? ਤੁਹਾਡੀ ਪਹਿਲੀ ਮਾਈਗ੍ਰੇਸ਼ਨ ਸਾਡੇ ਵੱਲੋਂ ਹੈ।
ਮੁਫ਼ਤ ਸ਼ੁਰੂ ਕਰੋ