ಹೋಸ್ಟಿಂಗ್ ಮತ್ತು ಕಾರ್ಯಕ್ಷಮತೆ
ನಾವು 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 ಅನ್ನು ಬಳಸದೆ ಅಥವಾ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಸಂಪರ್ಕಿಸದೆ, ನೇರವಾಗಿ ಕ್ಯಾಶ್ನಿಂದ ಮುಂಚಿತವಾಗಿ ರೆಂಡರ್ ಮಾಡಲಾದ ಪೂರ್ಣ ಪುಟವಾಗಿ ಒದಗಿಸಲಾಗುತ್ತದೆ. ಇದನ್ನು ಸಾಧ್ಯವಾಗಿಸುವ ಪದರಗಳು ಹೇಗೆ ಒಟ್ಟಿಗೆ ಹೊಂದಿಕೊಳ್ಳುತ್ತವೆ ಮತ್ತು ಪ್ರತಿಯೊಂದೂ ತನ್ನ ಸ್ಥಾನವನ್ನು ಹೇಗೆ ಸಮರ್ಥಿಸಿಕೊಳ್ಳುತ್ತದೆ ಎಂಬುದರ ಕುರಿತು ಈ ಪೋಸ್ಟ್‌ನ ಉಳಿದ ಭಾಗವು ವಿವರಿಸುತ್ತದೆ.
ಮುಖ್ಯವಾದ ಅಂಶವೆಂದರೆ, ಇವುಗಳು ನೀವು ಆಯ್ಕೆ ಮಾಡಬೇಕಾದ ಪರಸ್ಪರ ಸ್ಪರ್ಧಾತ್ಮಕ ಕ್ಯಾಶ್‌ಗಳಲ್ಲ. ಪೂರ್ಣ-ಪುಟದ ಕ್ಯಾಶ್ (full-page cache), ಆಬ್ಜೆಕ್ಟ್ ಕ್ಯಾಶ್ ಮತ್ತು CDN ಎಡ್ಜ್ ಪ್ರತಿಯೊಂದೂ ಬೇರೆ ಬೇರೆ ರೀತಿಯ ವಿನಂತಿಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತವೆ, ಮತ್ತು ಅವು ಒಂದಕ್ಕೊಂದು ಹೇಗೆ ಕಾರ್ಯವನ್ನು ಹಸ್ತಾಂತರಿಸುತ್ತವೆ ಎಂಬುದರಲ್ಲೇ ಅವುಗಳ ಮೌಲ್ಯ ಅಡಗಿದೆ.
LiteSpeed Enterprise + LSCache: ಸಂಪೂರ್ಣ-ಪುಟದ ಪದರ
ಪ್ರತಿಯೊಂದು ಸೈಟ್ ಸರ್ವರ್-ಮಟ್ಟದ LSCache ನೊಂದಿಗೆ LiteSpeed Enterprise ನಲ್ಲಿ ಚಲಿಸುತ್ತದೆ. ಫ್ರಂಟ್-ಎಂಡ್ ಪ್ರತಿಕ್ರಿಯೆಯು ಸಂಗ್ರಹಿಸಬಹುದಾದಾಗ (ಕ್ಯಾಶ್ ಮಾಡಬಹುದಾದಾಗ), ವೆಬ್ ಸರ್ವರ್ ಅದನ್ನು LiteSpeed ಕ್ಯಾಶ್-ನಿಯಂತ್ರಣ ಮತ್ತು ಟ್ಯಾಗ್ ಹೆಡರ್‌ಗಳೊಂದಿಗೆ ಗುರುತಿಸುತ್ತದೆ, ಮತ್ತು ಮುಂದಿನ ವೀಕ್ಷಣೆಯಲ್ಲೇ LiteSpeed ಸಂಪೂರ್ಣ ಪುಟವನ್ನು ನೇರವಾಗಿ ಒದಗಿಸುತ್ತದೆ — ಯಾವುದೇ PHP ಪ್ರಕ್ರಿಯೆಯು ರಚನೆಯಾಗುವುದಿಲ್ಲ, ಯಾವುದೇ MySQL ಕ್ವೆರಿಯನ್ನು ರವಾನಿಸಲಾಗುವುದಿಲ್ಲ. ಇದು ಅಪ್ಲಿಕೇಶನ್‌ನ ಸಂಪೂರ್ಣ ಬೂಟ್ ಅನ್ನು ಪ್ರಮುಖ ಮಾರ್ಗದಿಂದ ತೆಗೆದುಹಾಕುವುದರಿಂದ, WordPress TTFB ಮೇಲಿನ ಏಕೈಕ ಅತಿ ದೊಡ್ಡ ಪ್ರಭಾವವಾಗಿದೆ.
LSCache PHP ಪ್ಲಗಿನ್‌ನಲ್ಲಿ ಇರುವ ಬದಲು ವೆಬ್ ಸರ್ವರ್‌ನೊಳಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದರಿಂದ, ಇದು ವಿನಂತಿಯ ಜೀವಿತಾವಧಿಯಲ್ಲಿ ಮೊದಲೇ ಕಾರ್ಯನಿರ್ವಹಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ ಮತ್ತು ಸರ್ವರ್ ತಕ್ಷಣವೇ ಫ್ಲಶ್ ಮಾಡಬಹುದಾದ ರೂಪದಲ್ಲಿ ಪುಟಗಳನ್ನು ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುತ್ತದೆ. ಕ್ಯಾಶ್ ಕ್ರಾಲರ್ ಜನಪ್ರಿಯ ಪುಟಗಳನ್ನು ಸದಾ ಸಿದ್ಧ ಸ್ಥಿತಿಯಲ್ಲಿಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಕ್ಯಾಶ್ ತೆರವುಗೊಳಿಸಿದ ನಂತರ ಭೇಟಿ ನೀಡುವ ಮೊದಲ ಸಂದರ್ಶಕರು ಪುಟವನ್ನು ಮರು-ರಚಿಸುವ ಹೊರೆಯನ್ನು ಹೊರಬೇಕಾಗಿಲ್ಲ. ಇದರ ಫಲಿತಾಂಶವಾಗಿ, ಕ್ಯಾಶ್ ಇನ್ನೂ PHP ಯ ಹಿಂದೆ ಇರುವ ಸಾಮಾನ್ಯ ಸ್ಟಾಕ್‌ಗೆ ಜೋಡಿಸಲಾದ ಕೇವಲ-ಪ್ಲಗಿನ್ ಕ್ಯಾಶ್‌ಗಿಂತ ಗಮನಾರ್ಹವಾಗಿ ಕಡಿಮೆ ಮತ್ತು ಹೆಚ್ಚು ಸ್ಥಿರವಾದ TTFB ದೊರೆಯುತ್ತದೆ.
ನಮ್ಮದೇ ರೆಪೊ-ದರ್ಜೆಯ ಕ್ಯಾಶ್ ಪ್ಲಗಿನ್ ಪ್ರತಿಯೊಂದು ಸೈಟ್‌ನಲ್ಲೂ ಮೊದಲೇ ಇನ್‌ಸ್ಟಾಲ್ ಆಗಿರುತ್ತದೆ ಮತ್ತು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ನವೀಕರಣಗೊಳ್ಳುತ್ತದೆ, ಇದು WordPress ಅನ್ನು LSCache ಗೆ ನೇರವಾಗಿ ಸರಿಯಾಗಿ ಸಂಪರ್ಕಿಸುತ್ತದೆ. LiteSpeed ಅಲ್ಲದ ಮೂಲದಲ್ಲಿ, ಇದು ಪೂರ್ಣ-ಪುಟದ ಹೆಡರ್‌ಗಳನ್ನು ಹೊರಸೂಸುವುದಿಲ್ಲ ಮತ್ತು ಯಾವುದೇ ಅಡ್ಡಿಪಡಿಸುವುದಿಲ್ಲ, ಅದೇ ಸಮಯದಲ್ಲಿ ಆಬ್ಜೆಕ್ಟ್ ಕ್ಯಾಶ್ ಮತ್ತು ಹೊರಗಿಡುವ ನಿಯಮಗಳು ತಮ್ಮ ಕೆಲಸವನ್ನು ಮುಂದುವರಿಸುತ್ತವೆ — ಆದ್ದರಿಂದ ಮೈಗ್ರೇಟ್ ಮಾಡಲಾದ ಸೈಟ್ ಎಂದಿಗೂ ಅರ್ಧ-ಕಾನ್ಫಿಗರ್ ಆದ ಅಥವಾ ದೋಷಪೂರಿತ ಸ್ಥಿತಿಯಲ್ಲಿ ಉಳಿಯುವುದಿಲ್ಲ.
ಹಳೆಯ ವಿಷಯವನ್ನು ನೀಡದೆ ವೇಗವಾಗಿರುವುದು: ESI ಮತ್ತು ಸ್ಮಾರ್ಟ್ ಸ್ವಯಂಚಾಲಿತ ಪರ್ಜ್
ಆಕ್ರಮಣಕಾರಿ ಪೂರ್ಣ-ಪುಟದ ಕ್ಯಾಶಿಂಗ್ ಎರಡು ಶ್ರೇಷ್ಠ ವೈಫಲ್ಯದ ವಿಧಾನಗಳನ್ನು ಹೊಂದಿದೆ: ಲಾಗ್ ಇನ್ ಆಗಿರುವ ಬಳಕೆದಾರರಿಗೆ ಬೇರೆಯವರ ಪುಟವನ್ನು ನೀಡುವುದು, ಮತ್ತು ಬದಲಾಗಬೇಕಾಗಿದ್ದ ಪುಟವನ್ನು ಯಾರಿಗಾದರೂ ನೀಡುವುದು. ಇವೆರಡನ್ನೂ ಕಡಿಮೆ ಕ್ಯಾಶ್ ಮಾಡುವ ಬದಲು ಕ್ಯಾಶಿಂಗ್ ಹಂತದಲ್ಲೇ ಪರಿಹರಿಸಲಾಗುತ್ತದೆ.
ESI (Edge Side Includes) ಲೈವ್ ಆಗಿ ಇರಬೇಕಾದ ಭಾಗಗಳಿಗೆ ಪ್ರತ್ಯೇಕ ಅವಕಾಶವನ್ನು ನೀಡುತ್ತಾ, ಪುಟವನ್ನು ಕ್ಯಾಶ್ ಮಾಡಲು ನಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. WooCommerce ಸ್ಟೋರ್‌ನಲ್ಲಿ ಸಾಧ್ಯವಾದಷ್ಟು ವೇಗದ TTFB ಗಾಗಿ ಕ್ಯಾಟಲಾಗ್, ಉತ್ಪನ್ನ ಮತ್ತು ವರ್ಗ ಪುಟಗಳನ್ನು ಪೂರ್ಣ-ಪುಟ ಕ್ಯಾಶ್ ಆಗಿ ನೀಡಲಾಗುತ್ತದೆ, ಆದರೆ ESI ಪ್ರತಿ ವಿನಂತಿಗೆ ಕಾರ್ಟ್ ತುಣುಕು, ಮಿನಿ-ಕಾರ್ಟ್ ಮೊತ್ತಗಳು ಮತ್ತು ಖಾತೆಯ ಸ್ಥಿತಿಯನ್ನು ರೆಂಡರ್ ಮಾಡುತ್ತದೆ. ಕಾರ್ಟ್, ಚೆಕ್ಔಟ್, ಮೈ-ಅಕೌಂಟ್ ಮತ್ತು ಯಾವುದೇ nonce ಅಥವಾ ಸೆಷನ್ ಪುಟಗಳನ್ನು ಡೀಫಾಲ್ಟ್ ಆಗಿ ಹೊರಗಿಡಲಾಗುತ್ತದೆ. ಶಾಪರ್‌ಗಳು ಯಾವಾಗಲೂ ತಮ್ಮದೇ ಆದ ಬುಟ್ಟಿಯನ್ನು ಮತ್ತು ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಚೆಕ್ಔಟ್ ಅನ್ನು ನೋಡುತ್ತಾರೆ; ಪ್ರತಿಯೊಬ್ಬರೂ ಇನ್ನೂ ಸ್ಟೋರ್‌ಫ್ರಂಟ್ ಅನ್ನು ಕ್ಯಾಶ್‌ನಿಂದಲೇ ಪಡೆಯುತ್ತಾರೆ.
ಸ್ಮಾರ್ಟ್ ಸ್ವಯಂ-ತೆರವುಗೊಳಿಸುವಿಕೆಯ ಮೂಲಕ ತಾಜಾತನವನ್ನು ನಿರ್ವಹಿಸಲಾಗುತ್ತದೆ. ವಿಷಯ, ಉತ್ಪನ್ನಗಳು, ಬೆಲೆಗಳು ಅಥವಾ ಆರ್ಡರ್‌ಗಳು ಬದಲಾದಾಗ ತೆರವುಗೊಳಿಸುವ ಹುಕ್‌ಗಳು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ, ಆದ್ದರಿಂದ ಸಂಬಂಧಿತ ಸಂಗ್ರಹಿತ (ಕ್ಯಾಶ್ ಮಾಡಿದ) ಪುಟಗಳು ಟೈಮರ್‌ಗೆ ಕಾಯದೆ ತಕ್ಷಣವೇ ರಿಫ್ರೆಶ್ ಆಗುತ್ತವೆ, ಮತ್ತು ನೀವು ಡ್ಯಾಶ್ಬೋರ್ಡ್ನಿಂದ ಅಥವಾ WordPress ಒಳಗಿನಿಂದಲೂ ಅಗತ್ಯಕ್ಕೆ ತಕ್ಕಂತೆ ತೆರವುಗೊಳಿಸಬಹುದು. ಟ್ಯಾಗ್-ಆಧಾರಿತ ತೆರವುಗೊಳಿಸುವಿಕೆಯು ಒಂದು ಪೋಸ್ಟ್ ಅನ್ನು ಸಂಪಾದಿಸಿದರೆ ಆ ಪೋಸ್ಟ್ ಮತ್ತು ಅದರ ಆರ್ಕೈವ್ಗಳನ್ನು ಮಾತ್ರ ತೆರವುಗೊಳಿಸುತ್ತದೆ — ಸಂಪೂರ್ಣ ಸಂಗ್ರಹವನ್ನಲ್ಲ — ಆದ್ದರಿಂದ ಒಂದೇ ಒಂದು ಸಂಪಾದನೆಯು ಸಂಪೂರ್ಣ ಸೈಟ್ ಅನ್ನು ಕೋಲ್ಡ್-ಸ್ಟಾರ್ಟ್ ಮಾಡುವುದಿಲ್ಲ.
ಪ್ರತಿ-ಸೈಟ್‌ಗೆ Redis ಆಬ್ಜೆಕ್ಟ್ ಕ್ಯಾಶ್: ಪೂರ್ಣ ಪುಟವಾಗಿರಲು ಸಾಧ್ಯವಾಗದಿರುವುದಕ್ಕಾಗಿ
ಪ್ರತಿಯೊಂದು ವಿನಂತಿಯೂ ಸ್ಥಿರವಾದ ಪೂರ್ಣ ಪುಟವಾಗಿರಲು ಸಾಧ್ಯವಿಲ್ಲ. ಲಾಗ್-ಇನ್ ಆಗಿರುವ ಸೆಷನ್‌ಗಳು, WordPress ನಿರ್ವಾಹಕರು, WooCommerce ಕಾರ್ಟ್‌ಗಳು, ಹುಡುಕಾಟ ಮತ್ತು ESI ಲೈವ್ ಆಗಿ ಬಿಡುವ ಡೈನಾಮಿಕ್ ತುಣುಕುಗಳು ಇವೆಲ್ಲವೂ PHP ಅನ್ನು ಚಲಾಯಿಸಬೇಕಾಗುತ್ತದೆ. ಅವುಗಳಿಗಾಗಿ, ಗುರಿಯು 'ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಬಿಟ್ಟುಬಿಡಿ' ಎಂಬುದರಿಂದ 'ಡೇಟಾಬೇಸ್ ಅನ್ನು ಬಿಟ್ಟುಬಿಡಿ' ಎಂಬುದಕ್ಕೆ ಬದಲಾಗುತ್ತದೆ.
ಪ್ರತಿಯೊಂದು ಸೈಟ್ ತನ್ನದೇ ಆದ ಮೀಸಲಾದ Redis ಆಬ್ಜೆಕ್ಟ್ ಕ್ಯಾಶ್ ಅನ್ನು ಪಡೆಯುತ್ತದೆ. ಪುನರಾವರ್ತಿತ ಡೇಟಾಬೇಸ್ ರೀಡ್‌ಗಳ ಫಲಿತಾಂಶಗಳನ್ನು — ಆಯ್ಕೆಗಳು, ಟ್ರಾನ್ಸಿಯೆಂಟ್‌ಗಳು, ಪೋಸ್ಟ್ ಮತ್ತು ಪದಗಳ ಹುಡುಕಾಟಗಳು, WooCommerce ಉತ್ಪನ್ನ ಮತ್ತು ಸೆಷನ್ ಡೇಟಾವನ್ನು — WordPress ಮೆಮೊರಿಯಲ್ಲಿ ಕ್ಯಾಶ್ ಮಾಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಪ್ರತಿ ವಿಸಿಟ್‌ಗೆ ಅದೇ ಕ್ವೆರಿಯು MySQL ವಿರುದ್ಧ ರನ್ ಆಗುವುದಿಲ್ಲ. ಪೂರ್ಣ-ಪುಟದ ಕ್ಯಾಶ್ ಸಹಾಯ ಮಾಡಲು ಸಾಧ್ಯವಾಗದ ಸ್ಥಳಗಳಲ್ಲಿಯೇ ಇದರ ಪರಿಣಾಮವು ಹೆಚ್ಚು ಗೋಚರಿಸುತ್ತದೆ: ವೇಗವಾದ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ಗಳು, ವೇಗವಾದ ಕಾರ್ಟ್‌ಗಳು ಮತ್ತು ಟ್ರಾಫಿಕ್ ಅಡಿಯಲ್ಲಿ ಅತ್ಯಂತ ಕಡಿಮೆ ಡೇಟಾಬೇಸ್ ಲೋಡ್.
ಆಬ್ಜೆಕ್ಟ್ ಕ್ಯಾಶ್ ಪ್ರತಿಯೊಂದು ಸೈಟ್‌ಗೆ ಪ್ರತ್ಯೇಕವಾಗಿದ್ದು ಹಂಚಿಕೊಳ್ಳಲ್ಪಟ್ಟಿರುವುದಿಲ್ಲ, ಇದು ಕಾರ್ಯಕ್ಷಮತೆ ಮತ್ತು ಪ್ರತ್ಯೇಕೀಕರಣ (ಐಸೋಲೇಶನ್) ಎರಡಕ್ಕೂ ಅತ್ಯಂತ ಮುಖ್ಯವಾಗಿದೆ. ಪ್ರತಿ-ಸೈಟ್ ಡೇಟಾಬೇಸ್ ಥ್ರೊಟ್ಲಿಂಗ್‌ನೊಂದಿಗೆ ಸಂಯೋಜಿಸಲ್ಪಟ್ಟಿರುವುದರಿಂದ, ಒಂದು ಸೈಟ್‌ನ ಅತಿಯಾದ ಅಥವಾ ಕಳಪೆಯಾಗಿ ಬರೆದ ಕ್ವೆರಿಗಳು ಅದರ ನೆರೆಯ ಸೈಟ್‌ಗಳ ಡೇಟಾಬೇಸ್ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಕಸಿದುಕೊಳ್ಳಲು ಸಾಧ್ಯವಿಲ್ಲ. ಸಂಪೂರ್ಣ ಬಹು-ಪದರದ ಸೆಟಪ್ ಹೇಗೆ ಒಟ್ಟಾಗಿ ಹೊಂದಿಕೊಳ್ಳುತ್ತದೆ ಎಂಬುದರ ಕುರಿತು ನಮ್ಮ ಕ್ಯಾಶಿಂಗ್ ವೈಶಿಷ್ಟ್ಯ ಪುಟದಲ್ಲಿ ಮತ್ತು ಪ್ರತ್ಯೇಕೀಕರಣದ ಅಡಿಯಲ್ಲಿ ಟೆನೆಂಟ್‌ಗಳ ನಡುವಿನ ಗಡಿಗಳ ಕುರಿತು ನೀವು ಇನ್ನಷ್ಟು ಓದಬಹುದು.
ಎಡ್ಜ್ ಮತ್ತು ಅದರ ಕೆಳಗಿನ ಸಾರಿಗೆ
ಮೂಲ ಸರ್ವರ್‌ನಲ್ಲಿರುವ ಕ್ಯಾಶ್ ಕೂಡ ನೆಟ್‌ವರ್ಕ್ ಮೂಲಕವೇ ಹಾದುಹೋಗಬೇಕಾಗುತ್ತದೆ. ಸರ್ವರ್‌ನ ಮುಂಭಾಗದಲ್ಲಿ CDN ಎಡ್ಜ್ ಇರುವುದರಿಂದ, ಸ್ಥಿರ ಸ್ವತ್ತುಗಳು ಮತ್ತು ಕ್ಯಾಶ್ ಮಾಡಬಹುದಾದ ಪುಟಗಳನ್ನು ಸಂದರ್ಶಕರಿಗೆ ಹತ್ತಿರವಿರುವ ಉಪಸ್ಥಿತಿ ಕೇಂದ್ರದಿಂದ (point of presence) ಒದಗಿಸಲಾಗುತ್ತದೆ, ಮತ್ತು ಅಧಿಕ ದಟ್ಟಣೆಯಲ್ಲೂ ಮೂಲ ಸರ್ವರ್ ಒತ್ತಡವಿಲ್ಲದೆ ಇರುತ್ತದೆ. ನಮ್ಮ 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 ನ ಆರಂಭಿಕ ಹಂತವಾಗಿರುವುದರಿಂದ, ವೇಗದ ಮೂಲವು (origin) ಪ್ರತಿಯೊಂದು ನಂತರದ ಮೆಟ್ರಿಕ್‌ಗೆ ಬೇರೆ ಯಾವುದೇ ರೀತಿಯಲ್ಲಿ ಪಡೆಯಲಾಗದ ಆರಂಭಿಕ ಮುನ್ನಡೆಯನ್ನು ನೀಡುತ್ತದೆ.
ಆದರೆ LCP, CLS ಮತ್ತು INP ಗಳು ಹೆಚ್ಚಾಗಿ ಬ್ರೌಸರ್‌ನಲ್ಲಿಯೇ, ಪುಟದಿಂದಲೇ ನಿರ್ಧರಿಸಲ್ಪಡುತ್ತವೆ: ಆಪ್ಟಿಮೈಸ್ ಮಾಡದ ಹೀರೋ ಇಮೇಜ್, ರೆಂಡರ್-ತಡೆಯುವ CSS ಮತ್ತು JavaScript, ಫಾಂಟ್‌ಗಳು ಮತ್ತು ಜಾಹೀರಾತುಗಳು ಲೋಡ್ ಆಗುತ್ತಿದ್ದಂತೆ ಬದಲಾಗುವ ಲೇಔಟ್ ಮತ್ತು ಪ್ಲಗ್‌ಇನ್‌ಗಳಿಂದ ಮುಖ್ಯ-ಥ್ರೆಡ್‌ನ ಭಾರವಾದ ಕೆಲಸ. ಸರ್ವರ್ ಕ್ಯಾಶಿಂಗ್‌ನ ಯಾವುದೇ ಪ್ರಮಾಣವು 2 MB ಹೀರೋ ಇಮೇಜ್ ಅನ್ನು ಅಥವಾ ಮೆಗಾಬೈಟ್‌ಗಳಷ್ಟು JavaScript ಅನ್ನು ರವಾನಿಸುವ ಥೀಮ್ ಅನ್ನು ಸರಿಪಡಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಪ್ರಾಮಾಣಿಕ ಹೋಸ್ಟಿಂಗ್ ಸರ್ವರ್‌ನ ಕೊಡುಗೆಯನ್ನು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಸರಳ ಮತ್ತು ಸ್ಥಿರವಾಗಿಸುತ್ತದೆ, ನಂತರ ಮುಂಭಾಗವನ್ನು ಹಗುರವಾಗಿಡುವುದು ಸೈಟ್‌ನ ಮೇಲಿರುತ್ತದೆ.
ಆ ಕೆಲಸದ ವಿಭಜನೆಯು ಉಪಯುಕ್ತವಾದ ಮಾನಸಿಕ ಮಾದರಿಯಾಗಿದೆ. ವಿನಂತಿಯು ಬ್ರೌಸರ್ ಅನ್ನು ತ್ವರಿತವಾಗಿ ತಲುಪುತ್ತದೆ ಮತ್ತು ಟ್ರಾಫಿಕ್ ಹೆಚ್ಚಿದ್ದಾಗಲೂ ವೇಗವಾಗಿ ಉಳಿಯುತ್ತದೆ ಎಂದು ನಾವು ಖಾತರಿಪಡಿಸುತ್ತೇವೆ; ನೀವು ಪೇಲೋಡ್ ಅನ್ನು ಚಿಕ್ಕದಾಗಿ ಮತ್ತು ಸ್ಥಿರವಾಗಿರಿಸಿಕೊಳ್ಳಿ. ಡೈನಾಮಿಕ್ ಪುಟಗಳು ಸ್ಥಗಿತಗೊಳ್ಳದಂತೆ ಕ್ಯಾಶ್ ವಾರ್ಮ್-ಅಪ್, ಎಡ್ಜ್ ಡೆಲಿವರಿ ಮತ್ತು ಡೇಟಾಬೇಸ್ ಸ್ಪಂದಿಸುವಂತೆ ಇರಿಸಿಕೊಳ್ಳುವುದು ಈ ಎರಡೂ ಭೇಟಿಯಾಗುವ ಸ್ಥಳಗಳಾಗಿವೆ — ಇದು ನಮ್ಮ ಸ್ಟ್ಯಾಕ್ ಅನ್ನು ಅತ್ಯುತ್ತಮವಾಗಿ ಸಿದ್ಧಪಡಿಸಲಾದ ಸ್ಥಳವಾಗಿದೆ, ಮತ್ತು ಇದು ಜೆನೆರಿಕ್ ಹೋಸ್ಟ್‌ನಲ್ಲಿರುವ ಅದೇ ಸೈಟ್‌ಗಿಂತ ಈ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನಲ್ಲಿ ನಿರ್ವಹಿಸಲ್ಪಡುವ WordPress ಅನ್ನು ಹೆಚ್ಚು ವೇಗವಾಗಿಸುತ್ತದೆ.
ಪದೇ ಪದೇ ಕೇಳಲಾಗುವ ಪ್ರಶ್ನೆಗಳು
ನನಗೆ ಇನ್ನೂ WP Rocket ನಂತಹ ಕ್ಯಾಶಿಂಗ್ ಪ್ಲಗಿನ್ ಅಗತ್ಯವಿದೆಯೇ?
ಇಲ್ಲ. ಪೂರ್ಣ-ಪುಟದ ಕ್ಯಾಶಿಂಗ್ ಅನ್ನು LiteSpeed ನ LSCache ಮೂಲಕ ವೆಬ್ ಸರ್ವರ್‌ನಲ್ಲಿ ನಿರ್ವಹಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ನಮ್ಮದೇ ಆದ ಕ್ಯಾಶ್ ಪ್ಲಗಿನ್ — ಮೊದಲೇ ಇನ್‌ಸ್ಟಾಲ್ ಮಾಡಲಾದ ಮತ್ತು ಸ್ವಯಂ-ಅಪ್‌ಡೇಟ್ ಆಗುವ — WordPress ಅನ್ನು ಸರಿಯಾಗಿ ಸಂಪರ್ಕಿಸುತ್ತದೆ, ಜೊತೆಗೆ ಇದರ ಹಿಂದೆ ಪ್ರತಿ-ಸೈಟ್‌ಗೆ ಪ್ರತ್ಯೇಕ Redis ಆಬ್ಜೆಕ್ಟ್ ಕ್ಯಾಶ್ ಇರುತ್ತದೆ. ಇದರ ಮೇಲೆ ಎರಡನೇ ಪೂರ್ಣ-ಪುಟದ ಕ್ಯಾಶಿಂಗ್ ಪ್ಲಗಿನ್ ಅನ್ನು ಸೇರಿಸುವುದು ಸಹಾಯ ಮಾಡುವ ಬದಲು ಸರ್ವರ್-ಮಟ್ಟದ ಕ್ಯಾಶ್ ಜೊತೆ ಸಂಘರ್ಷಕ್ಕೆ ಕಾರಣವಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ ಇದು ಅಗತ್ಯವಿಲ್ಲ ಮತ್ತು ಶಿಫಾರಸು ಮಾಡುವುದಿಲ್ಲ.
ಕ್ಯಾಶಿಂಗ್ ನನ್ನ WooCommerce ಕಾರ್ಟ್ ಅಥವಾ ಲಾಗ್-ಇನ್ ಆಗಿರುವ ಪುಟಗಳನ್ನು ಹಾಳುಮಾಡುತ್ತದೆಯೇ?
ಇಲ್ಲ. ಕಾರ್ಟ್, ಚೆಕ್ಔಟ್, my-account ಮತ್ತು ಯಾವುದೇ nonce ಅಥವಾ ಸೆಷನ್ ಪುಟಗಳನ್ನು ಡೀಫಾಲ್ಟ್ ಆಗಿ ಕ್ಯಾಶ್ನಿಂದ ಹೊರಗಿಡಲಾಗುತ್ತದೆ, ಮತ್ತು ESI ಕಾರ್ಟ್ ತುಣುಕು ಮತ್ತು ಒಟ್ಟು ಮೊತ್ತವನ್ನು ಇತರ ಕ್ಯಾಶ್ ಮಾಡಲಾದ ಪುಟಗಳಲ್ಲಿ ಲೈವ್ ಆಗಿ ಇರಿಸುತ್ತದೆ. ಅಂಗಡಿಯ ಮುಂಭಾಗವು ಇನ್ನೂ ಕ್ಯಾಶ್ನಿಂದ ಲೋಡ್ ಆಗುತ್ತಿರುವಾಗಲೂ ಗ್ರಾಹಕರು ಯಾವಾಗಲೂ ತಮ್ಮದೇ ಬುಟ್ಟಿ ಮತ್ತು ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಚೆಕ್ಔಟ್ ಅನ್ನು ನೋಡುತ್ತಾರೆ.
ನಾನು ಪ್ರಕಟಿಸಿದಾಗ ಅಥವಾ ಸಂಪಾದಿಸಿದಾಗ ಕ್ಯಾಶ್ ಹೇಗೆ ತಾಜಾವಾಗಿರುತ್ತದೆ?
ಸ್ಮಾರ್ಟ್ ಸ್ವಯಂಚಾಲಿತ-ಪರ್ಜ್ ಸೂಕ್ತವಾದ WordPress ಹುಕ್ಗಳಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ವಿಷಯವನ್ನು ಪ್ರಕಟಿಸುವುದು, ಸಂಪಾದಿಸುವುದು ಅಥವಾ ಉತ್ಪನ್ನ, ಬೆಲೆ ಅಥವಾ ಆರ್ಡರ್ ಅನ್ನು ಬದಲಾಯಿಸುವುದು ಬಾಧಿತ ಪುಟಗಳು ಮತ್ತು ಅವುಗಳ ಆರ್ಕೈವ್ಗಳನ್ನು ಮಾತ್ರ ತೆರವುಗೊಳಿಸುತ್ತದೆ — ಸಂಪೂರ್ಣ ಸಂಗ್ರಹವನ್ನು (ಕ್ಯಾಶ್) ಅಲ್ಲ — ಮತ್ತು ಕ್ರಾಲ್ ಮಾಡುವ ಸಾಧನವು ಅವುಗಳನ್ನು ಮತ್ತೆ ವಾರ್ಮ್ ಮಾಡುತ್ತದೆ. ನೀವು ಡ್ಯಾಶ್ಬೋರ್ಡ್ನಿಂದ ಅಥವಾ WordPress ಒಳಗಿನಿಂದಲೂ ಬೇಡಿಕೆಯ ಮೇರೆಗೆ ಪರ್ಜ್ ಮಾಡಬಹುದು.
ಹೋಸ್ಟಿಂಗ್ ಮಾತ್ರ ನನಗೆ ಪರಿಪೂರ್ಣ Core Web Vitals ನೀಡಬಹುದೇ?
ಇದು ನಿಮಗೆ ಸಾಧ್ಯವಾದಷ್ಟು ಉತ್ತಮವಾದ TTFB ಅನ್ನು ನೀಡುತ್ತದೆ, ಇದು ಸರ್ವರ್‌ನ ಪಾಲಾಗಿದೆ ಮತ್ತು Largest Contentful Paint ಗಾಗಿ ಉತ್ತಮ ಆರಂಭವಾಗಿದೆ. ಆದರೆ LCP, CLS ಮತ್ತು INP ಗಳು ಹೆಚ್ಚಾಗಿ ಪುಟದಿಂದಲೇ ನಿರ್ಧರಿಸಲ್ಪಡುತ್ತವೆ — ಚಿತ್ರದ ಗಾತ್ರಗಳು, ರೆಂಡರಿಂಗ್ ತಡೆಯುವ ಸ್ವತ್ತುಗಳು, ಲೇಔಟ್ ಸ್ಥಿರತೆ ಮತ್ತು ಮುಖ್ಯ-ಥ್ರೆಡ್‌ನ JavaScript. ನಮ್ಮ ಸ್ಟ್ಯಾಕ್ ಸರ್ವರ್‌ನ ಕೊಡುಗೆಯನ್ನು ವೇಗವಾಗಿ ಮತ್ತು ಸ್ಥಿರವಾಗಿಸುತ್ತದೆ; ಮುಂಭಾಗದ (ಫ್ರಂಟ್-ಎಂಡ್) ಡೇಟಾ ಹೊರೆಯನ್ನು ಮಿತವಾಗಿರಿಸಿಕೊಳ್ಳುವುದು ಉಳಿದ ಅಂತರವನ್ನು ತುಂಬುತ್ತದೆ.
ಸಂಬಂಧಿತ
ಇದನ್ನು 14 ದಿನಗಳವರೆಗೆ ಉಚಿತವಾಗಿ ಪ್ರಯತ್ನಿಸಿ
ನಿಮ್ಮ ಮೊದಲ ಸೈಟ್‌ಗಳನ್ನು 14 ದಿನಗಳವರೆಗೆ ಉಚಿತವಾಗಿ ಚಾಲನೆ ಮಾಡಿ — ಕಾರ್ಡ್ ಅಗತ್ಯವಿಲ್ಲ. ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ನೆಟ್‌ವರ್ಕ್ ಅನ್ನು ಸ್ಥಳಾಂತರಿಸುತ್ತಿರುವಿರಾ? ಮೈಗ್ರೇಶನ್‌ಗಳು ಉಚಿತ ಮತ್ತು ಯಾವುದೇ ಮಿತಿಯಿಲ್ಲ.
ಉಚಿತವಾಗಿ ಪ್ರಾರಂಭಿಸಿ