កាលពីថ្ងៃទី ២ ខែកុម្ភៈ ឆ្នាំ ២០១៧ កន្លងទៅ Ann Taylor បានសរសេរអត្ថបទ 12 Things We Need to See From WordPress Page Builders in 2017 + Who Already Gets It Right នៅលើ CodeInWP។ យើងបានបន្តកែលម្អ Page Builder Sandwich ឥតឈប់ឈរអស់រយៈពេលជាងមួយឆ្នាំមកហើយ៖ យើងធ្វើការស្រាវជ្រាវ ស្តាប់មតិអតិថិជនរបស់យើង ដូច្នេះយើងគិតថា Page Builder Sandwich នឹងមានវត្តមាននៅក្នុងអត្ថបទ “Who Got it Right” របស់ CodeInWP។ ប៉ុន្តែយើងមិនបានជាប់នោះទេ ដោយសារតែបញ្ហាដំណើរការ (performance)។ 
ដូច្នេះហើយ យើងក៏បានសួរ Ann អំពីរឿងនេះ ហើយគាត់បានឆ្លើយតបមកវិញថា៖
…ខ្ញុំបានសាកល្បងប្រើប្រាស់កំណែឥតគិតថ្លៃបន្តិចបន្តួច។ វាបង្ហាញពីសក្តានុពលជាច្រើន៖ មានម៉ូឌុលច្រើន, ចំណុចប្រទាក់អ្នកប្រើ (UI) ងាយយល់, បទពិសោធន៍ WYSIWYG ដ៏អស្ចារ្យ, អ្វីៗគ្រប់យ៉ាងងាយស្រួលអូសទាញ។ ទោះជាយ៉ាងណាក៏ដោយ នៅពេលខ្ញុំដាក់ម៉ូឌុលប្រហែល ១០ នៅលើទំព័រ វាចាប់ផ្តើមពិបាកក្នុងការបន្តធ្វើការជាមួយវា ដោយសារតែល្បឿននៃការកែសម្រួលមានភាពយឺតយ៉ាវ…
យោងតាមការលើកឡើងរបស់គាត់ Page Builder Sandwich មានបញ្ហាដំណើរការ។ ហើយដោយសារតែយើងតែងតែស្តាប់មតិកែលម្អ យើងក៏បានពិនិត្យមើលបញ្ហានេះ។
ការធ្វើតេស្តដំណើរការ (Performance)
យើងត្រូវការវិធីសាស្ត្រមួយដើម្បីពិនិត្យមើលដំណើរការរបស់ PBS; ដោយសារ PBS ភាគច្រើនដំណើរការលើកម្មវិធីរុករក (browser) តាមរយៈ Javascript, Chrome’s Timeline profiler គឺជាឧបករណ៍ដ៏ត្រឹមត្រូវបំផុតសម្រាប់ការងារនេះ។ Timeline profiler អាចកំណត់អត្តសញ្ញាណ និងវាស់វែងដំណើរការផ្សេងៗដែលកំពុងកើតឡើងនៅក្នុងទំព័របណ្តាញអំឡុងពេល runtime ដែលល្អឥតខ្ចោះសម្រាប់ការស្វែងរកចំណុចស្ទះល្បឿន (bottlenecks)។
យើងគិតថាយើងគួរតែសាកល្បងជំហានដែលសាមញ្ញបំផុតជាមុនសិន – គឺការអូសកណ្តុររបស់យើងកាត់ធាតុ (elements) និងជួរដេក (rows) ជាច្រើន។ សាមញ្ញមែនទេ? យើងមានទំនុកចិត្តថាយើងនឹងមិនជួបបញ្ហាដំណើរការជាមួយនឹងអ្វីដែលសាមញ្ញបែបនេះឡើយ។ ជាអកុសល យើងបានគិតខុស។
នៅពេលដែលយើងចុចប៊ូតុងថត (record) យើងបានរំកិលកណ្តុរប្រហែល ២ វិនាទីនៅលើអេក្រង់ បន្ទាប់មកចុចប៊ូតុងបញ្ឈប់ (stop)។ នេះគឺជាលទ្ធផល timeline ពី profiler៖
មើលចុះ! វាពោរពេញទៅដោយចំណុចស្ទះដំណើរការយ៉ាងច្រើនសន្ធឹកសន្ធាប់!
មានរឿងរ៉ាវជាច្រើនបានកើតឡើងនៅក្នុងក្រាហ្វ ប៉ុន្តែបញ្ហាដែលច្បាស់បំផុតគឺមានផ្ទៃពណ៌ស្វាយជាច្រើននៅក្នុងនោះ (ដែលមិនគួរមានបែបនេះទេ)។ លើសពីនេះ ផ្ទៃពណ៌ស្វាយទាំងនេះមានទំហំធំទូលាយយ៉ាងច្បាស់ ហើយហាក់ដូចជាឡើងដល់ចំណុចកំពូលនៃក្រាហ្វទាំងអស់។ អ្នកក៏នឹងកត់សម្គាល់ឃើញផងដែរថាក្រាហ្វតែងតែពេញជានិច្ច ហើយផ្ទៃពណ៌ស្វាយស្ទើរតែមិនដែលធ្លាក់ចុះដល់សូន្យឡើយ។ វាហាក់ដូចជា browser កំពុងរវល់ធ្វើអ្វីមួយជានិច្ច ហើយស្ទើរតែមិនដែលសម្រាកសោះ។
ប៉ុន្តែតើផ្ទៃពណ៌ស្វាយទាំងអស់នោះមានន័យយ៉ាងណាឱ្យប្រាកដ?
Profiler បានបង្ហាញប្រាប់យើងយ៉ាងច្បាស់ថាពួកវាត្រូវបានគេហៅថា reflows។ នេះជានិយមន័យនៃ reflow ពីគេហទំព័រ Google Developer:
Reflow គឺជាឈ្មោះនៃដំណើរការរបស់ web browser សម្រាប់ការគណនាឡើងវិញនូវទីតាំង និងធរណីមាត្រនៃធាតុនានានៅក្នុងឯកសារ (document).. reflow គឺជាប្រតិបត្តិការដែលរារាំងអ្នកប្រើប្រាស់ (user-blocking operation) នៅក្នុង browser។
ដូច្នេះនេះមានន័យថា ការរំកិលកណ្តុររបស់អ្នកចុះឡើងនៅក្នុង PBS នឹងបង្កឱ្យមាន reflows រាប់មិនអស់។ អ្វីដែលកាន់តែអាក្រក់នោះគឺ reflow នីមួយៗបានផ្អាក browser មួយភ្លែត ដើម្បីឱ្យវាអាចបញ្ចប់ការគណនារបស់វា។ Reflows កាន់តែច្រើន មានន័យថា browser កាន់តែផ្អាកច្រើន ហើយបទពិសោធន៍ប្រើប្រាស់កាន់តែទាក់ៗ (janky) ខ្លាំងឡើង។ និយាយឱ្យងាយយល់ ផ្ទៃពណ៌ស្វាយច្រើន = មិនល្អ។
ដូច្នេះ វាបានបង្ហាញថា Ann និយាយត្រូវ៖ យើងពិតជាមានចំណុចស្ទះដំណើរការដ៏ធំមួយ ដូច្នេះក្រុមការងាររបស់យើងបានចាប់ផ្តើមធ្វើការភ្លាមៗដើម្បីដោះស្រាយវា។
ការដោះស្រាយបញ្ហា Reflow / Jank របស់យើង
មុននឹងធ្វើអ្វីផ្សេងទៀត យើងត្រូវធ្វើការស្រាវជ្រាវមួយចំនួនដើម្បីស្វែងយល់ថាតើអ្វីទៅដែលបណ្តាលឱ្យមាន reflow នេះតាំងពីដំបូង។ យើងបានរកឃើញថាជាក់ស្តែង រឿងសាមញ្ញជាច្រើននៅក្នុង Javascript អាចជំរុញឱ្យ browser បង្កជា reflow បាន។
ស្ទើរតែគ្រប់ function ដែលអ្នកអាចប្រើដើម្បីទទួលបានប្រវែងទទឹង (width) កម្ពស់ (height) ឬទីតាំង (position) នៃធាតុ DOM អាចបង្កឱ្យមាន reflow។ Paul Irish បានសរសេរបញ្ជីលម្អិតមួយ អំពី properties និង functions ទាំងអស់នៅក្នុង Javascript ដែលអាចបង្កឱ្យមានរឿងនេះ។ ដំណឹងមិនល្អនោះគឺថា Page Builder Sandwich ប្រើប្រាស់ properties និង functions ទាំងនេះជាច្រើន ដែលសុទ្ធតែបណ្តាលឱ្យមាន reflow៖
- elem.getBoundingClientRect()
- window.getComputedStyle()
- window.scrollY
- និងជាច្រើនទៀត…
ដំណោះស្រាយទី ១៖ ការរក្សាទុក Cache សម្រាប់ដំណើរការ Reflow ដែលចំណាយធនធានខ្ពស់
ដំណោះស្រាយដែលច្បាស់បំផុតគឺកុំប្រើប្រាស់ properties និង functions ទាំងនោះ។ ទោះជាយ៉ាងណាក៏ដោយ PBS ពឹងផ្អែកយ៉ាងខ្លាំងលើពួកវា ហើយយើងមិនអាចខ្វះពួកវាបានឡើយ។
ដំណោះស្រាយដែលយើងនៅសល់គឺកាត់បន្ថយការហៅប្រើ (calls) functions ទាំងនោះឱ្យបានច្រើនតាមដែលអាចធ្វើទៅបាន។ ចំណុចពិបាកនៅទីនេះគឺថាយើងបានប្រើប្រាស់ properties និង functions ទាំងនោះច្រើនដងនៅតាមផ្នែកផ្សេងៗគ្នានៃ PBS ហើយភាគច្រើន យើងបានប្រើប្រាស់វាលើធាតុ DOM ដូចគ្នាច្រើនដង។ ដើម្បីដោះស្រាយបញ្ហានេះ យើងបានបង្កើតយន្តការ caching ផ្ទាល់ខ្លួនរបស់យើងសម្រាប់ property/function ដែលមានបញ្ហានីមួយៗ។
ឧទាហរណ៍ function getBoundingClientRect ផ្តល់ឱ្យយើងនូវទំហំរង្វាស់ជា pixel ជាក់ស្តែងនៃ top, left, width, height, right, និង bottom នៃធាតុ DOM មួយ។ យើងប្រើ function នេះគ្រប់ពេលវេលាដើម្បីគណនាទីតាំងដែលត្រូវគូសបន្ទាត់គ្រោងធាតុ (element outlines) នៅក្នុង PBS។ នេះជា function សម្រាប់ caching ដែលយើងបានបង្កើតឡើងសម្រាប់រឿងនេះ៖
// 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 ត្រូវបានសាកសួរ (queried) យើងរក្សាទុកតម្លៃនោះសម្រាប់ការប្រើប្រាស់នៅពេលក្រោយ ដូច្នេះហើយវាជួយកាត់បន្ថយចំនួននៃការកកើត reflow។
យើងក៏ត្រូវការវិធីមួយដើម្បីសម្អាត cache ផងដែរ នៅពេលដែល client rects ដែលបានរក្សាទុកលែងមានសុពលភាព។ តម្លៃនៃ client rect ដែលបានរក្សាទុកមានការផ្លាស់ប្តូរនៅពេលដែលអ្នកប្រើប្រាស់ scroll ទំព័រ ឬបន្ថែម/ផ្លាស់ប្តូរ/លុបធាតុនៅលើអេក្រង់។ ដូច្នេះយើងបានបង្កើត function សម្អាត cache មួយដែលយើងអាចហៅប្រើនៅពេលណាដែលយើងត្រូវការតម្លៃ client rect ថ្មី៖
var clearClientRects = function() {
var i;
for ( i = 0; i < elemsWithBoundingRects.length; i++ ) {
if ( elemsWithBoundingRects[ i ] ) {
elemsWithBoundingRects[ i ]._boundingClientRect = null;
}
}
elemsWithBoundingRects = [];
};
យើងក៏បានអនុវត្តយន្តការ caching ដូចគ្នានេះផងដែរសម្រាប់ការហៅប្រើ functions ផ្សេងទៀតដែលស៊ីធនធានច្រើន ដែលយើងតែងតែប្រើជាញឹកញាប់។
ដំណោះស្រាយទី ២៖ ការដាក់ជាក្រុមរវាង Reads & Writes ដោយប្រើប្រាស់ FastDom
ការអនុវត្តដំណោះស្រាយទី ១ បានបង្កើនដំណើរការរបស់ PBS ប៉ុន្តែវានៅមិនទាន់គ្រប់គ្រាន់នៅឡើយទេ។
តាមរយៈការស្វែងរកបន្ថែមលើ Google យើងបានជួបប្រទះអត្ថបទមួយរបស់ Wilson Page ស្តីអំពី Preventing ‘layout thrashing’។ Wilson បាននិយាយថា៖
Layout Thrashing (reflow) កើតឡើងនៅពេលដែល JavaScript សរសេរ (writes) យ៉ាងគំហុក រួចអាន (reads) ពី DOM ច្រើនដង ដែលបណ្តាលឱ្យមាន document reflows។
ជាក់ស្តែង វាមិនគ្រប់គ្រាន់ទេក្នុងការកំណត់ការហៅប្រើប្រាស់ properties និង functions ជាក់លាក់ដែលបង្កឱ្យមាន reflow។ នៅពេលដែលអ្នកដំណើរការ “reads” និង “writes” បន្តបន្ទាប់គ្នាជាច្រើនដងនៅលើ DOM វាក៏បង្កឱ្យមាន browser reflow ផងដែរ។ នេះជាស្ថានភាពទូទៅមួយ ដែលដកស្រង់ចេញពីគេហទំព័ររបស់ Wilson ដោយផ្ទាល់៖
// 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
ឧទាហរណ៍ខាងលើបង្កឱ្យមាន reflow ចំនួន ៣ ដង ពីព្រោះវិមាត្រនៃទំព័រទាំងមូលត្រូវបាត់បង់សុពលភាពបន្ទាប់ពីមានការសរសេរ (write)។ ដំណោះស្រាយដែលត្រូវបានណែនាំសម្រាប់បញ្ហានេះគឺត្រូវរៀបចំកូដឡើងវិញដើម្បីប្រមូលផ្តុំរាល់ reads និង writes ទាំងអស់ជាមួយគ្នា ដើម្បីឱ្យដំណើរការទាំងមូលបង្កឱ្យមាន browser reflow តែ ១ ដងប៉ុណ្ណោះ៖
// 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 ការអាន និងសរសេរអ្វីៗដែលបង្កឱ្យមាន reflow កើតឡើងនៅកន្លែងខុសៗគ្នាជាច្រើន និងនៅពេលវេលាផ្សេងៗគ្នាជាច្រើនក្នុងអំឡុងពេលនៃដំណើរការរបស់ PBS។ ការរៀបចំកូដ Javascript រាប់ពាន់បន្ទាត់ឡើងវិញ មិនមែនជារឿងដែលអាចធ្វើទៅបាននោះទេ។
សំណាងល្អសម្រាប់យើង Wilson ក៏បានផ្តល់នូវដំណោះស្រាយមួយនៅក្នុងអត្ថបទរបស់គាត់ផងដែរ។ គាត់បានបង្កើត utility script តូចមួយដើម្បីជួយប្រមូលផ្តុំ reads និង writes ទាំងនោះជាមួយគ្នា ដែលមានឈ្មោះថា FastDom។
នេះជាកូដមួយចំនួនពី Page Builder Sandwich ដែលប្រើប្រាស់ FastDom ហើយក៏រួមបញ្ចូលទាំងដំណោះស្រាយទី ១ របស់យើងខាងលើផងដែរ៖
// 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 ទាំងអស់ ហើយដំណើរការពួកវាដោយអសមកាល (asynchronously) ដែលជាការប្រមូលផ្តុំរាល់ reads និង writes ទាំងអស់ជាមួយគ្នាប្រកបដោយប្រសិទ្ធភាព ដើម្បីកាត់បន្ថយ reflows ទាំងអស់នៅក្នុង browser។
ដំណោះស្រាយទី ៣៖ ការចូលប្រើប្រាស់ Style Objects ស៊ីធនធានច្រើន
យើងក៏បានរកឃើញផងដែរ ដោយមានជំនួយពី jsPerf ថា functions មួយចំនួនដែលទាញយក style ដំណើរការលឿនជាង functions ផ្សេងទៀត។
នៅក្នុង PBS ជាធម្មតាយើងត្រូវការទាញយកតម្លៃបច្ចុប្បន្ននៃ style ជាក់លាក់ណាមួយរបស់ធាតុ។ ឧទាហរណ៍ ជាធម្មតាយើងប្រើកូដនេះដើម្បីទទួលបាន top margin៖
var styles = window.getComputedStyle( elem );
var marginTop = styles.marginTop;
ប៉ុន្តែ យើងបានរកឃើញថាការធ្វើបែបនេះគឺលឿនជាងឆ្ងាយណាស់៖
var marginTop = elem.style.marginTop;
ទោះជាយ៉ាងណាក៏ដោយ elem.style.marginTop និង getComputedStyle មានភាពខុសគ្នាខ្លាំងណាស់។ វិធីទីមួយផ្តល់ឱ្យយើងតែ inline styling នៃធាតុប៉ុណ្ណោះ ហើយមិនគិតបញ្ចូល stylesheets ណាមួយឡើយ; ចំណែកវិធីទីពីរ គិតបញ្ចូលទាំង inline styles និង stylesheets។
លើសពីនេះទៅទៀត ទោះបីជាលទ្ធផល getComputedStyle ត្រូវបាន cached ក៏ដោយ ក៏វានៅតែដំណើរការយឺតខ្លាំងដដែល។ តាមពិតទៅ ការចូលទៅកាន់ style object ផ្ទាល់តែម្តង គឺជាដំណើរការដ៏យឺតយ៉ាវ។
ជាសំណាងល្អសម្រាប់យើង PBS ភ្ជាប់បន្ថែម inline styles ទៅកាន់ធាតុនានា ហើយដោយសារ inline styles មានអាទិភាពខ្ពស់ជាង (ភាគច្រើន) stylesheets ដូច្នេះវានឹងមានករណីខ្លះដែលការទាញយកតម្លៃ inline style គឺគ្រប់គ្រាន់ហើយ។ ដូច្នេះប្រសិនបើយើងបញ្ចូលវិធីសាស្រ្តទាំងពីរខាងលើចូលគ្នា យើងអាចបង្កើតកូដដែលដំណើរការបានលឿនជាងមុនយ៉ាងខ្លាំង៖
var marginTop = elem.style.marginTop;
if ( ! marginTop ) {
var styles = window.getComputedStyle( elem );
marginTop = styles.marginTop;
}
លទ្ធផលនៃការកែលម្អកូដ
ដំណោះស្រាយទាំង ៣ របស់យើងខាងលើបានចំណាយពេលស្រាវជ្រាវ ធ្វើតេស្ត និងការអនុវត្តជាក់ស្តែងយ៉ាងច្រើន (ហើយបានពន្យារពេលមុខងារ Fonts របស់យើងមិនឱ្យចេញផ្សាយទាន់ពេល) ប៉ុន្តែនៅទីបំផុត អ្វីៗគ្រប់យ៉ាងគឺពិតជាមានតម្លៃខ្លាំងណាស់។
ត្រលប់ទៅការធ្វើតេស្តដំបូងរបស់យើងនៃការរំកិលកណ្តុររបស់អ្នកកាត់អេក្រង់រយៈពេល ២ វិនាទី។ នេះជា timeline ចាស់ដែលអាក្រក់/ទាក់ៗ៖
ហើយនេះជារូបរាង timeline ថ្មីរបស់យើងបន្ទាប់ពីការកែលម្អដំណើរការ៖
ដូចដែលអ្នកអាចមើលឃើញ មានផ្ទៃពណ៌ស្វាយតិចជាងមុននៅក្នុងក្រាហ្វ។ ហើយមានភាពខុសគ្នាយ៉ាងច្បាស់ទៅលើបរិមាណនៃដំណើរការដែលត្រូវបានអនុវត្តដោយ browser។ រូបរាងចតុកោណកែងនៅផ្នែកខាងក្រោមក៏ស្តើងជាងមុនផងដែរ ដែលមានន័យថាដំណើរការនានាកំពុងដំណើរការលឿនជាងមុន។
ប្រសិនបើអ្នកប្រៀបធៀបបរិមាណនៃផ្ទៃពណ៌ស្វាយខ្ពស់/ធំទូលាយនៅក្នុងក្រាហ្វចាស់ និងក្រាហ្វថ្មី យើងកំពុងឃើញការកើនឡើងនៃដំណើរការរហូតដល់ ២០០% យ៉ាងភ្ញាក់ផ្អើល! យើងក៏ឃើញការកើនឡើងនៃដំណើរការនៅគ្រប់ផ្នែកទាំងអស់ផងដែរ។ មិនអន់ទាល់តែសោះ!
មេរៀន និងបទពិសោធន៍ដែលទទួលបាន
និយាយឱ្យត្រង់ទៅ យើងមិនបានគិតថា PBS មានបញ្ហាដំណើរការនោះទេ មុនពេលដែល Ann បានលើកឡើងអំពីវា។ មូលហេតុចម្បងគឺដោយសារតែយើងកំពុងប្រើប្រាស់ម៉ាស៊ីនកុំព្យូទ័រសម្រាប់តែការអភិវឌ្ឍ (development-centric machines) ហើយចំណុចស្ទះដំណើរការមិនសូវជាលេចឡើងច្បាស់នោះទេ។ ក្រឡេកមើលទៅក្រោយ ការត្រួតពិនិត្យដំណើរការគួរតែជាអាទិភាពចម្បងមួយ។ ប៉ុន្តែយ៉ាងហោចណាស់នៅពេលនេះ គិតត្រឹមកំណែ 4.3 វាត្រូវបានដោះស្រាយរួចរាល់ហើយ។ 
សម្រាប់អ្នកដែលចង់កែលម្អដំណើរការ WordPress plugin ផ្ទាល់ខ្លួន ជាពិសេសប្រសិនបើអ្នកកំពុងប្រើប្រាស់ Javascript ធ្ងន់ៗផងដែរនោះ នេះជាមេរៀនដែលខ្ញុំទទួលបានពីបទពិសោធន៍នេះ៖
- កំណត់/រក្សាទុក cache លើការហៅប្រើប្រាស់ properties/functions របស់អ្នកដែលបង្កឱ្យមាន reflow។ ប្រើប្រាស់ឯកសារនេះជាមគ្គុទ្ទេសក៍៖ What forces layout/reflow. The comprehensive list.
- ប្រមូលផ្តុំ “reads” និង “writes” ទៅកាន់ DOM styles ជាមួយគ្នា។ ប្រើប្រាស់ FastDom ដើម្បីធ្វើកិច្ចការនេះជំនួសអ្នក។
- ប្រើប្រាស់ Chrome’s Timeline profiler ហើយត្រូវប្រាកដថាអ្នកមាន reflows (ផ្ទៃពណ៌ស្វាយ) តិចបំផុតតាមដែលអាចធ្វើទៅបាន។
ប្រសិនបើអ្នកជាអ្នកសរសេរប្លុកដ៏ងប់ងល់ម្នាក់ ដែលការបង្កើតមាតិកាទាំងអស់របស់អ្នកវិលជុំវិញការសរសេរអត្ថបទពេញលេញ ដែលមានរូបភាពបន្ថែមម្ដងម្កាល នោះប្រហែលជាកម្មវិធីកែសម្រួលមាតិកា TinyMCE ដែលមានស្រាប់គឺគ្រប់គ្រាន់សម្រាប់តម្រូវការរបស់អ្នកហើយ។ ឧបករណ៍បច្ចុប្បន្នមានឧបករណ៍ចាំបាច់សម្រាប់ការសរសេរអត្ថបទរួចហើយ អ្នកមានឧបករណ៍ធ្វើទ្រង់ទ្រាយអត្ថបទមូលដ្ឋានដូចជា អក្សរដិត អក្សរទ្រេត ក្បាលកថាខណ្ឌ ជាដើម។ ប៉ុន្តែវាមានត្រឹមតែប៉ុណ្ណឹងឯង។
មើលចុះ! វាពោរពេញទៅដោយចំណុចស្ទះដំណើរការយ៉ាងច្រើនសន្ធឹកសន្ធាប់!
ដូចដែលអ្នកអាចមើលឃើញ មានផ្ទៃពណ៌ស្វាយតិចជាងមុននៅក្នុងក្រាហ្វ។ ហើយមានភាពខុសគ្នាយ៉ាងច្បាស់ទៅលើបរិមាណនៃដំណើរការដែលត្រូវបានអនុវត្តដោយ browser។ រូបរាងចតុកោណកែងនៅផ្នែកខាងក្រោមក៏ស្តើងជាងមុនផងដែរ ដែលមានន័យថាដំណើរការនានាកំពុងដំណើរការលឿនជាងមុន។
