ਪਿਛਲੇ ਫਰਵਰੀ 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 ਦਾ Timeline profiler ਇਸ ਕੰਮ ਲਈ ਸਹੀ ਟੂਲ ਸੀ। ਟਾਈਮਲਾਈਨ ਪ੍ਰੋਫਾਈਲਰ ਇਹ ਪਛਾਣ ਅਤੇ ਮਾਪ ਸਕਦਾ ਹੈ ਕਿ ਰਨਟਾਈਮ ਦੌਰਾਨ ਕਿਸੇ ਵੈੱਬਪੇਜ ‘ਤੇ ਕਿਹੜੀਆਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਚੱਲ ਰਹੀਆਂ ਹਨ, ਜੋ ਕਿ ਸਪੀਡ ਦੀਆਂ ਰੁਕਾਵਟਾਂ ਲੱਭਣ ਲਈ ਸੰਪੂਰਨ ਹੈ।
ਅਸੀਂ ਸੋਚਿਆ ਕਿ ਸਾਨੂੰ ਪਹਿਲਾਂ ਸਭ ਤੋਂ ਸਰਲ ਕਦਮਾਂ ਦੀ ਜਾਂਚ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ – ਕਈ ਐਲੀਮੈਂਟਾਂ ਅਤੇ ਕਤਾਰਾਂ ਉੱਤੇ ਸਾਡਾ ਮਾਊਸ ਘੁੰਮਾਉਣਾ। ਸਰਲ ਹੈ ਨਾ? ਸਾਨੂੰ ਭਰੋਸਾ ਸੀ ਕਿ ਅਸੀਂ ਇੰਨੀ ਸਰਲ ਚੀਜ਼ ਨਾਲ ਪ੍ਰਦਰਸ਼ਨ ਸੰਬੰਧੀ ਸਮੱਸਿਆਵਾਂ ਵਿੱਚ ਨਹੀਂ ਪਵਾਂਗੇ। ਬਦਕਿਸਮਤੀ ਨਾਲ, ਅਸੀਂ ਗਲਤ ਸੀ।
ਇੱਕ ਵਾਰ ਜਦੋਂ ਅਸੀਂ ਰਿਕਾਰਡ ਬਟਨ ਦਬਾਇਆ, ਅਸੀਂ ਸਕ੍ਰੀਨ ‘ਤੇ ਲਗਭਗ 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 ਵਿੱਚ ਐਲੀਮੈਂਟ ਦੀਆਂ ਬਾਹਰੀ ਰੇਖਾਵਾਂ ਨੂੰ ਕਿੱਥੇ ਖਿੱਚਣਾ ਹੈ, ਉਸ ਸਥਾਨ ਦੀ ਗਣਨਾ ਕਰਨ ਲਈ ਹਰ ਸਮੇਂ ਇਸ ਫੰਕਸ਼ਨ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ। ਇਸਦੇ ਲਈ ਸਾਡੇ ਦੁਆਰਾ ਬਣਾਇਆ ਗਿਆ ਕੈਸ਼ਿੰਗ ਫੰਕਸ਼ਨ ਇੱਥੇ ਹੈ:
// ਕੈਸ਼: ਸਾਡੇ 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 ਦੀ ਵਰਤੋਂ ਕੀਤੀ। ਹੁਣ ਹਰ ਵਾਰ ਜਦੋਂ ਕਲਾਇੰਟ ਰੈਕਟ ਦੀ ਪੁੱਛਗਿੱਛ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਅਸੀਂ ਭਵਿੱਖ ਦੇ ਸੰਦਰਭ ਲਈ ਉਸ ਮੁੱਲ ਨੂੰ ਸਟੋਰ ਕਰ ਲੈਂਦੇ ਹਾਂ, ਜਿਸ ਨਾਲ ਰੀਫਲੋਅ ਟ੍ਰਿਗਰਾਂ ਦੀ ਗਿਣਤੀ ਸੀਮਤ ਹੋ ਜਾਂਦੀ ਹੈ।
ਸਾਨੂੰ ਕੈਸ਼ ਨੂੰ ਕਲੀਅਰ ਕਰਨ ਦਾ ਇੱਕ ਤਰੀਕਾ ਵੀ ਚਾਹੀਦਾ ਸੀ ਜਦੋਂ ਸਟੋਰ ਕੀਤੇ ਕਲਾਇੰਟ ਰੈਕਟ ਅਵੈਧ ਹੋ ਜਾਂਦੇ ਹਨ। ਸਟੋਰ ਕੀਤੇ ਕਲਾਇੰਟ ਰੈਕਟ ਦੇ ਮੁੱਲ ਉਦੋਂ ਬਦਲ ਜਾਂਦੇ ਹਨ ਜਦੋਂ ਉਪਭੋਗਤਾ ਪੰਨੇ ਨੂੰ ਸਕ੍ਰੋਲ ਕਰਦਾ ਹੈ ਜਾਂ ਸਕ੍ਰੀਨ ਵਿੱਚ ਐਲੀਮੈਂਟਸ ਜੋੜਦਾ/ਬਦਲਦਾ/ਹਟਾਉਂਦਾ ਹੈ। ਇਸ ਲਈ ਅਸੀਂ ਇੱਕ ਕੈਸ਼ ਕਲੀਅਰਿੰਗ ਫੰਕਸ਼ਨ ਬਣਾਇਆ ਹੈ ਜਿਸਨੂੰ ਅਸੀਂ ਜਦੋਂ ਵੀ ਨਵੇਂ ਕਲਾਇੰਟ ਰੈਕਟ ਮੁੱਲਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਕਾਲ ਕਰ ਸਕਦੇ ਹਾਂ:
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 ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਵਿੱਚ ਸੁਧਾਰ ਹੋਇਆ, ਪਰ ਇਹ ਕਾਫ਼ੀ ਨਹੀਂ ਸੀ।
ਗੂਗਲ ‘ਤੇ ਥੋੜ੍ਹੀ ਹੋਰ ਖੋਜ ਕਰਨ ‘ਤੇ, ਸਾਨੂੰ ਵਿਲਸਨ ਪੇਜ ਦੁਆਰਾ ਲਿਖਿਆ Preventing ‘layout thrashing’ ‘ਤੇ ਇੱਕ ਲੇਖ ਮਿਲਿਆ। ਵਿਲਸਨ ਕਹਿੰਦਾ ਹੈ:
ਲੇਆਉਟ ਥ੍ਰੈਸ਼ਿੰਗ (ਰੀਫਲੋਅ) ਉਦੋਂ ਵਾਪਰਦੀ ਹੈ ਜਦੋਂ ਜਾਵਾਸਕ੍ਰਿਪਟ ਵਾਰ-ਵਾਰ 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 ਦੇ ਜੀਵਨ-ਚੱਕਰ ਦੌਰਾਨ ਬਹੁਤ ਸਾਰੀਆਂ ਵੱਖ-ਵੱਖ ਥਾਵਾਂ ‘ਤੇ ਬਹੁਤ ਸਾਰੇ ਵੱਖ-ਵੱਖ ਸਮਿਆਂ ‘ਤੇ ਰੀਫਲੋਅ-ਟ੍ਰਿਗਰ ਕਰਨ ਵਾਲੀਆਂ ਚੀਜ਼ਾਂ ਨੂੰ ਪੜ੍ਹਨਾ ਅਤੇ ਲਿਖਣਾ ਹੁੰਦਾ ਹੈ। ਜਾਵਾਸਕ੍ਰਿਪਟ ਕੋਡ ਦੀਆਂ ਹਜ਼ਾਰਾਂ ਲਾਈਨਾਂ ਨੂੰ ਮੁੜ-ਸੰਗਠਿਤ ਕਰਨਾ ਸੰਭਵ ਨਹੀਂ ਹੈ।
ਸਾਡੀ ਖੁਸ਼ਕਿਸਮਤੀ ਨਾਲ, ਵਿਲਸਨ ਨੇ ਆਪਣੇ ਲੇਖ ਵਿੱਚ ਇੱਕ ਹੱਲ ਵੀ ਪ੍ਰਦਾਨ ਕੀਤਾ ਹੈ। ਉਸਨੇ ਉਹਨਾਂ reads ਅਤੇ writes ਨੂੰ ਇਕੱਠੇ ਗਰੁੱਪ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਨ ਲਈ ਇੱਕ ਛੋਟੀ ਉਪਯੋਗੀ ਸਕ੍ਰਿਪਟ ਬਣਾਈ, ਜਿਸਨੂੰ FastDom ਕਿਹਾ ਜਾਂਦਾ ਹੈ।
Page Builder Sandwich ਦਾ ਕੁਝ ਕੋਡ ਇੱਥੇ ਦਿੱਤਾ ਗਿਆ ਹੈ ਜੋ FastDom ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ ਅਤੇ ਸਾਡੇ ਉੱਪਰ ਦਿੱਤੇ ਹੱਲ #1 ਨੂੰ ਵੀ ਸ਼ਾਮਲ ਕਰਦਾ ਹੈ:
// ਦੂਜੇ ਥ੍ਰੈੱਡਾਂ ਤੋਂ 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 ਕਾਲਾਂ ਨੂੰ ਇਕੱਠਾ ਗਰੁੱਪ ਕਰਦਾ ਹੈ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਅਸਿੰਕ੍ਰੋਨਸਲੀ ਚਲਾਉਂਦਾ ਹੈ, ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ ਸਾਰੇ ਰੀਫਲੋਅ ਨੂੰ ਘਟਾਉਣ ਲਈ ਸਾਰੇ reads ਅਤੇ writes ਨੂੰ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਢੰਗ ਨਾਲ ਇਕੱਠਾ ਕਰਦਾ ਹੈ।
ਹੱਲ #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 ਹੱਲਾਂ ਵਿੱਚ ਬਹੁਤ ਸਾਰੀ ਖੋਜ, ਟੈਸਟਿੰਗ ਅਤੇ ਅਸਲ ਲਾਗੂਕਰਨ ਸ਼ਾਮਲ ਸੀ (ਅਤੇ ਸਾਡੇ ਫੌਂਟਸ ਫੀਚਰ ਨੂੰ ਜਾਰੀ ਕਰਨ ਵਿੱਚ ਦੇਰੀ ਹੋਈ), ਪਰ ਅੰਤ ਵਿੱਚ ਇਹ ਸਭ ਲਾਭਦਾਇਕ ਰਿਹਾ।
2 ਸਕਿੰਟਾਂ ਲਈ ਸਕ੍ਰੀਨ ‘ਤੇ ਆਪਣੇ ਮਾਊਸ ਨੂੰ ਘੁੰਮਾਉਣ ਦੇ ਸਾਡੇ ਸ਼ੁਰੂਆਤੀ ਟੈਸਟ ‘ਤੇ ਵਾਪਸ ਆਉਂਦੇ ਹਾਂ। ਇੱਥੇ ਪੁਰਾਣੀ ਖ਼ਰਾਬ/ਅਸਥਿਰ ਟਾਈਮਲਾਈਨ ਹੈ:
ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ ਵਿੱਚ ਸੁਧਾਰਾਂ ਤੋਂ ਬਾਅਦ ਸਾਡੀ ਨਵੀਂ ਟਾਈਮਲਾਈਨ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ:
ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ, ਗ੍ਰਾਫ ਵਿੱਚ ਜਾਮਨੀ ਖੇਤਰ ਘੱਟ ਹਨ। ਅਤੇ ਬ੍ਰਾਊਜ਼ਰ ਦੁਆਰਾ ਕੀਤੀਆਂ ਜਾ ਰਹੀਆਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੀ ਮਾਤਰਾ ਵਿੱਚ ਇੱਕ ਧਿਆਨ ਦੇਣ ਯੋਗ ਅੰਤਰ ਹੈ। ਹੇਠਾਂ ਵਾਲੇ ਆਇਤਾਕਾਰ ਬਲਾਕ ਵੀ ਪਤਲੇ ਹਨ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਪ੍ਰਕਿਰਿਆਵਾਂ ਪਹਿਲਾਂ ਨਾਲੋਂ ਤੇਜ਼ੀ ਨਾਲ ਚੱਲ ਰਹੀਆਂ ਹਨ।
ਜੇਕਰ ਤੁਸੀਂ ਪੁਰਾਣੇ ਅਤੇ ਨਵੇਂ ਗ੍ਰਾਫਾਂ ਵਿੱਚ ਲੰਬੇ/ਚੌੜੇ ਜਾਮਨੀ ਖੇਤਰਾਂ ਦੀ ਤੁਲਨਾ ਕਰਦੇ ਹੋ, ਤਾਂ ਸਾਨੂੰ ਇੱਕ ਸ਼ਾਨਦਾਰ 200% ਕਾਰਗੁਜ਼ਾਰੀ ਵਾਧਾ ਦੇਖਣ ਨੂੰ ਮਿਲ ਰਿਹਾ ਹੈ! ਅਸੀਂ ਸਾਰੇ ਪਾਸੇ ਪ੍ਰਦਰਸ਼ਨ ਵਿੱਚ ਵਾਧਾ ਦੇਖ ਰਹੇ ਹਾਂ। ਬਿਲਕੁਲ ਵੀ ਮਾੜਾ ਨਹੀਂ!
ਮੁੱਖ ਨੁਕਤੇ ਅਤੇ ਸਿੱਖਿਆਵਾਂ
ਸੱਚ ਕਹਾਂ ਤਾਂ, ਐਨ ਵੱਲੋਂ ਇਹ ਗੱਲ ਉਠਾਏ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ ਅਸੀਂ ਨਹੀਂ ਸੋਚਿਆ ਸੀ ਕਿ PBS ਵਿੱਚ ਪ੍ਰਦਰਸ਼ਨ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਸਨ। ਮੁੱਖ ਤੌਰ ‘ਤੇ ਕਿਉਂਕਿ ਅਸੀਂ ਵਿਕਾਸ-ਕੇਂਦ੍ਰਿਤ ਮਸ਼ੀਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰ ਰਹੇ ਸੀ ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ ਦੀਆਂ ਰੁਕਾਵਟਾਂ ਇੰਨੀਆਂ ਸਪੱਸ਼ਟ ਨਹੀਂ ਸਨ। ਪਿੱਛੇ ਮੁੜ ਕੇ ਦੇਖਦੇ ਹੋਏ, ਪ੍ਰਦਰਸ਼ਨ ਦੀ ਜਾਂਚ ਕਰਨਾ ਮੁੱਖ ਤਰਜੀਹਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੋਣਾ ਚਾਹੀਦਾ ਸੀ। ਪਰ ਘੱਟੋ-ਘੱਟ ਹੁਣ, ਸੰਸਕਰਣ 4.3 ਦੇ ਅਨੁਸਾਰ ਇਸਦਾ ਹੱਲ ਕਰ ਲਿਆ ਗਿਆ ਹੈ। 
ਉਹਨਾਂ ਲੋਕਾਂ ਲਈ ਜੋ ਆਪਣੇ ਖੁਦ ਦੇ ਵਰਡਪ੍ਰੈਸ ਪਲੱਗਇਨ ਦੇ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਣਾ ਚਾਹੁੰਦੇ ਹਨ, ਖਾਸ ਕਰਕੇ ਜੇਕਰ ਤੁਸੀਂ ਵੀ ਭਾਰੀ ਜਾਵਾਸਕ੍ਰਿਪਟ ਦੀ ਵਰਤੋਂ ਕਰ ਰਹੇ ਹੋ, ਇਸ ਅਨੁਭਵ ਤੋਂ ਮੇਰੇ ਮੁੱਖ ਨੁਕਤੇ ਇੱਥੇ ਹਨ:
- ਰੀਫਲੋਅ ਨੂੰ ਸ਼ੁਰੂ ਕਰਨ ਵਾਲੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ/ਫੰਕਸ਼ਨਾਂ ਲਈ ਆਪਣੀਆਂ ਕਾਲਾਂ ਨੂੰ ਸੀਮਤ/ਕੈਸ਼ ਕਰੋ। ਇਸਨੂੰ ਇੱਕ ਗਾਈਡ ਵਜੋਂ ਵਰਤੋ: What forces layout/reflow. The comprehensive list.
- DOM ਸਟਾਈਲ ਲਈ “reads” ਅਤੇ “writes” ਨੂੰ ਇਕੱਠਾ ਗਰੁੱਪ ਕਰੋ। ਤੁਹਾਡੇ ਲਈ ਇਹ ਕਰਨ ਵਾਸਤੇ FastDom ਦੀ ਵਰਤੋਂ ਕਰੋ।
- Chrome ਦੇ Timeline profiler ਦੀ ਵਰਤੋਂ ਕਰੋ, ਅਤੇ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਤੁਹਾਡੇ ਕੋਲ ਜਿੰਨਾ ਸੰਭਵ ਹੋ ਸਕੇ ਘੱਟ ਰੀਫਲੋਅ (ਜਾਮਨੀ ਹਿੱਸਾ) ਹੋਣ।