ਹੋਸਟਿੰਗ ਅਤੇ ਕਾਰਗੁਜ਼ਾਰੀ
ਅਸੀਂ 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 ਪਲੱਗਇਨ ਦੀ ਬਜਾਏ ਵੈੱਬ ਸਰਵਰ ਦੇ ਅੰਦਰ ਰਹਿੰਦਾ ਹੈ, ਇਹ ਬੇਨਤੀ ਜੀਵਨ ਚੱਕਰ ਵਿੱਚ ਪਹਿਲਾਂ ਕੰਮ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ ਅਤੇ ਪੰਨਿਆਂ ਨੂੰ ਅਜਿਹੇ ਰੂਪ ਵਿੱਚ ਰੱਖਦਾ ਹੈ ਜਿਸਨੂੰ ਸਰਵਰ ਤੁਰੰਤ ਫਲੱਸ਼ ਕਰ ਸਕਦਾ ਹੈ। ਇੱਕ ਕੈਸ਼ ਕ੍ਰਾਲਰ ਪ੍ਰਸਿੱਧ ਪੰਨਿਆਂ ਨੂੰ ਵਾਰਮ ਰੱਖਦਾ ਹੈ, ਤਾਂ ਜੋ ਪਰਜ ਤੋਂ ਬਾਅਦ ਪਹਿਲੇ ਵਿਜ਼ਟਰ ਨੂੰ ਪੰਨੇ ਨੂੰ ਦੁਬਾਰਾ ਬਣਾਉਣ ਦਾ ਖਮਿਆਜ਼ਾ ਨਾ ਭੁਗਤਣਾ ਪਵੇ। ਨਤੀਜਾ ਇੱਕ ਆਮ ਸਟੈਕ 'ਤੇ ਲਗਾਏ ਗਏ ਸਿਰਫ਼-ਪਲੱਗਇਨ ਕੈਸ਼ ਦੇ ਮੁਕਾਬਲੇ ਕਾਫ਼ੀ ਘੱਟ ਅਤੇ ਵਧੇਰੇ ਨਿਰੰਤਰ TTFB ਹੈ, ਜਿੱਥੇ ਕੈਸ਼ ਅਜੇ ਵੀ PHP ਦੇ ਪਿੱਛੇ ਰਹਿੰਦਾ ਹੈ।
ਸਾਡਾ ਆਪਣਾ ਰੈਪੋ-ਗ੍ਰੇਡ ਕੈਸ਼ ਪਲੱਗਇਨ ਹਰੇਕ ਸਾਈਟ 'ਤੇ ਪਹਿਲਾਂ ਤੋਂ ਸਥਾਪਿਤ ਅਤੇ ਸਵੈ-ਅੱਪਡੇਟ ਹੋ ਕੇ ਆਉਂਦਾ ਹੈ, ਜੋ WordPress ਨੂੰ ਸ਼ੁਰੂ ਤੋਂ ਹੀ LSCache ਨਾਲ ਸਹੀ ਢੰਗ ਨਾਲ ਜੋੜਦਾ ਹੈ। ਗ਼ੈਰ-LiteSpeed ਮੂਲ 'ਤੇ ਇਹ ਪੂਰੇ ਪੰਨੇ ਦੇ ਹੈਡਰ ਜਾਰੀ ਨਹੀਂ ਕਰਦਾ ਅਤੇ ਰਸਤੇ ਤੋਂ ਹਟ ਜਾਂਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਆਬਜੈਕਟ ਕੈਸ਼ ਅਤੇ ਬੇਦਖ਼ਲੀ ਨਿਯਮ ਆਪਣਾ ਕੰਮ ਕਰਦੇ ਰਹਿੰਦੇ ਹਨ — ਇਸ ਲਈ ਮਾਈਗ੍ਰੇਟ ਕੀਤੀ ਗਈ ਸਾਈਟ ਕਦੇ ਵੀ ਖ਼ਰਾਬ ਜਾਂ ਅੱਧੀ-ਸੰਰਚਿਤ ਸਥਿਤੀ ਵਿੱਚ ਨਹੀਂ ਛੱਡੀ ਜਾਂਦੀ।
ਪੁਰਾਣੀ ਸਮੱਗਰੀ ਪਰੋਸੇ ਬਿਨਾਂ ਤੇਜ਼ ਰਹਿਣਾ: ESI ਅਤੇ ਸਮਾਰਟ ਆਟੋ-ਪਰਜ
ਹਮਲਾਵਰ ਪੂਰੇ-ਪੰਨੇ ਦੀ ਕੈਸ਼ਿੰਗ ਦੇ ਦੋ ਕਲਾਸਿਕ ਅਸਫਲਤਾ ਮੋਡ ਹਨ: ਲੌਗ-ਇਨ ਕੀਤੇ ਉਪਭੋਗਤਾ ਨੂੰ ਕਿਸੇ ਹੋਰ ਦਾ ਪੰਨਾ ਦਿਖਾਉਣਾ, ਅਤੇ ਕਿਸੇ ਨੂੰ ਵੀ ਅਜਿਹਾ ਪੰਨਾ ਦਿਖਾਉਣਾ ਜਿਸ ਵਿੱਚ ਤਬਦੀਲੀ ਹੋ ਜਾਣੀ ਚਾਹੀਦੀ ਸੀ। ਦੋਵਾਂ ਦਾ ਹੱਲ ਘੱਟ ਕੈਸ਼ ਕਰਨ ਦੀ ਬਜਾਏ ਕੈਸ਼ਿੰਗ ਪਰਤ 'ਤੇ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
ESI (Edge Side Includes) ਸਾਨੂੰ ਪੰਨੇ ਨੂੰ ਕੈਸ਼ ਕਰਨ ਦਿੰਦਾ ਹੈ ਜਦੋਂ ਕਿ ਉਹਨਾਂ ਹਿੱਸਿਆਂ ਲਈ ਛੇਕ ਬਣਾਏ ਜਾਂਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਦਾ ਲਾਈਵ ਰਹਿਣਾ ਜ਼ਰੂਰੀ ਹੈ। ਇੱਕ WooCommerce ਸਟੋਰ 'ਤੇ ਕੈਟਾਲਾਗ, ਉਤਪਾਦ ਅਤੇ ਸ਼੍ਰੇਣੀ ਪੰਨੇ ਸਭ ਤੋਂ ਤੇਜ਼ ਸੰਭਵ TTFB ਲਈ ਪੂਰੇ-ਪੰਨੇ ਦੇ ਕੈਸ਼ ਵਜੋਂ ਦਿੱਤੇ ਜਾਂਦੇ ਹਨ, ਜਦੋਂ ਕਿ ESI ਪ੍ਰਤੀ ਬੇਨਤੀ ਕਾਰਟ ਫਰੈਗਮੈਂਟ, ਮਿੰਨੀ-ਕਾਰਟ ਕੁੱਲ ਅਤੇ ਖਾਤਾ ਸਥਿਤੀ ਨੂੰ ਰੈਂਡਰ ਕਰਦਾ ਹੈ। ਕਾਰਟ, ਚੈੱਕਆਉਟ, ਮਾਈ-ਅਕਾਊਂਟ ਅਤੇ ਕੋਈ ਵੀ ਨੌਂਸ ਜਾਂ ਸੈਸ਼ਨ ਪੰਨੇ ਮੂਲ ਰੂਪ ਵਿੱਚ ਬਾਹਰ ਰੱਖੇ ਗਏ ਹਨ। ਖਰੀਦਦਾਰ ਹਮੇਸ਼ਾ ਆਪਣੀ ਟੋਕਰੀ ਅਤੇ ਇੱਕ ਕੰਮਕਾਜੀ ਚੈੱਕਆਉਟ ਦੇਖਦੇ ਹਨ; ਹਰ ਕਿਸੇ ਨੂੰ ਅਜੇ ਵੀ ਕੈਸ਼ ਤੋਂ ਸਟੋਰਫ੍ਰੰਟ ਮਿਲਦਾ ਹੈ।
ਤਾਜ਼ਾਪਨ ਨੂੰ ਸਮਾਰਟ ਆਟੋ-ਪਰਜ ਦੁਆਰਾ ਸੰਭਾਲਿਆ ਜਾਂਦਾ ਹੈ। ਜਦੋਂ ਸਮੱਗਰੀ, ਉਤਪਾਦ, ਕੀਮਤਾਂ ਜਾਂ ਆਰਡਰ ਬਦਲਦੇ ਹਨ ਤਾਂ ਪਰਜ ਹੁੱਕ ਆਪਣੇ ਆਪ ਚੱਲ ਪੈਂਦੇ ਹਨ, ਇਸ ਲਈ ਸੰਬੰਧਿਤ ਕੈਸ਼ ਕੀਤੇ ਪੰਨੇ ਟਾਈਮਰ ਦੀ ਬਜਾਏ ਤੁਰੰਤ ਰਿਫ੍ਰੈਸ਼ ਹੋ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਤੁਸੀਂ ਡੈਸ਼ਬੋਰਡ ਤੋਂ ਜਾਂ WordPress ਦੇ ਅੰਦਰੋਂ ਵੀ ਲੋੜ ਮੁਤਾਬਕ ਪਰਜ ਕਰ ਸਕਦੇ ਹੋ। ਟੈਗ-ਅਧਾਰਿਤ ਪਰਜਿੰਗ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇੱਕ ਪੋਸਟ ਨੂੰ ਸੰਪਾਦਿਤ ਕਰਨ ਨਾਲ ਸਿਰਫ਼ ਉਹ ਪੋਸਟ ਅਤੇ ਇਸਦੇ ਪੁਰਾਲੇਖ (ਆਰਕਾਈਵਜ਼) ਹੀ ਸਾਫ਼ ਹੁੰਦੇ ਹਨ — ਨਾ ਕਿ ਪੂਰੀ ਕੈਸ਼ — ਇਸ ਲਈ ਇੱਕ ਸਿੰਗਲ ਸੰਪਾਦਨ ਪੂਰੀ ਸਾਈਟ ਨੂੰ ਕੋਲਡ-ਸਟਾਰਟ ਨਹੀਂ ਕਰਦਾ।
ਪ੍ਰਤੀ-ਸਾਈਟ Redis ਆਬਜੈਕਟ ਕੈਸ਼: ਉਸ ਲਈ ਜੋ ਪੂਰਾ ਪੰਨਾ ਨਹੀਂ ਹੋ ਸਕਦਾ
ਹਰ ਬੇਨਤੀ ਇੱਕ ਸਥਿਰ ਪੂਰਾ ਪੰਨਾ ਨਹੀਂ ਹੋ ਸਕਦੀ। ਲੌਗ-ਇਨ ਕੀਤੇ ਸੈਸ਼ਨ, WordPress ਐਡਮਿਨ, WooCommerce ਕਾਰਟ, ਖੋਜ, ਅਤੇ ESI ਦੁਆਰਾ ਲਾਈਵ ਛੱਡੇ ਗਏ ਗਤੀਸ਼ੀਲ ਟੁਕੜਿਆਂ ਸਾਰਿਆਂ ਨੂੰ PHP ਚਲਾਉਣੀ ਪੈਂਦੀ ਹੈ। ਇਹਨਾਂ ਲਈ, ਟੀਚਾ 'ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਛੱਡੋ' ਤੋਂ 'ਡੇਟਾਬੇਸ ਨੂੰ ਛੱਡੋ' ਵਿੱਚ ਬਦਲ ਜਾਂਦਾ ਹੈ।
ਹਰੇਕ ਸਾਈਟ ਨੂੰ ਆਪਣਾ ਸਮਰਪਿਤ Redis ਆਬਜੈਕਟ ਕੈਸ਼ ਮਿਲਦਾ ਹੈ। WordPress ਵਾਰ-ਵਾਰ ਡੇਟਾਬੇਸ ਪੜ੍ਹਨ ਦੇ ਨਤੀਜਿਆਂ — ਵਿਕਲਪਾਂ, ਟ੍ਰਾਂਜਿਐਂਟਸ, ਪੋਸਟ ਅਤੇ ਟਰਮ ਖੋਜਾਂ, WooCommerce ਉਤਪਾਦ ਅਤੇ ਸੈਸ਼ਨ ਡੇਟਾ — ਨੂੰ ਮੈਮੋਰੀ ਵਿੱਚ ਕੈਸ਼ ਕਰਦਾ ਹੈ, ਤਾਂ ਜੋ ਹਰ ਵਾਰ ਆਉਣ 'ਤੇ MySQL ਵਿਰੁੱਧ ਉਹੀ ਕਵੇਰੀ ਨਾ ਚਲਾਈ ਜਾਵੇ। ਇਸਦਾ ਪ੍ਰਭਾਵ ਉੱਥੇ ਸਭ ਤੋਂ ਵੱਧ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ ਜਿੱਥੇ ਫੁੱਲ-ਪੇਜ ਕੈਸ਼ ਮਦਦ ਨਹੀਂ ਕਰ ਸਕਦਾ: ਤੇਜ਼ ਡੈਸ਼ਬੋਰਡ, ਤੇਜ਼ ਕਾਰਟਾਂ, ਅਤੇ ਟ੍ਰੈਫਿਕ ਦੇ ਦੌਰਾਨ ਬਹੁਤ ਘੱਟ ਡੇਟਾਬੇਸ ਲੋਡ।
ਆਬਜੈਕਟ ਕੈਸ਼ ਪ੍ਰਤੀ-ਸਾਈਟ ਹੁੰਦਾ ਹੈ, ਸਾਂਝਾ ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ, ਜੋ ਕਿ ਕਾਰਜਕੁਸ਼ਲਤਾ ਅਤੇ ਅਲੱਗ-ਥਲੱਗਤਾ (ਆਈਸੋਲੇਸ਼ਨ) ਦੋਵਾਂ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਪ੍ਰਤੀ-ਸਾਈਟ ਡਾਟਾਬੇਸ ਥ੍ਰੋਟਲਿੰਗ ਦੇ ਨਾਲ ਮਿਲ ਕੇ, ਇੱਕ ਸਾਈਟ ਦੀਆਂ ਭਾਰੀ ਜਾਂ ਮਾੜੇ ਢੰਗ ਨਾਲ ਲਿਖੀਆਂ ਗਈਆਂ ਪੁੱਛਗਿੱਛਾਂ (ਕੁਐਰੀਆਂ) ਇਸਦੇ ਗੁਆਂਢੀ ਸਾਈਟਾਂ ਲਈ ਡਾਟਾਬੇਸ ਸਰੋਤਾਂ ਨੂੰ ਖਤਮ ਨਹੀਂ ਕਰ ਸਕਦੀਆਂ। ਤੁਸੀਂ ਸਾਡੇ ਕੈਸ਼ਿੰਗ ਫੀਚਰ ਪੰਨੇ 'ਤੇ ਇਸ ਬਾਰੇ ਹੋਰ ਪੜ੍ਹ ਸਕਦੇ ਹੋ ਕਿ ਪੂਰਾ ਬਹੁ-ਪੱਧਰੀ ਸੈੱਟਅੱਪ ਕਿਵੇਂ ਇਕੱਠੇ ਕੰਮ ਕਰਦਾ ਹੈ, ਅਤੇ ਅਲੱਗ-ਥਲੱਗਤਾ ਅਧੀਨ ਟੈਨੈਂਟਾਂ ਵਿਚਕਾਰ ਸੀਮਾਵਾਂ ਬਾਰੇ ਜਾਣਕਾਰੀ ਲੈ ਸਕਦੇ ਹੋ।
ਕਿਨਾਰਾ ਅਤੇ ਇਸ ਦੇ ਹੇਠਾਂ ਦੀ ਆਵਾਜਾਈ
ਮੂਲ ਸਰਵਰ 'ਤੇ ਰਹਿਣ ਵਾਲੇ ਕੈਸ਼ ਨੂੰ ਅਜੇ ਵੀ ਨੈੱਟਵਰਕ ਪਾਰ ਕਰਨਾ ਪੈਂਦਾ ਹੈ। ਸਰਵਰ ਦੇ ਸਾਹਮਣੇ CDN ਐੱਜ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਜੋ ਸਥਿਰ ਸੰਪਤੀਆਂ ਅਤੇ ਕੈਸ਼ ਹੋਣ ਯੋਗ ਪੰਨੇ ਵਿਜ਼ਟਰ ਦੇ ਨੇੜਲੇ ਮੌਜੂਦਗੀ ਪੁਆਇੰਟ ਤੋਂ ਦਿੱਤੇ ਜਾਣ, ਅਤੇ ਲੋਡ ਦੇ ਹੇਠਾਂ ਵੀ ਮੂਲ ਸਰਵਰ ਸ਼ਾਂਤ ਰਹਿੰਦਾ ਹੈ। ਸਾਡੀ footprint-free ਹੋਸਟਿੰਗ ਲਾਈਨ ਲਈ ਇਹੀ ਐੱਜ ਕਈ ਪ੍ਰਦਾਤਾਵਾਂ ਵਿੱਚ ਫੈਲਿਆ ਇੱਕ ਮਲਟੀ-CDN ਪੂਲ ਹੈ, ਜੋ ਪ੍ਰਦਰਸ਼ਨ ਦੇ ਨਾਲ-ਨਾਲ ਇੱਕ footprint ਟੀਚੇ ਨੂੰ ਵੀ ਪੂਰਾ ਕਰਦਾ ਹੈ; ਮੁੱਖ ਧਾਰਾ ਦੇ WordPress 'ਤੇ ਇਹ ਸਿਰਫ਼ ਇੱਕ ਤੇਜ਼, ਚੰਗੀ ਤਰ੍ਹਾਂ ਵਿਵਹਾਰ ਕਰਨ ਵਾਲੀ ਪਰਤ ਹੈ ਜੋ ਮੂਲ ਸਰਵਰਾਂ ਨੂੰ ਵਿਹਲਾ ਰੱਖਦੀ ਹੈ।
ਅੰਦਰੂਨੀ ਤੌਰ 'ਤੇ, ਬੁਨਿਆਦੀ ਤੱਤਾਂ ਵਿੱਚ ਕੋਈ ਕਮੀ ਨਹੀਂ ਛੱਡੀ ਗਈ ਹੈ। ਸਾਈਟਾਂ HTTP/3 ਦੇ ਨਾਲ NVMe ਸਟੋਰੇਜ 'ਤੇ ਚੱਲਦੀਆਂ ਹਨ, ਇਸ ਲਈ ਕੈਸ਼ ਦੁਆਰਾ ਭੇਜੇ ਗਏ ਬਾਈਟ ਕਿਸੇ ਵੀ ਕੈਸ਼ ਮਿਸ ਦੇ ਪਿੱਛੇ ਤੇਜ਼ ਸਟੋਰੇਜ ਵਾਲੇ ਇੱਕ ਆਧੁਨਿਕ, ਮਲਟੀਪਲੈਕਸਡ ਟਰਾਂਸਪੋਰਟ ਰਾਹੀਂ ਪਹੁੰਚਦੇ ਹਨ। ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਲੇਅਰ ਐਡ-ਆਨ ਨਹੀਂ ਹੈ: LiteSpeed, LSCache, ਪ੍ਰਤੀ-ਸਾਈਟ Redis, NVMe ਅਤੇ HTTP/3 ਹਰੇਕ ਪਲਾਨ 'ਤੇ ਮੂਲ ਆਧਾਰ ਹਨ, ਨਾ ਕਿ ਕੋਈ ਅੱਪਸੇਲ ਪੱਧਰ।
ਅਸਲ ਵਿੱਚ ਕਿਹੜੀ ਚੀਜ਼ Core Web Vitals ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੀ ਹੈ
ਸਟੀਕ ਹੋਣਾ ਲਾਹੇਵੰਦ ਹੈ, ਕਿਉਂਕਿ ਹੋਸਟਿੰਗ ਨੂੰ ਅਕਸਰ Core Web Vitals ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਵਧਾ-ਚੜ੍ਹਾ ਕੇ ਪੇਸ਼ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। TTFB ਸਮੀਕਰਨ ਦਾ ਉਹ ਹਿੱਸਾ ਹੈ ਜਿਸਦਾ ਨਿਯੰਤਰਣ ਸਰਵਰ ਕੋਲ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਉੱਪਰ ਦਿੱਤਾ ਕੈਸ਼ਿੰਗ ਸਟੈਕ ਇਸਨੂੰ ਘਟਾਉਣ ਦਾ ਕੰਮ ਕਰਦਾ ਹੈ — ਐੱਜ ਤੋਂ HTTP/3 ਰਾਹੀਂ ਸਰਵ ਕੀਤਾ ਗਿਆ ਕੈਸ਼ ਕੀਤਾ ਪੂਰਾ ਪੰਨਾ TTFB ਦੇ ਸਭ ਤੋਂ ਹੇਠਲੇ ਪੱਧਰ ਦੇ ਬਰਾਬਰ ਹੁੰਦਾ ਹੈ। ਕਿਉਂਕਿ TTFB Largest Contentful Paint ਦਾ ਸ਼ੁਰੂਆਤੀ ਪੜਾਅ ਹੈ, ਇਸ ਲਈ ਇੱਕ ਤੇਜ਼ ਓਰੀਜਨ ਹਰੇਕ ਡਾਊਨਸਟ੍ਰੀਮ ਮੈਟ੍ਰਿਕ ਨੂੰ ਇੱਕ ਅਜਿਹੀ ਸ਼ੁਰੂਆਤੀ ਬੜ੍ਹਤ ਦਿੰਦਾ ਹੈ ਜੋ ਹੋਰ ਕਿਸੇ ਤਰੀਕੇ ਨਾਲ ਸੰਭਵ ਨਹੀਂ ਹੈ।
ਪਰ LCP, CLS ਅਤੇ INP ਜ਼ਿਆਦਾਤਰ ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ, ਪੰਨੇ ਦੁਆਰਾ ਹੀ ਤੈਅ ਕੀਤੇ ਜਾਂਦੇ ਹਨ: ਇੱਕ ਅਣ-ਅਨੁਕੂਲਿਤ ਹੀਰੋ ਚਿੱਤਰ, ਰੈਂਡਰਿੰਗ ਨੂੰ ਰੋਕਣ ਵਾਲੇ CSS ਅਤੇ JavaScript, ਫੌਂਟਾਂ ਅਤੇ ਵਿਗਿਆਪਨਾਂ ਦੇ ਲੋਡ ਹੋਣ ਨਾਲ ਬਦਲਦਾ ਖਾਕਾ, ਅਤੇ ਪਲੱਗਇਨਾਂ ਤੋਂ ਮੁੱਖ-ਥ੍ਰੈੱਡ ਦਾ ਭਾਰੀ ਕੰਮ। ਸਰਵਰ ਕੈਚਿੰਗ ਦੀ ਕੋਈ ਵੀ ਮਾਤਰਾ 2 MB ਦੇ ਹੀਰੋ ਚਿੱਤਰ ਜਾਂ ਮੈਗਾਬਾਈਟ JavaScript ਭੇਜਣ ਵਾਲੀ ਥੀਮ ਨੂੰ ਠੀਕ ਨਹੀਂ ਕਰ ਸਕਦੀ। ਇਮਾਨਦਾਰ ਹੋਸਟਿੰਗ ਸਰਵਰ ਦੇ ਯੋਗਦਾਨ ਨੂੰ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਢੰਗ ਨਾਲ ਮੁਫਤ ਅਤੇ ਇਕਸਾਰ ਬਣਾਉਂਦੀ ਹੈ, ਫਿਰ ਫਰੰਟ ਐਂਡ ਨੂੰ ਸੁਚਾਰੂ ਰੱਖਣਾ ਸਾਈਟ ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਹੁੰਦੀ ਹੈ।
ਕੰਮ ਦੀ ਇਹ ਵੰਡ ਇੱਕ ਉਪਯੋਗੀ ਮਾਨਸਿਕ ਮਾਡਲ ਹੈ। ਅਸੀਂ ਗਾਰੰਟੀ ਦਿੰਦੇ ਹਾਂ ਕਿ ਬੇਨਤੀ ਬ੍ਰਾਊਜ਼ਰ ਤੱਕ ਤੇਜ਼ੀ ਨਾਲ ਪਹੁੰਚਦੀ ਹੈ ਅਤੇ ਟ੍ਰੈਫਿਕ ਦੌਰਾਨ ਵੀ ਤੇਜ਼ ਰਹਿੰਦੀ ਹੈ; ਤੁਸੀਂ ਪੇਲੋਡ ਨੂੰ ਛੋਟਾ ਅਤੇ ਸਥਿਰ ਰੱਖੋ। ਜਿੱਥੇ ਇਹ ਦੋਵੇਂ ਮਿਲਦੇ ਹਨ — ਕੈਸ਼ ਵਾਰਮ-ਅੱਪ, ਐੱਜ ਡਿਲੀਵਰੀ, ਅਤੇ ਡਾਟਾਬੇਸ ਨੂੰ ਜਵਾਬਦੇਹ ਰੱਖਣਾ ਤਾਂ ਜੋ ਡਾਇਨਾਮਿਕ ਪੰਨੇ ਰੁਕ ਨਾ ਜਾਣ — ਬਿਲਕੁਲ ਉੱਥੇ ਹੀ ਸਾਡਾ ਸਟੈਕ ਟਿਊਨ ਕੀਤਾ ਗਿਆ ਹੈ, ਅਤੇ ਇਹੀ ਚੀਜ਼ ਇਸ ਪਲੇਟਫਾਰਮ 'ਤੇ ਪ੍ਰਬੰਧਿਤ WordPress ਨੂੰ ਇੱਕ ਆਮ ਹੋਸਟ 'ਤੇ ਉਸੇ ਸਾਈਟ ਨਾਲੋਂ ਤੇਜ਼ ਬਣਾਉਂਦੀ ਹੈ।
ਅਕਸਰ ਪੁੱਛੇ ਜਾਂਦੇ ਸਵਾਲ
ਕੀ ਮੈਨੂੰ ਅਜੇ ਵੀ WP Rocket ਵਰਗੇ ਕੈਚਿੰਗ ਪਲੱਗਇਨ ਦੀ ਲੋੜ ਹੈ?
ਨਹੀਂ। ਪੂਰੇ ਪੰਨੇ ਦੀ ਕੈਚਿੰਗ ਵੈੱਬ ਸਰਵਰ 'ਤੇ LiteSpeed ਦੇ LSCache ਦੁਆਰਾ ਸੰਭਾਲੀ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਸਾਡਾ ਆਪਣਾ ਕੈਸ਼ ਪਲੱਗਇਨ — ਪਹਿਲਾਂ ਤੋਂ ਸਥਾਪਤ ਅਤੇ ਆਟੋ-ਅੱਪਡੇਟ ਹੋਣ ਵਾਲਾ — WordPress ਨੂੰ ਇਸ ਨਾਲ ਸਹੀ ਢੰਗ ਨਾਲ ਜੋੜਦਾ ਹੈ, ਜਿਸ ਦੇ ਪਿੱਛੇ ਪ੍ਰਤੀ-ਸਾਈਟ ਇੱਕ Redis ਆਬਜੈਕਟ ਕੈਸ਼ ਹੁੰਦਾ ਹੈ। ਇਸਦੇ ਉੱਪਰ ਇੱਕ ਹੋਰ ਪੂਰੇ ਪੰਨੇ ਦਾ ਕੈਚਿੰਗ ਪਲੱਗਇਨ ਜੋੜਨਾ ਮਦਦ ਕਰਨ ਦੀ ਬਜਾਏ ਆਮ ਤੌਰ 'ਤੇ ਸਰਵਰ-ਪੱਧਰੀ ਕੈਸ਼ ਨਾਲ ਟਕਰਾਅ ਪੈਦਾ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਇਸਦੀ ਲੋੜ ਨਹੀਂ ਹੈ ਅਤੇ ਇਸਦੀ ਸਿਫ਼ਾਰਸ਼ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ।
ਕੀ ਕੈਸ਼ਿੰਗ ਮੇਰੀ WooCommerce ਕਾਰਟ ਜਾਂ ਲੌਗ-ਇਨ ਕੀਤੇ ਪੰਨਿਆਂ ਨੂੰ ਖਰਾਬ ਕਰੇਗੀ?
ਨਹੀਂ। Cart, checkout, my-account ਅਤੇ ਕੋਈ ਵੀ nonce ਜਾਂ session ਪੰਨੇ ਮੂਲ ਰੂਪ ਵਿੱਚ ਕੈਸ਼ ਤੋਂ ਬਾਹਰ ਰੱਖੇ ਜਾਂਦੇ ਹਨ, ਅਤੇ ESI ਕਾਰਟ ਦੇ ਭਾਗ ਅਤੇ ਕੁੱਲ ਰਕਮ ਨੂੰ ਹੋਰ ਕੈਸ਼ ਕੀਤੇ ਪੰਨਿਆਂ 'ਤੇ ਲਾਈਵ ਰੱਖਦਾ ਹੈ। ਖਰੀਦਦਾਰ ਹਮੇਸ਼ਾ ਆਪਣੀ ਟੋਕਰੀ ਅਤੇ ਇੱਕ ਕੰਮ ਕਰਦਾ ਚੈੱਕਆਊਟ ਦੇਖਦੇ ਹਨ ਜਦੋਂ ਕਿ ਸਟੋਰਫਰੰਟ ਅਜੇ ਵੀ ਕੈਸ਼ ਤੋਂ ਲੋਡ ਹੁੰਦਾ ਹੈ।
ਜਦੋਂ ਮੈਂ ਪ੍ਰਕਾਸ਼ਿਤ ਜਾਂ ਸੰਪਾਦਿਤ ਕਰਦਾ ਹਾਂ ਤਾਂ ਕੈਸ਼ ਕਿਵੇਂ ਤਾਜ਼ਾ ਰਹਿੰਦਾ ਹੈ?
ਸਮਾਰਟ ਆਟੋ-ਪਰਜ ਢੁਕਵੇਂ WordPress ਹੁੱਕਾਂ 'ਤੇ ਚੱਲਦਾ ਹੈ, ਇਸ ਲਈ ਸਮੱਗਰੀ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨ, ਸੰਪਾਦਿਤ ਕਰਨ, ਜਾਂ ਕਿਸੇ ਉਤਪਾਦ, ਕੀਮਤ ਜਾਂ ਆਰਡਰ ਨੂੰ ਬਦਲਣ ਨਾਲ ਸਿਰਫ਼ ਪ੍ਰਭਾਵਿਤ ਪੰਨੇ ਅਤੇ ਉਹਨਾਂ ਦੇ ਪੁਰਾਲੇਖ ਹੀ ਸਾਫ਼ ਹੁੰਦੇ ਹਨ — ਨਾ ਕਿ ਪੂਰਾ ਕੈਸ਼ੇ — ਅਤੇ ਇੱਕ ਕ੍ਰਾਲਰ ਉਹਨਾਂ ਨੂੰ ਦੁਬਾਰਾ ਗਰਮ ਕਰਦਾ ਹੈ। ਤੁਸੀਂ ਡੈਸ਼ਬੋਰਡ ਤੋਂ ਜਾਂ WordPress ਦੇ ਅੰਦਰੋਂ ਮੰਗ 'ਤੇ ਵੀ ਪਰਜ ਕਰ ਸਕਦੇ ਹੋ।
ਕੀ ਸਿਰਫ਼ ਹੋਸਟਿੰਗ ਹੀ ਮੈਨੂੰ ਸੰਪੂਰਨ Core Web Vitals ਦੇ ਸਕਦੀ ਹੈ?
ਇਹ ਤੁਹਾਨੂੰ ਸਭ ਤੋਂ ਵਧੀਆ ਸੰਭਵ TTFB ਦਿੰਦਾ ਹੈ, ਜੋ ਕਿ ਸਰਵਰ ਦਾ ਹਿੱਸਾ ਹੈ ਅਤੇ Largest Contentful Paint ਲਈ ਇੱਕ ਸ਼ੁਰੂਆਤੀ ਬੜ੍ਹਤ ਹੈ। ਪਰ LCP, CLS ਅਤੇ INP ਮੁੱਖ ਤੌਰ 'ਤੇ ਪੰਨੇ ਦੁਆਰਾ ਹੀ ਨਿਰਧਾਰਤ ਕੀਤੇ ਜਾਂਦੇ ਹਨ — ਚਿੱਤਰ ਆਕਾਰ, ਰੈਂਡਰ-ਬਲਾਕਿੰਗ ਸਰੋਤ, ਲੇਆਉਟ ਸਥਿਰਤਾ ਅਤੇ ਮੁੱਖ-ਥ੍ਰੈੱਡ JavaScript। ਸਾਡਾ ਸਟੈਕ ਸਰਵਰ ਦੇ ਯੋਗਦਾਨ ਨੂੰ ਤੇਜ਼ ਅਤੇ ਇਕਸਾਰ ਬਣਾਉਂਦਾ ਹੈ; ਫਰੰਟ-ਐਂਡ ਪੇਲੋਡ ਨੂੰ ਹਲਕਾ ਰੱਖਣਾ ਹੀ ਬਾਕੀ ਬਚੇ ਪਾੜੇ ਨੂੰ ਪੂਰਾ ਕਰਦਾ ਹੈ।
ਸੰਬੰਧਿਤ
ਇਸਨੂੰ 14 ਦਿਨਾਂ ਲਈ ਮੁਫ਼ਤ ਅਜ਼ਮਾਓ
ਆਪਣੀਆਂ ਪਹਿਲੀਆਂ ਸਾਈਟਾਂ 14 ਦਿਨਾਂ ਲਈ ਮੁਫ਼ਤ ਵਿੱਚ ਸ਼ੁਰੂ ਕਰੋ — ਕਿਸੇ ਕਾਰਡ ਦੀ ਲੋੜ ਨਹੀਂ। ਕੀ ਕੋਈ ਮੌਜੂਦਾ ਨੈੱਟਵਰਕ ਤਬਦੀਲ ਕਰ ਰਹੇ ਹੋ? ਮਾਈਗ੍ਰੇਸ਼ਨ ਮੁਫ਼ਤ ਅਤੇ ਅਸੀਮਤ ਹਨ।
ਮੁਫ਼ਤ ਸ਼ੁਰੂ ਕਰੋ