கடந்த பிப்ரவரி 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 பெரும்பாலும் ஜாவாஸ்கிரிப்ட் வழியாக உலாவியில் இயங்குவதால், இந்த வேலைக்கு குரோமின் டைம்லைன் ப்ரோஃபைலர் (Chrome’s Timeline profiler) சரியான கருவியாக இருந்தது. இயக்க நேரத்தில் (runtime) ஒரு வலைப்பக்கத்தில் என்னென்ன செயல்முறைகள் நடைபெறுகின்றன என்பதை டைம்லைன் ப்ரோஃபைலரால் அடையாளம் கண்டு அளவிட முடியும், இது வேகக் குறைபாடுகளைக் கண்டறிய மிகவும் ஏற்றது.
முதலில் மிக எளிய படிநிலையை நாங்கள் சோதிக்க வேண்டும் என்று கருதினோம் – பல கூறுகள் மற்றும் வரிசைகளின் மீது எங்கள் மவுஸை நகர்த்துவது. எளிதானதுதானே? இவ்வளவு எளிய விஷயத்தில் நாங்கள் செயல்திறன் சிக்கல்களைச் சந்திக்க மாட்டோம் என்பதில் நம்பிக்கையுடன் இருந்தோம். துரதிர்ஷ்டவசமாக, நாங்கள் தவறாக நினைத்துவிட்டோம்.
பதிவு செய்யும் பட்டனை (record button) அழுத்தியதும், திரையில் சுமார் 2 வினாடிகள் மவுஸை நகர்த்திவிட்டு, பின் நிறுத்துவதற்கான பட்டனை (stop button) அழுத்தினோம். இதோ ப்ரோஃபைலரிலிருந்து பெறப்பட்ட டைம்லைன்:
ஆச்சரியம் என்னவென்றால், இதில் செயல்திறன் தடைகள் நிரம்பி வழிந்தன!
வரைபடத்தில் நிறைய விஷயங்கள் நடக்கின்றன, ஆனால் மிக வெளிப்படையான பிரச்சனை என்னவென்றால், அதில் ஊதா நிறப் பகுதிகள் அதிகமாக உள்ளன (அப்படி இருக்கக்கூடாது). அதோடு, இந்த ஊதா நிறப் பகுதிகள் பார்வைக்கே மிகவும் அகலமாக இருப்பதோடு, அனைத்தும் வரைபடத்தின் உச்சத்தைத் தொடுவது போல் தோன்றுகின்றன. வரைபடம் எப்போதும் நிரம்பியிருப்பதையும், ஊதா நிறப் பகுதிகள் ஒருபோதும் பூஜ்ஜியத்திற்குக் குறையாமல் இருப்பதையும் நீங்கள் கவனிக்கலாம். உலாவி எப்போதும் எதையாவது செய்வதில் பிஸியாக இருப்பது போலவும், ஒருபோதும் ஓய்வெடுக்காதது போலவும் தோன்றுகிறது.
ஆனால் அந்த ஊதா நிறப் பகுதிகள் அனைத்தும் உண்மையில் எதைக் குறிக்கின்றன?
அவை reflows என்று அழைக்கப்படுகின்றன என்பதை ப்ரோஃபைலர் எங்களுக்குத் தெளிவுபடுத்தியது. Google Developer தளத்திலிருந்து:
Reflow என்பது ஆவணத்திலுள்ள கூறுகளின் நிலைகள் மற்றும் வடிவவியலை மறு கணக்கீடு செய்வதற்கான வலை உலாவி செயல்முறையின் பெயராகும்.. reflow என்பது உலாவியில் பயனரைத் தடுக்கும் (user-blocking) ஒரு செயல்பாடாகும்.
ஆகவே, PBS-இல் உங்கள் மவுஸை நகர்த்துவது அதிகளவிலான reflow-களைத் தூண்டுகிறது என்பதை இது குறிக்கிறது. இதில் இன்னும் மோசமான விஷயம் என்னவென்றால், ஒவ்வொரு reflow-வும் தன் கணக்கீடுகளை முடிப்பதற்காக உலாவியை ஒரு கணம் இடைநிறுத்துகிறது. அதிக reflow-கள் என்றால் உலாவியில் அதிக இடைநிறுத்தங்கள் ஏற்படும், மேலும் அனுபவம் இன்னும் அதிக தடங்கலாக (janky) மாறும். எளிமையாகச் சொன்னால், நிறைய ஊதா பகுதிகள் = மோசம்.
எனவே ஆன் கூறியது சரிதான் என்பது உறுதியானது: எங்களிடம் மிகப்பெரிய செயல்திறன் குறைபாடு உண்மையிலேயே இருந்தது, எனவே எங்கள் குழு உடனடியாக அதைச் சரிசெய்வதற்கான பணிகளில் இறங்கியது.
எங்கள் Reflow / Jank பிரச்சனையைச் சரிசெய்தல்
எல்லாவற்றிற்கும் மேலாக, முதலில் இந்த reflow ஏற்பட என்ன காரணம் என்பதைக் கண்டறிய நாங்கள் சில ஆராய்ச்சிகளைச் செய்ய வேண்டியிருந்தது. ஜாவாஸ்கிரிப்டில் உள்ள பல பொதுவான விஷயங்கள் உலாவியில் reflow ஏற்படத் தூண்டக்கூடும் என்பதை நாங்கள் கண்டறிந்தோம்.
DOM கூறுகளின் அகலம், உயரம் அல்லது நிலையைப் பெற நீங்கள் பயன்படுத்தக்கூடிய எந்தவொரு சார்பும் (function) ஒரு reflow-வைத் தூண்டக்கூடும். இதைச் செய்யக்கூடிய ஜாவாஸ்கிரிப்டில் உள்ள அனைத்து பண்புகள் மற்றும் சார்புகளின் விரிவான பட்டியலை பால் ஐரிஷ் (Paul Irish) எழுதியுள்ளார். கெட்ட செய்தி என்னவென்றால், Page Builder Sandwich இந்த பண்புகள் மற்றும் சார்புகளில் பலவற்றைப் பயன்படுத்துகிறது, அவை அனைத்தும் reflow-வை ஏற்படுத்துகின்றன:
- elem.getBoundingClientRect()
- window.getComputedStyle()
- window.scrollY
- மற்றும் பல…
தீர்வு #1: அதிக வளம் எடுக்கும் Reflow செயல்முறைகளை கேச் (Cache) செய்தல்
அந்த பண்புகள் மற்றும் சார்புகளைப் பயன்படுத்தாமல் இருப்பதே மிக வெளிப்படையான தீர்வாகும். இருப்பினும், PBS அவற்றை பெரிதும் நம்பியுள்ளது, அவை இல்லாமல் எங்களால் செயல்பட முடியாது.
அந்த சார்புகளுக்கான அழைப்புகளை முடிந்தவரை குறைப்பதே எங்களுக்கு எஞ்சியிருந்த தீர்வாகும். இதில் கடினமான பகுதி என்னவென்றால், PBS-இன் பல்வேறு பகுதிகளில் அந்த பண்புகளையும் சார்புகளையும் நாங்கள் பல முறை பயன்படுத்தினோம், மேலும் பெரும்பாலான நேரங்களில் ஒரே DOM கூறின் மீது அவற்றை பலமுறை பயன்படுத்தினோம். இதைச் சரிசெய்ய, சிக்கல் நிறைந்த ஒவ்வொரு பண்பு/சார்புக்கும் எங்கள் சொந்த கேச்சிங் அமைப்பை உருவாக்கினோம்.
உதாரணமாக, getBoundingClientRect சார்பானது DOM கூறின் தற்போதைய top, left, width, height, right மற்றும் bottom பிக்சல் அளவீடுகளை நமக்கு வழங்குகிறது. PBS-இல் கூறுகளின் வெளிப்புறக் கோடுகளை எங்கு வரைய வேண்டும் என்பதைக் கணக்கிட நாங்கள் இந்த சார்பை எப்போதும் பயன்படுத்துகிறோம். இதற்காக நாங்கள் உருவாக்கிய கேச்சிங் சார்பு இதோ:
// Cache: எங்கள் client rects இங்கே வைக்கப்பட்டுள்ளன, பின்னர் இவற்றை அழிக்க இதைப் பயன்படுத்தலாம்.
var elemsWithBoundingRects = [];
window.pbsGetBoundingClientRect = function( element ) {
// இதற்கு முன் client rect-ஐ ஏற்கனவே பெற்றுள்ளோமா என்பதைச் சரிபார்க்கவும்.
if ( ! element._boundingClientRect ) {
// இல்லையெனில், அதைப் பெற்று எதிர்காலப் பயன்பாட்டிற்காகச் சேமிக்கவும்.
element._boundingClientRect = element.getBoundingClientRect();
elemsWithBoundingRects.push( element );
}
return element._boundingClientRect;
};
getBoundingClientRect-ஐ அழைப்பதற்குப் பதிலாக, இப்போது நாங்கள் pbsGetBoundingClientRect-ஐப் பயன்படுத்தினோம். இப்போது ஒவ்வொரு முறையும் client rect வினவப்படும் போது, எதிர்காலப் பயன்பாட்டிற்காக அந்த மதிப்பைச் சேமித்து வைக்கிறோம், இதன் மூலம் reflow தூண்டல்களின் எண்ணிக்கையைக் கட்டுப்படுத்துகிறோம்.
சேமிக்கப்பட்ட client rects செல்லுபடியாகாமல் போகும்போது கேச்சை அழிப்பதற்கான ஒரு வழியும் எங்களுக்குத் தேவைப்பட்டது. பயனர் பக்கத்தை உருட்டும் போதோ அல்லது திரையில் கூறுகளைச் சேர்க்கும் போதோ/மாற்றும் போதோ/நீக்கும் போதோ சேமிக்கப்பட்ட 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-ஐப் பயன்படுத்தி Read & Write-களை ஒன்றாகக் குழுவாக்குதல்
தீர்வு #1-ஐ செயல்படுத்தியது PBS-இன் செயல்திறனை அதிகரித்தது, ஆனால் அது போதுமானதாக இல்லை.
மேலும் கூகுளில் தேடியபோது, ‘layout thrashing’ ஐத் தடுப்பது குறித்து வில்சன் பேஜ் (Wilson Page) எழுதிய ஒரு கட்டுரையைக் கண்டோம். வில்சன் கூறுகிறார்:
Layout Thrashing (reflow) occurs when JavaScript violently writes, then reads, from the DOM, multiple times causing document reflows.
குறிப்பிட்ட reflow-தூண்டும் பண்புகள் மற்றும் சார்புகளுக்கான உங்கள் அழைப்புகளைக் கட்டுப்படுத்துவது மட்டுமே போதாது என்பது தெளிவாகிறது. DOM-இல் தொடர்ந்து பல முறை “reads” மற்றும் “writes” செய்யும்போது, அது உலாவியின் reflow-வையும் தூண்டுகிறது. வில்சனின் தளத்திலிருந்து நேரடியாக ஒரு பொதுவான சூழல் இதோ:
// Read
var h1 = element1.clientHeight;
// Write (அமைப்பைச் செல்லாததாக்குகிறது)
element1.style.height = (h1 * 2) + 'px';
// Read (reflow-வைத் தூண்டுகிறது)
var h2 = element2.clientHeight;
// Write (அமைப்பைச் செல்லாததாக்குகிறது)
element2.style.height = (h2 * 2) + 'px';
// Read (reflow-வைத் தூண்டுகிறது)
var h3 = element3.clientHeight;
// Write (அமைப்பைச் செல்லாததாக்குகிறது)
element3.style.height = (h3 * 2) + 'px';
// Document reflows at end of frame
மேலே உள்ள எடுத்துக்காட்டு 3 reflow-களைத் தூண்டுகிறது, ஏனெனில் ஒரு write-க்குப் பிறகு முழுப் பக்கத்தின் பரிமாணங்களும் செல்லாததாகிவிடுகின்றன. இதற்குப் பரிந்துரைக்கப்பட்ட தீர்வு என்னவென்றால், அனைத்து read மற்றும் write-களையும் ஒன்றாக இணைக்கும் வகையில் குறியீட்டை மறுவரிசைப்படுத்துவதாகும், இதனால் முழு விஷயமும் 1 உலாவி reflow-வை மட்டுமே தூண்டும்:
// Read
var h1 = element1.clientHeight;
var h2 = element2.clientHeight;
var h3 = element3.clientHeight;
// Write (அமைப்பைச் செல்லாததாக்குகிறது)
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-இல் reflow-வை ஏற்படுத்தும் விஷயங்களைப் படிப்பதும் எழுதுவதும் அதன் வாழ்க்கைச் சுழற்சியின் போது பல இடங்களில் வெவ்வேறு நேரங்களில் நிகழ்கிறது. ஆயிரக்கணக்கான வரிகள் கொண்ட ஜாவாஸ்கிரிப்ட் குறியீட்டை மறுசீரமைப்பது சாத்தியமில்லை.
அதிர்ஷ்டவசமாக, வில்சன் தனது கட்டுரையில் ஒரு தீர்வையும் வழங்கியிருந்தார். அந்த read மற்றும் write-களை ஒன்றாக இணைக்க உதவும் ஒரு சிறிய பயன்பாட்டுக் குறியீட்டை அவர் உருவாக்கினார், அது FastDom என்று அழைக்கப்படுகிறது.
FastDom-ஐப் பயன்படுத்தும் மற்றும் மேலே உள்ள எங்கள் தீர்வு #1-ஐயும் உள்ளடக்கிய Page Builder Sandwich-இன் சில குறியீடுகள் இதோ:
// பிற திரட்களிலிருந்து வரும் reads-ஐ ஒன்றாக இணைக்கவும்.
fastdom.measure( function() {
// எங்கள் கேச் செய்யப்பட்ட client rect-ஐப் பயன்படுத்தவும்.
var rect = window.pbsGetBoundingClientRect( elem );
// பிற திரட்களிலிருந்து வரும் writes-ஐ ஒன்றாக இணைக்கவும்.
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 அழைப்புகளையும் ஒன்றாகக் குழுவாக்கி, அவற்றை ஒத்திசைவற்ற முறையில் இயக்குகிறது, இதன் மூலம் உலாவியில் உள்ள அனைத்து reflow-களையும் குறைக்க அனைத்து read மற்றும் write-களையும் திறம்பட ஒன்றாகக் குழுவாக்குகிறது.
தீர்வு #3: ஸ்டைல் ஆப்ஜெக்ட்களை அணுகுவது அதிக வளம் எடுக்கும் செயல்
jsPerf உதவியுடன் சில ஸ்டைல்-பெறும் சார்புகள் மற்றவற்றை விட வேகமாக இருப்பதையும் நாங்கள் கண்டறிந்தோம்.
PBS-இல், ஒரு கூறின் குறிப்பிட்ட ஸ்டைலின் தற்போதைய மதிப்பை நாம் வழக்கமாகப் பெற வேண்டும். உதாரணமாக, மேல் விளிம்பைப் பெற பொதுவாக இதைப் பயன்படுத்துகிறோம்:
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 திருத்தங்களுக்கு நிறைய ஆராய்ச்சி, சோதனை மற்றும் உண்மையான செயலாக்கம் தேவைப்பட்டது (மேலும் எங்கள் எழுத்துருக்கள் அம்சம் வெளியாவதையும் தாமதப்படுத்தியது), ஆனால் இறுதியில் அதற்கான பலன் கிடைத்தது.
திரையில் மவுஸை 2 வினாடிகள் நகர்த்தும் எங்கள் ஆரம்ப சோதனைக்குத் திரும்புவோம். இதோ பழைய தடங்கலான டைம்லைன்:
செயல்திறன் மேம்பாடுகளுக்குப் பிறகு எங்கள் புதிய டைம்லைன் எவ்வாறு காட்சியளிக்கிறது என்பது இதோ:
நீங்கள் பார்க்க முடியும் படி, வரைபடத்தில் ஊதா நிற விஷயங்கள் குறைவாக உள்ளன. மேலும் உலாவி மூலம் செயல்படுத்தப்படும் செயல்முறைகளின் அளவில் குறிப்பிடத்தக்க வேறுபாடு உள்ளது. கீழே உள்ள செவ்வகப் பகுதிகள் மெல்லியதாகவும் உள்ளன, அதாவது செயல்முறைகள் முன்பை விட வேகமாக இயக்கப்படுகின்றன என்பதைக் குறிக்கிறது.
பழைய மற்றும் புதிய வரைபடங்களில் உள்ள உயரமான/அகலமான ஊதா நிறப் பகுதிகளின் அளவை ஒப்பிட்டுப் பார்த்தால், நாம் மிகப்பெரிய அளவில் 200% செயல்திறன் அதிகரிப்பைக் காண்கிறோம்! அனைத்துப் பிரிவுகளிலும் செயல்திறன் அதிகரிப்பதை நாங்கள் காண்கிறோம். இது நிச்சயமாக மோசம் இல்லை!
முக்கிய படிப்பினைகள் மற்றும் கற்றல்கள்
நேர்மையாகச் சொல்வதானால், ஆன் இதைக் குறிப்பிடுவதற்கு முன்பு PBS-இல் செயல்திறன் சிக்கல்கள் இருப்பதாக நாங்கள் நினைக்கவில்லை. முக்கியமாக நாங்கள் மென்பொருள் மேம்பாட்டு சார்ந்த கணினிகளைப் பயன்படுத்தியதால் செயல்திறன் தடைகள் அவ்வளவு தெளிவாகத் தெரியவில்லை. திரும்பிப் பார்க்கும்போது, செயல்திறனைச் சரிபார்ப்பது முதன்மையான முன்னுரிமைகளில் ஒன்றாக இருந்திருக்க வேண்டும். ஆனால் இப்போது பதிப்பு 4.3-இல் இது சரிசெய்யப்பட்டுள்ளது. 
தங்களுடைய வேர்ட்பிரஸ் செருகுநிரலின் செயல்திறனை மேம்படுத்த விரும்புவோருக்கு, குறிப்பாக நீங்களும் அதிக ஜாவாஸ்கிரிப்டைப் பயன்படுத்துகிறீர்கள் என்றால், இந்த அனுபவத்திலிருந்து நான் கற்றுக்கொண்ட முக்கிய விஷயங்கள் இதோ:
- Reflow-வை தூண்டும் பண்புகள்/சார்புகளுக்கான உங்கள் அழைப்புகளைக் கட்டுப்படுத்துங்கள்/கேச் செய்யுங்கள். இதற்கு ஒரு வழிகாட்டியாக இதைப் பயன்படுத்தவும்: What forces layout/reflow. The comprehensive list.
- DOM ஸ்டைல்களுக்கான “reads” மற்றும் “writes”-ஐ ஒன்றாகக் குழுவாக்குங்கள். உங்களுக்காக இதைச் செய்ய FastDom-ஐப் பயன்படுத்துங்கள்.
- குரோமின் டைம்லைன் ப்ரோஃபைலரைப் பயன்படுத்துங்கள், மேலும் முடிந்தவரை குறைவான reflows (ஊதா நிறப் பகுதிகள்) இருப்பதை உறுதிப்படுத்திக் கொள்ளுங்கள்.
Another thing you’ll find handy when using Page Builder Sandwich is our Shortcode Mapping feature.
And then, to actually add the shortcode, I’ll just go to my page, and drag and drop the Shortcode Element:
Because we already have WooCommerce installed on our WordPress site, you can see that all of the shortcodes that are available on the WooCommerce plugin are already available on Page Builder Sandwich. This is what Shortcode Mapping is.
சந்தையில் பல டஜன் கணக்கிலான பேஜ் பில்டர்கள் உள்ளன, மேலும் நீங்கள் உங்களை நீங்களே கேட்டுக்கொள்ளலாம்: 
ஆச்சரியம் என்னவென்றால், இதில் செயல்திறன் தடைகள் நிரம்பி வழிந்தன!
நீங்கள் பார்க்க முடியும் படி, வரைபடத்தில் ஊதா நிற விஷயங்கள் குறைவாக உள்ளன. மேலும் உலாவி மூலம் செயல்படுத்தப்படும் செயல்முறைகளின் அளவில் குறிப்பிடத்தக்க வேறுபாடு உள்ளது. கீழே உள்ள செவ்வகப் பகுதிகள் மெல்லியதாகவும் உள்ளன, அதாவது செயல்முறைகள் முன்பை விட வேகமாக இயக்கப்படுகின்றன என்பதைக் குறிக்கிறது.
