ಚಿತ್ರಗಳ ಆಪ್ಟಿಮೈಸೇಶನ್ WordPress ಕಾರ್ಯಕ್ಷಮತೆಯಲ್ಲಿ ಅತ್ಯಂತ “ಹೆಚ್ಚು ಲಾಭದಾಯಕ” ಕೆಲಸಗಳಲ್ಲಿ ಒಂದು: ಅದೇ ಪುಟ ರಚನೆ, ಅದೇ ಥೀಮ್ ಇದ್ದರೂ, ಚಿತ್ರಗಳ ಗಾತ್ರ, ಆಯಾಮ, ಫಾರ್ಮ್ಯಾಟ್ ಮತ್ತು ವಿತರಣೆ ವಿಧಾನ ಸರಿಯಾಗಿದ್ದರೆ, ಲೋಡ್ ಅನುಭವವು ಬಹಳಷ್ಟು ಬಾರಿ ತಕ್ಷಣವೇ ಸುಧಾರಿಸುತ್ತದೆ.
ಆದರೆ ಚಿತ್ರ ಆಪ್ಟಿಮೈಸೇಶನ್ವೇ ಜನರನ್ನು ಅತ್ಯಂತ ಸುಲಭವಾಗಿ “ಎಷ್ಟೇ ಮಾಡಿದಷ್ಟು ಹೆಚ್ಚು ಗೊಂದಲಕ್ಕೆ” ಸಿಲುಕಿಸುತ್ತದೆ; ಕಾರಣ ತಂತ್ರಜ್ಞಾನ ತುಂಬ ಕಷ್ಟವಾದ್ದರಿಂದ ಅಲ್ಲ, ಮಾಹಿತಿಯೇ ತುಂಬ ಚದುರಿರುವುದರಿಂದ:
ನೀವು ಕೆಲವು ಲೇಖನಗಳನ್ನು ಓದಿ, “ಸಂಕುಚಿತಗೊಳಿಸುವುದು”, “WebP/AVIF”, “ಲೇಝಿ ಲೋಡಿಂಗ್” ಇವುಗಳ ಬಗ್ಗೆ ತಿಳಿದುಕೊಂಡಿದ್ದೀರಿ. ನಂತರ ಪ್ಲಗಿನ್ ಪರಿಚಯದಲ್ಲಿ ಮತ್ತೆ “ತಿಂಗಳಿಗೆ ಉಚಿತ 100 ಕ್ರೆಡಿಟ್ಗಳು”, “ಉಚಿತ 20MB”, “ಪ್ರತಿ ಚಿತ್ರಕ್ಕೆ 1 ಕ್ರೆಡಿಟ್” ಎಂದು ಹೇಳಿರುವುದನ್ನು ನೋಡಿ, ನೋಡಿದಷ್ಟು ಹೆಚ್ಚು ಗೊಂದಲವಾಗುತ್ತಿದೆ — ಹಾಗಾದರೆ ಉಚಿತ ಪ್ರಮಾಣ ಸಾಕಾಗುತ್ತದೆಯೇ? ಶುಲ್ಕವನ್ನು ಹೇಗೆ ಕಡಿತ ಮಾಡುತ್ತಾರೆ? “ಅದೇ ಒಂದೇ ವಸ್ತು” ಬಗ್ಗೆ ನೀವು ತಪ್ಪಾಗಿ ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೀರಾ? ಮತ್ತು ಅತ್ಯಂತ ಮುಖ್ಯವಾದುದು:ನೀನು ಮಾಡಿ ಮುಗಿಸಿದ ನಂತರ ನಿಜವಾಗಿಯೂ ಪರಿಣಾಮ ಬೀರಿತೇ?
ಈ ಲೇಖನವು ಕೇವಲ ಮೂರು ಕೆಲಸಗಳನ್ನು ಮಾತ್ರ ಮಾಡುತ್ತದೆ:
- ನಿಮಗೆ ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದಾದ ಒಂದು ಸಾಲುಮಾರ್ಗಸೂಚಿ(ಮೊದಲು ಏನು ಮಾಡಬೇಕು, ನಂತರ ಏನು ಮಾಡಬೇಕು)
- ನೀವು ಆಯ್ಕೆ ಮಾಡಬೇಕಾದ ಯೋಜನೆಯನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ವಿವರಿಸಿ (ಉಚಿತ/ಪಾವತಿದಲ್ಲಿ ನಿಖರವಾಗಿ ಏನು ವ್ಯತ್ಯಾಸ ಇದೆ, ಯಾವುದು ಯಾರಿಗೆ ಸೂಕ್ತ)
- ಸಾಮಾನ್ಯ ಸಮಸ್ಯೆಗಳನ್ನು ಮುಂಚಿತವಾಗಿ ಬರೆಯಿರಿ (ನೀವು ಮುಗಿಸಿದ ನಂತರ ಎಲ್ಲೆಡೆ ಹುಡುಕಿ ಪರಿಶೀಲಿಸಬೇಕಾಗದಂತೆ)
1. ಮೂಲ ಪದರ: WordPress ನಲ್ಲಿ ಏನು ಒಳಗೊಂಡಿದೆ, ಏನು ಒಳಗೊಂಡಿಲ್ಲ
ನೀವು ಮೊದಲು WordPress ಕೋರ್ ಈಗಾಗಲೇ ಏನು ಮಾಡಿದೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳದಿದ್ದರೆ, ಸುಲಭವಾಗಿ ಎರಡು ಪರಿಸ್ಥಿತಿಗಳು ಉಂಟಾಗಬಹುದು:
- ಬಳಸದ ಉಚಿತ ಸಾಮರ್ಥ್ಯದಿಂದ ಲಾಭವಾಗಲಿಲ್ಲ, ಬದಲಾಗಿ ಸಮಯ/ಹಣ ಖರ್ಚು ಮಾಡಿ ಅದೇ ಕೆಲಸವನ್ನು ಮತ್ತೆ ಮಾಡಿದರು
- WordPress ಹಳೆಯ ಚಿತ್ರಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ WebP/AVIF ಗೆ ಪರಿವರ್ತಿಸುತ್ತದೆ ಎಂದು ಭಾವಿಸಿದ್ದೆ, ಆದರೆ ಹಾಗಲ್ಲ ಎಂದು ತಿಳಿಯಿತು
WordPress ಕೋರ್ ಈಗಾಗಲೇ ಈ ಪ್ರಮುಖ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಒಳಗೊಂಡಿದೆ:
- ಪ್ರತಿಕ್ರಿಯಾಶೀಲ ಚಿತ್ರಗಳು(srcset/sizes):WordPress 4.4 ರಿಂದ, ಚಿತ್ರಗಳಿಗಾಗಿ ಮೂಲ ವ್ಯವಸ್ಥೆ ಔಟ್ಪುಟ್ ಮಾಡುತ್ತದೆ
srcsetಮತ್ತುsizes, ಮತ್ತು ಅಪ್ಲೋಡ್ ಮಾಡುವಾಗ ರಚಿಸಲಾದ ವಿವಿಧ ಗಾತ್ರದ ಚಿತ್ರಗಳನ್ನು ಬಳಸಿ, ಬ್ರೌಸರ್ವು ಪರದೆ ಪರಿಸ್ಥಿತಿಗೆ ಅನುಗುಣವಾಗಿ ಹೆಚ್ಚು ಸೂಕ್ತವಾದ ಸಂಪನ್ಮೂಲವನ್ನು ಲೋಡ್ ಮಾಡಲು ಆಯ್ಕೆಮಾಡುತ್ತದೆ. - ಸ್ಥಳೀಯ ಆಲಸ್ಯ ಲೋಡಿಂಗ್: WordPress 5.5 ರಿಂದ ಚಿತ್ರಗಳಿಗೆ ಡೀಫಾಲ್ಟ್ ಆಗಿ ನೆಟಿವ್ ಲೇಜಿ ಲೋಡಿಂಗ್ ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಲಾಗಿದೆ, HTML ಮಾನದಂಡವನ್ನು ಬಳಸುತ್ತದೆ
loadingಗುಣಲಕ್ಷಣದ ಅನುಷ್ಠಾನ. - WebP ಅಪ್ಲೋಡ್ಗೆ ಬೆಂಬಲ ಇದೆWordPress 5.8 ರಿಂದ JPEG/PNG ಹಾಗೆಯೇ WebP ಅನ್ನು ಅಪ್ಲೋಡ್ ಮಾಡಿ ಬಳಸಬಹುದು (ಹೋಸ್ಟಿಂಗ್ ಪರಿಸರವು WebP ಅನ್ನು ಬೆಂಬಲಿಸಿದರೆ)
- AVIF ಅಪ್ಲೋಡ್ಗೆ ಬೆಂಬಲ ಇದೆWordPress 6.5 ರಿಂದ JPEG/PNG ಹಾಗೆ AVIF ಅನ್ನು ಅಪ್ಲೋಡ್ ಮಾಡಿ ಬಳಸಬಹುದು (ಇದೂ ಹೋಸ್ಟಿಂಗ್ ಪರಿಸರದ ಬೆಂಬಲಕ್ಕೆ ಅವಲಂಬಿತವಾಗಿದೆ).
ಆದರೆ ಗಮನಿಸಿ:
“ಅಪ್ಲೋಡ್/ಬಳಕೆಗೆ ಬೆಂಬಲ ≠ ಸ್ವಯಂ ಪರಿವರ್ತನೆ/ಸ್ವಯಂ ವಿತರಣೆ
ಅಂದರೆ: ನೀವು ಈಗಾಗಲೇ WP 6.5 ಬಳಸುತ್ತಿದ್ದರೂ, ನಿಮ್ಮ ಮೀಡಿಯಾ ಲೈಬ್ರರಿಯಲ್ಲಿರುವ ಆ JPG/PNG ಫೈಲ್ಗಳು ಸ್ವಯಂಚಾಲಿತವಾಗಿ WebP/AVIF ಆಗಿ മാറುವುದಿಲ್ಲ; ಹಾಗೆಯೇ “ಬ್ರೌಸರ್ ಸಾಮರ್ಥ್ಯಕ್ಕೆ ಅನುಗುಣವಾಗಿ AVIF/WebP ಅನ್ನು ಔಟ್ಪುಟ್ ಮಾಡುವುದು ಮತ್ತು ಅದನ್ನು ಬೆಂಬಲಿಸದ ಬ್ರೌಸರ್ಗಳಿಗೆ ಮೂಲ ಚಿತ್ರಕ್ಕೆ ಹಿಂದಿರುಗುವುದು” ಎಂಬ ಸಂಪೂರ್ಣ ಪ್ರಕ್ರಿಯೆಯೂ ನಿಮಗೆ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಸಿಗುವುದಿಲ್ಲ — ಈ ಭಾಗವನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಪ್ಲಗಿನ್ ಅಥವಾ ಸೇವೆಯ ಮೂಲಕ ಪೂರ್ಣಗೊಳಿಸಬೇಕು.
2. ಮಾರ್ಗನಕ್ಷೆ: ಚಿತ್ರ ಆಪ್ಟಿಮೈಸೇಶನ್ 5 ಹಂತಗಳಲ್ಲಿ ಸಾಗುತ್ತದೆ
ಏನು ಮಾಡಬೇಕು, ಏಕೆ ಮಾಡಬೇಕು, ಯಾವ ಮಟ್ಟಿಗೆ ಮಾಡಿದರೆ ಅರ್ಹ ಎಂದು ಪರಿಗಣಿಸಬಹುದು, ಸಾಮಾನ್ಯ ತಪ್ಪುಗಳು ಯಾವುವು.
2.1 ಮೊದಲು “ಗಾತ್ರ”ವನ್ನು ಸರಿಯಾಗಿ ಮಾಡಿ (ಇದು ಅತ್ಯಂತ ಸುಲಭವಾಗಿ ಗಮನ ತಪ್ಪುವ ಭಾಗ, ಆದರೆ ಲಾಭ ಅತಿ ಹೆಚ್ಚು)
ಅನೇಕ ಸೈಟ್ಗಳು ನಿಧಾನವಾಗಿರುವುದು ಕಂಪ್ರೆಶನ್ ಮಾಡದ ಕಾರಣದಿಂದಲ್ಲ, ಬದಲಾಗಿಪ್ರದರ್ಶನ ಪ್ರದೇಶಕ್ಕಿಂತ ಬಹಳ ದೊಡ್ಡ ಚಿತ್ರವನ್ನು ಡೌನ್ಲೋಡ್ ಮಾಡಲಾಗಿದೆ:
ಉದಾಹರಣೆಗೆ, ಪುಟವು ವಾಸ್ತವವಾಗಿ ಕೇವಲ 900px ಅಗಲದಲ್ಲೇ ತೋರಿಸುತ್ತಿದ್ದರೂ, ನೀವು ಭೇಟಿ ದಾರರಿಗೆ 3000px ಮೂಲ ಚಿತ್ರವನ್ನು ಡೌನ್ಲೋಡ್ ಮಾಡಲು ಬಿಡುತ್ತೀರಿ; ಬ್ರೌಸರ್ ಕೇವಲ “ಮೊದಲು ಡೌನ್ಲೋಡ್ ಮಾಡಿ ನಂತರ ಚಿಕ್ಕದಾಗಿ ತೋರಿಸುತ್ತದೆ”. ಇದು ಬ್ಯಾಂಡ್ವಿಡ್ತ್ ವ್ಯರ್ಥ ಮಾಡುತ್ತದೆ, ಡಿಕೋಡಿಂಗ್ ಸಮಯವನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ, ಮತ್ತು ಮೊದಲ ಪರದೆ ಲೋಡ್ ಅನ್ನು ನಿಧಾನಗೊಳಿಸುತ್ತದೆ.
WordPress 4.4+ ನದುಪ್ರತಿಕ್ರಿಯಾಶೀಲ ಚಿತ್ರ ವ್ಯವಸ್ಥೆ(srcset/sizes)ಇದೇ ಈ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು.
ಏನು ಮಾಡಿದರೆ ಅರ್ಹತೆ ಹೊಂದುತ್ತದೆ:
- ಮೊಬೈಲ್ನಲ್ಲಿ ಪುಟ ತೆರೆಯುವಾಗ ಡೌನ್ಲೋಡ್ ಆಗುವ ಚಿತ್ರದ ಗಾತ್ರವು ಡೆಸ್ಕ್ಟಾಪ್ನಿಗಿಂತ ಗಮನಾರ್ಹವಾಗಿ ಚಿಕ್ಕದಾಗಿರಬೇಕು
- ಒಂದೇ ಚಿತ್ರಕ್ಕೆ ವಿವಿಧ ಸಾಧನಗಳಲ್ಲಿ ವಿಭಿನ್ನ ಗಾತ್ರದ ಸಂಪನ್ಮೂಲಗಳು ಲೋಡ್ ಆಗುತ್ತವೆ (ಯಾವಾಗಲೂ ಮೂಲ ಚಿತ್ರವನ್ನು ಡೌನ್ಲೋಡ್ ಮಾಡುವುದಿಲ್ಲ)
ಅತ್ಯಂತ ಸಾಮಾನ್ಯವಾದ ತಪ್ಪುಗಳು:
- ಕೆಲವು ಥೀಮ್ಗಳು/ಬಿಲ್ಡರ್ಗಳು ಚಿತ್ರಗಳನ್ನು CSS ಹಿನ್ನೆಲೆಚಿತ್ರವಾಗಿ ಬಳಸುತ್ತವೆ ಅಥವಾ ಕಸ್ಟಮ್ ರೀತಿಯಲ್ಲಿ ಔಟ್ಪುಟ್ ಮಾಡುತ್ತವೆ, ಇದರಿಂದ ಅದು ತಪ್ಪಿಸಿಕೊಳ್ಳಬಹುದು
srcsetಇದರಿಂದ ದೊಡ್ಡ ಚಿತ್ರಗಳು ನಿರಂತರವಾಗಿ ಲೋಡ್ ಆಗುತ್ತವೆ - ನೀವು ಹೊರಗಿನ ಚಿತ್ರ ಹೋಸ್ಟಿಂಗ್ ಅಥವಾ ತೃತೀಯಪಕ್ಷದ ಚಿತ್ರ ಬ್ಲಾಕ್ ಬಳಸಿದರೆ, ಮಾಧ್ಯಮ ಗ್ರಂಥಾಲಯದ ಬಹು ಗಾತ್ರ ವ್ಯವಸ್ಥೆಯನ್ನು ತಪ್ಪಿಸಬಹುದು
2.2 ಸಂಕುಚಿಸಿ (KB ಅನ್ನು ಕಡಿಮೆ ಮಾಡಿ, ಆದರೆ ಗುಣಮಟ್ಟವನ್ನು “ಹಾಳು” ಮಾಡಬೇಡಿ)
ಸಂಕುಚನದ ಮೂಲ ಅರ್ಥ “ಎಷ್ಟು ಚಿಕ್ಕದಾದರೂ ಉತ್ತಮ” ಎಂಬುದಲ್ಲ, ಬದಲಾಗಿ “ಕಣ್ಣಿಗೆ ಬಹುತೇಕ ವ್ಯತ್ಯಾಸ ಕಾಣಿಸದಿದ್ದರೂ, ಗಾತ್ರವು ಸ್ಪಷ್ಟವಾಗಿ ಕಡಿಮೆಯಾಗುವುದು” ಎಂಬುದಾಗಿದೆ.
ನಿಯಮಗಳು ಹೀಗಿವೆ:
- ಫೋಟೋ/ನೈಜ ಚಿತ್ರಗಳು(ವ್ಯಕ್ತಿಗಳು, ಉತ್ಪನ್ನಗಳು, ದೃಶ್ಯಗಳು): ಆದ್ಯತೆಯಿಂದ ನಷ್ಟಕಾರಿ ಸಂಕೋಚನ (ಹೆಚ್ಚಿನ ಲಾಭ)
- ಇಂಟರ್ಫೇಸ್ ಸ್ಕ್ರೀನ್ಶಾಟ್/ಹೆಚ್ಚು ಪಠ್ಯವಿರುವ ಚಿತ್ರ:ಸಂಕೋಚನವನ್ನು ಇನ್ನಷ್ಟು ಸಂಯಮಿತವಾಗಿ ಮಾಡಿ, ಪಠ್ಯವು ಮಸುಕಾಗುವುದನ್ನು ತಪ್ಪಿಸಿ
- ಲೋಗೋ/ಐಕಾನ್:SVG ಗೆ ಆದ್ಯತೆ ನೀಡಿ ಅಥವಾ ಲಾಸ್ಲೆಸ್ ಅನ್ನು ಎಚ್ಚರಿಕೆಯಿಂದ ಬಳಸಿ (ಲಾಸ್ಸಿ ಮಾಡಿದರೆ ಅಂಚುಗಳು ಸುಲಭವಾಗಿ ಮಸುಕಾಗುತ್ತವೆ)
ಏನು ಮಾಡಿದರೆ ಅರ್ಹತೆ ಹೊಂದುತ್ತದೆ:
- ಹೆಚ್ಚಿನ ಪುಟಗಳ ಚಿತ್ರಗಳ ಗಾತ್ರ ಸ್ಪಷ್ಟವಾಗಿ ಕಡಿಮೆಯಾಗಿದೆ
- ಸ್ಪಷ್ಟ ಶಬ್ದದ ಕಲೆಗಳು, ಅಂಚಿನ ಮಸುಕು, ಬಣ್ಣದ ಪಟ್ಟೆಗಳ ತುಂಡಾಗುವಿಕೆ, ಪಠ್ಯ ಮಸುಕು ಕಾಣಿಸಬಾರದು
2.3 WebP / AVIF(ಸ್ವರೂಪ ನೀತಿ: ಅದೇ ಸ್ಪಷ್ಟತೆಯಲ್ಲಿ ಕಡಿಮೆ ಗಾತ್ರ)
WordPress ಈಗ ಅಪ್ಲೋಡ್ಗೆ ಬೆಂಬಲಿಸುತ್ತದೆ WebP(5.8) ಮತ್ತು AVIF(6.5)。
ಆದರೆ “ಮುಂದಿನ ತಲೆಮಾರಿನ ಸ್ವರೂಪ” ಅನ್ನು ನಿಜವಾಗಿ ಬಳಸಲು, ಸಾಮಾನ್ಯವಾಗಿ ಎರಡು ವಿಷಯಗಳನ್ನು ಪರಿಹರಿಸಬೇಕು:
- ಇತಿಹಾಸ ಮಾಧ್ಯಮ ಗ್ರಂಥಾಲಯವನ್ನು ಗುಂಪಾಗಿ ಹೇಗೆ ಪರಿವರ್ತಿಸಬೇಕು(ಇಲ್ಲದಿದ್ದರೆ ನೀವು ಕೇವಲ “ಮುಂದೆ ಅಪ್ಲೋಡ್ ಮಾಡುವ ಹೊಸ ಚಿತ್ರಗಳನ್ನು” ಮಾತ್ರ ಆಪ್ಟಿಮೈಸ್ ಮಾಡಿದ್ದೀರಿ)
- ನಕಲು ರಚಿಸಬೇಕೇ, ಅಥವಾ ಮೂಲ ಚಿತ್ರವನ್ನು ಬದಲಾಯಿಸಬೇಕೇ(ಇದು ಅಪಾಯದ ಗಡಿ ರೇಖೆ; ಮುಂದಾಗಿ Plus WebP ಯ “ಬದಲಿಸಿ ಮತ್ತು ಮೂಲ ಚಿತ್ರವನ್ನು ಅಳಿಸಿ” ಬಗ್ಗೆ ಮುಖ್ಯವಾಗಿ ಹೇಳಲಾಗುತ್ತದೆ)
ಶಿಫಾರಸು ಮಾಡಿದ ಬರವಣಿಗೆ:
- WebP: ಸಾಮಾನ್ಯವಾಗಿ ಪೂರ್ವನಿಯೋಜಿತ ಮೊದಲ ಆಯ್ಕೆಯಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ (ಹೊಂದಾಣಿಕೆ ಹೆಚ್ಚು ಸ್ಥಿರವಾಗಿದೆ)
- AVIF:ಇನ್ನಷ್ಟು ಉನ್ನತ ಸಂಕುಚನ ದಿಕ್ಕು, ದೊಡ್ಡ ಚಿತ್ರಗಳು/ಮೊದಲ ಪರದೆಯ ದೊಡ್ಡ ಚಿತ್ರಗಳು/ಆಲ್ಬಮ್ ಚಿತ್ರಗಳಿಗೆ ಸೂಕ್ತ (ಆದರೆ ಇನ್ನಷ್ಟುಪರಿಸರ ಬೆಂಬಲದ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿದೆ)
2.4 ಆಲಸ್ಯ ಲೋಡಿಂಗ್ ಅನ್ನು ಸರಿಯಾಗಿ ಬಳಸಿ (ಎಲ್ಲಕ್ಕೂ ಒಂದೇ ರೀತಿಯಾಗಿ ಅನ್ವಯಿಸಬೇಡಿ)
WordPress 5.5 ರಿಂದಡೀಫಾಲ್ಟ್ ಲೇಜಿ ಲೋಡ್ಚಿತ್ರ။
ಇದು ಪ್ರಾರಂಭಿಕ ರೆಂಡರಿಂಗ್ ಸಮಯದಲ್ಲಿನ ಬ್ಯಾಂಡ್ವಿಡ್ತ್ ಬಳಕೆಯನ್ನು ಕಡಿಮೆ ಮಾಡಬಹುದು:
- ಮಂದ ಲೋಡ್ ಮಾಡುವುದು “ತೆರೆಯ ಹೊರಗಿನ ಸಂಪನ್ಮೂಲಗಳಿಗೆ” ಸೂಕ್ತವಾಗಿದೆ”
- ಮೊದಲ ಪರದೆಯಲ್ಲಿನ ಅತ್ಯಂತ ಪ್ರಮುಖ ದೊಡ್ಡ ಚಿತ್ರವನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ತಡವಾಗಿ ಲೋಡ್ ಮಾಡಲು ಸೂಕ್ತವಾಗಿರುವುದಿಲ್ಲ
2.5 ವಿತರಣಾ ಮಟ್ಟ: CDN / ಚಿತ್ರ CDN
ಸಂಕುಚನ, ಗಾತ್ರ, ಸ್ವರೂಪ ಇವು ಪರಿಹರಿಸುವುದು “ಕಡತವನ್ನು ಇನ್ನಷ್ಟು ಚಿಕ್ಕದಾಗಿ, ಇನ್ನಷ್ಟು ಸೂಕ್ತವಾಗಿ” ಎಂಬುದಾಗಿದೆ.
ಆದರೆ ಚಿತ್ರಗಳನ್ನು ಯಾವಾಗಲೂ ಮೂಲ ಸೈಟ್ನಿಂದ ದೂರದಿಂದ ಪಡೆಯಬೇಕಾದರೆ, ಜಾಲ ವಿಳಂಬವು ಅನುಭವವನ್ನು ಇನ್ನೂ ಸ್ಪಷ್ಟವಾಗಿ ಪ್ರಭಾವಿಸುತ್ತದೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ “ವಿತರಣಾ ಪದರ” ಪರಿಹಾರ ಬೇಕಾಗುತ್ತದೆ (CDN/ಚಿತ್ರ CDN).
ಎರಡು ಸಾಮಾನ್ಯ ದಿಕ್ಕುಗಳು:
- ಕ್ಲೌಡ್ಫ್ಲೇರ್ ಪೋಲಿಶ್:Cloudflare ದಸ್ತಾವೇಜುಗಳುPolish ನ ಸಂಕುಚಿತ ವಿಧಾನಗಳನ್ನು (ನಷ್ಟರಹಿತ/ನಷ್ಟಯುತ/WebP) ಪರಿಚಯಿಸಿ, ಜೊತೆಗೆ ಬಳಸುವುದನ್ನು ಉಲ್ಲೇಖಿಸಿದೆ
format=autoWebP/AVIF ಸ್ವರೂಪವನ್ನು ಬಳಸಲು ಅನುಮತಿ ಇದೆ. - ಜೆಟ್ಪ್ಯಾಕ್ ಸೈಟ್ ವೇಗವರ್ಧಕ:Jetpack ದಾಖಲಾತಿಇದು ಚಿತ್ರಗಳನ್ನು ಆಪ್ಟಿಮೈಸ್ ಮಾಡಿ, ಅದರ ಜಾಲದ ಮೂಲಕ ಸ್ಥಿರ ಸಂಪನ್ಮೂಲಗಳೊಂದಿಗೆ ವಿತರಿಸಲಾಗುತ್ತದೆ ಎಂದು ಸೂಚಿಸುತ್ತದೆ.
ಚಿತ್ರ ಸುಧಾರಣೆ ಗಾತ್ರವನ್ನು ಚಿಕ್ಕದಾಗಿಸಿ ಹೊಂದುವಂತೆ ಮಾಡುತ್ತದೆCDN ಹೆಚ್ಚು ಸಮೀಪ ಮತ್ತು ಹೆಚ್ಚು ಸ್ಥಿರ ವಿತರಣೆಗೆ ಹೊಣೆಗಾರಿದೆ
3. ಆಯ್ಕೆ: ಕೇವಲ ಎರಡು ಮುಖ್ಯ ಮಾರ್ಗಗಳನ್ನು ಮಾತ್ರ ಅನುಸರಿಸಿ
ಚಿತ್ರ ಆಪ್ಟಿಮೈಸೇಶನ್ನಲ್ಲಿ ಅತ್ಯಂತ ಸಾಮಾನ್ಯವಾದ ವೈಫಲ್ಯವು “ಪ್ಲಗಿನ್ ಇನ್ಸ್ಟಾಲ್ ಮಾಡಿಲ್ಲ” ಎಂಬುದಲ್ಲ, ಬದಲಾಗಿ ತುಂಬಾ ಹೆಚ್ಚು ಪ್ಲಗಿನ್ಗಳನ್ನು ಇನ್ಸ್ಟಾಲ್ ಮಾಡಿ ಮರುಮರು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವುದಾಗಿದೆ:
A ಸಂಕುಚನ ಮಾಡುತ್ತಿದೆ, B ಕೂಡ; A WebP/AVIF ಗೆ ಪರಿವರ್ತಿಸುತ್ತಿದೆ, B ಕೂಡ; A URL ಬದಲಿಸುತ್ತಿದೆ, B ಮತ್ತೆ ಮರುಬರೆಯುತ್ತಿದೆ—ಕೊನೆಯಲ್ಲಿ ನಿಮ್ಮ ಸೈಟ್ನಲ್ಲಿ ಈಗ ನಿಜವಾಗಿಯೂ ಏನು ನಡೆಯುತ್ತಿದೆ ಎಂದು ನಿಮಗೇ ಸ್ಪಷ್ಟವಾಗುವುದಿಲ್ಲ.
ನಿಯಮಗಳು:
ಒಂದು ಮಾತ್ರ ಮಾರ್ಗವನ್ನು ಅನುಸರಿಸಿ: ಇಲ್ಲವಾದರೆ ಸಂಪೂರ್ಣ ಉಚಿತ ಸ್ಥಳೀಯ, ಇಲ್ಲವಾದರೆ ಕ್ಲೌಡ್ ಸಂಕೋಚನೆಯ ಮೂರು ಆಯ್ಕೆಗಳಲ್ಲಿ ಒಂದನ್ನು ಆಯ್ಕೆಮಾಡಿ.
- ಮಾರ್ಗ A (ಸಂಪೂರ್ಣ ಉಚಿತ ಸ್ಥಳೀಯ):ಪ್ಲಸ್ WebP ಅಥವಾ AVIF + EWWW ಚಿತ್ರ ಆಪ್ಟಿಮೈಸರ್(ಅಥವಾ ಕೇವಲ ಒಂದನ್ನು ಆಯ್ಕೆಮಾಡಿ)
- ಮಾರ್ಗ B (ಕ್ಲೌಡ್ ಕಂಪ್ರೆಶನ್ ಮೂರು ಆಯ್ಕೆಯಲ್ಲಿ ಒಂದನ್ನು ಆರಿಸಿ):ಶಾರ್ಟ್ಪಿಕ್ಸೆಲ್ / ಇಮ್ಯಾಜಿಫೈ / ಟಿನಿಪಿಎನ್ಜಿ
3.1 ಮಾರ್ಗ A: ಸಂಪೂರ್ಣ ಉಚಿತ ಸ್ಥಳೀಯ (Plus WebP ಅಥವಾ AVIF ಅಥವಾ EWWW)
ಈ ಮಾರ್ಗದ ವಿಶೇಷತೆಗಳು:
- ನೀವು “ತಿಂಗಳಿಗೆ ಮಿತಿ/ಪ್ರತಿ ಚಿತ್ರಕ್ಕೆ ಶುಲ್ಕ” ಇರುವ ತೃತೀಯ-ಪಕ್ಷ ಸಂಕುಚನ ಸೇವೆಗಳ ಮೇಲೆ ಅವಲಂಬಿತರಾಗುವುದಿಲ್ಲ (ಆದರೆ ಕೆಲವು ವೈಶಿಷ್ಟ್ಯಗಳು ಐಚ್ಛಿಕ ಸೇವೆಗಳನ್ನೂ ನೀಡಬಹುದು)
- ಬೆಲೆ ಎಂದರೆ: ಬ್ಯಾಚ್ ಪ್ರಕ್ರಿಯೆ ಮಾಡುವುದರಿಂದ ಸರ್ವರ್ CPU/IO ಹೆಚ್ಚು ಬಳಸಬಹುದು, ಆದ್ದರಿಂದ ನೀವು “ತಂತ್ರ ಮತ್ತು ಅಪಾಯ” ಕಡೆ ಹೆಚ್ಚು ಗಮನ ಕೊಡಬೇಕು”
3.1.1 ಹೆಚ್ಚುವರಿ WebP ಅಥವಾ AVIFಮೂಲವು “ರಚನೆ/ಬದಲಾವಣೆ” ಆಗಿದೆ, ಇದು ಸಾಂಪ್ರದಾಯಿಕ ಅರ್ಥದ “ಸಂಕುಚಿಸುವ ಸಾಧನ” ಅಲ್ಲ”

- ಪೂರ್ಣ ಪ್ರಮಾಣದ ಚಿತ್ರಗಳನ್ನು ರಚಿಸುವಾಗ:ಮೂಲ ಚಿತ್ರ ಫೈಲ್ ID ಅನ್ನು WebP/AVIF ಬದಲಾಯಿಸುತ್ತದೆ, ಮೂಲ ಫೈಲ್ ಅಳಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ವಿಷಯದಲ್ಲಿರುವ URLಗಳನ್ನೂ ಬದಲಾಯಿಸಲಾಗುತ್ತದೆ。
- ಪ್ಲಗಿನ್ WP-CLI ಆಜ್ಞೆಯನ್ನು ಒದಗಿಸುತ್ತದೆ ಮತ್ತು ನೆನಪಿಸುತ್ತದೆ: ಫೈಲ್ಗಳು ಹೆಚ್ಚು ಇದ್ದರೆ WP-CLI ಬಳಸುವುದು ಇನ್ನಷ್ಟು ವಿಶ್ವಾಸಾರ್ಹ.
ಇದರರ್ಥ: ಇದು “ನಿಮಗಾಗಿ ಮೌನವಾಗಿ ಒಂದು WebP ರಚಿಸುವುದು” ಅಲ್ಲ, ಆದರೆ ಬಹುಶಃ ಒಂದು ಬಾರಿಆಸ್ತಿ ವರ್ಗಾವಣೆ(ವಿಶೇಷವಾಗಿ ನೀವು “ಬದಲಿಸಿ ಮತ್ತು ಮೂಲ ಚಿತ್ರವನ್ನು ಅಳಿಸಿ” ಸಂಬಂಧಿತ ಆಯ್ಕೆಯನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಿದಾಗ)。
ಎರಡು ವಿಧಾನಗಳ ನಡುವಿನ ವ್ಯತ್ಯಾಸ
ಮೋಡ್ 1: ಮೂಲ ಚಿತ್ರವನ್ನು ಉಳಿಸಿ + WebP/AVIF ಪ್ರತಿಗಳನ್ನು ರಚಿಸಿ (ಹೆಚ್ಚು ಸ್ಥಿರ)
- ಪ್ರಯೋಜನ: ಹೊಂದಾಣಿಕೆ ಸಮಸ್ಯೆಗಳು ಎದುರಾದಾಗ ಹಿಂದಕ್ಕೆ ಹಿಂತಿರುಗುವುದು ಹೆಚ್ಚು ಸುಲಭ
- ಬೆಲೆ: ಡಿಸ್ಕ್ ಬಳಕೆ ಹೆಚ್ಚುತ್ತದೆ (ಮೂಲ ಚಿತ್ರ + ಹೊಸ ಸ್ವರೂಪ + ಬಹು ಗಾತ್ರದ ಥಂಬ್ನೈಲ್ಗಳು)
ಮೋಡ್ 2: ಮೂಲ ಚಿತ್ರವನ್ನು ಬದಲಿಸಿ ಮತ್ತು ಅಳಿಸಿ (ಹೆಚ್ಚು ಆಕ್ರಮಕ)
- ಪ್ರಯೋಜನಗಳು: ಡಿಸ್ಕ್ ಅಷ್ಟು ಬೇಗ ದೊಡ್ಡದಾಗುವುದಿಲ್ಲ; ಸೈಟ್ ಒಳಗಿನ ಉಲ್ಲೇಖಗಳು ನೇರವಾಗಿ ಹೊಸ ಸ್ವರೂಪಕ್ಕೆ ಬದಲಾಗುತ್ತವೆ
- ಅಪಾಯ: ನೀವು “ಆಸ್ತಿ ಬದಲಾವಣೆ + ಉಲ್ಲೇಖ ಬದಲಾವಣೆ” ಮಾಡಿದರೆ, ಹೊಂದಾಣಿಕೆ ಸಮಸ್ಯೆಗಳನ್ನು ಪತ್ತೆಹಚ್ಚುವ ವೆಚ್ಚ ಇನ್ನಷ್ಟು ಹೆಚ್ಚುತ್ತದೆ (ವಿಶೇಷವಾಗಿ ಕೆಲವು ಬಾಹ್ಯ ವ್ಯವಸ್ಥೆಗಳು ಅಥವಾ ಥೀಮ್ ಲಾಜಿಕ್ ಮೂಲ ಫೈಲ್ ಹೆಸರು/ಮಾರ್ಗ/ಸ್ವರೂಪದ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿದ್ದರೆ)
ಸಲಹೆ
“ಬದಲಿಸಿ ಮತ್ತು ಮೂಲ ಚಿತ್ರವನ್ನು ಅಳಿಸಿ” ಆಯ್ಕೆ ಮಾಡುವ ಮೊದಲು, ಮೊದಲು ಸಣ್ಣ ಮಟ್ಟದಲ್ಲಿ ಪರೀಕ್ಷೆ ಮಾಡಿ + ಬಳಸಬಹುದಾದ ಬ್ಯಾಕಪ್ ಇರಲಿ; ಆರಂಭದಲ್ಲೇ ಸಂಪೂರ್ಣ ಲೈಬ್ರರಿಯನ್ನು ಬದಲಿಸಬೇಡಿ.
Plus WebP ಅಥವಾ AVIF ನ ಸಾಮಾನ್ಯ ಸಮಸ್ಯೆಗಳು
- ಪೂರ್ಣ ಲೈಬ್ರರಿ ಬದಲಿಸಿದ ನಂತರ, ಕೆಲವು ಪುಟಗಳ ಚಿತ್ರಗಳು ಅಸಾಮಾನ್ಯವಾಗಿ ತೋರುತ್ತವೆ
ಸಾಮಾನ್ಯವಾಗಿ ಕಾರಣ “ಚಿತ್ರ ಹಾಳಾಗಿದೆ” ಎಂಬುದಲ್ಲ; ಬದಲಾಗಿ URL ಬದಲಾವಣೆ, ಕ್ಯಾಶ್, ಥಂಬ್ನೇಲ್ ತಂತ್ರ ಇತ್ಯಾದಿ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿನ ಯಾವುದಾದರೂ ಒಂದು ಹಂತ ಸರಿಯಾಗಿ ಹೊಂದಿಕೊಳ್ಳದಿರುವುದಾಗಿದೆ. - ಹೆಚ್ಚಿನ ಥಂಬ್ನೇಲ್ಗಳಿದ್ದಷ್ಟು, ಬದಲಾವಣೆಯ ವ್ಯಾಪ್ತಿ ದೊಡ್ಡದು
WordPress ನಲ್ಲಿ ಒಂದು ಚಿತ್ರವನ್ನು ಅಪ್ಲೋಡ್ ಮಾಡಿದಾಗ ಹಲವು ಗಾತ್ರಗಳು ಸೃಷ್ಟಿಯಾಗುತ್ತವೆ; ಥೀಮ್ಗಳು/ಪ್ಲಗಿನ್ಗಳು ಇನ್ನಷ್ಟು ಗಾತ್ರಗಳನ್ನು ಸೇರಿಸಬಹುದು. ಸಂಪೂರ್ಣ ಬದಲಾವಣೆ ಎಂದರೆ ನೀವು ಬಹಳ ದೊಡ್ಡ ಫೈಲ್ಗಳ ಸಮೂಹವನ್ನು ಬದಲಾಯಿಸುತ್ತಿರುವಿರಬಹುದು. - ಕೇವಲ ಸ್ವರೂಪ ಬದಲಿಸಿದರೆ, ಗಾತ್ರವು ಕಡ್ಡಾಯವಾಗಿ ಅತಿ ಚಿಕ್ಕದಾಗುವುದಿಲ್ಲ
WebP/AVIF ಸಾಮಾನ್ಯವಾಗಿ ಇನ್ನಷ್ಟು ಚಿಕ್ಕದಾಗಿರುತ್ತದೆ, ಆದರೆ “ಗಾತ್ರ ನೀತಿ” ಮತ್ತು “ಸಂಕುಚಿತಗೊಳಿಸುವ ನೀತಿ” ಇನ್ನೂ ಬಹಳ ಮುಖ್ಯ. Plus WebP ಅನ್ನು “ಒಂದು ಕ್ಲಿಕ್ಕಿನಲ್ಲಿ ವೇಗ ಹೆಚ್ಚಿಸುವ”ಂತೆ ಪರಿಗಣಿಸಬೇಡಿ.
3.1.2 EWWW ಚಿತ್ರ ಆಪ್ಟಿಮೈಜರ್:ಉಚಿತ ಸ್ಥಳೀಯ ಸಂಕೋಚನದ ಪ್ರತಿನಿಧಿ

EWWW ಪ್ಲಗಿನ್ ಪುಟದ ಸ್ಥಾನೀಕರಣ ತುಂಬಾ ಸ್ಪಷ್ಟವಾಗಿದೆ:
- ಇದನ್ನು ನಿಮ್ಮ ಸರ್ವರ್ನಲ್ಲಿ ಹಲವು ಉಪಕರಣಗಳನ್ನು (jpegtran, optipng, pngout, pngquant, gifsicle, cwebp ಇತ್ಯಾದಿ) ಬಳಸಿ ಆಪ್ಟಿಮೈಸ್ ಮಾಡಬಹುದು
- ನೀವು ಹೆಚ್ಚಿನ ಸಂಕುಚಿತಗೊಳಿಸುವಿಕೆ ಅಥವಾ CPU ಅನ್ನು ಇನ್ನಷ್ಟು ಉಳಿಸಬೇಕಾದರೆ, CPU ಬಳಸುವ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಅದರ ಸರ್ವರ್ಗೆ ಸ್ಥಳಾಂತರಿಸಬಹುದು (ಐಚ್ಛಿಕ).
EWWW ಮಾರ್ಗ A ನಲ್ಲಿ ಯಾವ ಪಾತ್ರವನ್ನು ವಹಿಸಬೇಕು?
ನೀವು Plus WebP ಅನ್ನು “ಫಾರ್ಮಾಟ್ ವರ್ಗಾವಣೆ/ಬದಲಾವಣೆ ತಂತ್ರ”ಗಾಗಿ ಬಳಸುತ್ತಿದ್ದರೆ, EWWW ಇದನ್ನು ನಿರ್ವಹಿಸಲು ಹೆಚ್ಚು ಸೂಕ್ತವಾಗಿದೆ:
- ಸಂಕುಚನ ಮತ್ತು ಗಾತ್ರ ಆಪ್ಟಿಮೈಸೇಶನ್(ವಿಶೇಷವಾಗಿ JPG/PNG ಮುಂತಾದ ಮೂಲ ಸಂಪನ್ಮೂಲಗಳ ಗಾತ್ರ ಕಡಿತ)
- ಮಾಧ್ಯಮ ಗ್ರಂಥಾಲಯದ ಸಾಮೂಹಿಕ ಸುಧಾರಣಾ ಇತಿಹಾಸ(“URL ಅನ್ನು ಬದಲಿಸುವುದು” ಅಲ್ಲ, “ಗಾತ್ರವನ್ನು ಕಡಿಮೆ ಮಾಡುವುದು” ಅನ್ನು ಗುರಿಯಾಗಿಸಿ)
ಗಮನಿಸಿ
ಪ್ಲಸ್ WebP ಮತ್ತುಇಡಬ್ಲ್ಯೂಡಬ್ಲ್ಯೂ: ಎಲ್ಲವೂ AVIF ಅಥವಾ WebP ಗೆ ಪರಿವರ್ತಿಸಬಹುದು
ಇವುಗಳಲ್ಲಿ ಒಂದನ್ನೇ ಸ್ಥಾಪಿಸಲು ಶಿಫಾರಸು ಮಾಡಲಾಗುತ್ತದೆ, ಇಲ್ಲದಿದ್ದರೆ ಸಂಘರ್ಷ ಉಂಟಾಗಬಹುದು
EWWW ನ ಸಾಮಾನ್ಯ ಸಮಸ್ಯೆಗಳು
- ಬ್ಯಾಚ್ ಆಪ್ಟಿಮೈಸೇಶನ್ ಸಮಯದಲ್ಲಿ ಸರ್ವರ್ ಲೋಡ್ ಹೆಚ್ಚುತ್ತದೆ
ಸ್ಥಳೀಯ ಸಂಕೋಚನೆ CPU/IO ಅನ್ನು ಹೆಚ್ಚು ಬಳಸುತ್ತದೆ. ಆದ್ದರಿಂದ “ಬಳಸದಿರಿ” ಅಲ್ಲ, “ಹಂತ ಹಂತವಾಗಿ, ಕಡಿಮೆ ಬಳಕೆಯ ಸಮಯದಲ್ಲಿ, ಅಗತ್ಯವಿದ್ದರೆ ಆಫ್ಲೋಡ್/ಕ್ಲೌಡ್ ಪರಿಹಾರವನ್ನು ಆಯ್ಕೆಮಾಡಿ”. - “WebP ರಚಿಸಲಾಗಿದೆ ಎಂದರೆ ಮುಂಭಾಗದಲ್ಲಿ ಖಂಡಿತವಾಗಿಯೂ WebP ತೋರಿಸಲಾಗುತ್ತಿದೆ ಎಂಬುದಲ್ಲ
ಬಹಳಷ್ಟು ಪ್ಲಗಿನ್ಗಳಲ್ಲಿ ಈ ತಪ್ಪು ಅರ್ಥವಿದೆ: ಸೃಷ್ಟಿಸುವುದು ಒಂದು ವಿಷಯ, ವಿತರಣೆ ತಂತ್ರಗಳು (ಮರುಬರಹ, picture ಟ್ಯಾಗ್, ಕ್ಯಾಶ್ ಹಿಟ್ ಇತ್ಯಾದಿ) ಇನ್ನೊಂದು ವಿಷಯ. - ಇತರ ಪ್ಲಗಿನ್ಗಳೊಂದಿಗೆ ಒಂದೇ ಕೆಲಸವನ್ನು ಮರುಕಳಿಸುವುದು
ನೀವು ಮಾರ್ಗ A ಆಯ್ಕೆ ಮಾಡಿದರೆ, ಸಾಧ್ಯವಾದಷ್ಟು ShortPixel/Imagify/TinyPNG ಮುಂತಾದ ಕ್ಲೌಡ್ ಕಂಪ್ರೆಶನ್ನ್ನು ಮತ್ತೆ ಸೇರಿಸಬೇಡಿ; ನೀವು ಮಾರ್ಗ B ಆಯ್ಕೆ ಮಾಡಿದರೆ, Plus WebP ನ ಬದಲಾವಣೆ ಲಾಜಿಕ್ ಅನ್ನು ಮತ್ತೆ ಸಕ್ರಿಯಗೊಳಿಸಬೇಡಿ. ಮುಖ್ಯ ತತ್ವ:ಒಂದು ಮಾರ್ಗದಲ್ಲಿ ಕೊನೆಯವರೆಗೆ ಹೋಗಿ.
3.2 ಮಾರ್ಗ B: ಕ್ಲೌಡ್ ಕಂಪ್ರೆಷನ್ ಮೂರರಲ್ಲಿ ಒಂದು ಆಯ್ಕೆ (ShortPixel / Imagify / TinyPNG)
ಈ ಮಾರ್ಗವು ಸರ್ವರ್ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಉಳಿಸಿಕೊಳ್ಳಲು ಬಯಸುವ, ಬ್ಯಾಚ್ ಕೆಲಸಗಳನ್ನು ಸುಲಭವಾಗಿ ನಿರ್ವಹಿಸಲು ಬಯಸುವ ಮತ್ತು ಕೋಟಾ/ಬಳಕೆ ಆಧಾರಿತ ಶುಲ್ಕವನ್ನು ಒಪ್ಪುವವರಿಗೆ ಸೂಕ್ತವಾಗಿದೆ.
ಆದರೆ ಕ್ಲೌಡ್ ಸಂಕುಚನದ ಬಗ್ಗೆ ಅತ್ಯಂತ ಸುಲಭವಾಗಿ ತಪ್ಪು ಅರ್ಥವಾಗುವ ಅಂಶವೆಂದರೆ:ಉಚಿತ ಕೋಟಾ ಎಂದರೆ ಕೇವಲ “ಉಚಿತ ಸಂಖ್ಯೆಯಷ್ಟೇ” ಅಲ್ಲಥಂಬ್ನೇಲ್ ಗಾತ್ರಗಳ ಸಂಖ್ಯೆ, WebP/AVIF ರಚಿಸುವುದೇ ಮತ್ತು ಮರುಮರು ಮರುಸಂಕುಚಿತಗೊಳಿಸುವುದೇ ಎಂಬುದು ಬಳಕೆಯನ್ನು ಗಮನಾರ್ಹವಾಗಿ ಪರಿಣಾಮಗೊಳಿಸುತ್ತದೆ
ಕೆಳಗೆ ವಿವರಿಸಲಾಗುವುದು: ಉಚಿತ/ಶುಲ್ಕ ಎಂದರೇನು, ಮಿತಿ ಹೇಗೆ ಕಡಿತವಾಗುತ್ತದೆ, ಸಾಮಾನ್ಯವಾಗಿ ಯಾವ ತಪ್ಪುಗಳಲ್ಲಿ ಸಿಲುಕಬಹುದು, ಯಾವ ತಾಣ ಪ್ರಕಾರಗಳಿಗೆ ಇದು ಸೂಕ್ತವಾಗಿದೆ.
3.2.1 ShortPixelತಿಂಗಳಿಗೆ 100 ಉಚಿತ ಕ್ರೆಡಿಟ್ಗಳು, ಆದರೆ ಥಂಬ್ನೇಲ್ ಮತ್ತು WebP/AVIF ಕಾರಣದಿಂದ ಕ್ರೆಡಿಟ್ ಬಳಕೆ ಹೆಚ್ಚುತ್ತದೆ

ಉಚಿತ/ಪಾವತಿತ ಎಂದರೇನು
ShortPixel ಪ್ಲಗಿನ್ ಪರಿಚಯದಲ್ಲಿ ಸ್ಪಷ್ಟವಾಗಿ ಬರೆಯಲಾಗಿದೆ:
- ಪ್ರತಿ ತಿಂಗಳು 100 ಉಚಿತ ಕ್ರೆಡಿಟ್ಗಳು
- ಹೆಚ್ಚುವರಿ ಅನಿಯಮಿತ ಮಾಸಿಕ ಕ್ರೆಡಿಟ್ಗಳೂ ಇವೆ(ಪ್ಲಗಿನ್ ಪುಟದಲ್ಲಿ ಸಂಬಂಧಿತ ಬೆಲೆ ಮಾಹಿತಿ ನೀಡಲಾಗಿದೆ)
- ಶಾಶ್ವತ ಒಮ್ಮೆ ಬಳಕೆ ಕ್ರೆಡಿಟ್ ಪ್ಯಾಕ್ಗಳನ್ನೂ ಒದಗಿಸಲಾಗುತ್ತದೆ (ಆರಂಭಿಕ ಬೆಲೆ ಮಾಹಿತಿಯೊಂದಿಗೆ)
ಸೂಚನೆ:
- ಉಚಿತ: ಪ್ರತಿ ತಿಂಗಳು ನಿರ್ದಿಷ್ಟ credits ನೀಡಲಾಗುತ್ತದೆ, ಹಗುರ ಸೈಟ್ಗಳು ಅಥವಾ ಪರೀಕ್ಷೆಗೆ ಬಳಸಲು
- ಒಮ್ಮೆ ಬಳಕೆಯ ಪ್ಯಾಕೇಜ್: “ಮಾಧ್ಯಮ ಗ್ರಂಥಾಲಯ ತುಂಬಾ ದೊಡ್ಡದು, ಒಂದೇ ಸಲದಲ್ಲಿ ಉಳಿದಿರುವ ಎಲ್ಲವನ್ನು ತೆರವುಗೊಳಿಸಲು ಬಯಸುವ” ಸೈಟ್ಗಳಿಗೆ ಸೂಕ್ತ (ಒಮ್ಮೆ ಖರೀದಿಸಿ ಮುಗಿಯುವವರೆಗೆ ಬಳಸಬಹುದು; ಸಾಮಾನ್ಯವಾಗಿ ಅವಧಿ ಮೀರದು)
- ಮಾಸಿಕ/ಅನಿಯಮಿತ: ನಿರಂತರವಾಗಿ ಚಿತ್ರಗಳನ್ನು ನವೀಕರಿಸುವ ಮತ್ತು ದೀರ್ಘಕಾಲಿಕ ಸ್ಥಿರ ಆಪ್ಟಿಮೈಸೇಶನ್ಗೆ ಸೂಕ್ತವಾದ ಸೈಟ್ಗಳು
ShortPixel ಅಧಿಕೃತ KB ಕೂಡ “ಒಮ್ಮೆ ಖರೀದಿ ಪ್ಯಾಕೇಜ್ vs ಅನಿಯಮಿತ ಮಾಸಿಕ” ಕುರಿತು ನೀಡಿದೆಸ್ಪಷ್ಟ ವಿವರಣೆ:ಅನಿಯಮಿತ ಮಾಸಿಕ ಯೋಜನೆಗೆ ಮಾಸಿಕವಾಗಿ (ಅಥವಾ ವಾರ್ಷಿಕವಾಗಿ) ಪಾವತಿಸಲಾಗುತ್ತದೆ, ಇದು ಅನಿಯಮಿತ ಕ್ರೆಡಿಟ್ಗಳನ್ನು ನೀಡುತ್ತದೆ ಮತ್ತು ನಿಗದಿತ CDN ಕೋಟಾವನ್ನು ಒಳಗೊಂಡಿದೆ; ಒಮ್ಮೆಯ ಕ್ರೆಡಿಟ್ಗಳಿಗೆ ಅವಧಿ ಮುಗಿಯುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ನೀವು ಅವನ್ನು ನಿಮ್ಮ ಅಗತ್ಯಕ್ಕೆ ಅನುಗುಣವಾಗಿ ಇನ್ನಷ್ಟು ನಿಯಂತ್ರಿತವಾಗಿ ಬಳಸಬಹುದು.
ಸಲಹೆ
- ಹಳೆಯ ಸೈಟ್ ಕ್ಲಿಯರೆನ್ಸ್: ಒಮ್ಮೆ ಬಳಕೆಯ ಪ್ಯಾಕೇಜ್ಗೆ ಆದ್ಯತೆ
- ನಿರಂತರ ನವೀಕರಣ: ಮಾಸಿಕ/ಅನಿಯಮಿತಕ್ಕೆ ಹೆಚ್ಚು ಸೂಕ್ತ (ಕ್ರೆಡಿಟ್ಗಳನ್ನು ಲೆಕ್ಕಿಸಬೇಕಿಲ್ಲದಿದ್ದರೆ ಅನಿಯಮಿತ ಬಳಸಿ)
ಅತ್ಯಂತ ಮುಖ್ಯವಾದುದು: ShortPixel ನ ಕ್ರೆಡಿಟ್ಗಳನ್ನು ಹೇಗೆ ಲೆಕ್ಕ ಹಾಕಲಾಗುತ್ತದೆ?
ShortPixel ಅಧಿಕೃತ ದಸ್ತಾವೇಜುಗಳು KB ತುಂಬಾ ಸರಳವಾಗಿ ಹೇಳಿದೆ:
- WordPress ನಲ್ಲಿ ಒಂದು ಚಿತ್ರವನ್ನು ಅಪ್ಲೋಡ್ ಮಾಡಿದಾಗ ಹಲವು ಥಂಬ್ನೇಲ್ಗಳು ರಚಿಸಲ್ಪಡುತ್ತವೆ;
- ಪ್ರತಿ ಥಂಬ್ನೇಲ್ನ ಆಪ್ಟಿಮೈಸೇಶನ್ಗೆ ಒಂದು ಕ್ರೆಡಿಟ್ ಲೆಕ್ಕಿಸಲಾಗುತ್ತದೆ;
- ನೀವು WebP ಅಥವಾ AVIF ರಚಿಸಲು ಆಯ್ಕೆ ಮಾಡಿದರೆಪ್ರತಿ ಮೂಲಚಿತ್ರ ಮತ್ತು ಥಂಬ್ನೇಲ್ನ WebP/AVIF ಆವೃತ್ತಿ ಹೆಚ್ಚುವರಿಯಾಗಿ ಒಂದು ಕ್ರೆಡಿಟ್ ಬಳಸುತ್ತದೆ;
- ಕ್ರೆಡಿಟ್ ಬಳಕೆಯನ್ನು ಕಡಿಮೆ ಮಾಡಲು, ಕೆಲವು ಥಂಬ್ನೇಲ್ಗಳನ್ನು ಆಪ್ಟಿಮೈಸ್ ಮಾಡದೇ ಹೊರತಾಗಿಸಬಹುದು.
ನೀವು 1 ಚಿತ್ರವನ್ನು ಅಪ್ಲೋಡ್ ಮಾಡಿದರೆ, ಥೀಮ್/ಪ್ಲಗಿನ್ 8 ಥಂಬ್ನೇಲ್ಗಳನ್ನು ರಚಿಸುತ್ತದೆ:
- ಮೂಲ ಚಿತ್ರ + ಥಂಬ್ನೇಲ್ಗಳನ್ನು ಮಾತ್ರ ಆಪ್ಟಿಮೈಸ್ ಮಾಡಿ: 1 (ಮೂಲ ಚಿತ್ರ) + 8 (ಥಂಬ್ನೇಲ್ಗಳು) = 9 ಕ್ರೆಡಿಟ್ಗಳು
- WebP/AVIF ಕೂಡ ಸೃಷ್ಟಿಸಬೇಕಾದರೆ: ಮೇಲಿನ 9ಕ್ಕೂ ತಲಾ ಒಂದು next-gen ಆವೃತ್ತಿ ಹೆಚ್ಚಾಗಿ → ಇನ್ನೂ +9 ಕ್ರೆಡಿಟ್ಸ್
ಅಂದರೆ, ನೀವು “1 ಚಿತ್ರ” ಎಂದು ಭಾವಿಸಿದರೂ, ವಾಸ್ತವದಲ್ಲಿ ಸುಮಾರು “ಎರಡು ಅಂಕೆಯ credits” ಖರ್ಚಾಗಿರಬಹುದು.
ಆದ್ದರಿಂದ:“ಉಚಿತ 100 ಕ್ರೆಡಿಟ್ಗಳು” ಎಂದರೆ “ಉಚಿತ 100 ಚಿತ್ರಗಳು” ಅಲ್ಲ.
ShortPixel ಅತ್ಯಂತ ಸಾಮಾನ್ಯ ತಪ್ಪುಗಳು
- ಉಚಿತ 100 ಕ್ರೆಡಿಟ್ಗಳು ಬೇಗನೇ ಮುಗಿಯುತ್ತವೆ
ಮೂಲ ಕಾರಣ: ಹೆಚ್ಚು ಥಂಬ್ನೇಲ್ಗಳು + WebP/AVIF ರಚನೆಗೆ ಹೆಚ್ಚುವರಿ ಕ್ರೆಡಿಟ್ಗಳು
ಸಲಹೆ:
- ಮೊದಲು ಸೈಟ್ ಥಂಬ್ನೇಲ್ಗಳ ಸಂಖ್ಯೆಯನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡಿ
- ಅಗತ್ಯವಿಲ್ಲದ ಥಂಬ್ನೇಲ್ ಗಾತ್ರಗಳನ್ನು ಹೊರತುಪಡಿಸಿ (ನಿಜವಾಗಿ ಬಳಸುವ ಗಾತ್ರಗಳನ್ನು ಮಾತ್ರ ಸುಧಾರಿಸಿ)
- ಮೊದಲು ಸಂಕುಚನ ತಂತ್ರವನ್ನು ನಿಗದಿಪಡಿಸಿ ನಂತರ ಬ್ಯಾಚ್ನಲ್ಲಿ ಚಾಲನೆ ಮಾಡಿ, ಮರುಮರು ಪ್ರಯತ್ನ-ದೋಷದಿಂದ ಉಂಟಾಗುವ ವ್ಯಯವನ್ನು ತಪ್ಪಿಸಿ
- ಇತರ ಫಾರ್ಮ್ಯಾಟ್ ಪರಿವರ್ತನೆ ಪ್ಲಗಿನ್ಗಳನ್ನು ಕೂಡ ಸೇರಿಸಿ
ನೀವು Plus WebP ಬದಲಾವಣೆಯನ್ನೂ ಆನ್ ಮಾಡಿ, ಜೊತೆಗೆ ShortPixel ಮೂಲಕ next-gen ಟ್ಯಾಗ್ಗಳನ್ನು ರಚಿಸಲು/ಸೇರಿಸಲು ಹೇಳಿದರೆ, ಲಾಜಿಕ್ ಒಟ್ಟುಗೂಡಿ ಸಮಸ್ಯೆ ಪತ್ತೆಹಚ್ಚುವುದು ಕಷ್ಟವಾಗುತ್ತದೆ. ವಿಧಾನ B ಯಲ್ಲಿ ShortPixel ಒಂದೇ ಹೊಣೆ ಹೊರುತ್ತದೆ. - ಇನ್ಸ್ಟಾಲ್ ಮಾಡಿದರೆ ಸಾಕು, ಮುಂಭಾಗದಲ್ಲಿ WebP/AVIF ಹೊರಬರುತ್ತದೆ ಎಂದು ಭಾವಿಸುವುದು“
ShortPixel ಪ್ಲಗಿನ್ ಪುಟಇದು WebP/AVIF ಗೆ ಪರಿವರ್ತಿಸಬಹುದು ಮತ್ತು next-gen ಚಿತ್ರಗಳನ್ನು ಮುಂಭಾಗದ ಪುಟಕ್ಕೆ ಸೇರಿಸಬಹುದು (ಉದಾಹರಣೆಗೆ ಟ್ಯಾಗ್ ವಿಧಾನದಿಂದ)
ಆದರೆ ಮಾಡಿದ ನಂತರವೂ ಪರಿಣಾಮವನ್ನು ಪರಿಶೀಲಿಸಬೇಕು.
3.2.2 Imagifyಉಚಿತ 20MB/ತಿಂಗಳು; “ಮೂಲ ಚಿತ್ರದ ಗಾತ್ರ + ಥಂಬ್ನೇಲ್ಗಳ ಸಂಖ್ಯೆ” ಪ್ರಕಾರ ಕೋಟಾ ಕಡಿತ, ಮರುಸಂಕುಚಿಸಿದರೆ ಮರುಕಡಿತ ಆಗುತ್ತದೆ

ಉಚಿತ ಮಿತಿ ಮತ್ತು ಸ್ಥಾನೀಕರಣ
Imagify ಅಧಿಕೃತ ಬೆಲೆ ಪುಟಬಹಳ ಸ್ಪಷ್ಟವಾಗಿ ಬರೆಯಲಾಗಿದೆ:ಉಚಿತ ಖಾತೆಗೆ ಪ್ರತಿ ತಿಂಗಳು 20MB ಕೋಟಾ。
ಅದರ ಪ್ಲಗಿನ್ ಪುಟದಲ್ಲೂ ಇದು ಸಂಕೋಚಿಸಬಹುದು, ಗಾತ್ರ ಬದಲಾಯಿಸಬಹುದು ಮತ್ತು WebP/AVIF ಗೆ ಪರಿವರ್ತಿಸಬಹುದು ಎಂದು ಸ್ಪಷ್ಟವಾಗಿ ಹೇಳಲಾಗಿದೆ.
ಕೋಟಾ ಹೇಗೆ ಕಡಿತವಾಗುತ್ತದೆ?
Imagify ಅಧಿಕೃತ ದಸ್ತಾವೇಜುಗಳು “ಕೋಟಾ ಬಳಕೆ ಹೇಗೆ ಲೆಕ್ಕಿಸಲಾಗುತ್ತದೆ?” ಶುಲ್ಕ ವಿಧಿಸುವ ವಿಧಾನವನ್ನು ತುಂಬಾ ಸ್ಪಷ್ಟವಾಗಿ ವಿವರಿಸಿದೆ:
- ಥಂಬ್ನೇಲ್ಗಳ ಸಂಖ್ಯೆಯು ಬಳಕೆಯನ್ನು ಪರಿಣಾಮಗೊಳಿಸುತ್ತದೆಉದಾಹರಣೆಗೆ, ನಿಮ್ಮ ಬಳಿ 10 ಥಂಬ್ನೇಲ್ ಗಾತ್ರಗಳಿದ್ದರೆ, 1 ಚಿತ್ರವನ್ನು ಆಪ್ಟಿಮೈಸ್ ಮಾಡಿದಾಗ ಅದು 11 ಚಿತ್ರಗಳನ್ನು (ಮೂಲ ಚಿತ್ರ + 10 ಥಂಬ್ನೇಲ್ಗಳು) ಆಪ್ಟಿಮೈಸ್ ಮಾಡಿದಂತಾಗುತ್ತದೆ, ಮತ್ತು ಇವೆಲ್ಲವೂ ಕೋಟಾ ಬಳಕೆಗೆ ಸೇರುತ್ತವೆ.
- ಮೂಲ ಕಡತದ ಗಾತ್ರದ ಪ್ರಕಾರ ಕೋಟಾವನ್ನು ಕಡಿತಗೊಳಿಸಿ:ಉದಾಹರಣೆಗೆ, ನೀವು 100KB ಗಾತ್ರದ ಒಂದು ಚಿತ್ರವನ್ನು Imagify ಗೆ ಕಳುಹಿಸಿದರೆ, ನಿಮ್ಮ ಕೋಟಾದಿಂದ 100KB ಕಡಿತಗೊಳ್ಳುತ್ತದೆ.
- ಸಂಕುಚನ ಮಟ್ಟವನ್ನು ಬದಲಿಸಿ ಮತ್ತೆ ಆಪ್ಟಿಮೈಸ್ ಮಾಡಿದರೆ, ಕೋಟಾ ಮತ್ತೆ ಖರ್ಚಾಗುತ್ತದೆ。
- ಒಂದೇ API ಕೀ ಅನ್ನು ಅನೇಕ ಸೈಟ್ಗಳಲ್ಲಿ ಬಳಸಬಹುದು, ಆದರೆ ಕೋಟಾ ಈ ಸೈಟ್ಗಳ ನಡುವೆ ಹಂಚಿಕೊಳ್ಳಲಾಗುತ್ತದೆ.
ಇದೇ Imagify ಯ “ಮೂಲ ಅರ್ಥಗಮನ ವಿಧಾನ”:
ಇದು ಡೇಟಾ ಪ್ಯಾಕ್ನಂತಿದೆ: ನೀವು ಎಷ್ಟು ಕಳಿಸುತ್ತೀರೋ, ಅಷ್ಟು ಕಡಿತಗೊಳ್ಳುತ್ತದೆ; ಥಂಬ್ನೇಲ್ಗಳು ಹೆಚ್ಚು ಇದ್ದಷ್ಟು ಹೆಚ್ಚು ಕಡಿತಗೊಳ್ಳುತ್ತದೆ; ನೀವು ಮತ್ತೆ ಮತ್ತೆ ಭಾರಿ ಒತ್ತಡ ನೀಡಿದರೆ, ಮರುಮರುವಾಗಿ ಕಡಿತಗೊಳ್ಳುತ್ತದೆ.
ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಸುಲಭವಾದ Imagify ಕೋಟಾ ಉದಾಹರಣೆ
ನೀವು 800KB ಗಾತ್ರದ ಒಂದು ಮೂಲ ಚಿತ್ರವನ್ನು ಅಪ್ಲೋಡ್ ಮಾಡಿದ್ದೀರಿ ಎಂದು ಊಹಿಸಿಕೊಳ್ಳಿ; ಸೈಟ್ 8 ಥಂಬ್ನೇಲ್ ಚಿತ್ರಗಳನ್ನು ರಚಿಸುತ್ತದೆ.
- Imagify ಆಪ್ಟಿಮೈಸ್ ಮಾಡುವಾಗ “ಮೂಲ ಚಿತ್ರ + 8 ಥಂಬ್ನೇಲ್ಗಳು” ಎಲ್ಲವನ್ನೂ ಒಳಗೊಳ್ಳುತ್ತದೆ (ನೀವು ಎಲ್ಲವನ್ನೂ ಆಪ್ಟಿಮೈಸ್ ಮಾಡುವುದನ್ನು ಆಯ್ಕೆ ಮಾಡಿದರೆ), ಅಂದರೆ ಈ ಒಂದೇ ಕ್ರಿಯೆಯಿಂದ “ಈ ಎಲ್ಲಾ ಕಡತಗಳ ಮೂಲ ಗಾತ್ರಗಳ ಒಟ್ಟು ಮೊತ್ತ”ಕ್ಕೆ ಸಮೀಪವಾದ ಕೋಟಾ ಬಳಸಲಾಗುತ್ತದೆ.
ಇದಕ್ಕಾಗಿಯೇ ಕೆಲವು ಸೈಟ್ಗಳಿಗೆ “20MB ತುಂಬ ಬೇಗ ಮುಗಿದುಹೋಗುತ್ತದೆ” ಎಂದು ಅನಿಸುತ್ತದೆ: ಅದು Imagify ಸಾಕಾಗುವುದಿಲ್ಲ ಎಂಬುದರಿಂದಲ್ಲ, ನೀವು ಪ್ರತಿ ಬಾರಿ ಅಪ್ಲೋಡ್ ಮಾಡುವ ಚಿತ್ರಗಳು ತುಂಬ ದೊಡ್ಡದಾಗಿರುವುದು, ಥಂಬ್ನೇಲ್ಗಳು ತುಂಬ ಹೆಚ್ಚು ಇರುವುದು, ಮತ್ತು ನೀವು ಬಹುಶಃ ಕಂಪ್ರೆಶನ್ ಮಟ್ಟಗಳನ್ನು ಮರುಮರು ಪ್ರಯತ್ನಿಸುತ್ತಿರುವುದರಿಂದ.
Imagify ಸಾಮಾನ್ಯ ದೋಷಗಳು
- ಉಚಿತ 20MB ಸಂಪೂರ್ಣ ಸೈಟ್ ಇತಿಹಾಸ ಕ್ಲಿಯರಿಂಗ್ಗೆ ಸಾಕಾಗುವುದಿಲ್ಲ“
20MB ಸಾಮಾನ್ಯವಾಗಿ ಪರೀಕ್ಷೆ ಮತ್ತು ಲಘು ನವೀಕರಣಗಳಿಗೆ ಹೆಚ್ಚು ಸೂಕ್ತವಾಗಿದೆ; ನಿಮ್ಮ ಮೀಡಿಯಾ ಲೈಬ್ರರಿ ಮೂಲತಃ ಈಗಾಗಲೇ ಬಹಳ ದೊಡ್ಡದಿದ್ದರೆ, ಒಂದೇ ಬಾರಿಗೆ ಸಂಪೂರ್ಣ ಲೈಬ್ರರಿಯನ್ನು ತೆರವುಗೊಳಿಸಲು ಅಪ್ಗ್ರೇಡ್ ಮಾಡಬೇಕಾಗುವ ಸಾಧ್ಯತೆ ಹೆಚ್ಚು. - ಸಂಕುಚನ ಮಟ್ಟವನ್ನು ಮರುಮರು ಹೊಂದಿಸುವುದರಿಂದ ಕೋಟಾ ಮರುಮರು ಬಳಕೆಯಾಗುತ್ತದೆ
Imagify ಸ್ಪಷ್ಟವಾಗಿ ವಿವರಿಸಿಮತ್ತೆ ಆಪ್ಟಿಮೈಸ್ ಮಾಡಿದರೆ ಕೋಟಾ ಮತ್ತೆ ಬಳಸಲಾಗುತ್ತದೆ.
ನಾನು ನಿಮಗೆ ಸಲಹೆ ನೀಡುತ್ತೇನೆ, ಈ ಪುಟದಲ್ಲೇ “ತಂತ್ರ”ವನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಬರೆಯಿರಿ:
- ಮೊದಲು ಕೆಲವು ಚಿತ್ರಗಳನ್ನು ಬಳಸಿ ಸಂಕುಚನ ಮಟ್ಟ ಮತ್ತು ದೃಶ್ಯ ಗುಣಮಟ್ಟವನ್ನು ನಿರ್ಧರಿಸಿ
- ನೀತಿಯನ್ನು ದೃಢಪಡಿಸಿದ ನಂತರ ಬ್ಯಾಚ್ನಲ್ಲಿ ಚಾಲನೆ ಮಾಡಿ
ಸಂಪೂರ್ಣ ಡೇಟಾಬೇಸ್ನಲ್ಲಿ ಮರುಮರು ಪ್ರಯತ್ನಿಸುವುದನ್ನು ತಪ್ಪಿಸಿ
- ಬಹು ಸೈಟ್ಗಳು ಒಂದೇ API Key ಅನ್ನು ಹಂಚಿಕೊಂಡರೆ ಕೋಟಾ ಅರ್ಥವಾಗದಂತೆ ಕಡಿಮೆಯಾಗುತ್ತದೆ“
ನೀವು ಒಂದೇ API ಕೀಯನ್ನು ಹಲವಾರು ಸೈಟ್ಗಳಲ್ಲಿ ಬಳಸಿದರೆ, ಕೋಟಾ ಹಂಚಿಕೊಳ್ಳಲಾಗುತ್ತದೆ.
ಆದ್ದರಿಂದ ತಂಡ/ಬಹು-ಸೈಟ್ ಸಂದರ್ಭಗಳಲ್ಲಿ, ಯಾವ ಸೈಟ್ಗಳು ಹಂಚಿಕೊಳ್ಳುತ್ತವೆ ಮತ್ತು ಯಾವವು ಪ್ರತ್ಯೇಕವಾಗಿ ಬಳಸುತ್ತವೆ ಎಂಬುದನ್ನು ಸ್ಪಷ್ಟಪಡಿಸುವುದು ಉತ್ತಮ, ಇಲ್ಲದಿದ್ದರೆ ಬಜೆಟ್ ನಿಯಂತ್ರಣ ತಪ್ಪಬಹುದು.
3.2.3 TinyPNG(ಟೈನಿ ಕಂಪ್ರೆಸ್ ಚಿತ್ರಗಳು):ಉಚಿತ 500 ಕ್ರೆಡಿಟ್ಗಳು/ತಿಂಗಳು;WebP/AVIF ಗೆ ಪರಿವರ್ತಿಸಿದರೆ “ಪ್ರತಿ ಗಾತ್ರಕ್ಕೆ ಹೆಚ್ಚುವರಿ 1 ಕ್ರೆಡಿಟ್ ಕಡಿತವಾಗುತ್ತದೆ”

ಉಚಿತ ಮಿತಿ ಮತ್ತು ಅದರ ಬಿಲ್ಲಿಂಗ್ ವಿಧಾನ
TinyPNG ನ WordPress ಪ್ಲಗಿನ್ ಪುಟದಲ್ಲಿ ತುಂಬಾ ಸ್ಪಷ್ಟವಾಗಿ ಬರೆಯಲಾಗಿದೆ:
- ಪ್ರತಿ ತಿಂಗಳು 500 ಕ್ರೆಡಿಟ್ಗಳು ಉಚಿತ
- “ಸಾಮಾನ್ಯ WordPress ಸ್ಥಾಪನೆ”ಯಲ್ಲಿ, ಸುಮಾರು ಸಂಕುಚಿತಗೊಳಿಸಬಹುದು ತಿಂಗಳಿಗೆ ಸುಮಾರು 100 ಚಿತ್ರಗಳು
- ಆದರೆ AVIF ಅಥವಾ WebP ಪರಿವರ್ತನೆಯನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಿದರೆ:ಪ್ರತಿ ಚಿತ್ರದ ಗಾತ್ರಕ್ಕೆ ಹೆಚ್ಚುವರಿಯಾಗಿ ಒಂದು ಕ್ರೆಡಿಟ್ ಬಳಸಲಾಗುತ್ತದೆಆದ್ದರಿಂದ ಬಹುಶಃ ಕೇವಲ ಸಂಕುಚಿತ ಮಾಡಿ ಪರಿವರ್ತಿಸಬಹುದು ತಿಂಗಳಿಗೆ ಸುಮಾರು 50 ಚಿತ್ರಗಳು(ಇದು ನೀವು ಹೊಂದಿರುವ ಥಂಬ್ನೇಲ್ ಗಾತ್ರಗಳ ಸಂಖ್ಯೆಯ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿದೆ)。
ಅದೇ ವೇಳೆ, Tinify (TinyPNG/TinyJPG ನ ಅಭಿವೃದ್ಧಿಕಾರರು) ಕೂಡ ಅದರಲ್ಲಿದೆ API ಬೆಲೆ ನಿಗದಿ ಪುಟಸ್ಪಷ್ಟವಾಗಿ ಬರೆಯಿರಿ: ನೋಂದಾಯಿಸಿದರೆ ತಿಂಗಳಿಗೆ 500 ಉಚಿತ ಸಂಕುಚನಗಳು ದೊರೆಯುತ್ತವೆ; ಅದನ್ನು ಮೀರಿದ ನಂತರ ಯಶಸ್ವಿ ಸಂಕುಚನಗಳ ಸಂಖ್ಯೆಯ ಆಧಾರದಲ್ಲಿ ಶುಲ್ಕ ವಿಧಿಸಲಾಗುತ್ತದೆ, ಕಡ್ಡಾಯ ಚಂದಾದಾರಿಕೆ ಇಲ್ಲ.
TinyPNG ನ ಕಾರ್ಯವಿಧಾನವನ್ನು ಒಂದು ವಾಕ್ಯದಲ್ಲಿ ಸಂಕ್ಷಿಪ್ತವಾಗಿ ಹೇಳಿ:
ಇದು ಕ್ರೆಡಿಟ್ಗಳ ಆಧಾರದ ಮೇಲೆ ಲೆಕ್ಕಿಸಲಾಗುತ್ತದೆ; ಹೆಚ್ಚು ಥಂಬ್ನೇಲ್ ಗಾತ್ರಗಳು ಮತ್ತು ನೀವು ಹೆಚ್ಚು WebP/AVIF ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಿದಷ್ಟು, ಕ್ರೆಡಿಟ್ಗಳು ಅಷ್ಟು ಬೇಗ ಖರ್ಚಾಗುತ್ತವೆ.
ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಸುಲಭವಾದ TinyPNG ಕ್ರೆಡಿಟ್ಗಳ ಉದಾಹರಣೆ
ನಿಮ್ಮ ಸೈಟ್ ಪ್ರತಿ ಚಿತ್ರಕ್ಕೆ 8 ಥಂಬ್ನೇಲ್ ಗಾತ್ರಗಳನ್ನು ರಚಿಸುತ್ತದೆ ಎಂದು ಊಹಿಸಿ:
- ಕೇವಲ ಸಂಕೋಚನೆ: ಮೂಲ ಚಿತ್ರ + 8 ಥಂಬ್ನೇಲ್ಗಳು → 9 ಕ್ರೆಡಿಟ್ಗಳು ಬೇಕು
- WebP/AVIF ಪರಿವರ್ತನೆ ಸಕ್ರಿಯವಾಗಿದ್ದರೆ: ಪ್ರತಿ ಗಾತ್ರಕ್ಕೂ ಇನ್ನೊಂದು ಕ್ರೆಡಿಟ್ ಕಡಿತವಾಗುತ್ತದೆ → ಬಹುತೇಕ ದ್ವಿಗುಣವಾಗಬಹುದು
ಇದು ಪ್ಲಗಿನ್ ಪುಟದ ವಿವರಣೆಗೆ ಸರಿಯಾಗಿ ಹೊಂದುತ್ತದೆ: ಪರಿವರ್ತನೆಯನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಿದ ನಂತರ ಉಚಿತ ಮಿತಿ ಸುಮಾರು “100 ಚಿತ್ರಗಳು/ತಿಂಗಳು” ಯಿಂದ “50 ಚಿತ್ರಗಳು/ತಿಂಗಳು” ಆಗುತ್ತದೆ.
TinyPNG ಸಾಮಾನ್ಯ ದೋಷಗಳು
- 500 ಕ್ರೆಡಿಟ್ಸ್ = 500 ಚಿತ್ರಗಳು
ಇಲ್ಲ. ಇದು ಚಿತ್ರದ ಗಾತ್ರ/ರೂಪಾಂತರದ ಆಧಾರದ ಮೇಲೆ ಬಳಕೆಯಾಗುತ್ತದೆ. ಪ್ಲಗಿನ್ ಪುಟದಲ್ಲೇ “ಪ್ರತಿ ಚಿತ್ರ ಗಾತ್ರದ ಪರಿವರ್ತನೆಗೆ ಹೆಚ್ಚುವರಿಯಾಗಿ 1 ಕ್ರೆಡಿಟ್ ಕಡಿತವಾಗುತ್ತದೆ” ಎಂದು ಸ್ಪಷ್ಟವಾಗಿ ಸೂಚಿಸಲಾಗಿದೆ. - ಥೀಮ್/ಇ-ಕಾಮರ್ಸ್ ಪ್ಲಗಿನ್ಗಳು ತುಂಬಾ ಹೆಚ್ಚು ಗಾತ್ರಗಳನ್ನು ಸೃಷ್ಟಿಸುತ್ತಿವೆ, ಉಚಿತ ಮಿತಿ ಸ್ಪಷ್ಟವಾಗಿ ಕಡಿಮೆಯಾಗಿದೆ
ಗಾತ್ರಗಳು ಹೆಚ್ಚಾದಂತೆ, credits ಹೆಚ್ಚು ಪ್ರಮಾಣದಲ್ಲಿ ಖರ್ಚಾಗುವ ಸಾಧ್ಯತೆ ಹೆಚ್ಚುತ್ತದೆ. - ಪರಿವರ್ತನೆ ಸಕ್ರಿಯಗೊಳಿಸಿದ ಬಳಿಕ ಮಿತಿ ಏಕಾಏಕಿ ಬೇಗ ಖಾಲಿಯಾಗುತ್ತದೆ
ಇದು ಬಗ್ ಅಲ್ಲ, ಇದು ಅದರ ಶುಲ್ಕ ವಸೂಲಿ ವಿಧಾನ.
ತಂತ್ರ ಸಲಹೆ:
- ಉಚಿತ ಹಂತವನ್ನು ಮುಖ್ಯವಾಗಿ ಕಂಪ್ರೆಷನ್ಗೆ ಬಳಸುತ್ತಿದ್ದರೆ, ಮೊದಲು ಕೇವಲ ಕಂಪ್ರೆಸ್ ಮಾಡಿ. ಸೈಟ್ ರಚನೆ ಸ್ಥಿರವಾಗಿದೆ ಮತ್ತು next-gen ನಿಜವಾಗಿಯೂ ಬೇಕೆಂದು ದೃಢಪಟ್ಟ ನಂತರ ಪರಿವರ್ತನೆಯನ್ನು ಆರಂಭಿಸಿ
4. ಸಂದರ್ಭಾನುಸಾರ ಶಿಫಾರಸು: ವಿಭಿನ್ನ ರೀತಿಯ ಸೈಟ್ಗಳನ್ನು ಹೇಗೆ ಆಯ್ಕೆ ಮಾಡುವುದು
ಅದೇ WordPress ಆದರೂ, ವಿಷಯ ತಾಣ, ಇ-ಕಾಮರ್ಸ್, ಪೋರ್ಟ್ಫೋಲಿಯೊ, ಸದಸ್ಯತ್ವ ತಾಣಗಳ “ಚಿತ್ರ ಒತ್ತಡ ಬಿಂದುಗಳು” ಒಂದೇ ರೀತಿಯಾಗಿರುವುದಿಲ್ಲ.
4.1 ವಿಷಯ ತಾಣ/ಬ್ಲಾಗ್(ಲೇಖನಗಳಲ್ಲಿ ಹೆಚ್ಚು ಚಿತ್ರಗಳು, ನವೀಕರಣ ಮಧ್ಯಮ ಆವೃತ್ತಿ)
ಪ್ರಾಥಮಿಕತೆ ಸಲಹೆ:
- ಗಾತ್ರ ನೀತಿ (ಹಂತ 1)
- ಕುಗ್ಗಿಸಿ(Step 2)
- WebP(ಹಂತ 3)
ಹೆಚ್ಚು ಸೂಕ್ತವಾದ ಮಾರ್ಗ:
- ತಲೆನೋವು ತಪ್ಪಿಸಿಕೊಳ್ಳಲು: ಮಾರ್ಗ B ಮೂರು ಆಯ್ಕೆಗಳಲ್ಲಿ ಒಂದು (ShortPixel / Imagify / TinyPNG)
- ಉಚಿತವಾಗಿ ಬೇಕೇ: ಮಾರ್ಗ A (Plus WebP + EWWW), ಆದರೆ ಮೊದಲು “ಸಾವಧಾನ ಮೋಡ್ (ಮೂಲ ಚಿತ್ರಗಳನ್ನು ಅಳಿಸುವುದಿಲ್ಲ)” ಇಂದ ಅಪಾಯವನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡಲು ಪ್ರಾರಂಭಿಸುವುದು ಶಿಫಾರಸು ಮಾಡಲಾಗುತ್ತದೆ
ಸಾಮಾನ್ಯ ತಪ್ಪುಗಳು:
- ಲೇಖನ ಪುಟದ ಮೊದಲ ಚಿತ್ರ ಬಹಳ ದೊಡ್ಡದು, ಲೇಜಿ ಲೋಡಿಂಗ್ ತಂತ್ರ ಸರಿಯಿಲ್ಲಮೊದಲ ಪರದೆ ಲೋಡ್ ನಿಧಾನಗೊಳಿಸುತ್ತದೆ
4.2 ಇ-ಕಾಮರ್ಸ್/ಉತ್ಪನ್ನ ತಾಣ (ಹೆಚ್ಚಿನ ಥಂಬ್ನೇಲ್ಗಳು, ಹೆಚ್ಚಿನ ಚಿತ್ರ ರೂಪಾಂತರಗಳು, ಸ್ಥಿರತೆ ಮೊದಲದು)
ಇ-ಕಾಮರ್ಸ್ನಲ್ಲಿ ಹೆಚ್ಚು ಸಮಸ್ಯೆಗಳು ಉಂಟಾಗುವ ಸ್ಥಳವು “ಸಂಕುಚಿತಗೊಳಿಸುವ ಪರಿಣಾಮ ಚೆನ್ನಾಗಿಲ್ಲ” ಎಂಬುದು ಅಲ್ಲ; ಬದಲಾಗಿ “ಆಪ್ಟಿಮೈಸ್ ಮಾಡಿದ ನಂತರ ಕೆಲವು ಗಾತ್ರಗಳು ಸರಿಯಾಗಿಲ್ಲ, ಥಂಬ್ನೇಲ್ಗಳು ಕಾಣೆಯಾಗಿದೆ, ಫ್ರಂಟ್ಎಂಡ್ ಘಟಕಗಳು ಚಿತ್ರವನ್ನು ಪಡೆಯಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ” ಎಂಬುದಾಗಿದೆ.
ಪ್ರಾಥಮಿಕತೆ ಸಲಹೆ:
- ಮೊದಲು ಸ್ಥಿರವಾಗಿ ಮಾಡಿ: ಸಂಕುಚನ ತಂತ್ರವನ್ನು ಸ್ವಲ್ಪ ಸಂಯಮದಿಂದ ಇಡಿ, ಆರಂಭದಲ್ಲೇ ಸಂಪೂರ್ಣ ಡೇಟಾಬೇಸ್ ಬದಲಾವಣೆಯನ್ನು ಮಾಡಬೇಡಿ
- ಮೌಲ್ಯಮಾಪನ ಥಂಬ್ನೇಲ್ ಗಾತ್ರ: ಇ-ಕಾಮರ್ಸ್ ಥೀಮ್ಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಹೆಚ್ಚು ಗಾತ್ರಗಳನ್ನು ರಚಿಸುತ್ತವೆ, ಬಳಕೆ ಪ್ರಮಾಣವೂ ಹೆಚ್ಚಾಗಬಹುದು (ShortPixel/TinyPNG ನಲ್ಲಿ ವಿಶೇಷವಾಗಿ ಸ್ಪಷ್ಟ)
- ಮೊದಲು ಸಣ್ಣ ವ್ಯಾಪ್ತಿಯಲ್ಲಿ ಪರಿಶೀಲಿಸಿ ನಂತರ ಬ್ಯಾಚ್ ಮಾಡಿ(ತುಂಬಾ ಮುಖ್ಯ)
ಹೆಚ್ಚು ಸೂಕ್ತವಾದ ಮಾರ್ಗ:
- ಮಾರ್ಗ B ಹೆಚ್ಚು ಸುಲಭ: ShortPixel/Imagify/TinyPNG ಎಲ್ಲವೂ ಬ್ಯಾಚ್ನಲ್ಲಿ ಮಾಡಬಹುದು, ಮುಖ್ಯವಾದುದು ಕೋಟಾ ವ್ಯವಸ್ಥೆಯನ್ನು ಅರ್ಥಮಾಡಿಕೊಂಡು ವೆಚ್ಚವನ್ನು ಮುಂಚಿತವಾಗಿ ಅಂದಾಜಿಸುವುದು
- ಮಾರ್ಗ A ಕೂಡ ಸರಿ, ಆದರೆ Plus WebP ನ “ID ಅನ್ನು ಮೇಲ್ಚಾಪು/ಮೂಲ ಚಿತ್ರ ಅಳಿಸಿ/URL ಬದಲಾಯಿಸಿ” ವರ್ತನೆಯನ್ನು ಹೆಚ್ಚು ಜಾಗರೂಕತೆಯಿಂದ ನೋಡಬೇಕು: ಇದು ಆಸ್ತಿ ಸ್ಥಳಾಂತರಕ್ಕೆ ಸೇರಿದ್ದು, ಆರಂಭದಲ್ಲೇ ಸಂಪೂರ್ಣವಾಗಿ ಬದಲಿಸುವುದು ಶಿಫಾರಸು ಅಲ್ಲ.
4.3 ಪೋರ್ಟ್ಫೋಲಿಯೊ/ಛಾಯಾಗ್ರಹಣ ಸೈಟ್(ಒಂದು ಚಿತ್ರದ ಗುಣಮಟ್ಟಕ್ಕೆ ಸಂವೇದನಾಶೀಲ, ಚಿತ್ರಗಳು ದೊಡ್ಡವು, ದೃಶ್ಯಾನುಭವದ ನಿರೀಕ್ಷೆ ಹೆಚ್ಚು)
ಪ್ರಾಥಮಿಕತೆ ಸಲಹೆ:
- ಗಾತ್ರದ ತಂತ್ರ (ಪ್ರದರ್ಶನ ಪ್ರದೇಶ ನಿಯಂತ್ರಣ)
- ಸಂಕುಚನ ತಂತ್ರ (ಸ್ವಲ್ಪ ದೊಡ್ಡದಾಗಿದ್ದರೂ ಸರಿ, ವಿವರಗಳು ಹಾಳಾಗಬಾರದು)
- WebP/AVIF ದೊಡ್ಡ ಚಿತ್ರ ಸಂದರ್ಭಗಳಲ್ಲಿ ಸ್ಪಷ್ಟ ಲಾಭ ನೀಡುತ್ತದೆ, ಆದರೆ ದೃಶ್ಯ ಗುಣಮಟ್ಟವನ್ನು ಪರಿಶೀಲಿಸಬೇಕು
ಹೆಚ್ಚು ಸೂಕ್ತವಾದ ಮಾರ್ಗ:
- Imagify:“ಮೂಲ ಚಿತ್ರದ ಗಾತ್ರ” ಆಧರಿಸಿ ಕೋಟಾವನ್ನು ಕಡಿತಗೊಳಿಸಲಾಗುತ್ತದೆ. ಇಂತಹ ತಾಣಗಳಲ್ಲಿ “ಬಜೆಟ್ ನಿಯಂತ್ರಿಸಬಹುದಾದ” ವ್ಯವಸ್ಥೆ ರೂಪಿಸಲು ಸುಲಭ (ಪ್ರತಿ ದೊಡ್ಡ ಚಿತ್ರಕ್ಕೆ ಅಂದಾಜು ಎಷ್ಟು ಕಡಿತವಾಗುತ್ತದೆ ಎಂಬುದು ನಿಮಗೆ ಗೊತ್ತಿರುತ್ತದೆ), ಆದರೆ ಒಂದೇ ಚಿತ್ರವನ್ನು ಮರುಮರು ಭಾರವಾಗಿ ಸಂಕುಚಿತ ಮಾಡುವುದನ್ನು ತಪ್ಪಿಸಬೇಕು.
- ShortPixelಥಂಬ್ನೇಲ್ ಗಾತ್ರಗಳು ಕಡಿಮೆ ಇದ್ದರೆ, ಕ್ರೆಡಿಟ್ಗಳು ಕೂಡ ಸ್ಪಷ್ಟವಾಗಿರುತ್ತವೆ; ಆದರೆ ನೀವು ಹಲವು ಗಾತ್ರಗಳು + ನೆಕ್ಸ್ಟ್-ಜೆನ್ ರಚಿಸಿದರೆ, ಕ್ರೆಡಿಟ್ ಬಳಕೆ ಹೆಚ್ಚಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ ಮುಂಚಿತವಾಗಿ ಯೋಜಿಸಬೇಕು.
5. ಮಿತಿ/ಬಿಲ್ಲಿಂಗ್ ಹೋಲಿಕೆ: “ಉಚಿತವು ಸಾಕೇ?” ಅನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಹೇಳಿ
ಯಾವುದನ್ನು ಆಯ್ಕೆ ಮಾಡಿದರೆ ಹೆಚ್ಚು ಲಾಭ, ಉಚಿತವಾಗಿ ಎಷ್ಟು ಕಾಲ ಸಾಗುತ್ತದೆ?
5.1 ಮೂರು ಕಡಿತ ಶುಲ್ಕ ಮಾದರಿಗಳು
- ShortPixelಕ್ರೆಡಿಟ್ಸ್ಕ್ರೆಡಿಟ್ಗಳನ್ನು ಮೂಲ ಚಿತ್ರ + ಥಂಬ್ನೇಲ್ಗಳ ಸಂಖ್ಯೆಯ ಆಧಾರದ ಮೇಲೆ ಲೆಕ್ಕಿಸಲಾಗುತ್ತದೆ; WebP/AVIF ರಚಿಸಿದರೆ ಪ್ರತಿ ಸಂಬಂಧಿತ ಆವೃತ್ತಿಗೆ ಹೆಚ್ಚುವರಿ ಕ್ರೆಡಿಟ್ ಕಡಿತವಾಗುತ್ತದೆ.
- Imagify(MB ಕೋಟಾ):“ಮೂಲ ಫೈಲ್ ಗಾತ್ರ”ದ ಆಧಾರದ ಮೇಲೆ ಕೋಟಾ ಕಡಿತಗೊಳ್ಳುತ್ತದೆ; ಥಂಬ್ನೇಲ್ಗಳು ಹೆಚ್ಚು ಇದ್ದಷ್ಟು ಹೆಚ್ಚು ಕಡಿತಗೊಳ್ಳುತ್ತದೆ; ಮರು-ಕಂಪ್ರೆಸ್ ಮಾಡಿದರೆ ಮತ್ತೆ ಕಡಿತಗೊಳ್ಳುತ್ತದೆ.
- TinyPNGಕ್ರೆಡಿಟ್ಸ್ಪ್ರತಿ ತಿಂಗಳು 500 ಕ್ರೆಡಿಟ್ಗಳು; WebP/AVIF ಪರಿವರ್ತನೆ ಸಕ್ರಿಯಗೊಳಿಸಿದರೆ ಪ್ರತಿಯೊಂದು ಚಿತ್ರದ ಗಾತ್ರಕ್ಕೂ ಹೆಚ್ಚುವರಿ ಕ್ರೆಡಿಟ್ ಕಡಿತವಾಗುತ್ತದೆ។
5.2 ತ್ವರಿತ ಅಂದಾಜು ವಿಧಾನ
ನೀವು ಹೀಗೆ ಅಂದಾಜಿಸಬಹುದು:
- ನೀವು ಸಾಮಾನ್ಯವಾಗಿ ಅಪ್ಲೋಡ್ ಮಾಡುವ ಮೂಲ ಚಿತ್ರದೊಂದನ್ನು ಆಯ್ದು, ಅದರ ಅಂದಾಜು ಗಾತ್ರವನ್ನು ನೋಡಿ (ಉದಾ. 300KB / 1MB / 3MB)
- ನಿಮ್ಮ ಸೈಟ್ನಲ್ಲಿ ಎಷ್ಟು ಥಂಬ್ನೇಲ್ ಗಾತ್ರಗಳು ಸೃಷ್ಟಿಯಾಗುತ್ತವೆ ಎಂಬುದು ನೋಡಿ (ಉದಾ. 5 / 10 / 20)
- ನೀವು WebP/AVIF ರಚಿಸಬೇಕೇ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಿ (ಹೌದು/ಇಲ್ಲ)
ನಂತರ ಕೆಳಗಿನ “ಮಾನಸಿಕ ಲೆಕ್ಕಾಚಾರ” ಬಳಸಿ ವೆಚ್ಚವನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಿ:
- ShortPixelಪ್ರತಿ ಚಿತ್ರಕ್ಕೆ ≈ (1 + ಥಂಬ್ನೇಲ್ ಸಂಖ್ಯೆ) ಕ್ರೆಡಿಟ್ಗಳು; WebP/AVIF ರಚಿಸಿದರೆ ≈ ಮತ್ತೆ ದ್ವಿಗುಣ (ಯಾಕೆಂದರೆ next-gen ಆವೃತ್ತಿಗೂ ಕ್ರೆಡಿಟ್ ಬೇಕು)
- Imagify:ಪ್ರತಿ ಚಿತ್ರ≈(ಮೂಲ ಚಿತ್ರದ ಗಾತ್ರ + ಪ್ರತಿ ಥಂಬ್ನೇಲ್ನ ಗಾತ್ರ)ಕೋಟಾದಿಂದ ಕಡಿತವಾಗುತ್ತದೆ;ಸಂಕುಚನ ಮಟ್ಟವನ್ನು ಬದಲಿಸಿ ಮರುಸಂಕುಚಿಸಿದರೆ ಮತ್ತೆ ಕಡಿತವಾಗುತ್ತದೆ
- TinyPNGಉಚಿತ 500 ಕ್ರೆಡಿಟ್ಗಳು; ನಿಮ್ಮ ಸೈಟ್ನಲ್ಲಿ ಪ್ರತಿ ಚಿತ್ರಕ್ಕೆ ಹಲವು ಗಾತ್ರಗಳು ಉಂಟಾಗಿ, ಪರಿವರ್ತನೆ ಸಕ್ರಿಯಗೊಂಡಿದ್ದರೆ, ಉಚಿತ ಚಿತ್ರಗಳ ಸಂಖ್ಯೆ ಗಮನಾರ್ಹವಾಗಿ ಕಡಿಮೆಯಾಗುತ್ತದೆ (ಪ್ಲಗಿನ್ ಪುಟದಲ್ಲಿ “ಸುಮಾರು 100 ಚಿತ್ರಗಳು/ತಿಂಗಳು” ಮತ್ತು “ಸುಮಾರು 50 ಚಿತ್ರಗಳು/ತಿಂಗಳು” ಎಂಬ ಸರಳ ನಿರೀಕ್ಷೆ ನೀಡಲಾಗಿದೆ)
6. ಅಪಾಯ ಸೂಚನೆ
ಅಪಾಯ 1: ಒಂದೇ ಕೆಲಸವನ್ನು ಹಲವು ಪ್ಲಗಿನ್ಗಳು ಮರುಮಾಡದಂತೆ ನೋಡಿಕೊಳ್ಳಿ
ಇದು ಅತ್ಯಂತ ಸಾಮಾನ್ಯವಾದ “ವಿಪತ್ತಿನ ಮೂಲ”
- ಮಾರ್ಗ A៖Plus WebP ಅಥವಾ AVIF + EWWWಇಬ್ಬರ ಕೆಲಸವನ್ನು ಹಂಚಿಕೊಳ್ಳಿ; ಒಂದೇ ರೀತಿಯ ಪರಿವರ್ತನೆ ಮತ್ತು ವಿತರಣೆಯನ್ನು ಒಂದೇ ವೇಳೆ ಮಾಡಬೇಡಿ, ಅಥವಾ ಅವುಗಳಲ್ಲಿ ಒಂದನ್ನೇ ಸ್ಥಾಪಿಸಿ
- ಮಾರ್ಗ B:ShortPixel / Imagify / TinyPNG ಮೂರರಲ್ಲಿ ಒಂದು ಆಯ್ಕೆ ಮಾಡಿ(ಆಯ್ಕೆಮಾಡಿ ಒಬ್ಬರನ್ನು ಸಂಕುಚಿತಗೊಳಿಸುವುದು ಮತ್ತು next-gen ಗೆ ಜವಾಬ್ದಾರರು)
ಅಪಾಯ 2: Plus WebP ನ “ID ಅನ್ನು ಮೇಲೆಯೆಳೆಯುವುದು / ಮೂಲ ಚಿತ್ರವನ್ನು ಅಳಿಸುವುದು / URL ಅನ್ನು ಬದಲಿಸುವುದು” ಎಂಬುದು ಆಸ್ತಿ ಸ್ಥಳಾಂತರಕ್ಕೆ ಸೇರಿದೆ
ಮತ್ತೆ ಒತ್ತಿಹೇಳುತ್ತೇನೆ:ಪ್ಲಸ್ WebP ವಿವರಣೆಯಲ್ಲಿ ಸಂಪೂರ್ಣವಾಗಿ ರಚಿಸುವಾಗ ಮೂಲ ಚಿತ್ರದ ID ಅನ್ನು ಮೇಲೇಳಿಸಲಾಗುತ್ತದೆ, ಮೂಲ ಕಡತವನ್ನು ಅಳಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ವಿಷಯ URL ಅನ್ನು ಬದಲಿಸಲಾಗುತ್ತದೆ ಎಂದು ಸ್ಪಷ್ಟವಾಗಿ ಬರೆಯಲಾಗಿದೆ.
ಇದರ ಅರ್ಥ ಇದು “ಯಾವಾಗ ಬೇಕಾದರೂ ಹಿಂತೆಗೆದುಕೊಳ್ಳಬಹುದಾದ ಸಣ್ಣ ಸೆಟ್ಟಿಂಗ್” ಅಲ್ಲ, ಬದಲಾಗಿ ಇದು ಆಸ್ತಿ-ಮಟ್ಟದ ಒಮ್ಮೆಗಿನ ಬದಲಾವಣೆ.
ಸೂಚಿಸಲಾದ ತಂತ್ರವು ಹೀಗಿರಬೇಕು:
- ಮೊದಲು ಸಣ್ಣ ಪ್ರಮಾಣದಲ್ಲಿ ಪರೀಕ್ಷಿಸಿ (ಕೆಲವು ದಶಕಗಳಿಂದ ಕೆಲವು ನೂರರವರೆಗೆ)
- ಮುಂಭಾಗ ಪ್ರದರ್ಶನ, ಥಂಬ್ನೈಲ್ ಮತ್ತು ಕ್ಯಾಶ್ ನವೀಕರಣ ಎಲ್ಲವೂ ಸರಿಯೇ ಎಂದು ದೃಢಪಡಿಸಿ
- ಮತ್ತೆ ಸಂಪೂರ್ಣ ಗ್ರಂಥಾಲಯದಲ್ಲಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಿ
ಅಪಾಯ 3: ಕ್ಲೌಡ್ ಕಂಪ್ರೆಶನ್ನ “ಉಚಿತ ಮಿತಿ”ಯ ನೈಜ ಬಳಕೆ ಥಂಬ್ನೇಲ್ಗಳ ಸಂಖ್ಯೆಯೂ next-gen ಆಯ್ಕೆಯೂ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿದೆ
- ShortPixelಥಂಬ್ನೇಲ್ ಮತ್ತು next-gen ಕ್ರೆಡಿಟ್ಗಳನ್ನು ಗಮನಾರ್ಹವಾಗಿ ಪ್ರಭಾವಿಸುತ್ತದೆ
- TinyPNGWebP/AVIF ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಿದರೆ ಪ್ರತಿ ಚಿತ್ರದ ಗಾತ್ರಕ್ಕೆ ಹೆಚ್ಚುವರಿ ಕ್ರೆಡಿಟ್ ಕಡಿತವಾಗುತ್ತದೆ
- Imagify:ಮೂಲ ಚಿತ್ರದ ಗಾತ್ರದಂತೆ ಕಡಿತವಾಗುತ್ತದೆ; ಥಂಬ್ನೇಲ್ಗಳು ಹೆಚ್ಚು ಇದ್ದಷ್ಟು ಹೆಚ್ಚು ಕಡಿತವಾಗುತ್ತದೆ; ಮತ್ತೆ ಒತ್ತಿದರೆ ಪುನಃ ಕಡಿತವಾಗುತ್ತದೆ
ಅಪಾಯ 4: “WebP/AVIF ರಚಿಸಲಾಗಿದೆ” ಎಂದರೆ “ಮುಂಭಾಗದಲ್ಲಿ WebP/AVIF ವಿತರಿಸಲಾಗುತ್ತಿದೆ” ಎಂದಲ್ಲ”
ಪರಿವರ್ತನೆ ಮಾಡಿದರೂ ವೇಗ ಹೆಚ್ಚಿಲ್ಲವೆಂದು ಅನಿಸುತ್ತದೆ, ಕಾರಣ ಮುಂಭಾಗ ಇನ್ನೂ JPG/PNG ನಲ್ಲೇ ನೀಡುತ್ತಿದೆ (ಕ್ಯಾಶ್/ರೀರೈಟ್/ಟ್ಯಾಗ್/ಬ್ರೌಸರ್ ಹೊಂದಾಣಿಕೆ ಇತ್ಯಾದಿಯಲ್ಲಿ ಯಾವುದಾದರೂ ಸರಿಯಾಗಿಲ್ಲ)
7. ಮಾಡಿದ ನಂತರ ಪರಿಣಾಮಕಾರಿಯಾಗಿದೆಯೇ ಎಂದು ಹೇಗೆ ಪರಿಶೀಲಿಸಬೇಕು
4 ಅತ್ಯಂತ ಸರಳ ಪರಿಶೀಲನಾ ಅಂಶಗಳು:
- ಒಂದೇ ಪುಟವನ್ನು ಎರಡನೇ ಬಾರಿ ರಿಫ್ರೆಶ್ ಮಾಡಿದಾಗ, ಲೋಡ್ ಹೆಚ್ಚು ಸ್ಥಿರವಾಗಿಯೂ ವೇಗವಾಗಿಯೂ ಇದೆಯೇ(ಕ್ಯಾಶೆ ಮತ್ತು ಆಪ್ಟಿಮೈಸೇಶನ್ ಪರಿಣಾಮಕಾರಿಯೇ ಎಂಬ ಅನುಭವ)
- ಮೊಬೈಲ್ ಮತ್ತು ಡೆಸ್ಕ್ಟಾಪ್ನಲ್ಲಿ ಲೋಡ್ ಆಗುವ ಚಿತ್ರದ ಗಾತ್ರ ಸ್ಪಷ್ಟವಾಗಿ ಭಿನ್ನವೇ(ಪ್ರತಿಕ್ರಿಯಾಶೀಲ}
srcset/sizesಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆಯೇ?) - ಕೆಲವು ಚಿತ್ರಗಳನ್ನು ಯಾದೃಚ್ಛಿಕವಾಗಿ ಪರಿಶೀಲಿಸಿ: WebP ಅಥವಾ AVIF ಫೈಲ್ಗಳು/ಸಂಪನ್ಮೂಲಗಳು ಕಾಣುತ್ತವೆಯೇ(ತಾಣವು ನಿಜವಾಗಿಯೂ ಬಳಕೆಯಲ್ಲಿದೆಯೇ) next-gen)
- ಕೆಲವು ಚಿತ್ರಗಳನ್ನು ಯಾದೃಚ್ಛಿಕವಾಗಿ ಪರಿಶೀಲಿಸಿ: ದೊಡ್ಡದಾಗಿ ನೋಡಿ ಸ್ಪಷ್ಟವಾಗಿ ಮಸುಕಾಗಿದೆಯೇ, ಪಠ್ಯ ಮಬ್ಬಾಗಿ ಕಾಣಿಸುತ್ತಿದೆಯೇ ಎಂದು ನೋಡಿಸಂಕುಚನ ಗುಣಮಟ್ಟ ಅತಿಯಾದಿದೆಯೇ
ಈ ನಾಲ್ಕೂ ಹೊಂದಿದ್ದರೆ, ನೀವು ಆಯ್ಕೆ ಮಾಡಿದ ಮಾರ್ಗ ಈಗಾಗಲೇ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ ಎಂದು ಅರ್ಥ. ಮುಂದಾಗಿ ನಂತರ ಮಾಡಿ ವಿತರಣಾ ಹಂತ“ಒಟ್ಟಾರೆಯಾಗಿ ಇನ್ನಷ್ಟು ಸ್ಥಿರವಾಗಿರುತ್ತದೆ.
8. ಕ್ರಮ ಸಲಹೆಗಳು
- ಮೊದಲು ಮಾರ್ಗವನ್ನು ಆಯ್ಕೆಮಾಡಿ:
- ಸಾಧ್ಯವಾದಷ್ಟು ಉಚಿತವಾಗಿ:Plus WebP ಅಥವಾ AVIF + EWWW (ಅಥವಾ ಅವುಗಳಲ್ಲಿ ಒಂದನ್ನು ಮಾತ್ರ ಸ್ಥಾಪಿಸಿ)
- ಸರ್ವರ್ ಸಂಪನ್ಮೂಲ ಉಳಿಸಿ, ಬಳಕೆ ಮಟ್ಟಕ್ಕೆ ಅನುಗುಣವಾಗಿ ಪಾವತಿಸಿ, ಇನ್ನಷ್ಟು ನಿಶ್ಚಿಂತೆShortPixel / Imagify / TinyPNG ಇವುಗಳಲ್ಲಿ ಒಂದನ್ನು ಆಯ್ಕೆಮಾಡಿ
- ಮೊದಲು ಸಣ್ಣ ಪ್ರಮಾಣದ ಪರೀಕ್ಷೆ ಮಾಡಿ (ಕೆಲವು ದಶಕ ಚಿತ್ರಗಳು)
- ಸರಿ ಎಂದು ದೃಢಪಡಿಸಿದ ನಂತರ ಬ್ಯಾಚ್ ಮಾಡಿ
- ವಿತರಣೆ ಸ್ಥಿರತೆಯನ್ನು ಇನ್ನಷ್ಟು ಹೆಚ್ಚಿಸುವ ಅಗತ್ಯವಿದೆ:ಓದು CDN ವೇಗವರ್ಧನೆ
ಸಾಮಾನ್ಯ ಪ್ರಶ್ನೆಗಳು
1. ನಾನು ಒಟ್ಟಿಗೆ ಎಷ್ಟು ಪ್ಲಗಿನ್ಗಳನ್ನು ಇನ್ಸ್ಟಾಲ್ ಮಾಡಬೇಕು? ಎಲ್ಲವನ್ನೂ ಇನ್ಸ್ಟಾಲ್ ಮಾಡಬಹುದೇ?
ಸಾಧ್ಯವಾದಷ್ಟು ಒಂದೇ ಮಾರ್ಗವನ್ನು ಮಾತ್ರ ತೆಗೆದುಕೊಳ್ಳಿ.
- ಮಾರ್ಗ A: Plus WebP ಅಥವಾ AVIF + EWWW Image Optimizer (ಅಥವಾ ಅವುಗಳಲ್ಲಿ ಒಂದನ್ನೇ ಮಾತ್ರ ಸ್ಥಾಪಿಸಿ)
- ಆಯ್ಕೆ B: ShortPixel / Imagify / TinyPNG ಇವರಲ್ಲಿ ಒಂದನ್ನು ಆಯ್ಕೆ ಮಾಡಿ
ಒಂದೇ ಸೈಟ್ನಲ್ಲಿ ಹಲವು ಪ್ಲಗಿನ್ಗಳಿಂದ ಕಂಪ್ರೆಸ್/WebP/AVIF/URL ಬದಲಾವಣೆ/ಡಿಲಿವರಿ ರೀರೈಟ್ ಒಟ್ಟಿಗೆ ಮಾಡಿದರೆ, ಗೊಂದಲವೂ ಹೆಚ್ಚುತ್ತದೆ ಮತ್ತು ಸಮಸ್ಯೆ ಪತ್ತೆಹಚ್ಚುವುದೂ ಕಷ್ಟವಾಗುತ್ತದೆ.
2. WordPress ಈಗಾಗಲೇ WebP/AVIF ಅನ್ನು ಬೆಂಬಲಿಸುತ್ತಿಲ್ಲವೇ? ನನಗೆ ಇನ್ನೂ ಪ್ಲಗಿನ್ ಬೇಕೇ?
ಸ್ಪಷ್ಟವಾಗಿ ಬೇರ್ಪಡಿಸಬೇಕು:
“ಅಪ್ಲೋಡ್/ಬಳಕೆಗೆ ಬೆಂಬಲ ≠ ಸ್ವಯಂ ಪರಿವರ್ತನೆ/ಸ್ವಯಂ ವಿತರಣೆ
WordPress 6.5 ಕೂಡ ಹಳೆಯ JPG/PNGಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಗುಂಪುವಾಗಿ WebP/AVIFಗೆ ಪರಿವರ್ತಿಸುವುದಿಲ್ಲ, ಹಾಗೆಯೇ “ಬ್ರೌಸರ್ ಸಾಮರ್ಥ್ಯಕ್ಕೆ ಅನುಗುಣವಾಗಿ AVIF/WebP ಅನ್ನು ಔಟ್ಪುಟ್ ಮಾಡಿ ಮತ್ತು ಹಿಂತಿರುಗುವಿಕೆ ಒದಗಿಸುವ” ಸಂಪೂರ್ಣ ಸರಪಳಿಯನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ನಿಮ್ಮಿಗಾಗಿ ಮಾಡಿಕೊಡುವುದಿಲ್ಲ. ಹಳೆಯ ಮಾಧ್ಯಮ ಗ್ರಂಥಾಲಯವೂ ಅದಕ್ಕೆ ಹೊಂದಿಕೊಳ್ಳಬೇಕಾದರೆ, ಸಾಮಾನ್ಯವಾಗಿ ಪ್ಲಗಿನ್ ಅಥವಾ ಸೇವೆಯ ಸಹಾಯ ಬೇಕಾಗುತ್ತದೆ.
3. ಚಿತ್ರ ಆಪ್ಟಿಮೈಸೇಶನ್ನಲ್ಲಿ, ಅತ್ಯಂತ “ಹೆಚ್ಚು ಲಾಭದಾಯಕ” ಹಂತ ಯಾವುದು?
ಸಾಮಾನ್ಯವಾಗಿ ಮೊದಲು “ಗಾತ್ರ” ಸರಿಯಾಗಿಸಿ (srcset/sizes)。
ಅನೇಕ ತಾಣಗಳು ನಿಧಾನವಾಗಿರುವುದು ಸಂಕುಚನೆ ಮಾಡದದ್ದರಿಂದಲ್ಲ; ಪುಟದಲ್ಲಿ ಕೇವಲ 900px ಮಾತ್ರ ತೋರಿಸಿದರೂ ಬಳಕೆದಾರರಿಂದ 3000px ಮೂಲಚಿತ್ರವನ್ನು ಡೌನ್ಲೋಡ್ ಮಾಡಿಸುತ್ತಿರುವುದರಿಂದ. ಸಂಕುಚನೆ ಮಾಡಿದರೆ KB ಉಳಿಯಬಹುದು, ಆದರೆ “ಗಾತ್ರ ಸರಿಯಿಲ್ಲ” ಎಂದರೆ ನೀವು ಅನಾವಶ್ಯಕವಾಗಿ ಹಲವೆರಡು ಪಟ್ಟು ಹೆಚ್ಚು ಡೇಟಾವನ್ನು ಡೌನ್ಲೋಡ್ ಮಾಡುತ್ತೀರಿ.
4. ಈಗ ಲೋಡ್ ಆಗುತ್ತಿರುವುದು “ಚಿಕ್ಕದಾದ ಚಿತ್ರ”ವೇ ಎಂದು ನಾನು ಹೇಗೆ ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲಿ, ಸದಾ ಮೂಲ ಚಿತ್ರವನ್ನೇ ಡೌನ್ಲೋಡ್ ಮಾಡುತ್ತಿರುವುದಲ್ಲವೇ?
ಎರಡು ಘಟನೆಗಳನ್ನು ನೋಡಿ:
- ಮೊಬೈಲ್ನಲ್ಲಿ ಪುಟ ತೆರೆಯುವಾಗ ಡೌನ್ಲೋಡ್ ಮಾಡಿದ ಚಿತ್ರದ ಗಾತ್ರ ಡೆಸ್ಕ್ಟಾಪ್ಗಿಂತ ಸ್ಪಷ್ಟವಾಗಿ ಚಿಕ್ಕದು
- ಒಂದೇ ಚಿತ್ರಕ್ಕೆ ವಿಭಿನ್ನ ಸಾಧನಗಳಲ್ಲಿ ಲೋಡ್ ಆಗುವ ಸಂಪನ್ಮೂಲದ ಗಾತ್ರ ಬೇರೆಬೇರೆ ಇರುತ್ತದೆ
ಚಿತ್ರವನ್ನು ಯಾವಾಗಲೂ ಮೂಲ ಗಾತ್ರದಲ್ಲೇ ಡೌನ್ಲೋಡ್ ಆಗುತ್ತಿದ್ದರೆ, ಸಾಮಾನ್ಯ ಕಾರಣವೆಂದರೆ ಥೀಮ್/ಬಿಲ್ಡರ್ ಚಿತ್ರವನ್ನು CSS ಹಿನ್ನೆಲೆ ಚಿತ್ರವಾಗಿ ಅಥವಾ ಕಸ್ಟಮ್ ಔಟ್ಪುಟ್ ಆಗಿ ನೀಡುವುದರಿಂದ ಮೀಡಿಯಾ ಲೈಬ್ರರಿಯ ಬಹು-ಗಾತ್ರ ಮತ್ತು srcset ಅನ್ನು ಬಿಟ್ಟುಹೋಗುತ್ತದೆ.
5. “WebP/AVIF ರಚಿಸಲಾಗಿದೆ” ಎಂದರೆ ಮುಂಭಾಗದಲ್ಲಿ ಖಂಡಿತವಾಗಿಯೂ WebP/AVIF ನೀಡಲಾಗುತ್ತಿದೆ ಎಂದೇನಾ?
ಸಮಾನವಲ್ಲ.
ರಚನೆ ಎಂದರೆ ಕೇವಲ “ಫೈಲ್-ಮಟ್ಟ”ದಲ್ಲೇ ಪೂರ್ಣಗೊಂಡಿದೆ; ಮುಂಭಾಗದಲ್ಲಿ ನಿಜವಾಗಿಯೂ WebP/AVIF ವಿತರಿಸಲಾಗುತ್ತಿದೆಯೇ ಎಂಬುದು ರೀರೈಟ್, picture ಟ್ಯಾಗ್ ತಂತ್ರ, ಕ್ಯಾಶ್ ಹಿಟ್ ಆಗಿದೆಯೇ, ಬ್ರೌಸರ್ ಸಮನ್ವಯ ಪರಿಣಾಮಕಾರಿಯೇ ಇತ್ಯಾದಿಗಳ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿದೆ. ನೀವು ಕೆಲಸ ಮುಗಿಸಿದ ನಂತರ ಖಂಡಿತವಾಗಿಯೂ “ಕೆಲವು ಚಿತ್ರಗಳ ಸಂಪನ್ಮೂಲ ಪ್ರಕಾರವನ್ನು ಯಾದೃಚ್ಛಿಕವಾಗಿ ಪರಿಶೀಲಿಸಿ”.
6. ಹಾಗಾದರೆ Plus WebP ಅಥವಾ AVIF ನ ಅಪಾಯ ನಿಜವಾಗಿ ಎಲ್ಲಿದೆ? ನಾನು ಒಂದು ಕ್ಲಿಕ್ನಲ್ಲಿ ಸಂಪೂರ್ಣ ಲೈಬ್ರರಿಯನ್ನೇ ರನ್ ಮಾಡಬಹುದೇ?
ಇದರ ಅಪಾಯದ ಅಂಶವು “ಸಂಕುಚಿಸುವುದು” ಅಲ್ಲ, ಬದಲಾಗಿಆಸ್ತಿ ವರ್ಗಾವಣೆ ಮಟ್ಟದ ಬದಲಾವಣೆಗಳು:
- ಸಂಪೂರ್ಣವಾಗಿ ರಚಿಸುವಾಗ ಮೂಲ ಚಿತ್ರ ಫೈಲ್ ID ಅನ್ನು ಮೇಲೇರಿ ಬರೆಯಬಹುದು, ಮೂಲ ಫೈಲ್ ಅನ್ನು ಅಳಿಸಬಹುದು ಮತ್ತು ವಿಷಯದಲ್ಲಿನ URL ಅನ್ನು ಬದಲಾಯಿಸಬಹುದು.
ಆದ್ದರಿಂದಒಟ್ಟಾರೆ ಡೇಟಾಬೇಸ್ ಅನ್ನು ತಕ್ಷಣವೇ ಬದಲಾಯಿಸುವುದು ಶಿಫಾರಸು ಅಲ್ಲ: ಮೊದಲು ಸಣ್ಣ ಪ್ರಮಾಣದಲ್ಲಿ ಪರೀಕ್ಷಿಸಿ (ಕೆಲವು ದಶಕಗಳಿಂದ ಕೆಲವು ನೂರುವರೆಗೆ) + ಬಳಸಬಹುದಾದ ಬ್ಯಾಕಪ್ ಇದ್ದರೆ, ನಂತರ ಮಾತ್ರ ಸಂಪೂರ್ಣ ಡೇಟಾಬೇಸ್ನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವುದನ್ನು ಪರಿಗಣಿಸಿ.
7. Plus WebP ನ ಎರಡು ಮೋಡ್ಗಳನ್ನು ಹೇಗೆ ಆರಿಸಬೇಕು: ಮೂಲ ಚಿತ್ರವನ್ನು ಉಳಿಸುವುದಾ vs ಬದಲಿಸಿ ಮೂಲ ಚಿತ್ರವನ್ನು ಅಳಿಸುವುದಾ?
ಸರಳವಾಗಿ ಅರ್ಥೈಸುವುದಾದರೆ:
- ಮೋಡ್ 1: ಮೂಲ ಚಿತ್ರವನ್ನು ಉಳಿಸಿ + WebP/AVIF ಪ್ರತಿಗಳನ್ನು ರಚಿಸಿ (ಹೆಚ್ಚು ಸ್ಥಿರ): ಹಿಂತಿರುಗಿಸಲು ಅನುಕೂಲ, ಆದರೆ ಡಿಸ್ಕ್ ಬಳಕೆ ಹೆಚ್ಚುತ್ತದೆ (ಮೂಲ ಚಿತ್ರ + ಹೊಸ ಸ್ವರೂಪ + ಬಹು ಗಾತ್ರದ ಥಂಬ್ನೇಲ್ಗಳು).
- ಮೋಡ್ 2: ಮೂಲ ಚಿತ್ರವನ್ನು ಬದಲಿಸಿ ಮತ್ತು ಅಳಿಸಿ (ಹೆಚ್ಚು ಆಕ್ರಮಕ): ಡಿಸ್ಕ್ ಸುಲಭವಾಗಿ ವಿಸ್ತರಿಸುವುದಿಲ್ಲ, ಆದರೆ ನೀವು “ಆಸ್ತಿ ಬದಲಾವಣೆ + ಉಲ್ಲೇಖ ಬದಲಾವಣೆ” ಮಾಡುತ್ತಿರುವಾಗ, ಹೊಂದಾಣಿಕೆ ಸಮಸ್ಯೆಗಳ ಪರಿಶೀಲನೆ ವೆಚ್ಚ ಹೆಚ್ಚು ಆಗುತ್ತದೆ.
ಸೈಟ್ ಎಷ್ಟು ಸಂಕೀರ್ಣವಾಗಿದೆಯೋ (ಇ-ಕಾಮರ್ಸ್/ಹೆಚ್ಚು ಪ್ಲಗಿನ್ಗಳು/ಹೆಚ್ಚು ಗಾತ್ರಗಳು), ಅಷ್ಟು ಸ್ಥಿರವಾದ ಮೋಡ್ನಿಂದ ಪ್ರಾರಂಭಿಸುವುದನ್ನು ಹೆಚ್ಚು ಶಿಫಾರಸು ಮಾಡಲಾಗುತ್ತದೆ.
8. EWWW Image Optimizer ಉಚಿತ ಸ್ಥಳೀಯ ಸಂಕೋಚನೆ ಸಾಕಾಗುತ್ತದೆಯೇ? ಇದು ಸರ್ವರ್ಗೆ ಹೆಚ್ಚು ಭಾರವಾಗಬಹುದೇ?
EWWW ಹೆಚ್ಚು ಸ್ಥಳೀಯವಾಗಿ ಕೆಲಸ ಮಾಡುವ ಸಂಕುಚಕದಂತೆ: CPU/IO ಅನ್ನು ಬಳಸುತ್ತದೆ
ಸಾಮಾನ್ಯವಾಗಿ ಗುಚ್ಛ ಆಪ್ಟಿಮೈಜೇಶನ್ ವೇಳೆ ಲೋಡ್ ಹೆಚ್ಚಾಗಬಹುದು; ಇದು ಅದು ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ ಎಂದಲ್ಲ, ಸರಿಯಾದ ತಂತ್ರ ಬೇಕು: ಹಂತ ಹಂತವಾಗಿ, ಕಡಿಮೆ ಟ್ರಾಫಿಕ್ ಸಮಯದಲ್ಲಿ, ಅಗತ್ಯವಿದ್ದರೆ ಆಫ್ಲೋಡ್ ಅಥವಾ ಕ್ಲೌಡ್ ಪರಿಹಾರ ಆಯ್ಕೆ ಮಾಡಿ.
ನೀವು ತಲೆನೋವಿಲ್ಲದ ಪರಿಹಾರವನ್ನು ಬಯಸುತ್ತಿದ್ದರೆ, ಅಥವಾ ಸರ್ವರ್ ಸಂಪನ್ಮೂಲಗಳು ಕಡಿಮೆಯಿದ್ದರೆ, ಮಾರ್ಗ B ಸರ್ವರ್ಗೆ ಹೆಚ್ಚು ಮಿತವ್ಯಯಿ.
9. ShortPixel ನ 100 ಉಚಿತ ಕ್ರೆಡಿಟ್ಗಳು/ತಿಂಗಳು, ಯಾಕೆ ಕೆಲವೇ ಚಿತ್ರಗಳಲ್ಲಿ ಮುಗಿದಂತೆ ಅನಿಸುತ್ತದೆ?
ಯಾಕೆಂದರೆ ಕ್ರೆಡಿಟ್ಗಳು ಎಂದರೆ ಚಿತ್ರದ ಸಂಖ್ಯೆ ಅಲ್ಲ“ಥಂಬ್ನೇಲ್ ಮತ್ತು next-gen ಮೂಲಕ ವಿಸ್ತರಿಸಲಾಗುತ್ತದೆ៖
- ಮೂಲ ಚಿತ್ರ + ಪ್ರತಿ ಥಂಬ್ನೇಲ್ಗೂ ಕ್ರೆಡಿಟ್ ಲೆಕ್ಕಿಸಲಾಗುತ್ತದೆ
- WebP/AVIF ರಚಿಸಿದರೆ, ಪ್ರತಿ ಸಂಬಂಧಿತ ಆವೃತ್ತಿಗೆ ಹೆಚ್ಚುವರಿ ಕ್ರೆಡಿಟ್ ಬಳಸಲಾಗುತ್ತದೆ
ಆದ್ದರಿಂದ ನೀವು “1 ಚಿತ್ರ” ಎಂದು ಭಾವಿಸಬಹುದು, ಆದರೆ ವಾಸ್ತವದಲ್ಲಿ ಸುಮಾರು “2 ಅಂಕೆಯ credits” ಖರ್ಚಾಗಬಹುದು。ShortPixel
10. Imagify ನ ಉಚಿತ 20MB/ತಿಂಗಳು ಏಕೆ ಬೇಗ ಮುಗಿದುಹೋಗುತ್ತದೆ?
Imagify ಹೆಚ್ಚು “ಟ್ರಾಫಿಕ್ ಪ್ಯಾಕೇಜ್” ಹಾಗೆ ಇದೆ:
- ನೀವು ಕಳುಹಿಸಿದಂತೆಮೂಲ ಕಡತದ ಗಾತ್ರಕೋಟಾ ಕಡಿತಗೊಳಿಸಿ
- ಚಿಕ್ಕಚಿತ್ರಗಳು ಹೆಚ್ಚು ಇದ್ದಷ್ಟು, ಬಳಕೆ ಹೆಚ್ಚು
- ಸಂಕುಚನ ಮಟ್ಟವನ್ನು ಬದಲಿಸಿ ಮರು-ಆಪ್ಟಿಮೈಸ್ ಮಾಡಿದರೆ, ಕೋಟಾ ಮತ್ತೆ ಬಳಸಲಾಗುತ್ತದೆ
- ಅದೇ API ಕೀನ್ನು ಹಲವು ತಾಣಗಳಲ್ಲಿ ಒಟ್ಟಿಗೆ ಬಳಸಬಹುದು, ಕೋಟಾ ಹಂಚಿಕೊಳ್ಳಲಾಗುತ್ತದೆ
ಆದ್ದರಿಂದ “20MB ಬೇಗನೇ ಮುಗಿದುಹೋಗುತ್ತದೆ” ಎನ್ನುವುದು ಸಾಮಾನ್ಯವಾಗಿ ಚಿತ್ರಗಳು ತುಂಬಾ ದೊಡ್ಡದಿರುವುದು, ಥಂಬ್ನೇಲ್ಗಳು ತುಂಬಾ ಹೆಚ್ಚಿರುವುದು, ಅಥವಾ ಮರುಮರು ಪ್ರಯತ್ನ-ತಪ್ಪು ಮಾಡುವುದರಿಂದ ಉಂಟಾಗುತ್ತದೆ.
11. TinyPNG ಉಚಿತ 500 ಕ್ರೆಡಿಟ್ಗಳು/ತಿಂಗಳು, ಪ್ಲಗಿನ್ ಏಕೆ ಸುಮಾರು 100 ಚಿತ್ರಗಳು/ತಿಂಗಳು ಮಾತ್ರ ಎಂದು ಹೇಳುತ್ತದೆ, ಮತ್ತು WebP/AVIF ಆನ್ ಮಾಡಿದ ನಂತರ ಅದು 50 ಚಿತ್ರಗಳು/ತಿಂಗಳಿಗೆ ಏಕೆ ಆಗುತ್ತದೆ?
ಏಕೆಂದರೆ TinyPNG ಕ್ರೆಡಿಟ್ಗಳು ಕೂಡ “ಗಾತ್ರ/ವೇರಿಯಂಟ್”ಗಳಿಂದ ಹೆಚ್ಚಾಗುತ್ತವೆ៖
- ಸಾಮಾನ್ಯ WordPress ಸ್ಥಾಪನೆಯಲ್ಲಿ ತಿಂಗಳಿಗೆ ಸುಮಾರು 100 ಚಿತ್ರಗಳು ಸಂಕುಚಿತವಾಗುತ್ತವೆ
- AVIF ಅಥವಾ WebP ಪರಿವರ್ತನೆಯನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಿ:ಪ್ರತಿ ಚಿತ್ರದ ಗಾತ್ರಕ್ಕೆ ಹೆಚ್ಚುವರಿಯಾಗಿ ಒಂದು ಕ್ರೆಡಿಟ್ ಬಳಸಲಾಗುತ್ತದೆಆದ್ದರಿಂದ, ಬಹುಶಃ ತಿಂಗಳಿಗೆ ಸುಮಾರು 50 ಚಿತ್ರಗಳನ್ನು ಮಾತ್ರ ಸಂಕುಚಿತಿಸಿ ಮತ್ತು ಪರಿವರ್ತಿಸಬಹುದು (ಥಂಬ್ನೇಲ್ ಗಾತ್ರಗಳ ಸಂಖ್ಯೆಯನ್ನು ಅವಲಂಬಿಸಿ).
ಆದ್ದರಿಂದ 500 ಕ್ರೆಡಿಟ್ಸ್ ≠ 500 ಚಿತ್ರಗಳು.
12. ನನ್ನ ತಾಣದಲ್ಲಿ ಒಟ್ಟಾರೆ ಎಷ್ಟು ಥಂಬ್ನೇಲ್ಗಳಿವೆ? ಅದು ಏಕೆ ಇಷ್ಟು ದೊಡ್ಡ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ?
WordPress ನಲ್ಲಿ ಒಂದು ಚಿತ್ರವನ್ನು ಅಪ್ಲೋಡ್ ಮಾಡಿದಾಗ ಹಲವು ಗಾತ್ರಗಳು ಸೃಷ್ಟಿಯಾಗುತ್ತವೆ; ಥೀಮ್ಗಳು/ಪ್ಲಗಿನ್ಗಳು (ವಿಶೇಷವಾಗಿ ಇ-ಕಾಮರ್ಸ್) ಇನ್ನೂ ಹೆಚ್ಚಿನ ಗಾತ್ರಗಳನ್ನು ಸೇರಿಸಬಹುದು.
ಕ್ಲೌಡ್ ಸಂಕೋಚನದ ಕ್ರೆಡಿಟ್ಗಳು/ಕೋಟಾ ಸಾಮಾನ್ಯವಾಗಿ “ಮೂಲ ಚಿತ್ರ + ಥಂಬ್ನೇಲ್ಗಳನ್ನು ಒಟ್ಟಿಗೆ ಲೆಕ್ಕಿಸಲಾಗುತ್ತದೆ”, ಆದ್ದರಿಂದ ಥಂಬ್ನೇಲ್ಗಳ ಸಂಖ್ಯೆ ಹೆಚ್ಚು ಇದ್ದಂತೆ ಉಚಿತ ಮಿತಿ ಅಷ್ಟು ಬೇಗ ಮುಗಿಯುತ್ತದೆ.
13. ಲೇಜಿ ಲೋಡಿಂಗ್ ಖಂಡಿತವಾಗಿಯೂ ವೇಗವನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆಯೇ? ಕೆಲವರು ಲೇಜಿ ಲೋಡಿಂಗ್ ಬದಲಾಗಿ ನಿಧಾನಗೊಳ್ಳುತ್ತದೆ ಎಂದು ಏಕೆ ಹೇಳುತ್ತಾರೆ?
ಸೋಮಾರಿ ಲೋಡಿಂಗ್ “ಪರದೆಯ ಹೊರಗಿನ ಸಂಪನ್ಮೂಲಗಳಿಗೆ” ಸೂಕ್ತವಾಗಿದೆ.
ಮೊದಲ ಪರದೆಯಲ್ಲಿರುವ ಅತ್ಯಂತ ಪ್ರಮುಖ ದೊಡ್ಡ ಚಿತ್ರವೂ ತಡವಾಗಿ ಲೋಡ್ ಆದರೆ, ಮೊದಲ ಪರದೆ ಅನುಭವ ನಿಧಾನವಾಗಬಹುದು. WordPress 5.5 ರಿಂದ ಡೀಫಾಲ್ಟ್ ಲೇಜಿ-ಲೋಡಿಂಗ್ ಸರಿಯೇ, ಆದರೆ “ಎಲ್ಲಕ್ಕೂ ಒಂದೇ ನಿಯಮ” ಎಂದು ಮಾಡಬೇಡಿ.
14. ನಾನು ಮಾರ್ಗ A ಅಥವಾ B ಅನ್ನು ತೆಗೆದುಕೊಂಡರೆ, CDN / ಚಿತ್ರ CDN ಯಾವಾಗ ಬೇಕು?
ಸಂಕುಚನ, ಗಾತ್ರ, ಸ್ವರೂಪವು “ಫೈಲ್ ಇನ್ನಷ್ಟು ಚಿಕ್ಕದು ಮತ್ತು ಹೆಚ್ಚು ಸೂಕ್ತ” ಎಂಬುದನ್ನು ಪರಿಹರಿಸುತ್ತವೆ;
CDN ಹತ್ತಿರದ ಮತ್ತು ಸ್ಥಿರವಾದ ವಿತರಣೆಯನ್ನು ಪರಿಹರಿಸುತ್ತದೆ。
ಚಿತ್ರಗಳನ್ನು ಮೂಲ ಸೈಟ್ನಿಂದ ದೂರದಿಂದ ಪಡೆದುಕೊಳ್ಳುವುದರಿಂದ ವಿಳಂಬ ಸ್ಪಷ್ಟವಾಗಿದ್ದರೆ, ಹೆಚ್ಚುವರಿಯಾಗಿ CDN/ಚಿತ್ರ CDN (ಉದಾಹರಣೆಗೆ Cloudflare Polish / Jetpack Site Accelerator) ಸೇರಿಸಿದರೆ ಒಟ್ಟಾರೆ ಹೆಚ್ಚು ಸ್ಥಿರವಾಗುತ್ತದೆ, ಓದುವಿಕೆ WordPress CDN ವೇಗವರ್ಧನೆ。
15. ಮಾಡಿದ ನಂತರ ಅದು ನಿಜವಾಗಿಯೂ ಪರಿಣಾಮಕಾರಿಯಾಗಿದೆ ಎಂದು ಪರಿಶೀಲಿಸಲು ನಾನು ಬಳಸಬಹುದಾದ ಅತ್ಯಂತ ಸರಳ ವಿಧಾನ ಯಾವುದು?
ಸಮಯ ಉಳಿಸುವ ಪರಿಶೀಲನಾ ವಿಧಾನ:
- ಒಂದೇ ಪುಟವನ್ನು ಎರಡನೇ ಬಾರಿ ರಿಫ್ರೆಶ್ ಮಾಡಿದಾಗ, ಲೋಡ್ ಹೆಚ್ಚು ಸ್ಥಿರವಾಗಿಯೂ ವೇಗವಾಗಿಯೂ ಇದೆಯೇ
- ಮೊಬೈಲ್ ಮತ್ತು ಡೆಸ್ಕ್ಟಾಪ್ನಲ್ಲಿ ಲೋಡ್ ಆಗುವ ಚಿತ್ರಗಳ ಗಾತ್ರದಲ್ಲಿ ಸ್ಪಷ್ಟ ವ್ಯತ್ಯಾಸವಿದೆಯೇ (srcset/sizes ಕೆಲಸ ಮಾಡುತ್ತದೆಯೇ)
- ಕೆಲವು ಚಿತ್ರಗಳನ್ನು ಯಾದೃಚ್ಛಿಕವಾಗಿ ಪರಿಶೀಲಿಸಿ: WebP ಅಥವಾ AVIF ಫೈಲ್ಗಳು/ಸಂಪನ್ಮೂಲಗಳು ಕಾಣುತ್ತವೆಯೇ
- ಕೆಲವು ಚಿತ್ರಗಳನ್ನು ಯಾದೃಚ್ಛಿಕವಾಗಿ ಪರಿಶೀಲಿಸಿ: ದೊಡ್ಡದಾಗಿ ನೋಡಿ ಸ್ಪಷ್ಟವಾಗಿ ಮಸುಕಾಗಿದೆಯೇ, ಪಠ್ಯ ಮಬ್ಬಾಗಿ ಕಾಣಿಸುತ್ತಿದೆಯೇ ಎಂದು ನೋಡಿ