ಇತ್ತೀಚಿನ ವರ್ಷಗಳಲ್ಲಿ, ಫ್ರಂಟ್-ಎಂಡ್ ಪ್ರಾಜೆಕ್ಟ್‌ಗಳನ್ನು ಆಪ್ಟಿಮೈಸ್ ಮಾಡಲು ಹೆಚ್ಚು ಹೆಚ್ಚು ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳು ಸ್ವಯಂ-ಹೋಸ್ಟಿಂಗ್ ಅಥವಾ ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಪ್ರಾಕ್ಸಿ ಮಾಡಲು ಅವಕಾಶಗಳನ್ನು ನೀಡುತ್ತವೆ. Akamai ನಿಮಗೆ ಹೊಂದಿಸಲು ಅನುಮತಿಸುತ್ತದೆ ಸ್ವಯಂ-ರಚಿಸಿದ URL ಗಳಿಗಾಗಿ. ಕ್ಲೌಡ್‌ಫ್ಲೇರ್ ಎಡ್ಜ್ ವರ್ಕರ್ಸ್ ತಂತ್ರಜ್ಞಾನವನ್ನು ಹೊಂದಿದೆ. Fasterzine ಮಾಡಬಹುದು ಪುಟಗಳಲ್ಲಿನ URL ಗಳು ಸೈಟ್ನ ಮುಖ್ಯ ಡೊಮೇನ್‌ನಲ್ಲಿರುವ ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಸೂಚಿಸುತ್ತವೆ.
ನಿಮ್ಮ ಪ್ರಾಜೆಕ್ಟ್‌ನಲ್ಲಿ ಬಳಸಲಾದ ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಸೇವೆಗಳು ಆಗಾಗ್ಗೆ ಬದಲಾಗುವುದಿಲ್ಲ ಮತ್ತು ಅವುಗಳನ್ನು ಗ್ರಾಹಕರಿಗೆ ತಲುಪಿಸುವ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಸುಧಾರಿಸಬಹುದು ಎಂದು ನಿಮಗೆ ತಿಳಿದಿದ್ದರೆ, ನೀವು ಬಹುಶಃ ಅಂತಹ ಸೇವೆಗಳನ್ನು ಪ್ರಾಕ್ಸಿ ಮಾಡುವ ಬಗ್ಗೆ ಯೋಚಿಸುತ್ತಿದ್ದೀರಿ. ಈ ವಿಧಾನದೊಂದಿಗೆ, ನೀವು ಈ ಸಂಪನ್ಮೂಲಗಳನ್ನು ನಿಮ್ಮ ಬಳಕೆದಾರರಿಗೆ ಹತ್ತಿರ ತರಬಹುದು ಮತ್ತು ಕ್ಲೈಂಟ್ ಬದಿಯಲ್ಲಿ ಅವರ ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವಿಕೆಯ ಮೇಲೆ ಸಂಪೂರ್ಣ ನಿಯಂತ್ರಣವನ್ನು ಪಡೆಯಬಹುದು. ಇದು ಹೆಚ್ಚುವರಿಯಾಗಿ, ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಸೇವೆಯ "ಕ್ರ್ಯಾಶ್" ಅಥವಾ ಅದರ ಕಾರ್ಯಕ್ಷಮತೆಯ ಅವನತಿಯಿಂದ ಉಂಟಾಗುವ ತೊಂದರೆಗಳಿಂದ ಬಳಕೆದಾರರನ್ನು ರಕ್ಷಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ.
ಒಳ್ಳೆಯದು: ಸುಧಾರಿತ ಕಾರ್ಯಕ್ಷಮತೆ
ಬೇರೊಬ್ಬರ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಸ್ವಯಂ ಹೋಸ್ಟ್ ಮಾಡುವುದರಿಂದ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸ್ಪಷ್ಟ ರೀತಿಯಲ್ಲಿ ಸುಧಾರಿಸುತ್ತದೆ. ಬ್ರೌಸರ್ ಮತ್ತೆ DNS ಅನ್ನು ಪ್ರವೇಶಿಸುವ ಅಗತ್ಯವಿಲ್ಲ, ಇದು TCP ಸಂಪರ್ಕವನ್ನು ಸ್ಥಾಪಿಸುವ ಅಗತ್ಯವಿಲ್ಲ ಮತ್ತು ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಡೊಮೇನ್‌ನಲ್ಲಿ TLS ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಅನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ. ಕೆಳಗಿನ ಎರಡು ಅಂಕಿಗಳನ್ನು ಹೋಲಿಸುವ ಮೂಲಕ ಬೇರೊಬ್ಬರ ಸಂಪನ್ಮೂಲಗಳ ಸ್ವಯಂ-ಹೋಸ್ಟಿಂಗ್ ಕಾರ್ಯಕ್ಷಮತೆಯ ಮೇಲೆ ಹೇಗೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ ಎಂಬುದನ್ನು ನೀವು ನೋಡಬಹುದು.
ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಬಾಹ್ಯ ಮೂಲಗಳಿಂದ ಡೌನ್‌ಲೋಡ್ ಮಾಡಲಾಗಿದೆ (ಇದರಿಂದ ತೆಗೆದುಕೊಳ್ಳಲಾಗಿದೆ )
ಥರ್ಡ್-ಪಾರ್ಟಿ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಉಳಿದ ಸೈಟ್ ಸಾಮಗ್ರಿಗಳಂತೆಯೇ ಅದೇ ಸ್ಥಳದಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ (ಇದರಿಂದ ತೆಗೆದುಕೊಳ್ಳಲಾಗಿದೆ )
ಮುಖ್ಯ ಡೊಮೇನ್‌ನೊಂದಿಗೆ ಈಗಾಗಲೇ ಸ್ಥಾಪಿಸಲಾದ HTTP/2 ಸಂಪರ್ಕದಿಂದ ಡೇಟಾವನ್ನು ಮಲ್ಟಿಪ್ಲೆಕ್ಸ್ ಮತ್ತು ಆದ್ಯತೆಯ ಸಾಮರ್ಥ್ಯವನ್ನು ಬ್ರೌಸರ್ ಬಳಸುತ್ತದೆ ಎಂಬ ಅಂಶದಿಂದ ಪರಿಸ್ಥಿತಿಯನ್ನು ಸುಧಾರಿಸಲಾಗಿದೆ.
ನೀವು ಥರ್ಡ್-ಪಾರ್ಟಿ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಹೋಸ್ಟ್ ಮಾಡದಿದ್ದರೆ, ಮುಖ್ಯವಾದುದಕ್ಕಿಂತ ವಿಭಿನ್ನವಾದ ಡೊಮೇನ್‌ನಿಂದ ಅವುಗಳನ್ನು ಲೋಡ್ ಮಾಡುವುದರಿಂದ, ಅವುಗಳನ್ನು ಆದ್ಯತೆ ನೀಡಲಾಗುವುದಿಲ್ಲ. ಇದು ಕ್ಲೈಂಟ್‌ನ ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್‌ಗಾಗಿ ಪರಸ್ಪರ ಸ್ಪರ್ಧಿಸಲು ಕಾರಣವಾಗುತ್ತದೆ. ಇದು ಆದರ್ಶ ಸಂದರ್ಭಗಳಲ್ಲಿ ಸಾಧಿಸಬಹುದಾದ ಪುಟಕ್ಕಿಂತ ಹೆಚ್ಚು ಉದ್ದವಾದ ಪುಟವನ್ನು ನಿರ್ಮಿಸಲು ಪ್ರಮುಖವಾದ ವಿಷಯಕ್ಕಾಗಿ ಲೋಡ್ ಸಮಯವನ್ನು ಉಂಟುಮಾಡಬಹುದು. ಎಲ್ಲವನ್ನೂ ಚೆನ್ನಾಗಿ ವಿವರಿಸುವ HTTP/2 ಆದ್ಯತೆಯ ಕುರಿತು ಮಾತನಾಡಿ.
ಬಾಹ್ಯ ಸಂಪನ್ಮೂಲಗಳಿಗೆ ಲಿಂಕ್‌ಗಳಲ್ಲಿ ಗುಣಲಕ್ಷಣಗಳ ಬಳಕೆಯನ್ನು ಊಹಿಸಬಹುದು preconnect ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುವಲ್ಲಿ ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಆದಾಗ್ಯೂ, ವಿಭಿನ್ನ ಡೊಮೇನ್‌ಗಳಿಗೆ ಈ ಲಿಂಕ್‌ಗಳಲ್ಲಿ ಹಲವಾರು ಇದ್ದರೆ, ಇದು ಅತ್ಯಂತ ನಿರ್ಣಾಯಕ ಕ್ಷಣದಲ್ಲಿ ಸಂವಹನ ಮಾರ್ಗವನ್ನು ವಾಸ್ತವವಾಗಿ ಓವರ್‌ಲೋಡ್ ಮಾಡಬಹುದು.
ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಸಂಪನ್ಮೂಲಗಳನ್ನು ನೀವೇ ಹೋಸ್ಟ್ ಮಾಡಿದರೆ, ಕ್ಲೈಂಟ್‌ಗೆ ಈ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಎಷ್ಟು ನಿಖರವಾಗಿ ನೀಡಲಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ನೀವು ನಿಯಂತ್ರಿಸಬಹುದು. ಅವುಗಳೆಂದರೆ, ನಾವು ಈ ಕೆಳಗಿನವುಗಳ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತಿದ್ದೇವೆ:
- ಪ್ರತಿ ಬ್ರೌಸರ್‌ಗೆ ಸೂಕ್ತವಾದ ಡೇಟಾ ಕಂಪ್ರೆಷನ್ ಅಲ್ಗಾರಿದಮ್ ಅನ್ನು ಬಳಸಲಾಗಿದೆ ಎಂದು ನೀವು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಬಹುದು (Brotli/gzip).
- ಹೆಚ್ಚು ಪ್ರಸಿದ್ಧವಾದ ಪೂರೈಕೆದಾರರೊಂದಿಗೆ (ಉದಾಹರಣೆಗೆ, GA ಟ್ಯಾಗ್‌ಗೆ ಅನುಗುಣವಾದ ಮೌಲ್ಯವನ್ನು 30 ನಿಮಿಷಗಳಿಗೆ ಹೊಂದಿಸಲಾಗಿದೆ) ಸಹ ಸಾಮಾನ್ಯವಾಗಿ ನಿರ್ದಿಷ್ಟವಾಗಿ ದೀರ್ಘವಾಗಿರದ ಸಂಪನ್ಮೂಲಗಳಿಗಾಗಿ ನೀವು ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವ ಸಮಯವನ್ನು ಹೆಚ್ಚಿಸಬಹುದು.
ನಿಮ್ಮ ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವ ನಿರ್ವಹಣಾ ಕಾರ್ಯತಂತ್ರದಲ್ಲಿ (URL ಹ್ಯಾಶ್‌ಗಳು, ಆವೃತ್ತಿಗಳು, ಇತ್ಯಾದಿ) ಸಂಬಂಧಿತ ವಿಷಯವನ್ನು ಸೇರಿಸುವ ಮೂಲಕ ನೀವು ಸಂಪನ್ಮೂಲಕ್ಕಾಗಿ TTL ಅನ್ನು ಒಂದು ವರ್ಷಕ್ಕೆ ವಿಸ್ತರಿಸಬಹುದು. ನಾವು ಇದರ ಬಗ್ಗೆ ಕೆಳಗೆ ಮಾತನಾಡುತ್ತೇವೆ.
▍ಥರ್ಡ್-ಪಾರ್ಟಿ ಸೇವೆಗಳ ಕಾರ್ಯಾಚರಣೆಯಲ್ಲಿ ಅಡಚಣೆಗಳ ವಿರುದ್ಧ ರಕ್ಷಣೆ ಅಥವಾ ಅವುಗಳ ಸ್ಥಗಿತಗೊಳಿಸುವಿಕೆ
ಥರ್ಡ್-ಪಾರ್ಟಿ ಸಂಪನ್ಮೂಲಗಳ ಸ್ವಯಂ-ಹೋಸ್ಟಿಂಗ್‌ನ ಮತ್ತೊಂದು ಆಸಕ್ತಿದಾಯಕ ಅಂಶವೆಂದರೆ ಅದು ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಸೇವೆಗಳ ನಿಲುಗಡೆಗೆ ಸಂಬಂಧಿಸಿದ ಅಪಾಯಗಳನ್ನು ತಗ್ಗಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ನೀವು ಬಳಸುತ್ತಿರುವ ಮೂರನೇ ವ್ಯಕ್ತಿಯ A/B ಪರೀಕ್ಷಾ ಪರಿಹಾರವನ್ನು ಪುಟದ ಮುಖ್ಯ ವಿಭಾಗದಲ್ಲಿ ಲೋಡ್ ಮಾಡುವ ಬ್ಲಾಕಿಂಗ್ ಸ್ಕ್ರಿಪ್ಟ್ ಆಗಿ ಅಳವಡಿಸಲಾಗಿದೆ ಎಂದು ಭಾವಿಸೋಣ. ಈ ಸ್ಕ್ರಿಪ್ಟ್ ನಿಧಾನವಾಗಿ ಲೋಡ್ ಆಗುತ್ತದೆ. ಅನುಗುಣವಾದ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಲೋಡ್ ಮಾಡಲು ವಿಫಲವಾದರೆ, ಪುಟವು ಖಾಲಿಯಾಗಿರುತ್ತದೆ. ಲೋಡ್ ಆಗಲು ಬಹಳ ಸಮಯ ತೆಗೆದುಕೊಂಡರೆ, ಪುಟವು ದೀರ್ಘ ವಿಳಂಬದೊಂದಿಗೆ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ. ಅಥವಾ, ಯೋಜನೆಯು ಮೂರನೇ ವ್ಯಕ್ತಿಯ CDN ಸಂಪನ್ಮೂಲದಿಂದ ಡೌನ್‌ಲೋಡ್ ಮಾಡಲಾದ ಲೈಬ್ರರಿಯನ್ನು ಬಳಸುತ್ತದೆ ಎಂದು ಭಾವಿಸೋಣ. ಈ ಸಂಪನ್ಮೂಲವು ವೈಫಲ್ಯವನ್ನು ಅನುಭವಿಸಿದೆ ಅಥವಾ ನಿರ್ದಿಷ್ಟ ದೇಶದಲ್ಲಿ ನಿರ್ಬಂಧಿಸಲಾಗಿದೆ ಎಂದು ಊಹಿಸೋಣ. ಅಂತಹ ಪರಿಸ್ಥಿತಿಯು ಸೈಟ್ನ ತರ್ಕದ ಉಲ್ಲಂಘನೆಗೆ ಕಾರಣವಾಗುತ್ತದೆ.
ಕೆಲವು ಬಾಹ್ಯ ಸೇವೆಗಳು ಲಭ್ಯವಿಲ್ಲದಿದ್ದಾಗ ನಿಮ್ಮ ಸೈಟ್ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಕಂಡುಹಿಡಿಯಲು, ನೀವು SPOF ವಿಭಾಗವನ್ನು ಬಳಸಬಹುದು .
webpagetest.org ನಲ್ಲಿ SPOF ವಿಭಾಗ
▍ಬ್ರೌಸರ್‌ಗಳಲ್ಲಿ ವಸ್ತುಗಳನ್ನು ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವ ಸಮಸ್ಯೆಗಳ ಬಗ್ಗೆ ಏನು? (ಸುಳಿವು: ಇದು ಪುರಾಣ)
ಸಾರ್ವಜನಿಕ ಸಿಡಿಎನ್‌ಗಳನ್ನು ಬಳಸುವುದರಿಂದ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಉತ್ತಮ ಸಂಪನ್ಮೂಲ ಕಾರ್ಯಕ್ಷಮತೆಗೆ ಕಾರಣವಾಗುತ್ತದೆ ಎಂದು ನೀವು ಭಾವಿಸಬಹುದು, ಏಕೆಂದರೆ ಈ ಸೇವೆಗಳು ಸಾಕಷ್ಟು ಉತ್ತಮ-ಗುಣಮಟ್ಟದ ನೆಟ್‌ವರ್ಕ್‌ಗಳನ್ನು ಹೊಂದಿವೆ ಮತ್ತು ಪ್ರಪಂಚದಾದ್ಯಂತ ವಿತರಿಸಲ್ಪಡುತ್ತವೆ. ಆದರೆ ಎಲ್ಲವೂ ವಾಸ್ತವವಾಗಿ ಸ್ವಲ್ಪ ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾಗಿದೆ.
ನಾವು ಹಲವಾರು ವಿಭಿನ್ನ ಸೈಟ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ ಎಂದು ಹೇಳೋಣ: website1.com, website2.com, website3.com. ಈ ಎಲ್ಲಾ ಸೈಟ್‌ಗಳು jQuery ಲೈಬ್ರರಿಯನ್ನು ಬಳಸುತ್ತವೆ. ನಾವು ಅದನ್ನು CDN ಬಳಸಿಕೊಂಡು ಅವರಿಗೆ ಸಂಪರ್ಕಿಸುತ್ತೇವೆ, ಉದಾಹರಣೆಗೆ - googleapis.com. ಬ್ರೌಸರ್ ಒಮ್ಮೆ ಲೈಬ್ರರಿಯನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡಲು ಮತ್ತು ಸಂಗ್ರಹಿಸಲು ನೀವು ನಿರೀಕ್ಷಿಸಬಹುದು ಮತ್ತು ನಂತರ ಅದನ್ನು ಎಲ್ಲಾ ಮೂರು ಸೈಟ್‌ಗಳಲ್ಲಿ ಬಳಸಬಹುದು. ಇದು ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿನ ಲೋಡ್ ಅನ್ನು ಕಡಿಮೆ ಮಾಡಬಹುದು. ಬಹುಶಃ ಇದು ಎಲ್ಲೋ ಹಣವನ್ನು ಉಳಿಸಲು ಮತ್ತು ಸಂಪನ್ಮೂಲ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸುಧಾರಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಪ್ರಾಯೋಗಿಕ ದೃಷ್ಟಿಕೋನದಿಂದ, ಎಲ್ಲವೂ ವಿಭಿನ್ನವಾಗಿ ಕಾಣುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ಸಫಾರಿ ಎಂಬ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಹೊಂದಿದೆ : ಸಂಗ್ರಹವು ಡಾಕ್ಯುಮೆಂಟ್‌ನ ಮೂಲ ಮತ್ತು ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಸಂಪನ್ಮೂಲದ ಮೂಲವನ್ನು ಆಧರಿಸಿ ಡ್ಯುಯಲ್ ಕೀಗಳನ್ನು ಬಳಸುತ್ತದೆ. ಈ ವಿಷಯದ ಬಗ್ಗೆ ಉತ್ತಮ ಲೇಖನ.
ಹಳೆಯ ಅಧ್ಯಯನಗಳು и , ಹಾಗೆಯೇ ಇತ್ತೀಚಿನದು ಪಾಲ್ ಕ್ಯಾಲ್ವಾನೊ, ನಾವು ನಿರೀಕ್ಷಿಸುವಷ್ಟು ಕಾಲ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಬ್ರೌಸರ್ ಕ್ಯಾಶ್‌ಗಳಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗುವುದಿಲ್ಲ ಎಂದು ತೋರಿಸಿ: “ಪ್ರಾಜೆಕ್ಟ್‌ನ ಸ್ವಂತ ಮತ್ತು ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಸಂಪನ್ಮೂಲಗಳ ಕ್ಯಾಶಿಂಗ್ ಸಮಯದ ನಡುವೆ ಗಂಭೀರ ಅಂತರವಿದೆ. ನಾವು CSS ಮತ್ತು ವೆಬ್ ಫಾಂಟ್‌ಗಳ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತಿದ್ದೇವೆ. ಅವುಗಳೆಂದರೆ, 95% ಸ್ಥಳೀಯ ಫಾಂಟ್‌ಗಳು ಒಂದು ವಾರಕ್ಕಿಂತ ಹೆಚ್ಚಿನ ಸಂಗ್ರಹ ಜೀವನವನ್ನು ಹೊಂದಿದ್ದರೆ, ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಫಾಂಟ್‌ಗಳ 50% ಒಂದು ವಾರಕ್ಕಿಂತ ಕಡಿಮೆ ಸಂಗ್ರಹ ಜೀವನವನ್ನು ಹೊಂದಿವೆ! ಇದು ವೆಬ್ ಡೆವಲಪರ್‌ಗಳಿಗೆ ಫಾಂಟ್ ಫೈಲ್‌ಗಳನ್ನು ಹೋಸ್ಟ್ ಮಾಡಲು ಬಲವಾದ ಕಾರಣವನ್ನು ನೀಡುತ್ತದೆ!
ಪರಿಣಾಮವಾಗಿ, ನೀವು ಇತರ ಜನರ ವಿಷಯವನ್ನು ಹೋಸ್ಟ್ ಮಾಡಿದರೆ, ಬ್ರೌಸರ್ ಕ್ಯಾಶಿಂಗ್‌ನಿಂದ ಉಂಟಾಗುವ ಯಾವುದೇ ಕಾರ್ಯಕ್ಷಮತೆಯ ಸಮಸ್ಯೆಗಳನ್ನು ನೀವು ಗಮನಿಸುವುದಿಲ್ಲ.
ಈಗ ನಾವು ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಸ್ವಯಂ-ಹೋಸ್ಟಿಂಗ್‌ನ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಒಳಗೊಂಡಿದ್ದೇವೆ, ಈ ವಿಧಾನದ ಉತ್ತಮ ಅನುಷ್ಠಾನವನ್ನು ಕೆಟ್ಟದರಿಂದ ಹೇಗೆ ಹೇಳುವುದು ಎಂಬುದರ ಕುರಿತು ಮಾತನಾಡೋಣ.
ಕೆಟ್ಟದ್ದು: ದೆವ್ವವು ವಿವರಗಳಲ್ಲಿದೆ
ನಿಮ್ಮ ಸ್ವಂತ ಡೊಮೇನ್‌ಗೆ ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಸರಿಸುವುದನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಮಾಡಲಾಗುವುದಿಲ್ಲ, ಅಂತಹ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಸರಿಯಾಗಿ ಸಂಗ್ರಹಿಸಲಾಗಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುವುದಿಲ್ಲ.
ಇಲ್ಲಿ ಪ್ರಮುಖ ಸಮಸ್ಯೆಗಳೆಂದರೆ ಕ್ಯಾಶಿಂಗ್ ಸಮಯ. ಉದಾಹರಣೆಗೆ, ಆವೃತ್ತಿಯ ಮಾಹಿತಿಯನ್ನು ಈ ರೀತಿಯ ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಸ್ಕ್ರಿಪ್ಟ್ ಹೆಸರುಗಳಲ್ಲಿ ಸೇರಿಸಲಾಗಿದೆ: jquery-3.4.1.js. ಅಂತಹ ಫೈಲ್ ಭವಿಷ್ಯದಲ್ಲಿ ಬದಲಾಗುವುದಿಲ್ಲ, ಮತ್ತು ಪರಿಣಾಮವಾಗಿ ಇದು ಅದರ ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವಲ್ಲಿ ಯಾವುದೇ ಸಮಸ್ಯೆಗಳನ್ನು ಉಂಟುಮಾಡುವುದಿಲ್ಲ.
ಆದರೆ ಫೈಲ್‌ಗಳು, ಕ್ಯಾಶ್ ಮಾಡಿದ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವಾಗ ಕೆಲವು ಆವೃತ್ತಿಯ ಸ್ಕೀಮ್ ಅನ್ನು ಬಳಸದಿದ್ದರೆ, ಫೈಲ್ ಹೆಸರು ಬದಲಾಗದೆ ಇರುವಾಗ ಅದರ ವಿಷಯಗಳು ಬದಲಾಗಬಹುದು, ಹಳೆಯದಾಗಬಹುದು. ಇದು ಗಂಭೀರ ಸಮಸ್ಯೆಯಾಗಿರಬಹುದು, ಉದಾಹರಣೆಗೆ, ಗ್ರಾಹಕರು ಸಾಧ್ಯವಾದಷ್ಟು ಬೇಗ ಸ್ವೀಕರಿಸಲು ಅಗತ್ಯವಿರುವ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳಿಗೆ ಸ್ವಯಂಚಾಲಿತ ಭದ್ರತಾ ಪ್ಯಾಚ್‌ಗಳನ್ನು ಸೇರಿಸಲು ಇದು ಅನುಮತಿಸುವುದಿಲ್ಲ. ಕ್ಯಾಶ್‌ನಲ್ಲಿ ಅಂತಹ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ನವೀಕರಿಸಲು ಡೆವಲಪರ್ ಪ್ರಯತ್ನವನ್ನು ಮಾಡಬೇಕಾಗುತ್ತದೆ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ಸಂಗ್ರಹದಿಂದ ಕ್ಲೈಂಟ್‌ನಲ್ಲಿ ಬಳಸಿದ ಕೋಡ್ ಯೋಜನೆಯ ಸರ್ವರ್ ಭಾಗವನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸಿದ ಕೋಡ್‌ನ ಇತ್ತೀಚಿನ ಆವೃತ್ತಿಯಿಂದ ಭಿನ್ನವಾಗಿದೆ ಎಂಬ ಅಂಶದಿಂದಾಗಿ ಇದು ಅಪ್ಲಿಕೇಶನ್ ವೈಫಲ್ಯಗಳಿಗೆ ಕಾರಣವಾಗಬಹುದು.
ನಿಜ, ನಾವು ಆಗಾಗ್ಗೆ ನವೀಕರಿಸುವ ವಸ್ತುಗಳ ಬಗ್ಗೆ ಮಾತನಾಡಿದರೆ (ಟ್ಯಾಗ್ ಮ್ಯಾನೇಜರ್‌ಗಳು, ಎ/ಬಿ ಪರೀಕ್ಷೆಗೆ ಪರಿಹಾರಗಳು), ನಂತರ ಸಿಡಿಎನ್ ಪರಿಕರಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಅವುಗಳನ್ನು ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವುದು ಪರಿಹರಿಸಬಹುದಾದ ಕಾರ್ಯವಾಗಿದೆ, ಆದರೆ ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾಗಿದೆ. ಕಮಾಂಡರ್ಸ್ ಆಕ್ಟ್, ಟ್ಯಾಗ್ ಮ್ಯಾನೇಜ್‌ಮೆಂಟ್ ಪರಿಹಾರದಂತಹ ಸೇವೆಗಳು ಹೊಸ ಆವೃತ್ತಿಗಳನ್ನು ಪ್ರಕಟಿಸುವಾಗ ವೆಬ್‌ಹೂಕ್‌ಗಳನ್ನು ಬಳಸುತ್ತವೆ. ಇದು ನಿಮಗೆ CDN ನಲ್ಲಿ ಸಂಗ್ರಹ ಫ್ಲಶ್ ಅನ್ನು ಒತ್ತಾಯಿಸುವ ಸಾಮರ್ಥ್ಯವನ್ನು ನೀಡುತ್ತದೆ, ಅಥವಾ ಇನ್ನೂ ಉತ್ತಮವಾಗಿ, ಹ್ಯಾಶ್ ಅಥವಾ URL ನವೀಕರಣವನ್ನು ಒತ್ತಾಯಿಸುವ ಸಾಮರ್ಥ್ಯವನ್ನು ನೀಡುತ್ತದೆ.
▍ಗ್ರಾಹಕರಿಗೆ ವಸ್ತುಗಳ ಹೊಂದಾಣಿಕೆಯ ವಿತರಣೆ
ಹೆಚ್ಚುವರಿಯಾಗಿ, ನಾವು ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವಿಕೆಯ ಬಗ್ಗೆ ಮಾತನಾಡುವಾಗ, CDN ನಲ್ಲಿ ಬಳಸಲಾದ ಕ್ಯಾಶಿಂಗ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳು ಕೆಲವು ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಸಂಪನ್ಮೂಲಗಳಿಗೆ ಸೂಕ್ತವಾಗಿರುವುದಿಲ್ಲ ಎಂಬ ಅಂಶವನ್ನು ನಾವು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳಬೇಕಾಗುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ಅಂತಹ ಸಂಪನ್ಮೂಲಗಳು ಬಳಕೆದಾರರ ಏಜೆಂಟ್ ಸ್ನಿಫಿಂಗ್ (ಅಡಾಪ್ಟಿವ್ ಸರ್ವಿಂಗ್) ತಂತ್ರಜ್ಞಾನವನ್ನು ಆ ಬ್ರೌಸರ್‌ಗಳಿಗೆ ನಿರ್ದಿಷ್ಟವಾಗಿ ಆಪ್ಟಿಮೈಸ್ ಮಾಡಿದ ವಿಷಯದ ಆವೃತ್ತಿಗಳೊಂದಿಗೆ ನಿರ್ದಿಷ್ಟ ಬ್ರೌಸರ್‌ಗಳಿಗೆ ಸೇವೆ ಸಲ್ಲಿಸಬಹುದು. ಈ ತಂತ್ರಜ್ಞಾನಗಳು ಬ್ರೌಸರ್ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡಲು ನಿಯಮಿತ ಅಭಿವ್ಯಕ್ತಿಗಳು ಅಥವಾ HTTP ಹೆಡರ್ ಮಾಹಿತಿಯ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಅವಲಂಬಿಸಿವೆ. User-Agent. ಅವರು ಯಾವ ಬ್ರೌಸರ್‌ನೊಂದಿಗೆ ವ್ಯವಹರಿಸುತ್ತಿದ್ದಾರೆಂದು ತಿಳಿದ ನಂತರ, ಅವರು ಅದಕ್ಕೆ ವಿನ್ಯಾಸಗೊಳಿಸಿದ ವಸ್ತುಗಳನ್ನು ನೀಡುತ್ತಾರೆ.
ಇಲ್ಲಿ ನೀವು ಎರಡು ಸೇವೆಗಳನ್ನು ನೆನಪಿಸಿಕೊಳ್ಳಬಹುದು. ಮೊದಲನೆಯದು googlefonts.com. ಎರಡನೆಯದು polyfill.io. Google ಫಾಂಟ್‌ಗಳ ಸೇವೆಯು ಬ್ರೌಸರ್‌ನ ಸಾಮರ್ಥ್ಯಗಳ ಆಧಾರದ ಮೇಲೆ ನಿರ್ದಿಷ್ಟ ಸಂಪನ್ಮೂಲಕ್ಕಾಗಿ ವಿವಿಧ CSS ಕೋಡ್‌ಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ (ಬಳಸಿಕೊಂಡು woff2 ಸಂಪನ್ಮೂಲಗಳಿಗೆ ಲಿಂಕ್‌ಗಳನ್ನು ನೀಡುತ್ತದೆ unicode-range).
ವಿಭಿನ್ನ ಬ್ರೌಸರ್‌ಗಳಿಂದ ಮಾಡಲಾದ ಒಂದೆರಡು Google ಫಾಂಟ್‌ಗಳ ಪ್ರಶ್ನೆಗಳ ಫಲಿತಾಂಶಗಳು ಇಲ್ಲಿವೆ.
Chrome ನಿಂದ Google ಫಾಂಟ್‌ಗಳ ಪ್ರಶ್ನೆಯ ಫಲಿತಾಂಶ
IE10 ನಿಂದ ಕಾರ್ಯಗತಗೊಳಿಸಿದ Google ಫಾಂಟ್‌ಗಳ ಪ್ರಶ್ನೆಯ ಫಲಿತಾಂಶ
Polyfill.io ಬ್ರೌಸರ್‌ಗೆ ಅಗತ್ಯವಿರುವ ಪಾಲಿಫಿಲ್‌ಗಳನ್ನು ಮಾತ್ರ ನೀಡುತ್ತದೆ. ಕಾರ್ಯಕ್ಷಮತೆಯ ಕಾರಣಗಳಿಗಾಗಿ ಇದನ್ನು ಮಾಡಲಾಗುತ್ತದೆ.
ಉದಾಹರಣೆಗೆ, ನೀವು ವಿವಿಧ ಬ್ರೌಸರ್‌ಗಳಿಂದ ಈ ಕೆಳಗಿನ ವಿನಂತಿಯನ್ನು ಚಲಾಯಿಸಿದರೆ ಏನಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ನೋಡೋಣ:
IE10 ನಿಂದ ಕಾರ್ಯಗತಗೊಳಿಸಿದ ಅಂತಹ ವಿನಂತಿಗೆ ಪ್ರತಿಕ್ರಿಯೆಯಾಗಿ, 34 KB ಡೇಟಾವನ್ನು ಸ್ವೀಕರಿಸಲಾಗುತ್ತದೆ. ಮತ್ತು ಅದಕ್ಕೆ ಉತ್ತರ, Chrome ನಿಂದ ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗುತ್ತದೆ, ಖಾಲಿಯಾಗಿರುತ್ತದೆ.
ಕೋಪ: ಕೆಲವು ಗೌಪ್ಯತೆ ಪರಿಗಣನೆಗಳು
ಈ ಹಂತವು ಕ್ರಮದಲ್ಲಿ ಕೊನೆಯದು, ಆದರೆ ಮುಖ್ಯವಲ್ಲ. ಪ್ರಾಜೆಕ್ಟ್‌ನ ಮುಖ್ಯ ಡೊಮೇನ್‌ನಲ್ಲಿ ಅಥವಾ ಅದರ ಉಪಡೊಮೇನ್‌ನಲ್ಲಿ ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಸಂಪನ್ಮೂಲಗಳ ಸ್ವಯಂ-ಹೋಸ್ಟಿಂಗ್ ಬಳಕೆದಾರರ ಗೌಪ್ಯತೆಗೆ ಅಪಾಯವನ್ನುಂಟುಮಾಡುತ್ತದೆ ಮತ್ತು ಮುಖ್ಯ ವೆಬ್ ಪ್ರಾಜೆಕ್ಟ್ ಅನ್ನು ಋಣಾತ್ಮಕವಾಗಿ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ ಎಂಬುದು ಪಾಯಿಂಟ್.
ನಿಮ್ಮ CDN ಸಿಸ್ಟಮ್ ಅನ್ನು ಸರಿಯಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡದಿದ್ದರೆ, ನಿಮ್ಮ ಡೊಮೇನ್‌ನ ಕುಕೀಗಳನ್ನು ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಸೇವೆಗೆ ಕಳುಹಿಸುವುದನ್ನು ನೀವು ಕೊನೆಗೊಳಿಸಬಹುದು. CDN ಮಟ್ಟದಲ್ಲಿ ಸರಿಯಾದ ಫಿಲ್ಟರಿಂಗ್ ಅನ್ನು ಆಯೋಜಿಸದಿದ್ದರೆ, ನಿಮ್ಮ ಸೆಷನ್ ಕುಕೀಗಳನ್ನು ಸಾಮಾನ್ಯವಾಗಿ JavaScript ನಲ್ಲಿ ಬಳಸಲಾಗುವುದಿಲ್ಲ (ಇದರೊಂದಿಗೆ httponly), ವಿದೇಶಿ ಹೋಸ್ಟ್‌ಗೆ ಕಳುಹಿಸಬಹುದು.
ಯೂಲೇರಿಯನ್ ಅಥವಾ ಕ್ರಿಟಿಯೊದಂತಹ ಟ್ರ್ಯಾಕರ್‌ಗಳೊಂದಿಗೆ ಇದು ನಿಖರವಾಗಿ ಏನಾಗಬಹುದು. ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಟ್ರ್ಯಾಕರ್ಗಳು ಕುಕೀಯಲ್ಲಿ ಅನನ್ಯ ಗುರುತಿಸುವಿಕೆಯನ್ನು ಹೊಂದಿಸಿರಬಹುದು. ಅವರು ಸೈಟ್ ವಸ್ತುಗಳ ಭಾಗವಾಗಿದ್ದರೆ, ಬಳಕೆದಾರರು ವಿಭಿನ್ನ ವೆಬ್ ಸಂಪನ್ಮೂಲಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವಾಗ ಅವರು ತಮ್ಮ ವಿವೇಚನೆಯಿಂದ ಗುರುತಿಸುವಿಕೆಯನ್ನು ಓದಬಹುದು.
ಈ ದಿನಗಳಲ್ಲಿ, ಹೆಚ್ಚಿನ ಬ್ರೌಸರ್‌ಗಳು ಈ ರೀತಿಯ ಟ್ರ್ಯಾಕರ್ ನಡವಳಿಕೆಯ ವಿರುದ್ಧ ರಕ್ಷಣೆಯನ್ನು ಒಳಗೊಂಡಿವೆ. ಪರಿಣಾಮವಾಗಿ, ಟ್ರ್ಯಾಕರ್ಗಳು ಈಗ ತಂತ್ರಜ್ಞಾನವನ್ನು ಬಳಸುತ್ತಾರೆ , ವಿವಿಧ ಪ್ರಾಜೆಕ್ಟ್‌ಗಳಿಗೆ ತಮ್ಮದೇ ಆದ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳಂತೆ ಮರೆಮಾಚುವುದು. ಅವುಗಳೆಂದರೆ, ಟ್ರ್ಯಾಕರ್ಗಳು ನಿರ್ದಿಷ್ಟ ಡೊಮೇನ್‌ಗಾಗಿ ತಮ್ಮ ಸೆಟ್ಟಿಂಗ್‌ಗಳಿಗೆ CNAME ಅನ್ನು ಸೇರಿಸಲು ಸೈಟ್ ಮಾಲೀಕರಿಗೆ ನೀಡುತ್ತವೆ, ಅದರ ವಿಳಾಸವು ಸಾಮಾನ್ಯವಾಗಿ ಅಕ್ಷರಗಳ ಯಾದೃಚ್ಛಿಕ ಗುಂಪಿನಂತೆ ಕಾಣುತ್ತದೆ.
ಎಲ್ಲಾ ಉಪಡೊಮೇನ್‌ಗಳಿಗೆ ವೆಬ್‌ಸೈಟ್ ಕುಕೀಗಳನ್ನು ಲಭ್ಯವಾಗುವಂತೆ ಮಾಡಲು ಶಿಫಾರಸು ಮಾಡದಿದ್ದರೂ (ಉದಾಹರಣೆಗೆ - *.website.com), ಅನೇಕ ಸೈಟ್‌ಗಳು ಇದನ್ನು ಮಾಡುತ್ತವೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಅಂತಹ ಕುಕೀಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಮಾರುವೇಷದ ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಟ್ರ್ಯಾಕರ್‌ಗೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ. ಪರಿಣಾಮವಾಗಿ, ನಾವು ಇನ್ನು ಮುಂದೆ ಯಾವುದೇ ಗೌಪ್ಯತೆಯ ಬಗ್ಗೆ ಮಾತನಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ.
ಅಲ್ಲದೆ, HTTP ಹೆಡರ್‌ಗಳೊಂದಿಗೆ ಅದೇ ವಿಷಯ ಸಂಭವಿಸುತ್ತದೆ , ಇವುಗಳನ್ನು ಮುಖ್ಯ ಡೊಮೇನ್‌ಗೆ ಮಾತ್ರ ಕಳುಹಿಸಲಾಗುತ್ತದೆ, ಏಕೆಂದರೆ ಅವುಗಳನ್ನು ರಚಿಸಲು ಬಳಸಬಹುದು ಬಳಕೆದಾರ. ನೀವು ಬಳಸುವ CDN ಸೇವೆಯು ಈ ಹೆಡರ್‌ಗಳನ್ನು ಸರಿಯಾಗಿ ಫಿಲ್ಟರ್ ಮಾಡುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ.
ಫಲಿತಾಂಶಗಳು
ನೀವು ಶೀಘ್ರದಲ್ಲೇ ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಸಂಪನ್ಮೂಲಗಳ ಸ್ವಯಂ-ಹೋಸ್ಟಿಂಗ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಯೋಜಿಸುತ್ತಿದ್ದರೆ, ನಾನು ನಿಮಗೆ ಕೆಲವು ಸಲಹೆಗಳನ್ನು ನೀಡುತ್ತೇನೆ:
- ನಿಮ್ಮ ಪ್ರಮುಖ JS ಲೈಬ್ರರಿಗಳು, ಫಾಂಟ್‌ಗಳು ಮತ್ತು CSS ಫೈಲ್‌ಗಳನ್ನು ಹೋಸ್ಟ್ ಮಾಡಿ. ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಸೇವೆಯ ದೋಷದಿಂದಾಗಿ ಸೈಟ್‌ಗೆ ಪ್ರಮುಖವಾದ ಸಂಪನ್ಮೂಲ ಲಭ್ಯವಿಲ್ಲದ ಕಾರಣ ಇದು ಸೈಟ್ ವೈಫಲ್ಯ ಅಥವಾ ಕಾರ್ಯಕ್ಷಮತೆಯ ಕುಸಿತದ ಅಪಾಯವನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.
- ನೀವು CDN ನಲ್ಲಿ ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಸಂಗ್ರಹಿಸುವ ಮೊದಲು, ಅವುಗಳ ಫೈಲ್‌ಗಳನ್ನು ಹೆಸರಿಸುವಾಗ ಕೆಲವು ರೀತಿಯ ಆವೃತ್ತಿಯ ವ್ಯವಸ್ಥೆಯನ್ನು ಬಳಸಲಾಗಿದೆಯೇ ಅಥವಾ ಹೊಸ ಆವೃತ್ತಿಯನ್ನು ಪ್ರಕಟಿಸುವಾಗ CDN ಸಂಗ್ರಹವನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ಅಥವಾ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಮರುಹೊಂದಿಸುವ ಮೂಲಕ ನೀವು ಈ ಸಂಪನ್ಮೂಲಗಳ ಜೀವನಚಕ್ರವನ್ನು ನಿರ್ವಹಿಸಬಹುದು ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ. ಬರಹ.
- ನಿಮ್ಮ CDN, ಪ್ರಾಕ್ಸಿ ಸರ್ವರ್ ಮತ್ತು ಕ್ಯಾಷ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳ ಬಗ್ಗೆ ಬಹಳ ಜಾಗರೂಕರಾಗಿರಿ. ನಿಮ್ಮ ಪ್ರಾಜೆಕ್ಟ್ ಅಥವಾ ಹೆಡರ್‌ಗಳನ್ನು ಕುಕೀಗಳನ್ನು ಕಳುಹಿಸುವುದನ್ನು ತಡೆಯಲು ಇದು ನಿಮ್ಮನ್ನು ಅನುಮತಿಸುತ್ತದೆ
Client-Hintsಮೂರನೇ ವ್ಯಕ್ತಿಯ ಸೇವೆಗಳು.
ಆತ್ಮೀಯ ಓದುಗರು! ನಿಮ್ಮ ಯೋಜನೆಗಳ ಕಾರ್ಯಾಚರಣೆಗೆ ಅತ್ಯಂತ ಮುಖ್ಯವಾದ ನಿಮ್ಮ ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಇತರ ಜನರ ವಸ್ತುಗಳನ್ನು ನೀವು ಹೋಸ್ಟ್ ಮಾಡುತ್ತೀರಾ?
ಮೂಲ: www.habr.com