ಕಳೆದ ಫೆಬ್ರವರಿ 2, 2017 ರಂದು, ಆನ್ ಟೇಲರ್ ಅವರು CodeInWP ನಲ್ಲಿ 12 Things We Need to See From WordPress Page Builders in 2017 + Who Already Gets It Right ಎಂಬ ಲೇಖನವನ್ನು ಬರೆದಿದ್ದರು. ನಾವು ಈಗ ಒಂದು ವರ್ಷಕ್ಕೂ ಹೆಚ್ಚು ಕಾಲದಿಂದ Page Builder Sandwich ಅನ್ನು ನಿರಂತರವಾಗಿ ಸುಧಾರಿಸುತ್ತಿದ್ದೇವೆ: ನಾವು ಸಂಶೋಧನೆ ಮಾಡುತ್ತೇವೆ, ನಮ್ಮ ಗ್ರಾಹಕರ ಮಾತು ಕೇಳುತ್ತೇವೆ, ಆದ್ದರಿಂದ Page Builder Sandwich CodeInWP ನ “Who Got it Right” ಲೇಖನದಲ್ಲಿ ಸ್ಥಾನ ಪಡೆಯುತ್ತದೆ ಎಂದು ನಾವು ಭಾವಿಸಿದ್ದೆವು. ಆದರೆ ಕಾರ್ಯಕ್ಷಮತೆಯ ಸಮಸ್ಯೆಯಿಂದಾಗಿ ನಮಗೆ ಸ್ಥಾನ ಸಿಗಲಿಲ್ಲ. 
ಆದ್ದರಿಂದ ನಾವು ಆನ್ ಅವರ ಬಳಿ ಈ ಬಗ್ಗೆ ಕೇಳಿದೆವು, ಮತ್ತು ಅವರು ಹೀಗೆ ಉತ್ತರಿಸಿದರು:
…ನಾನು ಉಚಿತ ಆವೃತ್ತಿಯನ್ನು ಸ್ವಲ್ಪ ಪರೀಕ್ಷಿಸಿದೆ. ಇದು ಸಾಕಷ್ಟು ಭರವಸೆ ಮೂಡಿಸುತ್ತದೆ: ಹಲವಾರು ಮಾಡ್ಯೂಲ್‌ಗಳು, ಸಾಕಷ್ಟು ಅರ್ಥಗರ್ಭಿತ UI, ಉತ್ತಮ WYSIWYG ಅನುಭವ, ಪ್ರತಿಯೊಂದನ್ನೂ ಸುಲಭವಾಗಿ ಡ್ರ್ಯಾಗ್ ಮಾಡಬಹುದು. ಆದರೆ, ಪುಟದಲ್ಲಿ ಸುಮಾರು 10 ಮಾಡ್ಯೂಲ್‌ಗಳಿದ್ದಾಗ, ಎಡಿಟಿಂಗ್ ವೇಗ ಕಡಿಮೆಯಾದ ಕಾರಣ ಅದರೊಂದಿಗೆ ಕೆಲಸ ಮುಂದುವರಿಸುವುದು ಕಷ್ಟವಾಯಿತು…
ಅವರ ಪ್ರಕಾರ, Page Builder Sandwich ಕಾರ್ಯಕ್ಷಮತೆಯ ಸಮಸ್ಯೆಗಳನ್ನು ಹೊಂದಿದೆ. ಮತ್ತು ನಾವು ಯಾವಾಗಲೂ ಪ್ರತಿಕ್ರಿಯೆಗಳಿಗೆ ಗಮನ ನೀಡುವುದರಿಂದ, ನಾವು ಇದನ್ನು ಪರಿಶೀಲಿಸಿದೆವು.
ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಪರೀಕ್ಷಿಸುವುದು
PBS ನ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಪರಿಶೀಲಿಸಲು ನಮಗೆ ಒಂದು ಮಾರ್ಗ ಬೇಕಿತ್ತು; PBS ಮುಖ್ಯವಾಗಿ Javascript ಮೂಲಕ ಬ್ರೌಸರ್‌ನಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದರಿಂದ, Chrome ನ Timeline ಪ್ರೊಫೈಲರ್ ಈ ಕೆಲಸಕ್ಕೆ ಸರಿಯಾದ ಸಾಧನವಾಗಿತ್ತು. ಟೈಮ್‌ಲೈನ್ ಪ್ರೊಫೈಲರ್ ರನ್‌ಟೈಮ್ ಸಮಯದಲ್ಲಿ ವೆಬ್‌ಪುಟದಲ್ಲಿ ಯಾವ ಪ್ರಕ್ರಿಯೆಗಳು ನಡೆಯುತ್ತಿವೆ ಎಂಬುದನ್ನು ಗುರುತಿಸಿ ಅಳೆಯಬಲ್ಲದು, ಇದು ವೇಗದ ಅಡೆತಡೆಗಳನ್ನು ಹುಡುಕಲು ಅತ್ಯುತ್ತಮವಾಗಿದೆ.
ನಾವು ಮೊದಲು ಅತ್ಯಂತ ಸರಳವಾದ ಹಂತವನ್ನು ಪರೀಕ್ಷಿಸಬೇಕೆಂದು ನಿರ್ಧರಿಸಿದೆವು – ಹಲವು ಎಲಿಮೆಂಟ್‌ಗಳು ಮತ್ತು ಸಾಲುಗಳ ಮೇಲೆ ನಮ್ಮ ಮೌಸ್ ಅನ್ನು ಚಲಿಸುವುದು. ಸರಳವಾಗಿದೆ ಅಲ್ಲವೇ? ಇಷ್ಟೊಂದು ಸರಳವಾದ ವಿಷಯದಲ್ಲಿ ಕಾರ್ಯಕ್ಷಮತೆಯ ಸಮಸ್ಯೆಗಳು ಎದುರಾಗುವುದಿಲ್ಲ ಎಂದು ನಮಗೆ ಖಚಿತವಿತ್ತು. ದುರದೃಷ್ಟವಶಾತ್, ನಮ್ಮ ಊಹೆ ತಪ್ಪಾಗಿತ್ತು.
ನಾವು ರೆಕಾರ್ಡ್ ಬಟನ್ ಒತ್ತಿದ ನಂತರ, ಪರದೆಯ ಮೇಲೆ ಸುಮಾರು 2 ಸೆಕೆಂಡುಗಳ ಕಾಲ ಮೌಸ್ ಚಲಿಸಿ, ನಂತರ ಸ್ಟಾಪ್ ಬಟನ್ ಒತ್ತಿದೆವು. ಪ್ರೊಫೈಲರ್‌ನಿಂದ ಬಂದ ಟೈಮ್‌ಲೈನ್ ಫಲಿತಾಂಶ ಇಲ್ಲಿದೆ:
ನೋಡಿ! ಇದು ಕಾರ್ಯಕ್ಷಮತೆಯ ಅಡೆತಡೆಗಳಿಂದ ತುಂಬಿ ತುಳುಕುತ್ತಿದೆ!
ಗ್ರಾಫ್‌ನಲ್ಲಿ ಬಹಳಷ್ಟು ಸಂಗತಿಗಳು ನಡೆಯುತ್ತಿವೆ, ಆದರೆ ಅತ್ಯಂತ ಸ್ಪಷ್ಟವಾದ ಸಮಸ್ಯೆಯೆಂದರೆ ಅದರಲ್ಲಿ ಸಾಕಷ್ಟು ನೇರಳೆ ಬಣ್ಣದ ಪ್ರದೇಶಗಳಿವೆ (ಹೀಗಿರಬಾರದು). ಅಷ್ಟೇ ಅಲ್ಲದೆ, ಈ ನೇರಳೆ ಪ್ರದೇಶಗಳು ಸ್ಪಷ್ಟವಾಗಿ ತುಂಬಾ ಅಗಲವಾಗಿವೆ ಮತ್ತು ಎಲ್ಲವೂ ಗ್ರಾಫ್‌ನ ಗರಿಷ್ಠ ಮಿತಿಯನ್ನು ಮುಟ್ಟುವಂತೆ ಕಾಣುತ್ತವೆ. ಗ್ರಾಫ್ ಯಾವಾಗಲೂ ತುಂಬಿರುವುದನ್ನು ಮತ್ತು ನೇರಳೆ ಪ್ರದೇಶಗಳು ಬಹುತೇಕ ಶೂನ್ಯಕ್ಕೆ ಇಳಿಯದೇ ಇರುವುದನ್ನು ಕೂಡ ನೀವು ಗಮನಿಸಬಹುದು. ಬ್ರೌಸರ್ ಯಾವಾಗಲೂ ಏನನ್ನಾದರೂ ಮಾಡುವುದರಲ್ಲಿ ನಿರತವಾಗಿರುವಂತೆ ಮತ್ತು ಎಂದಿಗೂ ವಿಶ್ರಾಂತಿ ಪಡೆಯದಂತೆ ತೋರುತ್ತದೆ.
ಆದರೆ ಆ ಎಲ್ಲಾ ನೇರಳೆ ಪ್ರದೇಶಗಳ ನಿಜವಾದ ಅರ್ಥವೇನು?
ಅವುಗಳನ್ನು reflows ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ ಎಂದು ಪ್ರೊಫೈಲರ್ ನಮಗೆ ತಿಳಿಸಿತು. Google Developer ಸೈಟ್:
ಡಾಕ್ಯುಮೆಂಟ್‌ನಲ್ಲಿರುವ ಎಲಿಮೆಂಟ್‌ಗಳ ಸ್ಥಾನಗಳು ಮತ್ತು ರೇಖಾಗಣಿತವನ್ನು ಮರು-ಲೆಕ್ಕಾಚಾರ ಮಾಡುವ ವೆಬ್ ಬ್ರೌಸರ್ ಪ್ರಕ್ರಿಯೆಗೆ ರಿಫ್ಲೋ (Reflow) ಎಂದು ಹೆಸರು.. ರಿಫ್ಲೋ ಎಂಬುದು ಬ್ರೌಸರ್‌ನಲ್ಲಿ ಬಳಕೆದಾರರನ್ನು ನಿರ್ಬಂಧಿಸುವ ಕಾರ್ಯಾಚರಣೆಯಾಗಿದೆ.
ಇದರರ್ಥ PBS ನಲ್ಲಿ ಮೌಸ್ ಚಲಿಸುವುದು ಬಹಳಷ್ಟು ರಿಫ್ಲೋಗಳನ್ನು ಪ್ರಚೋದಿಸುತ್ತದೆ. ಇನ್ನೂ ಕೆಟ್ಟ ಸಂಗತಿಯೆಂದರೆ, ಪ್ರತಿ ರಿಫ್ಲೋ ಸಹ ತನ್ನ ಲೆಕ್ಕಾಚಾರಗಳನ್ನು ಪೂರ್ಣಗೊಳಿಸಲು ಬ್ರೌಸರ್ ಅನ್ನು ಕ್ಷಣಕಾಲ ನಿಲ್ಲಿಸುತ್ತದೆ. ಹೆಚ್ಚು ರಿಫ್ಲೋಗಳೆಂದರೆ ಹೆಚ್ಚು ಬ್ರೌಸರ್ ವಿರಾಮಗಳು, ಮತ್ತು ಅನುಭವವು ಇನ್ನಷ್ಟು ತಡೆಹಿಡಿಯುವಂತಾಗುತ್ತದೆ (janky). ಸರಳವಾಗಿ ಹೇಳುವುದಾದರೆ, ಹೆಚ್ಚು ನೇರಳೆ ಪ್ರದೇಶಗಳು = ಕೆಟ್ಟದು.
ಹಾಗಾಗಿ ಆನ್ ಹೇಳಿದ್ದು ಸರಿ ಎಂಬುದು ಸಾಬೀತಾಯಿತು: ನಮ್ಮಲ್ಲಿ ನಿಜವಾಗಿಯೂ ದೊಡ್ಡ ಕಾರ್ಯಕ್ಷಮತೆಯ ಅಡಚಣೆ ಇತ್ತು, ಆದ್ದರಿಂದ ನಮ್ಮ ತಂಡವು ತಕ್ಷಣವೇ ಅದನ್ನು ಸರಿಪಡಿಸಲು ಕಾರ್ಯಪ್ರವೃತ್ತವಾಯಿತು.
ನಮ್ಮ ರಿಫ್ಲೋ / ಜ್ಯಾಂಕ್ ಸಮಸ್ಯೆಯನ್ನು ಸರಿಪಡಿಸುವುದು
ಎಲ್ಲಕ್ಕಿಂತ ಮೊದಲು, ಈ ರಿಫ್ಲೋಗೆ ಕಾರಣವೇನು ಎಂಬುದನ್ನು ಕಂಡುಹಿಡಿಯಲು ನಾವು ಸ್ವಲ್ಪ ಸಂಶೋಧನೆ ಮಾಡಬೇಕಿತ್ತು. ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್‌ನಲ್ಲಿನ ಹಲವು ಸಾಮಾನ್ಯ ಸಂಗತಿಗಳು ಬ್ರೌಸರ್‌ನಲ್ಲಿ ರಿಫ್ಲೋ ಉಂಟುಮಾಡಲು ಪ್ರೇರೇಪಿಸುತ್ತವೆ ಎಂದು ನಾವು ಕಂಡುಕೊಂಡೆವು.
DOM ಎಲಿಮೆಂಟ್‌ನ ಅಗಲ, ಎತ್ತರ ಅಥವಾ ಸ್ಥಾನವನ್ನು ಪಡೆಯಲು ನೀವು ಬಳಸಬಹುದಾದ ಬಹುತೇಕ ಯಾವುದೇ ಫಂಕ್ಷನ್ ರಿಫ್ಲೋ ಅನ್ನು ಪ್ರಚೋದಿಸಬಹುದು. ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್‌ನಲ್ಲಿ ಇದನ್ನು ಮಾಡಬಹುದಾದ ಎಲ್ಲಾ ಪ್ರಾಪರ್ಟಿಗಳು ಮತ್ತು ಫಂಕ್ಷನ್‌ಗಳ ವಿಸ್ತೃತ ಪಟ್ಟಿಯನ್ನು ಪಾಲ್ ಐರಿಶ್ ಬರೆದಿದ್ದಾರೆ. ಕೆಟ್ಟ ಸುದ್ದಿಯೆಂದರೆ Page Builder Sandwich ಈ ಪ್ರಾಪರ್ಟಿಗಳು ಮತ್ತು ಫಂಕ್ಷನ್‌ಗಳಲ್ಲಿ ಹಲವನ್ನು ಬಳಸುತ್ತದೆ, ಮತ್ತು ಇವೆಲ್ಲವೂ ರಿಫ್ಲೋಗೆ ಕಾರಣವಾಗುತ್ತವೆ:
- elem.getBoundingClientRect()
- window.getComputedStyle()
- window.scrollY
- ಮತ್ತು ಇನ್ನೂ ಹಲವು…
ಪರಿಹಾರ #1: ದುಬಾರಿ ರಿಫ್ಲೋ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಕ್ಯಾಶ್ ಮಾಡುವುದು
ಅತ್ಯಂತ ಸ್ಪಷ್ಟವಾದ ಪರಿಹಾರವೆಂದರೆ ಆ ಪ್ರಾಪರ್ಟಿಗಳು ಮತ್ತು ಫಂಕ್ಷನ್‌ಗಳನ್ನು ಬಳಸದಿರುವುದು. ಆದರೆ, PBS ಅವುಗಳ ಮೇಲೆ ಹೆಚ್ಚು ಅವಲಂಬಿತವಾಗಿದೆ ಮತ್ತು ಅವುಗಳಿಲ್ಲದೆ ನಮಗೆ ಮುಂದುವರಿಯಲು ಸಾಧ್ಯವಿಲ್ಲ.
ನಮಗೆ ಉಳಿದಿರುವ ಪರಿಹಾರವೆಂದರೆ ಆ ಫಂಕ್ಷನ್‌ಗಳಿಗೆ ಮಾಡುವ ಕರೆಗಳನ್ನು ಸಾಧ್ಯವಾದಷ್ಟು ಕಡಿಮೆ ಮಾಡುವುದು. ಕಷ್ಟದ ವಿಷಯವೆಂದರೆ ನಾವು ಆ ಪ್ರಾಪರ್ಟಿಗಳು ಮತ್ತು ಫಂಕ್ಷನ್‌ಗಳನ್ನು PBS ನ ವಿವಿಧ ಭಾಗಗಳಲ್ಲಿ ಹಲವು ಬಾರಿ ಬಳಸಿದ್ದೆವು, ಮತ್ತು ಹೆಚ್ಚಿನ ಬಾರಿ, ಒಂದೇ DOM ಎಲಿಮೆಂಟ್ ಮೇಲೆ ಅವುಗಳನ್ನು ಪದೇ ಪದೇ ಬಳಸುತ್ತಿದ್ದೆವು. ಇದನ್ನು ಸರಿಪಡಿಸಲು, ನಾವು ಸಮಸ್ಯೆಯುಂಟುಮಾಡುವ ಪ್ರತಿಯೊಂದು ಪ್ರಾಪರ್ಟಿ/ಫಂಕ್ಷನ್‌ಗಾಗಿ ನಮ್ಮದೇ ಆದ ಕ್ಯಾಶಿಂಗ್ ವ್ಯವಸ್ಥೆಯನ್ನು ರಚಿಸಿದೆವು.
ಉದಾಹರಣೆಗೆ, getBoundingClientRect ಫಂಕ್ಷನ್ ನಮಗೆ DOM ಎಲಿಮೆಂಟ್‌ನ ಪ್ರಸ್ತುತ top, left, width, height, right, ಮತ್ತು bottom ಪಿಕ್ಸೆಲ್ ಅಳತೆಗಳನ್ನು ನೀಡುತ್ತದೆ. PBS ನಲ್ಲಿ ಎಲಿಮೆಂಟ್ ಔಟ್‌ಲೈನ್‌ಗಳನ್ನು ಎಲ್ಲಿ ಬಿಡಿಸಬೇಕು ಎಂಬ ಸ್ಥಳವನ್ನು ಲೆಕ್ಕಹಾಕಲು ನಾವು ಈ ಫಂಕ್ಷನ್ ಅನ್ನು ಸದಾ ಬಳಸುತ್ತೇವೆ. ಇದಕ್ಕಾಗಿ ನಾವು ರಚಿಸಿದ ಕ್ಯಾಶಿಂಗ್ ಫಂಕ್ಷನ್ ಇಲ್ಲಿದೆ:
// Cache: Our client rects are kept here, we can use this to clear them later.
var elemsWithBoundingRects = [];
window.pbsGetBoundingClientRect = function( element ) {
// Check if we already got the client rect before.
if ( ! element._boundingClientRect ) {
// If not, get it then store it for future use.
element._boundingClientRect = element.getBoundingClientRect();
elemsWithBoundingRects.push( element );
}
return element._boundingClientRect;
};
getBoundingClientRect ಅನ್ನು ಕರೆಯುವ ಬದಲು, ನಾವು ಈಗ pbsGetBoundingClientRect ಅನ್ನು ಬಳಸಿದೆವು. ಈಗ ಪ್ರತಿ ಬಾರಿ client rect ಕ್ವೆರಿ ಆದಾಗ, ಭವಿಷ್ಯದ ಬಳಕೆಗಾಗಿ ನಾವು ಆ ಮೌಲ್ಯವನ್ನು ಸಂಗ್ರಹಿಸಿಡುತ್ತೇವೆ, ಇದರಿಂದಾಗಿ ರಿಫ್ಲೋ ಪ್ರಚೋದನೆಗಳ ಸಂಖ್ಯೆ ಸೀಮಿತವಾಗುತ್ತದೆ.
ಸಂಗ್ರಹಿಸಲಾದ client rect ಗಳು ಅಮಾನ್ಯವಾದಾಗ ಕ್ಯಾಶ್ ಅನ್ನು ತೆರವುಗೊಳಿಸಲು ನಮಗೆ ಒಂದು ಮಾರ್ಗ ಬೇಕಿತ್ತು. ಬಳಕೆದಾರರು ಪುಟವನ್ನು ಸ್ಕ್ರೋಲ್ ಮಾಡಿದಾಗ ಅಥವಾ ಪರದೆಯಲ್ಲಿ ಎಲಿಮೆಂಟ್‌ಗಳನ್ನು ಸೇರಿಸಿದಾಗ/ಬದಲಾಯಿಸಿದಾಗ/ತೆಗೆದುಹಾಕಿದಾಗ ಸಂಗ್ರಹಿಸಲಾದ client rect ನ ಮೌಲ್ಯಗಳು ಬದಲಾಗುತ್ತವೆ. ಆದ್ದರಿಂದ ನಮಗೆ ಹೊಸ client rect ಮೌಲ್ಯಗಳು ಬೇಕಾದಾಗಲೆಲ್ಲಾ ಕರೆಯಬಹುದಾದ ಕ್ಯಾಶ್ ತೆರವುಗೊಳಿಸುವ ಫಂಕ್ಷನ್ ಅನ್ನು ನಾವು ರಚಿಸಿದೆವು:
var clearClientRects = function() {
var i;
for ( i = 0; i < elemsWithBoundingRects.length; i++ ) {
if ( elemsWithBoundingRects[ i ] ) {
elemsWithBoundingRects[ i ]._boundingClientRect = null;
}
}
elemsWithBoundingRects = [];
};
ನಾವು ಸಾಮಾನ್ಯವಾಗಿ ಬಳಸುವ ಇತರ ದುಬಾರಿ ಫಂಕ್ಷನ್ ಕರೆಗಳಿಗೂ ಇದೇ ರೀತಿಯ ಕ್ಯಾಶಿಂಗ್ ವ್ಯವಸ್ಥೆಯನ್ನು ಅಳವಡಿಸಿದೆವು.
ಪರಿಹಾರ #2: FastDom ಬಳಸಿ Reads & Writes ಗಳನ್ನು ಒಟ್ಟಿಗೆ ಗುಂಪು ಮಾಡುವುದು
ಪರಿಹಾರ #1 ಅನ್ನು ಅಳವಡಿಸಿದ್ದು PBS ನ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಹೆಚ್ಚಿಸಿತು, ಆದರೆ ಅದು ಸಾಕಾಗಲಿಲ್ಲ.
ಇನ್ನಷ್ಟು ಗೂಗಲ್ ಮಾಡಿದಾಗ, ‘ಲೇಔಟ್ ಥ್ರ್ಯಾಶಿಂಗ್’ ತಡೆಗಟ್ಟುವ ಕುರಿತು ವಿಲ್ಸನ್ ಪೇಜ್ ಅವರ ಲೇಖನ ನಮಗೆ ಸಿಕ್ಕಿತು. ವಿಲ್ಸನ್ ಹೇಳುತ್ತಾರೆ:
ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ DOM ನಿಂದ ಹಲವು ಬಾರಿ ತೀವ್ರವಾಗಿ ಬರೆಯುವಾಗ ಮತ್ತು ನಂತರ ಓದುವಾಗ ಲೇಔಟ್ ಥ್ರ್ಯಾಶಿಂಗ್ (ರಿಫ್ಲೋ) ಸಂಭವಿಸುತ್ತದೆ, ಇದು ಡಾಕ್ಯುಮೆಂಟ್ ರಿಫ್ಲೋಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ.
ನಿರ್ದಿಷ್ಟ ರಿಫ್ಲೋ-ಪ್ರಚೋದಕ ಪ್ರಾಪರ್ಟಿಗಳು ಮತ್ತು ಫಂಕ್ಷನ್‌ಗಳ ಕರೆಗಳನ್ನು ಸೀಮಿತಗೊಳಿಸಿದರೆ ಮಾತ್ರ ಸಾಲದು. ನೀವು DOM ನಲ್ಲಿ ಸತತವಾಗಿ ಹಲವು “ಓದುವಿಕೆಗಳು” (reads) ಮತ್ತು “ಬರೆಯುವಿಕೆಗಳನ್ನು” (writes) ನಿರ್ವಹಿಸಿದಾಗಲೂ, ಅದು ಬ್ರೌಸರ್ ರಿಫ್ಲೋ ಅನ್ನು ಪ್ರಚೋದಿಸುತ್ತದೆ. ವಿಲ್ಸನ್ ಅವರ ಸೈಟ್‌ನಿಂದ ನೇರವಾಗಿ ತೆಗೆದುಕೊಂಡ ವಿಶಿಷ್ಟ ಸನ್ನಿವೇಶ ಇಲ್ಲಿದೆ:
// Read
var h1 = element1.clientHeight;
// Write (invalidates layout)
element1.style.height = (h1 * 2) + 'px';
// Read (triggers reflow)
var h2 = element2.clientHeight;
// Write (invalidates layout)
element2.style.height = (h2 * 2) + 'px';
// Read (triggers reflow)
var h3 = element3.clientHeight;
// Write (invalidates layout)
element3.style.height = (h3 * 2) + 'px';
// Document reflows at end of frame
ಮೇಲಿನ ಉದಾಹರಣೆಯು 3 ರಿಫ್ಲೋಗಳನ್ನು ಪ್ರಚೋದಿಸುತ್ತದೆ ಏಕೆಂದರೆ ಒಂದು ಬರವಣಿಗೆಯ ನಂತರ ಇಡೀ ಪುಟದ ಆಯಾಮಗಳು ಅಮಾನ್ಯವಾಗುತ್ತವೆ. ಇದಕ್ಕೆ ಸೂಚಿಸಲಾದ ಪರಿಹಾರವೆಂದರೆ, ಇಡೀ ಪ್ರಕ್ರಿಯೆಯು ಕೇವಲ 1 ಬ್ರೌಸರ್ ರಿಫ್ಲೋ ಅನ್ನು ಮಾತ್ರ ಪ್ರಚೋದಿಸುವಂತೆ ಮಾಡಲು, ಎಲ್ಲಾ ಓದುವಿಕೆಗಳು ಮತ್ತು ಬರೆಯುವಿಕೆಗಳನ್ನು ಒಟ್ಟಿಗೆ ಗುಂಪು ಮಾಡಲು ಕೋಡ್ ಅನ್ನು ಮರುಹೊಂದಿಸುವುದು:
// Read
var h1 = element1.clientHeight;
var h2 = element2.clientHeight;
var h3 = element3.clientHeight;
// Write (invalidates layout)
element1.style.height = (h1 * 2) + 'px';
element2.style.height = (h2 * 2) + 'px';
element3.style.height = (h3 * 2) + 'px';
// Document reflows at end of frame
ಮೇಲಿನ ತುಣುಕು ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುವುದು ಸುಲಭವೆಂದು ತೋರಿಸುತ್ತದೆ. ಆದರೆ ವಾಸ್ತವದಲ್ಲಿ, PBS ನಲ್ಲಿ ರಿಫ್ಲೋ ಪ್ರಚೋದಿಸುವ ವಿಷಯಗಳನ್ನು ಓದುವುದು ಮತ್ತು ಬರೆಯುವುದು PBS ನ ಜೀವಿತಾವಧಿಯಲ್ಲಿ ವಿವಿಧ ಸಮಯಗಳಲ್ಲಿ ವಿವಿಧ ಸ್ಥಳಗಳಲ್ಲಿ ಸಂಭವಿಸುತ್ತದೆ. ಸಾವಿರಾರು ಸಾಲುಗಳ ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಕೋಡ್ ಅನ್ನು ಮರುಹೊಂದಿಸುವುದು ಪ್ರಾಯೋಗಿಕವಲ್ಲ.
ನಮ್ಮ ಅದೃಷ್ಟಕ್ಕೆ, ವಿಲ್ಸನ್ ತಮ್ಮ ಲೇಖನದಲ್ಲಿ ಪರಿಹಾರವನ್ನೂ ನೀಡಿದ್ದಾರೆ. ಅವರು ಆ ಓದುವಿಕೆಗಳು ಮತ್ತು ಬರೆಯುವಿಕೆಗಳನ್ನು ಒಟ್ಟಿಗೆ ಸೇರಿಸಲು ಸಹಾಯ ಮಾಡುವ ಸಣ್ಣ ಯುಟಿಲಿಟಿ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ರಚಿಸಿದರು, ಅದರ ಹೆಸರು FastDom.
FastDom ಅನ್ನು ಬಳಸುವ ಮತ್ತು ಮೇಲೆ ತಿಳಿಸಲಾದ ನಮ್ಮ ಪರಿಹಾರ #1 ಅನ್ನು ಸಹ ಒಳಗೊಂಡಿರುವ Page Builder Sandwich ನ ಕೆಲವು ಕೋಡ್ ಇಲ್ಲಿದೆ:
// Bunch together the reads from other threads.
fastdom.measure( function() {
// Use our cached client rect.
var rect = window.pbsGetBoundingClientRect( elem );
// Bunch together the writes from other threads.
fastdom.mutate( function() {
elem.style.top = ( rect.top + window.pbsScrollY() ) + 'px';
elem.style.height = rect.height + 'px';
elem.style.left = rect.left + 'px';
elem.style.width = rect.width + 'px';
}.bind( this ) );
}.bind( this ) );
FastDom ಏನು ಮಾಡುತ್ತದೆ ಎಂದರೆ, ಅದು ಎಲ್ಲಾ fastdom.measure ಕರೆಗಳನ್ನು ಮತ್ತು ಎಲ್ಲಾ fastdom.mutate ಕರೆಗಳನ್ನು ಒಟ್ಟಿಗೆ ಗುಂಪು ಮಾಡಿ ಅವುಗಳನ್ನು ಅಸಮಕಾಲಿಕವಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತದೆ, ಬ್ರೌಸರ್‌ನಲ್ಲಿನ ಎಲ್ಲಾ ರಿಫ್ಲೋಗಳನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಎಲ್ಲಾ ಓದುವಿಕೆಗಳು ಮತ್ತು ಬರೆಯುವಿಕೆಗಳನ್ನು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಒಟ್ಟುಗೂಡಿಸುತ್ತದೆ.
ಪರಿಹಾರ #3: ಸ್ಟೈಲ್ ಆಬ್ಜೆಕ್ಟ್‌ಗಳನ್ನು ಪ್ರವೇಶಿಸುವುದು ದುಬಾರಿಯಾಗಿದೆ
ಕೆಲವು ಸ್ಟೈಲ್-ಪಡೆಯುವ ಫಂಕ್ಷನ್‌ಗಳು ಇತರಕ್ಕಿಂತ ವೇಗವಾಗಿವೆ ಎಂದು ನಾವು jsPerf ಸಹಾಯದಿಂದ ಕಂಡುಕೊಂಡೆವು.
PBS ನಲ್ಲಿ, ನಾವು ಸಾಮಾನ್ಯವಾಗಿ ಎಲಿಮೆಂಟ್‌ನ ನಿರ್ದಿಷ್ಟ ಸ್ಟೈಲ್‌ನ ಪ್ರಸ್ತುತ ಮೌಲ್ಯವನ್ನು ಪಡೆಯಬೇಕಾಗುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, top margin ಪಡೆಯಲು ನಾವು ಸಾಮಾನ್ಯವಾಗಿ ಇದನ್ನು ಬಳಸುತ್ತೇವೆ:
var styles = window.getComputedStyle( elem );
var marginTop = styles.marginTop;
ಆದರೆ, ಹೀಗೆ ಮಾಡುವುದು ಹೆಚ್ಚು ವೇಗವಾಗಿರುತ್ತದೆ ಎಂದು ನಾವು ಕಂಡುಕೊಂಡೆವು:
var marginTop = elem.style.marginTop;
ಆದಾಗ್ಯೂ, elem.style.marginTop ಮತ್ತು getComputedStyle ತುಂಬಾ ಭಿನ್ನವಾಗಿವೆ. ಮೊದಲನೆಯದು ನಮಗೆ ಎಲಿಮೆಂಟ್‌ನ ಇನ್‌ಲೈನ್ ಸ್ಟೈಲಿಂಗ್ ಅನ್ನು ಮಾತ್ರ ನೀಡುತ್ತದೆ, ಮತ್ತು ಯಾವುದೇ ಸ್ಟೈಲ್‌ಶೀಟ್‌ಗಳನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳುವುದಿಲ್ಲ; ಮತ್ತು ಎರಡನೆಯದು ಇನ್‌ಲೈನ್ ಶೈಲಿಗಳು ಮತ್ತು ಸ್ಟೈಲ್‌ಶೀಟ್‌ಗಳು ಎರಡನ್ನೂ ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ.
ಇನ್ನೊಂದು ವಿಷಯವೆಂದರೆ, getComputedStyle ಫಲಿತಾಂಶವನ್ನು ಕ್ಯಾಶ್ ಮಾಡಿದಾಗಲೂ, ಅದು ಇನ್ನೂ ತುಂಬಾ ನಿಧಾನವಾಗಿತ್ತು. ತಿಳಿದುಬಂದಂತೆ, ಸ್ವತಃ ಸ್ಟೈಲ್ ಆಬ್ಜೆಕ್ಟ್ ಅನ್ನು ಪ್ರವೇಶಿಸುವುದೇ ನಿಧಾನಗತಿಯ ಪ್ರಕ್ರಿಯೆಯಾಗಿದೆ.
ನಮ್ಮ ಅದೃಷ್ಟಕ್ಕೆ, PBS ಎಲಿಮೆಂಟ್‌ಗಳಿಗೆ ಇನ್‌ಲೈನ್ ಶೈಲಿಗಳನ್ನು ಸೇರಿಸುತ್ತದೆ, ಮತ್ತು ಇನ್‌ಲೈನ್ ಶೈಲಿಗಳು ಸ್ಟೈಲ್‌ಶೀಟ್‌ಗಳಿಗಿಂತ (ಹೆಚ್ಚಿನ ಸಮಯ) ಆದ್ಯತೆಯನ್ನು ಪಡೆಯುವುದರಿಂದ, ಇನ್‌ಲೈನ್ ಶೈಲಿಯ ಮೌಲ್ಯವನ್ನು ಪಡೆಯುವುದು ಸಾಕಾಗುವ ಸಂದರ್ಭಗಳಿರುತ್ತವೆ. ಆದ್ದರಿಂದ ನಾವು ಮೇಲಿನ ಎರಡು ವಿಧಾನಗಳನ್ನು ಸಂಯೋಜಿಸಿದರೆ, ನಾವು ಹೆಚ್ಚು ವೇಗವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಕೋಡ್ ಅನ್ನು ಪಡೆಯಬಹುದು:
var marginTop = elem.style.marginTop;
if ( ! marginTop ) {
var styles = window.getComputedStyle( elem );
marginTop = styles.marginTop;
}
ಕೋಡ್ ಸುಧಾರಣೆಗಳ ಫಲಿತಾಂಶಗಳು
ಮೇಲಿನ ನಮ್ಮ 3 ಪರಿಹಾರಗಳಿಗೆ ಸಾಕಷ್ಟು ಸಂಶೋಧನೆ, ಪರೀಕ್ಷೆ ಮತ್ತು ನೈಜ ಅನುಷ್ಠಾನದ ಅಗತ್ಯವಿತ್ತು (ಮತ್ತು ನಮ್ಮ Fonts ವೈಶಿಷ್ಟ್ಯ ಬಿಡುಗಡೆಯಾಗುವುದನ್ನು ವಿಳಂಬಗೊಳಿಸಿತು), ಆದರೆ ಕೊನೆಗೆ ಅದೆಲ್ಲವೂ ಸಾರ್ಥಕವಾಯಿತು.
ಪರದೆಯ ಮೇಲೆ 2 ಸೆಕೆಂಡುಗಳ ಕಾಲ ನಿಮ್ಮ ಮೌಸ್ ಚಲಿಸುವ ನಮ್ಮ ಆರಂಭಿಕ ಪರೀಕ್ಷೆಗೆ ಹಿಂತಿರುಗೋಣ. ಹಳೆಯ ಅಸ್ತವ್ಯಸ್ತವಾದ/ತಡೆಹಿಡಿಯುವ ಟೈಮ್‌ಲೈನ್ ಇಲ್ಲಿದೆ:
ಮತ್ತು ಕಾರ್ಯಕ್ಷಮತೆಯ ಸುಧಾರಣೆಗಳ ನಂತರ ನಮ್ಮ ಹೊಸ ಟೈಮ್‌ಲೈನ್ ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:
ನೀವು ನೋಡುವಂತೆ, ಗ್ರಾಫ್‌ನಲ್ಲಿ ನೇರಳೆ ಬಣ್ಣದ ಪ್ರದೇಶಗಳು ಕಡಿಮೆಯಾಗಿವೆ. ಮತ್ತು ಬ್ರೌಸರ್ ನಿರ್ವಹಿಸುವ ಪ್ರಕ್ರಿಯೆಗಳ ಪ್ರಮಾಣದಲ್ಲಿ ಗಮನಾರ್ಹ ವ್ಯತ್ಯಾಸವಿದೆ. ಕೆಳಗಿನ ಆಯತಾಕಾರದ ಭಾಗಗಳು ಸಹ ತೆಳುವಾಗಿವೆ, ಇದರರ್ಥ ಪ್ರಕ್ರಿಯೆಗಳು ಹಿಂದಿನದಕ್ಕಿಂತ ವೇಗವಾಗಿ ನಡೆಯುತ್ತಿವೆ.
ಹಳೆಯ ಮತ್ತು ಹೊಸ ಗ್ರಾಫ್‌ಗಳಲ್ಲಿನ ಎತ್ತರದ/ಅಗಲವಾದ ನೇರಳೆ ಪ್ರದೇಶಗಳ ಪ್ರಮಾಣವನ್ನು ನೀವು ಹೋಲಿಸಿದರೆ, ನಾವು ಬರೋಬ್ಬರಿ 200% ಕಾರ್ಯಕ್ಷಮತೆಯ ಹೆಚ್ಚಳವನ್ನು ಕಾಣುತ್ತಿದ್ದೇವೆ! ನಾವು ಒಟ್ಟಾರೆಯಾಗಿಯೂ ಕಾರ್ಯಕ್ಷಮತೆಯ ಹೆಚ್ಚಳವನ್ನು ಕಾಣುತ್ತಿದ್ದೇವೆ. ಖಂಡಿತವಾಗಿಯೂ ಕೆಟ್ಟದ್ದಲ್ಲ!
ಪ್ರಮುಖ ಅಂಶಗಳು ಮತ್ತು ಕಲಿಕೆಗಳು
ಪ್ರಾಮಾಣಿಕವಾಗಿ ಹೇಳಬೇಕೆಂದರೆ, ಆನ್ ಈ ವಿಷಯವನ್ನು ಪ್ರಸ್ತಾಪಿಸುವ ಮೊದಲು PBS ನಲ್ಲಿ ಕಾರ್ಯಕ್ಷಮತೆಯ ಸಮಸ್ಯೆಗಳಿವೆ ಎಂದು ನಾವು ಭಾವಿಸಿರಲಿಲ್ಲ. ಮುಖ್ಯವಾಗಿ ಏಕೆಂದರೆ ನಾವು ಡೆವಲಪ್‌ಮೆಂಟ್-ಕೇಂದ್ರಿತ ಯಂತ್ರಗಳನ್ನು ಬಳಸುತ್ತಿದ್ದೆವು ಮತ್ತು ಕಾರ್ಯಕ್ಷಮತೆಯ ಅಡೆತಡೆಗಳು ಅಷ್ಟಾಗಿ ಗೋಚರಿಸುತ್ತಿರಲಿಲ್ಲ. ಹಿಂತಿರುಗಿ ನೋಡಿದಾಗ, ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಪರಿಶೀಲಿಸುವುದು ಪ್ರಮುಖ ಆದ್ಯತೆಗಳಲ್ಲಿ ಒಂದಾಗಿರಬೇಕಿತ್ತು. ಆದರೆ ಕನಿಷ್ಠ ಈಗ, ಆವೃತ್ತಿ 4.3 ರಂತೆ ಅದನ್ನು ಸರಿಪಡಿಸಲಾಗಿದೆ. 
ತಮ್ಮದೇ ಆದ ವರ್ಡ್‌ಪ್ರೆಸ್ ಪ್ಲಗಿನ್ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸುಧಾರಿಸಲು ಬಯಸುವವರಿಗೆ, ವಿಶೇಷವಾಗಿ ನೀವು ಹೆವಿ ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಬಳಸುತ್ತಿದ್ದರೆ, ಈ ಅನುಭವದಿಂದ ನನ್ನ ಪ್ರಮುಖ ಸಲಹೆಗಳು ಇಲ್ಲಿವೆ:
- ರಿಫ್ಲೋ ಪ್ರಚೋದಿಸುವ ಪ್ರಾಪರ್ಟಿಗಳು/ಫಂಕ್ಷನ್‌ಗಳಿಗೆ ಮಾಡುವ ಕರೆಗಳನ್ನು ಮಿತಿಗೊಳಿಸಿ/ಕ್ಯಾಶ್ ಮಾಡಿ. ಇದಕ್ಕಾಗಿ ಮಾರ್ಗದರ್ಶಿಯಾಗಿ ಇದನ್ನು ಬಳಸಿ: What forces layout/reflow. The comprehensive list.
- DOM ಶೈಲಿಗಳಿಗೆ “reads” ಮತ್ತು “writes” ಗಳನ್ನು ಒಟ್ಟಿಗೆ ಗುಂಪು ಮಾಡಿ. ನಿಮಗಾಗಿ ಇದನ್ನು ಮಾಡಲು FastDom ಬಳಸಿ.
- Chrome ನ Timeline ಪ್ರೊಫೈಲರ್ ಬಳಸಿ, ಮತ್ತು ಸಾಧ್ಯವಾದಷ್ಟು ಕಡಿಮೆ ರಿಫ್ಲೋಗಳನ್ನು (ನೇರಳೆ ಬಣ್ಣದ ಭಾಗಗಳು) ಹೊಂದಿರುವಂತೆ ನೋಡಿಕೊಳ್ಳಿ.
ನೀವು ಸಾಂದರ್ಭಿಕ ಪೂರಕ ಚಿತ್ರಗಳನ್ನು ಒಳಗೊಂಡಿರುವ ಪೂರ್ಣ ಪ್ರಮಾಣದ ಲೇಖನಗಳನ್ನು ಬರೆಯುವುದರ ಸುತ್ತಲೇ ನಿಮ್ಮ ಎಲ್ಲಾ ವಿಷಯ ರಚನೆ ಕೇಂದ್ರೀಕೃತವಾಗಿರುವ ಕಡು ಬ್ಲಾಗರ್ ಆಗಿದ್ದರೆ, ಪ್ರಾಯಶಃ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ TinyMCE ಕಂಟೆಂಟ್ ಎಡಿಟರ್ ನಿಮ್ಮ ಅಗತ್ಯಗಳಿಗೆ ಸಾಕಾಗಬಹುದು. ಪ್ರಸ್ತುತ ಟೂಲ್‌ಸೆಟ್ ಈಗಾಗಲೇ ಲೇಖನಗಳನ್ನು ಬರೆಯಲು ಅಗತ್ಯವಾದ ಪರಿಕರಗಳನ್ನು ಒಳಗೊಂಡಿದೆ, ನಿಮ್ಮ ಬಳಿ ಬೋಲ್ಡ್, ಇಟಾಲಿಕ್, ಹೆಡಿಂಗ್ಸ್ ಮುಂತಾದ ಮೂಲಭೂತ ಪಠ್ಯ ಫಾರ್ಮ್ಯಾಟಿಂಗ್ ಪರಿಕರಗಳಿವೆ. ಆದರೆ ಅದು ಅಷ್ಟಕ್ಕೇ ಸೀಮಿತವಾಗಿದೆ.
ನೋಡಿ! ಇದು ಕಾರ್ಯಕ್ಷಮತೆಯ ಅಡೆತಡೆಗಳಿಂದ ತುಂಬಿ ತುಳುಕುತ್ತಿದೆ!
ನೀವು ನೋಡುವಂತೆ, ಗ್ರಾಫ್‌ನಲ್ಲಿ ನೇರಳೆ ಬಣ್ಣದ ಪ್ರದೇಶಗಳು ಕಡಿಮೆಯಾಗಿವೆ. ಮತ್ತು ಬ್ರೌಸರ್ ನಿರ್ವಹಿಸುವ ಪ್ರಕ್ರಿಯೆಗಳ ಪ್ರಮಾಣದಲ್ಲಿ ಗಮನಾರ್ಹ ವ್ಯತ್ಯಾಸವಿದೆ. ಕೆಳಗಿನ ಆಯತಾಕಾರದ ಭಾಗಗಳು ಸಹ ತೆಳುವಾಗಿವೆ, ಇದರರ್ಥ ಪ್ರಕ್ರಿಯೆಗಳು ಹಿಂದಿನದಕ್ಕಿಂತ ವೇಗವಾಗಿ ನಡೆಯುತ್ತಿವೆ.
