14 ਜੁਲਾ 2025·7 ਮਿੰਟ
ਸੁਧਾਰਨ ਤੋਂ ਪਹਿਲਾਂ ਮਾਪੋ: Paul Irish ਦਾ ਤੇਜ਼ੀ ਵਾਲਾ ਵਰਕਫਲੋ
ਸੂਚਨਾ-ਚੱਕਰ: ਪਹਿਲਾਂ ਬੇਸਲਾਈਨ ਲਓ, ਪ੍ਰੋਫਾਈਲ ਕਰੋ, ਇੱਕ ਚੀਜ਼ ਬਦਲੋ, ਪ੍ਰਭਾਵ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ — ਇਹ ਆਸਾਨ ਲੂਪ ਤੁਹਾਡੀ ਪਰਫਾਰਮੈਂਸ ਦੀ ਆਦਤ ਬਣਾਉਂਦਾ ਹੈ।
ਸੂਚਨਾ-ਚੱਕਰ: ਪਹਿਲਾਂ ਬੇਸਲਾਈਨ ਲਓ, ਪ੍ਰੋਫਾਈਲ ਕਰੋ, ਇੱਕ ਚੀਜ਼ ਬਦਲੋ, ਪ੍ਰਭਾਵ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ — ਇਹ ਆਸਾਨ ਲੂਪ ਤੁਹਾਡੀ ਪਰਫਾਰਮੈਂਸ ਦੀ ਆਦਤ ਬਣਾਉਂਦਾ ਹੈ।
ਜਦੋਂ ਤੁਸੀਂ ਮੁੱਢੇ ਤੌਰ 'ਤੇ ਫਿਕਸਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰਦੇ ਹੋ ਤਾਂ ਪਰਫਾਰਮੈਂਸ ਦਾ ਕੰਮ ਬੇਤਰਤੀਬੀ محسوس ਹੁੰਦਾ ਹੈ। ਇੱਕ ਦਿਨ ਤੁਸੀਂ ਫਾਈਲਾਂ ਨੂੰ ਮਿਨੀਫਾਈ ਕਰਦੇ ਹੋ, ਦੂਜੇ ਦਿਨ ਕੈਸ਼ਿੰਗ ਸੈਟਿੰਗ ਸੁਧਾਰਦੇ ਹੋ, ਫਿਰ ਕੋਈ ਲਾਇਬ੍ਰੇਰੀ ਹਟਾਉਂਦੇ ਹੋ। ਕਈ ਵਾਰੀ ਇਹ ਮਦਦ ਕਰਦਾ ਹੈ। ਕਈ ਵਾਰੀ ਕੁਝ ਨਹੀਂ ਬਦਲਦਾ, ਅਤੇ ਤੁਸੀਂ ਸਮਝ ਨਹੀਂ ਪਾਂਦੇ ਕਿ ਕਿਉਂ।
ਸਭ ਤੋਂ ਵੱਡਾ ਖਤਰਾ ਗਲਤ ਚੀਜ਼ 'ਤੇ ਅਪਟਾਇਮਾਈਜ਼ ਕਰਨਾ ਹੈ। ਜੇ ਪੇਜ ਧੀਮਾ ਹੈ ਕਿਉਂਕਿ ਮੁੱਖ ਥ੍ਰੈਡ JavaScript ਨਾਲ ਬਲਾਕ ਹੋ ਰਿਹਾ ਹੈ, ਤਾਂ ਤਸਵੀਰਾਂ ਨੂੰ ਸਥਿਤ ਕਰਨ ਵਿੱਚ ਘੰਟਿਆਂ ਖਰਚ ਕਰਨਾ ਬਹੁਤ ਘੱਟ असर ਕਰੇਗਾ। ਜਾਂ ਤੁਸੀਂ ਉਹ ਚੀਜ਼ ਤੇਜ਼ ਕਰਦੇ ਹੋ ਜੋ ਉਪਭੋਗਤਾ ਮਹਿਸੂਸ ਨਹੀਂ ਕਰਦੇ, ਜਦ ਕਿ ਅਸਲ ਦੇਰ ਕਿਸੇ ਲੰਬੇ API ਕਾਲ, ਇੱਕ ਲੇਆਉਟ ਜੋ ਵਾਰ-ਵਾਰ ਰੀਫਲੋ ਕਰ ਰਿਹਾ ਹੈ, ਜਾਂ ਇੱਕ ਇੱਕਲੌਤਾ ਬਲੋਕਿੰਗ ਸਕ੍ਰਿਪਟ ਹੋ ਸਕਦੀ ਹੈ।
ਇੱਕ ਹੋਰ ਜਾਲ ਹੈ "ਭਾਵਨਾਤਮਕ" ਅੰਦਾਜ਼ੇ ਨਾਲ ਨਿਰਣਯ ਲੈਣਾ। “ਜ਼ਿਆਦਾ ਤੇਜ਼ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ” ਪਲੇਸੇਬੋ ਬਦਲਾਵ (ਜਿਵੇਂ ਸਪਿੰਨਰ) ਜਾਂ ਵੱਖ-ਵੱਖ ਨੈੱਟਵਰਕ, ਡਿਵਾਈਸ ਜਾਂ ਸਮੇਂ 'ਤੇ ਟੈਸਟ ਕਰਨ ਕਾਰਨ ਹੋ ਸਕਦਾ ਹੈ। “ਸੱਚਮੁੱਚ ਤੇਜ਼ ਹੈ” ਇਹ ਮਤਲਬ ਹੈ ਕਿ ਓਹੀ ਐਕਸ਼ਨ, ਓਹੀ ਹਾਲਾਤਾਂ ਹੇٺ, ਬਿਹਤਰ ਨੰਬਰ ਦਿੱਤੇ।
ਇਕ ਸਧਾਰਣ ਵਚਨ ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਵੱਧਤਰ ਮਸਲੇ ਠੀਕ ਕਰ ਦਿੰਦਾ: ਮਾਪੋ, ਫਿਰ ਸੁਧਾਰੋ ਅਤੇ ਫੈਸਲਾ ਕਰੋ। ਜਦੋਂ ਤੁਸੀਂ ਪਰਫਾਰਮੈਂਸ ਨੂੰ ਮਾਪਣ ਵਾਲੀ ਸਮੱਸਿਆ ਸਮਝਕੇ ਹਲ ਕਰਦੇ ਹੋ, ਤਾਂ ਤਕੜੇ ਅਨੁਮਾਨ ਬੰਦ ਹੋ ਜਾਂਦੇ ਹਨ ਅਤੇ ਤੁਸੀਂ ਸਿੱਖਣਾ ਸ਼ੁਰੂ ਕਰਦੇ ਹੋ।
ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਲੂਪ ਇਹੋ ਜਿਹਾ ਹੈ: ਇੱਕ ਉਪਭੋਗਤਾ ਐਕਸ਼ਨ ਚੁਣੋ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਸੁਧਾਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਦਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੇ ਹਾਲਾਤਾਂ ਵਿੱਚ ਇੱਕ ਬੇਸਲਾਈਨ ਰਿਕਾਰਡ ਕਰੋ, ਇੱਕ ਐਸਾ ਬਦਲਾਅ ਕਰੋ ਜੋ ਤੁਸੀਂ ਸਮਝਾ ਸਕੋ, ਫਿਰ ਮੁੜ ਮਾਪੋ ਅਤੇ ਕੇਵਲ ਉਦੋਂ ਹੀ ਬਦਲਾਅ ਰੱਖੋ ਜੇ ਨੰਬਰ ਸੁਧਰਦੇ ਹਨ।
Paul Irish ਵੈਬ ਪਰਫਾਰਮੈਂਸ ਦੇ ਸਭ ਤੋਂ ਜਾਣੇ-ਮਾਨੇ ਆਵਾਜ਼ਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹਨ। ਬ੍ਰਾੁਜ਼ਰ ਟੂਲਿੰਗ ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ ਗਾਈਡੈਂਸ 'ਚ ਕੰਮ ਕਰਦਿਆਂ, ਉਹ ਐਕ ਸੋਧ ਪ੍ਰਸਿੱਧ ਕੀਤਾ: ਤੁਹਾਡਾ ਪਹਿਲਾ ਕੰਮ ਇਹ ਅਨੁਮਾਨ ਲਾਉਣਾ ਨਹੀਂ ਕਿ ਕੀ ਧੀਮਾ ਹੈ, ਤੁਹਾਡਾ ਕੰਮ ਇਹ ਸਾਬਤ ਕਰਨਾ ਹੈ।
ਇਹ ਮਨੋਭਾਵ ਟੀਮ ਦੇ ਗਤੀਵਿਧੀਆਂ ਨੂੰ ਬਦਲ ਦਿੰਦਾ ਹੈ। "ਤਸਵੀਰਾਂ ਹਮੇਸ਼ਾਂ ਸਮੱਸਿਆ ਹਨ" ਜਾਂ "ਇਹ ਫਰੇਮਵਰਕ ਦੀ ਵਜ੍ਹਾ ਹੋਵੇਗੀ" ਵਰਗੀਆਂ ਆਦਤਾਂ ਤੋਂ ਬਦਲ ਕੇ ਤੁਸੀਂ ਸਬੂਤਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰਦੇ ਹੋ। ਜਦੋਂ ਤੁਸੀਂ ਕੋਈ ਟਾਈਮਲਾਈਨ, ਇੱਕ ਧੀਮਾ ਕਵੇਰੀ, ਜਾਂ ਲੰਬਾ ਟਾਸਕ ਦਰਸਾ ਸਕਦੇ ਹੋ, ਗੱਲ-ਬਾਤ ਦੋਸ਼ ਲਗਾਉਣ ਤੋਂ ਠੀਕਨਾਂ ਦੀਆਂ ਗੱਲਾਂ ਵੱਲ ਹੋ ਜਾਂਦੀ ਹੈ।
"ਸੁਧਾਰਨ ਤੋਂ ਪਹਿਲਾਂ ਮਾਪੋ" ਵਿਵਾਦਾਂ ਨੂੰ ਠੰਢਾ ਕਰਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਸਾਂਝੇ ਨਿਯਮ ਬਣਾਉਂਦਾ ਹੈ: ਅਪਮਤ ਕਰੋ ਕਿ ਤੁਸੀਂ ਕੀ ਮਾਪ ਰਹੇ ਹੋ, "ਬਿਹਤਰ" ਦਾ ਕੀ ਮਤਲਬ ਹੈ, ਅਤੇ ਸਿਰਫ਼ ਨੰਬਰ ਜਦੋਂ ਹਿਲਦੇ ਹਨ ਤਾਂ ਖ਼ੁਸ਼ੀ ਮਨਾਓ।
ਇਹ ਛੋਟੇ ਸਾਈਟਾਂ ਤੇ ਵੱਡੇ ਐਪ दोनों 'ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ। ਇੱਕ ਇਕੱਲੀ ਬੇਸਲਾਈਨ ਮਾਰਕੀਟਿੰਗ ਪੇਜ 'ਤੇ ਵੱਖ-ਵੱਖ ਛੋਟੀਆਂ ਅਪਟਾਇਮਾਈਜ਼ੇਸ਼ਨਾਂ ਨੂੰ ਰੋਕ ਸਕਦੀ ਹੈ। ਇੱਕ ਵੱਡੇ ਪ੍ਰੋਡਕਟ 'ਤੇ, ਲਗਾਤਾਰ ਮਾਪ ਇਸ ਗੱਲ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਂਦੇ ਹਨ ਕਿ ਪਰਫਾਰਮੈਂਸ ਅਨੰਤ ਟੂ-ਡੂ ਸੂਚੀ ਵਿੱਚ ਨਾਹ ਬਦਲ ਜਾਵੇ।
ਇਸਨੂੰ ਅਸਲ ਬਣਾਉਣ ਦਾ ਇੱਕ ਸਧਾਰਣ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ ਪਰਫਾਰਮੈਂਸ ਨੂੰ ਇੱਕ ਬੱਗ ਰਿਪੋਰਟ ਵਾਂਗ ਟ੍ਰੀਟ ਕਰੋ: ਮੁੜ ਬਣਾਉਣ ਦੇ ਸਪਸ਼ਟ ਕਦਮ, ਜੋ ਮੈਟ੍ਰਿਕ ਤੁਸੀਂ ਦੇਖਿਆ ਹੈ, ਅਤੇ ਇੱਕ ਬਦਲਾਅ ਜੋ ਇੱਕ ਨਤੀਜੇ ਨਾਲ ਜੁੜਿਆ ਹੋਵੇ। ਜੇ ਦੋ ਲੋਕ ਅਸਹਿਮਤ ਹਨ, ਤਾਂ ਮਾਪ ਮੁੜ ਚਲਾਓ ਅਤੇ ਡੇਟਾ ਨੂੰ ਫੈਸਲਾ ਕਰਨ ਦਿਓ।
ਪਹਿਲਾਂ ਪਰਫਾਰਮੈਂਸ ਨੂੰ ਇੱਕ ਇੰਸਟ੍ਰੂਮੈਂਟੇਸ਼ਨ ਸਮੱਸਿਆ ਸਮਝੋ: ਉਹ ਤਰੀਕੇ ਜੋੜੋ ਜਿਨ੍ਹਾਂ ਨਾਲ ਤੁਸੀਂ ਵੇਖ ਸਕੋ ਕਿ ਉਪਭੋਗਤਾ ਅਸਲ ਵਿੱਚ ਕੀ ਅਨੁਭਵ ਕਰ ਰਹੇ ਹਨ। ਜੇ ਤੁਸੀਂ ਇਸਨੂੰ ਨਹੀਂ ਦੇਖ ਸਕਦੇ, ਤਾਂ ਤੁਸੀਂ ਰਾਏਂ ਦੀ ਬਜਾਏ ਸਬੂਤਾਂ 'ਤੇ ਝਗੜੋਗੇ। ਇਹੀ ਮਾਇਨਿੰਗ ਪਹਿਲਾਂ ਮਾਪਣ ਦੇ ਪਿੱਛੇ ਹੈ।
ਇੰਸਟ੍ਰੂਮੈਂਟੇਸ਼ਨ ਨੂੰ ਮਹਿੰਗਾ ਹੋਣ ਦੀ ਲੋੜ ਨਹੀਂ। ਇਹ ਕੁਝ ਸੰਕੇਤਾਂ ਨੂੰ ਇੱਕੋ ਜਿਹੇ ਥਾਵਾਂ ਤੇ ਲਗਾਤਾਰ ਇਕੱਤਰ ਕਰਨ ਦੀ ਗੱਲ ਹੈ ਤਾਂ ਜੋ ਤੁਸੀਂ ਬੁਨਿਆਦੀ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦੇ ਸਕੋ:
ਆਮਤੌਰ 'ਤੇ ਤੁਸੀਂ ਦੋ ਕਿਸਮਾਂ ਦੇ ਡਾਟਾ ਚਾਹੁੰਦੇ ਹੋ।
ਲੈਬ ਡੇਟਾ ਇਕ ਨਿਯੰਤਰਿਤ ਸੈਟਅਪ ਵਿੱਚ ਕੈਪਚਰ ਹੁੰਦਾ ਹੈ: ਇੱਕ ਨਿਰਧਾਰਤ ਲੈਪਟਾਪ ਜਾਂ ਟੈਸਟ ਡਿਵਾਈਸ, ਸਥਿਰ ਨੈੱਟਵਰਕ ਪ੍ਰੋਫਾਈਲ, ਹਰ ਦੌੜ ਲਈ ਓਹੀ ਕਦਮ। ਇਹ ਡੀਬੱਗਿੰਗ ਲਈ ਬਹੁਤ ਵਧੀਆ ਹੈ ਕਿਉਂਕਿ ਤੁਸੀਂ ਸੁਸਤਤਾ ਨੂੰ ਮੰਗ ਤੇ ਦੁਹਰਾਉਣ ਯੋਗ ਬਣਾਉਂਦੇ ਹੋ।
ਰੀਅਲ ਯੂਜ਼ਰ ਡੇਟਾ ਉਹ ਹੈ ਜੋ ਜੰਗਲ ਵਿੱਚ ਲੋਕ ਮਹਿਸੂਸ ਕਰਦੇ ਹਨ: ਵੱਖ-ਵੱਖ ਡਿਵਾਈਸ, ਸਥਾਨ ਅਤੇ ਕਨੈਕਸ਼ਨ ਗੁਣਵੱਤਾ। ਇਹ ਪ੍ਰਾਰੰਭਿਕਤਾ ਲਈ ਵਧੀਆ ਹੈ ਕਿਉਂਕਿ ਇਹ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਅਸਲ ਉਪਭੋਗਤਿਆਂ ਨੂੰ ਕੀ ਨੁਕਸਾਨ ਪਹੁੰਚਦਾ ਹੈ, ਸਿਰਫ ਇੱਕ ਟੈਸਟ ਦੌੜ ਨਹੀਂ।
ਐਕਸਪੋਰਟ ਕਰਨ ਵਾਲੇ ਬਿਨਾਂ ਮਾਹਿਰ ਹੋਏ ਵੀ, ਤੁਸੀਂ ਪੇਜ ਲੋਡ ਮਾਈਲਸਟੋਨ (ਜਿਵੇਂ ਪਹਿਲੀ ਸਮੱਗਰੀ ਦਿਖਾਉਣ), ਲੰਬੇ ਟਾਸਕ ਅਤੇ ਮੁੱਖ-ਥ੍ਰੈਡ ਬਲਾਕਿੰਗ, ਸਲੇਟ ਰਿਕਵੈਸਟਾਂ, ਮਹਿੰਗੀ ਰੇਂਡਰਿੰਗ ਵਰਕ (ਲੇਆਉਟ, ਸਟਾਈਲ, ਪੇਂਟ), ਅਤੇ ਸਰਵਰ ਰਿਸਪਾਂਸ ਟਾਈਮ ਮਾਪ ਸਕਦੇ ਹੋ।
ਇਹ ਸੰਕੇਤ ਆਮ ਤੌਰ 'ਤੇ ਕਈ ਥਾਵਾਂ 'ਤੇ ਮਿਲਦੇ ਹਨ: ਲੈਬ ਪ੍ਰੋਫਾਇਲਿੰਗ ਲਈ ਬ੍ਰਾਊਜ਼ਰ ਡਿਵੈਲਪਰ ਟੂਲ, ਬੈਕਐਂਡ ਟਾਈਮਿੰਗ ਲਈ ਸਰਵਰ ਲਾਗ ਅਤੇ ਟਰੇਸ, ਅਤੇ ਰੀਅਲ ਯੂਜ਼ਰ ਡੈਟਾ ਲਈ ਐਨਾਲਿਟਿਕਸ ਜਾਂ RUM ਡੈਸ਼ਬੋਰਡ। ਉਦਾਹਰਨ ਲਈ, ਜੇ ਚੈਕਆਉਟ ਧੀਮਾ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ, ਤਾਂ DevTools ਦਿਖਾ ਸਕਦਾ ਹੈ ਕਿ ਬ੍ਰਾਊਜ਼ਰ ਇੱਕ ਵੱਡਾ ਕਾਰਟ UI ਰੇਂਡਰ ਕਰਨ ਵਿੱਚ ਵਿਆਸਤ ਹੈ ਜਦਕਿ ਸਰਵਰ ਲਾਗ API ਨੂੰ ਤੇਜ਼ ਦਿਖਾ ਰਹੇ ਹਨ। ਇੰਸਟ੍ਰੂਮੈਂਟੇਸ਼ਨ ਤੋਂ ਬਿਨਾਂ ਤੁਸੀਂ ਬੈਕਐਂਡ ਨੂੰ ਠੀਕ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਅਸਲ ਸਮੱਸਿਆ ਕਦੇ ਹੱਲ ਨਹੀਂ ਹੋਵੇਗੀ।
ਸੁਧਾਰਨ ਤੋਂ ਪਹਿਲਾਂ ਮਾਪਣ ਲਈ, ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਸ਼ੁਰੂਆਤੀ ਬਿੰਦੂ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜਿਸ 'ਤੇ ਤੁਸੀਂ ਭਰੋਸਾ ਕਰ ਸਕੋ। ਇੱਕ ਬੇਸਲਾਈਨ ਹੈ ਉਹੀ ਐਕਸ਼ਨ, ਓਹੀ ਤਰੀਕੇ ਨਾਲ ਮਾਪਿਆ ਗਿਆ, ਓਹੀ ਹਾਲਾਤਾਂ ਹੇਠ।
ਇੱਕ ਅਸਲ ਉਪਭੋਗਤਾ ਯਾਤਰਾ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ, "ਸਾਈਟ ਸਾਰਾ" ਨਹੀਂ। ਇੱਕ ਵਾਕ ਵਿੱਚ ਵਰਣਨ ਕਰਨ ਯੋਗ ਚੀਜ਼ ਚੁਣੋ, ਜਿਵੇਂ "ਹੋਮ ਪੇਜ ਖੋਲ੍ਹੋ ਅਤੇ ਪਹਿਲੇ ਪ੍ਰੋਡਕਟ ਗ੍ਰਿਡ ਤੱਕ ਸਕ੍ਰੋਲ ਕਰੋ" ਜਾਂ "ਲਾਗਇਨ ਕਰੋ ਅਤੇ ਡੈਸ਼ਬੋਰਡ ਤੱਕ ਪਹੁੰਚੋ"। ਇਸਨੂੰ ਸੰਕੁਚਿਤ ਰੱਖਣ ਨਾਲ ਨੰਬਰ ਸਥਿਰ ਰਹਿੰਦੇ ਹਨ ਅਤੇ ਅਗਲੇ ਕਦਮ ਸਪਸ਼ਟ ਹੋ ਜਾਂਦੇ ਹਨ।
ਅਗਲਾ, 1 ਤੋਂ 3 ਮੈਟ੍ਰਿਕਸ ਚੁਣੋ ਜੋ ਯਾਤਰਾ ਨਾਲ ਮਿਲਦੇ ਹੋਣ। ਪੇਜ ਵੇਖਣ ਲਈ ਆਮ ਜੋੜੀ LCP (ਮੁੱਖ ਸਮੱਗਰੀ ਕਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਆਉਂਦੀ ਹੈ) ਅਤੇ TTFB (ਸਰਵਰ ਕਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਜਵਾਬ ਦਿੰਦਾ ਹੈ) ਹੋ ਸਕਦੇ ਹਨ। ਚੈਕਆਉਟ ਵਰਗੇ ਫਲੋ ਲਈ, ਤੁਸੀਂ ਪਹਿਲੇ ਕਦਮ ਨੂੰ ਪੂਰਾ ਕਰਨ ਦਾ ਸਮਾਂ ਅਤੇ ਭੁਗਤਾਨ ਕਾਲ ਲਈ API ਰਿਸਪਾਂਸ ਸਮਾਂ ਟ੍ਰੈਕ ਕਰ ਸਕਦੇ ਹੋ। ਬਹੁਤ ਸਾਰੇ ਮੈਟ੍ਰਿਕਸ ਨੇੜੇ-ਨੀਚੇ ਕਰਨ ਵਿੱਚ ਆਸਾਨੀ ਹੋਵੇਗੀ।
ਟੈਸਟ ਸੈਟਅਪ ਲਿਖੋ ਤਾਂ ਜੋ ਕੋਈ ਹੋਰ ਵੀ ਸਗੋਂ ਦੁਹਰਾਂ ਸਕੇ। ਛੋਟੇ ਫਰਕ ਨਤੀਜੇ ਬਦਲ ਸਕਦੇ ਹਨ:
ਅੰਤ 'ਚ, ਆਪਣੇ ਦਰਸ਼ਕ ਲਈ "ਕਾਫੀ ਚੰਗਾ" ਦੀ ਪਰਿਭਾਸ਼ਾ ਦਿਓ। ਉਦਾਹਰਨ: "ਮਿਡ-ਰੇਂਜ ਫੋਨ ਤੇ 4G ਉੱਤੇ LCP 2.5s ਤੋਂ ਘੱਟ"। ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਤਦੇ ਹੋ, ਤੋਟ ਜਾਂ ਸਨੇਪਸ਼ਾਟ ਲੈਣਾ ਟੈਸਟ ਤੋਂ ਪਹਿਲਾਂ ਮਦਦ ਕਰਦਾ ਹੈ ਤਾਂ ਕਿ ਤੁਹਾਡੀ ਬੇਸਲਾਈਨ ਇੱਕ ਜਾਣੀ-ਪਛਾਣ ਵਰਜ਼ਨ ਨਾਲ ਜੁੜੀ ਰਹੇ।
ਕੋਈ ਵੀ ਚੀਜ਼ ਪ੍ਰੋਫਾਈਲ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਸਮੱਸਿਆ ਨੂੰ ਦੁਬਾਰਾ ਮੰਗ 'ਤੇ ਹੋਣ ਯੋਗ ਬਣਾਓ। ਜੇ ਤੁਸੀਂ ਇਸਨੂੰ ਦੁਹਰਾਉ ਨਹੀਂ ਸਕਦੇ, ਤਾਂ ਨਤੀਜੇ 'ਤੇ ਭਰੋਸਾ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ।
ਲੋਕਾਂ ਦੀ ਮਹਿਸੂਸ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ, ਆਪਣੇ ਅਨੁਮਾਨ ਤੋਂ ਨਹੀਂ। ਕੀ ਇਹ ਪਹਿਲੀ ਰੇਂਡਰ ਢੀਲੀ ਹੈ? ਕੋਈ ਕਲਿਕ ਜੋ ਹੰਗ ਕਰਦਾ ਹੈ? ਫਾਰਮ ਭੇਜਣ ਤੋਂ ਬਾਅਦ ਲੰਬਾ ਇੰਤਜ਼ਾਰ? ਉਹ ਸਮਾਂ ਚੁਣੋ ਜਿਸ 'ਤੇ ਉਪਭੋਗਤਾ ਸ਼ਿਕਾਇਤ ਕਰਦੇ ਹਨ ਅਤੇ ਉੱਥੇ ਧਿਆਨ ਕੇਂਦ੍ਰਿਤ ਕਰੋ।
ਇੱਕ ਤੇਜ਼ ਦੌੜ ਕਰੋ ਤਾਂ ਜੋ ਪੁਸ਼ਟੀ ਕਰ ਸਕੋ ਕਿ ਸੁਸਤਤਾ ਅਸਲ ਹੈ ਅਤੇ ਦੁਹਰਾਓਯੋਗ ਹੈ। ਬਾਕੀ ਸਭ ਕੁਝ ਇੱਕੋ ਜਿਹਾ ਰੱਖੋ: ਇੱਕੋ ਪੇਜ, ਇੱਕੋ ਡਿਵਾਈਸ, ਜੇ ਸੰਭਵ ਹੋਏ ਤਾਂ ਇੱਕੋ ਨੈੱਟਵਰਕ। ਫਿਰ ਟ੍ਰਿਗਰ ਅਤੇ ਉਸ ਨਕਤੇ ਨੂੰ ਨੋਟ ਕਰੋ ਜਿੱਥੇ ਇਹ ਧੀਮਾ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ, ਜਿਵੇਂ "Pay 'ਤੇ ਕਲਿਕ ਕਰਨ ਤੋਂ ਬਾਅਦ ਬਟਨ ਇਕ ਸੇਕੰਡ ਲਈ ਜਮ ਜਾਂਦਾ ਹੈ" ਜਾਂ "ਸਕ੍ਰੋਲ ਕਰਨ 'ਤੇ ਪ੍ਰੋਡਕਟ ਲਿਸਟ ਆਉਂਦਿਆਂ ਜਾਗ ਨਾਲ ਰੁਕਾਵਟ ਹੁੰਦੀ ਹੈ"।
ਇਸਨੂੰ ਦੁਹਰਾਏ ਜਾਣ ਯੋਗ ਰੱਖਣ ਲਈ ਇਕ ਛੋਟਾ ਸਕ੍ਰਿਪਟ ਵਰਤਣਾ ਸਧਾਰਣ ਤਰੀਕਾ ਹੈ: ਪੇਜ ਫ੍ਰੈਸ਼ ਟੈਬ ਵਿੱਚ ਖੋਲ੍ਹੋ, ਵਿੱਥੀ ਲੱਗਣ ਵਾਲੀ ਕਾਰਵਾਈ ਕਰੋ, ਜਦੋਂ ਇਹ ਹੌਲੀ ਹੋਵੇ ਉਹ ਨਕਤਾ ਨੋਟ ਕਰੋ, ਫਿਰ ਇੱਕ ਵਾਰੀ ਫੇਰ ਦੁਹਰਾਓ ਤਾ ਪੁਸ਼ਟੀ ਹੋ ਜਾਏ।
ਇੱਕ ਜਾਂ ਦੋ ਬੇਸਲਾਈਨ ਰਿਕਾਰਡਿੰਗਾਂ ਲਓ, ਦਹਾਂ ਨਹੀਂ। ਤੁਸੀਂ ਸਿਰਫ ਇੰਨਾ ਸਬੂਤ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਕਹ ਸਕੋ, "ਹਾਂ, ਰੁਕਾਵਟ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਇਹ ਇਥੇ ਹੁੰਦੀ ਹੈ।"
ਇਕ ਵਾਰੀ ਤੁਸੀਂ ਰੁਕਾਵਟ ਨੂੰ ਦੁਹਰਾ ਸਕਦੇ ਹੋ, ਅਨੁਮਾਨ ਲਾਉਣਾ ਬੰਦ ਕਰੋ। ਇੱਕ ਪ੍ਰੋਫਾਇਲਰ ਖੋਲ੍ਹੋ (ਜ਼ਿਆਦਾਤਰ ਲੋਕਾਂ ਲਈ, ਬ੍ਰਾਊਜ਼ਰ ਦੀ Performance ਪੈਨਲ) ਅਤੇ ਸੁਸਤ ਇੰਟਰਐਕਸ਼ਨ ਦੀ ਇੱਕ ਦੌੜ ਰਿਕਾਰਡ ਕਰੋ। ਮਕਸਦ ਹਰ ਮੁੱਦੇ ਨੂੰ ਲੱਭਣਾ ਨਹੀਂ ਹੈ; ਇਹ ਜਾਣਨਾ ਹੈ ਕਿ ਸਮਾਂ ਕਿੱਥੇ ਲੰਘਦਾ ਹੈ।
ਸਭ ਤੋਂ ਵੱਡੇ ਸਮੇਂ ਦੇ ਬਲਾਕਾਂ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ। ਛੋਟੇ ਸਪਾਈਕ ਸੱਚ ਹੋ ਸਕਦੇ ਹਨ, ਪਰ ਉਹ ਅਕਸਰ ਇੱਕ ਨੋਟਿਸੇਬਲ ਦੇਰ ਦਾ ਏਕ ਕਾਰਨ ਨਹੀਂ ਬਣਦੇ।
ਰਿਕਾਰਡਿੰਗ ਨੂੰ ਪੜ੍ਹਨ ਦਾ ਇੱਕ ਫਾਇਦੇਮੰਦ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ ਸਮੇਂ ਨੂੰ ਕੁਝ ਬਕਟਾਂ ਵਿੱਚ ਵੰਡੋ: ਨੈੱਟਵਰਕ ਅਤੇ ਲੋਡਿੰਗ (ਰਿਕਵੇਸਟਾਂ ਦੀ ਉਡੀਕ), ਮੁੱਖ-ਥ੍ਰੈਡ ਸਕ੍ਰਿਪਟਿੰਗ (ਲੰਬੇ JavaScript ਟਾਸਕ), ਰੈਂਡਰ ਅਤੇ ਪੇਂਟ (ਲੇਆਉਟ ਅਤੇ ਸਟਾਈਲ ਕੰਮ), ਖਾਲੀ ਸਮਾਂ (ਕਿਸੇ ਹੋਰ ਚੀਜ਼ ਦੀ ਉਡੀਕ), ਅਤੇ ਦੁਹਰਾਉਂਦਾ ਕੰਮ (ਉਹੀ ਮਹਿੰਗਾ ਕਦਮ ਵਾਰ-ਵਾਰ ਹੋ ਰਿਹਾ ਹੈ)।
ਅਕਸਰ ਗਲਤੀ ਇਹ ਹੋੰਦੀ ਹੈ ਕਿ ਸਲੋ ਸਰਵਰ ਰਿਸਪਾਂਸ ਨੂੰ ਕਲਾਇਂਟ ਕੰਮ ਨਾਲ ਗਲਤ ਸਮਝ ਲਿਆ ਜਾਂਦਾ ਹੈ। ਜੇ ਟਾਈਮਲਾਈਨ ਦਿਖਾਉਂਦੀ ਹੈ ਕਿ ਰਿਕਵੇਸਟਾਂ ਦੀ ਉਡੀਕ ਵਿੱਚ ਲੰਮੇ ਖਾਲੀ ਪੜਾਅ ਹਨ, ਤਾਂ ਤੁਹਾਡਾ ਬੋਤਲਨੈਕ ਨੈੱਟਵਰਕ ਜਾਂ ਬੈਕਐਂਡ ਹੋ ਸਕਦਾ ਹੈ। ਜੇ ਇਹ ਮੁੱਖ ਟਰੈਡ 'ਤੇ ਲੰਬੇ ਟਾਸਕ ਦਿਖਾਉਂਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਫਰੰਟ-ਐਂਡ ਸਮੱਸਿਆ ਹੈ ਭਾਵੇਂ ਨੈੱਟਵਰਕ ਤੇਜ਼ ਹੋਵੇ।
ਕੋਈ ਵੀ ਬਦਲਾਅ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਜੋ ਤੁਸੀਂ ਦੇਖਿਆ ਉਸ 'ਤੇ ਆਧਾਰਿਤ ਇੱਕ ਛੋਟਾ, ਟੈਸਟਯੋਗ ਹਿਪੋਥੇਸਿਸ ਲਿਖੋ। ਉਦਾਹਰਨ: "ਪੇਜ ਧੀਮਾ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ API ਜਵਾਬ ਮਿਲਣ ਦੇ ਬਾਅਦ JSON ਪਾਰਸਿੰਗ ਮੁੱਖ ਥ੍ਰੈਡ ਨੂੰ ਬਲਾਕ ਕਰ ਰਿਹਾ ਹੈ।" ਇਹ ਵਾਕ ਅਗਲੇ ਕਦਮ ਨੂੰ ਸੈੱਟ ਕਰਦਾ ਹੈ।
ਜਦੋਂ ਤੁਸੀਂ ਸੰਭਾਵੀ ਬੋਤਲਨੈਕ ਪਛਾਣ ਲੈ ਲੈਂਦੇ ਹੋ, "ਹਰ ਚੀਜ਼ ٹھੀਕ ਕਰੋ" ਦੀ ਖਾਹਿਸ਼ ਤੋਂ ਬਚੋ। ਇੱਕ ਵੈਰੀਅਬਲ ਬਦਲੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਕਾਰਨ ਤੇ ਪ੍ਰਭਾਵ ਨੂੰ ਜੋੜ ਸਕੋ।
ਬਦਲਾਅ ਨੂੰ ਛੋਟਾ ਅਤੇ ਅਸਾਨ ਵਾਪਸੀਯੋਗ ਰੱਖੋ। ਵੱਡੇ ਰੀਰਾਈਟ ਨਤੀਜੇ ਨੂੰ ਧੁੰਦਲਾ ਕਰ ਦਿੰਦੇ ਹਨ: ਜੇ ਪਰਫਾਰਮੈਂਸ ਸੁਧਰਦੀ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਨਹੀਂ ਪਤਾ ਕਿ ਕਿਹੜੀ ਚੀਜ਼ ਕੰਮ ਕੀਤੀ। ਜੇ ਇਹ ਖਰਾਬ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਰੋਲਬੈਕ ਖਤਰਨਾਕ ਹੋ ਸਕਦਾ ਹੈ।
ਸਾਰੇ ਚੰਗੇ "ਇੱਕ-ਚੀਜ਼" ਬਦਲਾਅ ਖਾਸ ਅਤੇ ਟੈਸਟਯੋਗ ਹੁੰਦੇ ਹਨ। ਉਦਾਹਰਨਾਂ: ਇੱਕ ਇਤਨਾ-ਵੱਡਾ ਤੀਜਾ-ਪੱਖੀ ਸਕ੍ਰਿਪਟ ਜਿਹੜਾ ਰੇਂਡਰ ਨੂੰ ਬਲਾਕ ਕਰ ਰਿਹਾ ਹੈ, ਇੱਕ ਵੱਡੀ ਤਸਵੀਰ ਨੂੰ ਕੰਪ੍ਰੈਸ ਕਰਨਾ, ਇੱਕ ਮਹਿੰਗੇ ਡੀਬੀ ਕਵੇਰੀ 'ਤੇ ਕੈਸ਼ਿੰਗ ਲਗਾਉਣਾ, ਇੱਕ ਭਾਰੀ UI ਕੰਪੋਨੈਂਟ ਨੂੰ ਵੰਡਣਾ ਤਾਂ ਜੋ ਇਹ ਪਹਿਲੇ ਦ੍ਰਿਸ਼ਤ ਵਿੱਚ ਘੱਟ ਕੰਮ ਰੇਂਡਰ ਕਰੇ, ਜਾਂ ਪ੍ਰੋਫਾਇਲਰ ਵਿੱਚ ਵੇਖੇ ਇੱਕ ਗਰਮ ਲੂਪ ਦਾ ਕੰਮ ਘਟਾਉਣਾ।
ਕੋਡ ਛੇੜਨ ਤੋਂ ਪਹਿਲਾਂ ਲਿਖੋ ਕਿ ਤੁਸੀਂ ਕੀ ਬਦਲੇਆ, ਕਿਉਂ ਇਹ ਚੁਣਿਆ, ਅਤੇ ਤੁਸੀਂ ਕੀ ਉਮੀਦ ਕਰਦੇ ਹੋ ਕਿ ਸੁਧਰੇਗਾ (ਉਦਾਹਰਨ ਲਈ, "ਮੁੱਖ-ਥ੍ਰੈਡ ਸਮਾਂ ਘਟੇਗਾ" ਜਾਂ "DB ਸਮਾਂ ਅੱਧਾ ਹੋ ਜਾਵੇਗਾ")।
ਜੇ ਤੁਹਾਡੀ ਟੀਮ ਇੱਕ ਪਲੇਟਫਾਰਮ ਵਰਤੀਦੀ ਹੈ ਜੋ ਸਨੇਪਸ਼ਾਟ ਅਤੇ ਰੋਲਬੈਕ ਸਹਾਇਕ ਹੈ (ਜਿਵੇਂ Koder.ai), ਤਾਂ ਬਦਲਾਅ ਤੋਂ ਸਿੱਧਾ ਪਹਿਲਾਂ ਸਨੇਪਸ਼ਾਟ ਲੈ ਲਓ ਤਾਂ ਜੋ "ਛੋਟਾ ਅਤੇ ਵਾਪਸ ਲੈਣਯੋਗ" ਅਸਲੀ ਬਣੇ।
ਤੁਸੀਂ ਇੱਕ ਚੀਜ਼ ਬਦਲੀ। ਹੁਣ ਸਾਬਤ ਕਰੋ ਕਿ ਇਸ ਨਾਲ ਮਦਦ ਹੋਈ।
ਉਹੀ ਟੈਸਟ ਸੈਟਅਪ ਮੁੜ ਚਲਾਓ ਜੋ ਤੁਸੀਂ ਬੇਸਲਾਈਨ ਲਈ ਵਰਤਿਆ: ਇੱਕੋ ਡਿਵਾਈਸ, ਇੱਕੋ ਬ੍ਰਾਊਜ਼ਰ ਵਰਜਨ, ਇੱਕੋ ਰੂਟ ਅਤੇ ਫਲੋ, ਅਤੇ ਇਕੋ ਦੌੜਾਂ ਦੀ ਗਿਣਤੀ। ਪਹਿਲਾਂ-ਬਾਅਦ ਦੀ ਤੁਲਨਾ ਉਹੀ ਮੈਟ੍ਰਿਕਸ ਵਰਤ ਕੇ ਕਰੋ। ਰਾਹ ਵਿੱਚ ਕੋਈ ਨਵਾਂ ਮੈਟ੍ਰਿਕ ਨਾ ਜੋੜੋ ਸਿਰਫ ਇਸ ਲਈ ਕਿ ਉਹ ਚੰਗਾ ਲੱਗਦਾ ਹੈ।
ਸ਼ੋਰ (noise) ਟੀਮਾਂ ਦੇ ਵਿਚਕਾਰ ਬਹਿਸ ਦਾ ਸਭ ਤੋਂ ਆਮ ਕਾਰਨ ਹੈ। ਗਰਮ/ਠੰਢੇ ਕੈਸ਼, ਐਕਸਟੈਂਸ਼ਨ ਜਾਂ ਬੈਕਗ੍ਰਾਊਂਡ ਪ੍ਰੋਸੈੱਸ, ਵੱਖ-ਵੱਖ ਨੈੱਟਵਰਕ ਹਾਲਾਤ ਜਾਂ VPN, ਸਰਵਰ ਵੈਰੀਅਂਸ (ਖ਼ਾਮੋਸ਼ ਮਿੰਟ vs ਬਿਜ਼ੀ ਮਿੰਟ), ਅਤੇ "ਡਿਪਲੋਇਲ ਤੋਂ ਬਾਅਦ ਤੁਰੰਤ" ਅਤੇ ਸਥਿਰ ਅਵਸਥਾ ਵਿੱਚ ਫ਼ਰਕ 'ਤੇ ਧਿਆਨ ਦਿਓ।
ਜੇ ਮੀਡੀਅਨ ਸੁਧਰਦਾ ਹੈ ਪਰ ਸਭ ਤੋਂ ਖਰਾਬ ਕੇਸ ਬਦਤਰ ਹੋ ਜਾਵੇ, ਤਾਂ ਇਹ ਇੱਕ ਅਸਲ ਤਰ੍ਹਾਂ ਦਾ ਟਰੇਡਆਫ ਹੈ। ਤੁਹਾਡੇ ਉਪਭੋਗਤਿਆਂ ਲਈ ਕੀ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਉਹ ਨਿਰਧਾਰਤ ਕਰੋ ਅਤੇ ਫ਼ੈਸਲਾ ਦਰਜ ਕਰੋ: ਬਦਲਾਅ ਰੱਖੋ, ਰਿਵਰਟ ਕਰੋ, ਜਾਂ ਨਵੀਂ ਹਿਪੋਥੇਸਿਸ ਲਿਖੋ ਅਤੇ ਫੇਰ ਟੈਸਟ ਕਰੋ।
ਪਰਫਾਰਮੈਂਸ ਕੰਮ ਬੇਲਗਾਮ ਹੋ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਗਲਤ ਚੀਜ਼ ਮਾਪ ਰਹੇ ਹੋ ਜਾਂ ਇਕੱਠੇ ਬਹੁਤ ਸਾਰੀਆਂ ਚੀਜ਼ਾਂ ਬਦਲ ਦਿੰਦਿਆਂ ਹੋ। ਤੁਸੀਂ ਬਹੁਤ ਮਿਹਨਤ ਖਰਚ ਕਰ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਕੋਈ ਸਾਫ਼ ਜਿੱਤ ਦੇ, ਭਾਵੇਂ ਤੁਹਾਡਾ ਐਪ ਕੁਝ ਸੁਧਾਰਾਂ ਦੇ ਰਿਹਾ ਹੋਵੇ।
ਇੱਕ ਆਮ ਗਲਤੀ ਇੱਕ ਇਕੱਲੇ ਸਕੋਰ ਨੂੰ ਲਕੜੀ ਬਣਾਉਣਾ ਹੈ। ਸਕੋਰ ਕੰਮ ਆ ਸਕਦੇ ਹਨ, ਪਰ ਉਪਭੋਗਤਾ "92" ਨਹੀਂ ਦੇਖਦੇ — ਉਹ "ਪੇਜ 2 ਸਕਿੰਟ ਵਿੱਚ ਸਮਗਰੀ ਦਿਖਾਉਂਦਾ ਹੈ" ਜਾਂ "Buy ਤੇ ਟੈਪ ਕਰਨ 'ਤੇ ਜਵਾਬ ਤੁਰੰਤ ਆਉਂਦਾ ਹੈ" ਮਹਿਸੂਸ ਕਰਦੇ ਹਨ। ਇੱਕ ਉਪਭੋਗਤਾ-ਦਿੱਖੀ ਨਤੀਜੇ ਚੁਣੋ ਅਤੇ ਉਸਨੂੰ ਲਗਾਤਾਰ ਮਾਪੋ।
ਇੱਕ ਹੋਰ ਜਾਲ ਸਿਰਫ਼ ਤਾਕਤਵਰ ਲੈਪਟੌਪ 'ਤੇ ਟੈਸਟ ਕਰਨ ਦਾ ਹੈ। ਬਹੁਤ ਸਰਤੀਆਂ ਮਿਡ-ਰੇਂਜ ਫੋਨਾਂ, ਝਟਪਟ ਨੈੱਟਵਰਕਾਂ, ਜਾਂ ਜਦੋਂ CPU ਬਿਜ਼ੀ ਹੋਵੇ, 'ਤੇ ਹੀ ਦਿਖਾਈ ਦੇਂਦੀਆਂ ਹਨ। ਜੇ ਤੁਸੀਂ ਸਿਰਫ਼ ਸਭ ਤੋਂ ਵਧੀਆ ਡਿਵਾਈਸ 'ਤੇ ਪ੍ਰੋਫਾਈਲ ਕਰੋਗੇ, ਤਾਂ ਤੁਸੀਂ ਬੋਤਲਨੈਕ मिस ਕਰ ਸਕਦੇ ਹੋ।
ਗੁੰਝਲਦਾਰਤਾ ਆਮ ਤੌਰ 'ਤੇ ਇਹਨਾਂ ਪਟਰਨਾਂ ਤੋਂ ਆਉਂਦੀ ਹੈ: ਆਸਾਨ ਨੂੰ ਅਪਟਾਇਮਾਈਜ਼ ਕਰਨਾ ਨਾ ਕਿ ਸਭ ਤੋਂ ਵਧੀਆਂ ਰੁਕਾਵਟ; ਬਹੁਤ ਸਾਰੀਆਂ ਛੋਟੀਆਂ ਤਬਦੀਲੀਆਂ ਇਕੱਠੀਆਂ ਕਰ ਦੇਣਾ; ਹਰੇਕ ਦੌੜ 'ਚ ਟੈਸਟ ਪਾਥ ਬਦਲਦੇ ਰਹਿਣਾ; ਮੁੜ-ਟੈਸਟ ਛੱਡ ਦੇਣਾ ਕਿਉਂਕਿ ਇਹ "ਤੇਜ਼ ਮਹਿਸੂਸ" ਹੁੰਦਾ ਹੈ; ਜਾਂ ਬੇਸਲਾਈਨ ਨੂੰ ਫੇਰ ਨਾ ਚਲਾਉਂਦੇ ਹੋਏ ਜਿੱਤ ਦਾ ਐਲਾਨ ਕਰ ਦਿੱਤਾ ਜਾਵੇ।
ਜੇ ਤੁਸੀਂ ਐਪ Koder.ai ਵਰਤ ਕੇ ਤਿਆਰ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਵੀ ਇਕੋ ਅਨੁਸ਼ਾਸਨ ਲਾਗੂ ਹੁੰਦਾ ਹੈ: ਇੱਕ ਚੇਜ਼ ਬਦਲੋ, ਫਿਰ ਓਹੀ ਫਲੋ 'ਤੇ ਵੈਰੀਫਾਈ ਕਰੋ ਤਾਂ ਜੋ ਨਤੀਜੇ 'ਤੇ ਭਰੋਸਾ ਕੀਤਾ ਜਾ ਸਕੇ।
ਜੇ ਤੁਸੀਂ ਇੱਕ ਆਦਤ ਰੱਖੋ, ਤਾਂ ਇਹ ਰੱਖੋ: ਸੁਧਾਰਨ ਤੋਂ ਪਹਿਲਾਂ ਮਾਪੋ। ਮਕਸਦ ਅਨੰਤ ਡੇਟਾ ਨਹੀਂ, ਪਰ ਇੱਕ ਦਹਰਾਏ ਜਾਣਯੋਗ ਲੂਪ ਹੈ ਜਿਸ 'ਤੇ ਤੁਸੀਂ ਭਰੋਸਾ ਕਰ ਸਕੋ।
ਪੂਰੀ ਸਾਈਟ 'ਦੀ ਬਜਾਏ ਠੀਕ ਉਪਭੋਗਤਾ ਯਾਤਰਾ ਨਾਮਵਾਂ ਕਰੋ। "ਹੋਮਪੇਜ ধੀਮਾ ਹੈ" ਅਸਪਸ਼ਟ ਹੈ। "Product page ਤੋਂ Buy ਕਲਿਕ ਕਰਕੇ confirmation ڏਿਖਾਈ ਦੇਣ ਤੱਕ" ਤੁਹਾਨੂੰ ਇੱਕ ਕਲਿਕ ਪਾਥ ਦਿੰਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਦੁਹਰਾ ਸਕਦੇ ਹੋ।
ਇਸ ਚੈਕਲਿਸਟ ਨੂੰ ਵਰਤੋ:
ਪਰਫਾਰਮੈਂਸ ਕੰਮ ਦਾ ਸ਼ਾਂਤ ਰੂਪ ਸਧਾਰਣ ਹੈ: ਇੱਕ ਪਾਥ, ਇੱਕ ਸੈਟਅਪ, ਇੱਕ ਬਦਲਾਅ, ਇੱਕ ਪੁਸ਼ਟੀ ਕੀਤੀ ਨਤੀਜਾ।
ਆਮ ਸ਼ਿਕਾਇਤ: ਗਾਹਕ "Pay" 'ਤੇ ਕਲਿਕ ਕਰਨ ਤੋਂ ਬਾਅਦ ਚੈਕਆਉਟ ਧੀਮਾ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ। ਲੋਕ ਅਨੁਮਾਨ ਲਾਉਣ ਲੱਗ ਪੈਂਦੇ ਹਨ (ਤਸਵੀਰਾਂ, ਫੋਂਟ, ਬਟਨ)। ਬਜਾਏ ਇਸਦੇ, ਇਸਨੂੰ ਇਕ ਟੈਸਟ ਵਾਂਗ ਵਰਤੋ ਜੋ ਤੁਸੀਂ ਦੁਹਰਾ ਸਕੋ।
ਇੱਕ ਬੇਸਲਾਈਨ ਸੈੱਟ ਕਰੋ ਜੋ ਤੁਸੀਂ ਮੁੜ ਚਲਾ ਸਕੋ। ਇੱਕ ਡਿਵਾਈਸ ਅਤੇ ਇੱਕ ਪਾਥ ਚੁਣੋ (cart -> checkout -> Pay -> confirmation)। ਨੈੱਟਵਰਕ ਥਰੌਟਲਿੰਗ ਚਾਲੂ ਕਰੋ (ਉਦਾਹਰਨ ਲਈ, Fast 3G) ਅਤੇ ਹਰ ਦੌੜ 'ਚ ਇਹ ਹੀ ਰੱਖੋ। ਇੱਕ ਸਧਾਰਣ ਨੰਬਰ ਮਾਪੋ: "Pay 'ਤੇ ਕਲਿਕ ਕਰਨ ਤੋਂ ਲੈ ਕੇ confirmation ਸਕਰੀਨ ਤੱਕ ਦਾ ਸਮਾਂ"।
ਫਿਰ ਓਹੀ ਲਹਜ਼ੇ ਦੀ ਪ੍ਰੋਫਾਇਲ ਕਰੋ ਅਤੇ ਦੇਖੋ ਕਿ ਸਮਾਂ ਕਿੱਥੇ ਲੰਘਦਾ ਹੈ। ਤੁਸੀਂ ਆਮ ਤੌਰ 'ਤੇ ਤਿੰਨ ਬਕਟਾਂ ਵਿਚੋਂ ਫੈਸਲਾ ਕਰ ਰਹੇ ਹੋ: ਨੈੱਟਵਰਕ (ਲੰਬਾ ਰਿਕਵੇਸਟ ਜਾਂ ਬਹੁਤ ਸਾਰੀਆਂ ਰਿਕਵੇਸਟਾਂ), ਸਰਵਰ (ਭੁਗਤਾਨ ਕਾਲ ਹੀ ਧੀਮੀ ਹੈ ਜਦਕਿ ਬ੍ਰਾੁਜ਼ਰ ਆਈਡਲ ਹੈ), ਜਾਂ ਮੁੱਖ-ਥ੍ਰੈਡ (ਬ੍ਰਾੁਜ਼ਰ ਜਾਵਾਸਕ੍ਰਿਪਟ ਚਲਾ ਰਿਹਾ ਹੈ ਅਤੇ UI ਅਪਡੇਟ ਨਹੀਂ ਕਰ ਸਕਦਾ)।
ਕਲਪਨਾ ਕਰੋ ਕਿ ਪ੍ਰੋਫਾਈਲ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ "Pay" 'ਤੇ ਕਲਿਕ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਬ੍ਰਾਊਜ਼ਰ ਇਕ analytics ਰਿਕਵੇਸਟ ਅਤੇ ਇੱਕ fraud-check ਸਕ੍ਰਿਪਟ ਕਾਲ ਕਰਦਾ ਹੈ, ਅਤੇ payment ਰਿਕਵੇਸਟ ਉਹਨਾਂ ਦੇ ਪਿੱਛੇ ਰੁਕਿਆ ਹੋਇਆ ਹੈ। ਇਹ "ਸਭ ਕੁਝ ਤੇਜ਼ ਕਰੋ" ਦੀ ਸਮੱਸਿਆ ਨਹੀਂ ਹੈ; ਇਹ ਇੱਕ ਬਲੋਕਿੰਗ ਕਦਮ ਹੈ।
ਜਾਣ-ਬੂਝ ਕੇ ਇੱਕ ਬਦਲਾਅ ਕਰੋ। ਉਦਾਹਰਨ ਲਈ, payment ਰਿਕਵੇਸਟ ਨੂੰ ਤੁਰੰਤ ਸ਼ੁਰੂ ਹੋਣ ਦਿਓ, ਅਤੇ analytics ਨੂੰ ਸਿਰਫ confirmation ਸਕਰੀਨ ਦਿਖਣ ਤੋਂ ਬਾਅਦ ਭੇਜੋ।
ਇੱਕੋ ਸੈਟਅਪ ਨਾਲ ਵੈਰੀਫਾਈ ਕਰੋ: ਇੱਕੋ ਥਰੌਟਲਿੰਗ, ਇੱਕੋ ਕਦਮ, ਕਈ ਦੌੜ। ਜੇ confirmation ਸਮਾਂ ਘਟਦਾ ਹੈ ਅਤੇ ਐਰਰ ਵੱਧਦੇ ਨਹੀਂ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਅਸਲ ਜਿੱਤ ਹੈ। ਨਾਲ ਹੀ ਇਹ ਵੀ ਜਾਂਚੋ ਕਿ ਤੁਸੀਂ refunds, retries, ਜਾਂ double-submit ਰੱਖਿਆ ਨਹੀਂ ਤੋੜੀ।
ਜਦੋਂ ਇਹ ਇੱਕ ਰੁਟੀਨ ਬਣ ਜਾਵੇ ਨਾ ਕਿ ਰੇਸਕਿਊ ਮਿਸ਼ਨ, ਤਾਂ ਪਰਫਾਰਮੈਂਸ ਸੰਭਾਲਣਾ ਆਸਾਨ ਰਹਿੰਦਾ ਹੈ। ਮਾਪਣ ਨੂੰ ਡਿਫੌਲਟ ਕਾਰਵਾਈ ਬਣਾ ਦਿਓ, ਭਾਵੇਂ ਸਭ ਕੁਝ ਠੀਕ ਲੱਗ ਰਿਹਾ ਹੋਵੇ।
ਇੱਕ ਛੋਟਾ ਸੈੱਟ ਮੈਟ੍ਰਿਕਸ ਚੁਣੋ ਜੋ ਤੁਹਾਡੀ ਟੀਮ ਹਮੇਸ਼ਾ ਟ੍ਰੈਕ ਕਰੇਗੀ। ਇਸਨੂੰ ਲਗਾਤਾਰ ਰੱਖੋ ਤਾਂ ਕਿ ਰੁਝਾਨ ਆਸਾਨੀ ਨਾਲ ਦਿਖਾਈ ਦੇਣ:
ਇਨ੍ਹਾਂ ਮੈਟ੍ਰਿਕਸ ਦੇ ਆਸ-ਪਾਸ ਇੱਕ ਲੂਪ ਬਣਾਓ। ਅਕਸਰ ਇੱਕ ਹਫ਼ਤਾਵਾਰ ਬੇਸਲਾਈਨ ਚੈੱਕ ਕਾਫ਼ੀ ਹੁੰਦਾ ਹੈ। ਜਦੋਂ ਕੋਈ ਮੈਟ੍ਰਿਕ ਡ੍ਰਿਫਟ ਕਰੇ, ਉਹ ਤੁਹਾਡਾ ਟ੍ਰਿਗਰ ਹੈ ਕਿ ਦੁਬਾਰਾ ਰੁਕਾਵਟ ਨੂੰ ਦੁਹਰਾਓ, ਪ੍ਰੋਫਾਈਲ ਕਰੋ, ਇੱਕ ਬਦਲਾਅ ਕਰੋ, ਅਤੇ ਪ੍ਰਭਾਵ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ।
ਜੋ ਕੁਝ ਤੁਸੀਂ ਮਾਪਦੇ ਹੋ ਉਸ ਦਾ ਸਧਾਰਣ ਪਰਫਾਰਮੈਂਸ ਲੌਗ ਰੱਖੋ। ਦਰਜ ਕਰੋ ਕਿ ਤੁਸੀਂ ਕੀ ਮਾਪਿਆ (ਡਿਵਾਈਸ, ਨੈੱਟਵਰਕ, ਅਤੇ ਬਿਲਡ ਸਮੇਤ), ਤੁਸੀਂ ਕੀ ਬਦਲਿਆ, ਅਤੇ ਨੰਬਰਾਂ ਨੇ ਬਦਲ ਕੇ ਕੀ ਕੀਤਾ।
ਜੇ ਤੁਸੀਂ Koder.ai ਨਾਲ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ Planning Mode ਤੁਹਾਨੂੰ ਯਾਤਰਾ ਅਤੇ ਤੁਸੀਂ ਕਿੰਨਾ ਮੈਟ੍ਰਿਕ ਚਾਹੁੰਦੇ ਹੋ ਇਹ ਲਿਖਣ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ। ਫਿਰ ਸਨੇਪਸ਼ਾਟ ਅਤੇ ਰੋਲਬੈਕ ਵਰਤ ਕੇ ਐਕਸਪੈਰੀਮੈਂਟ ਸੁਰੱਖਿਅਤ ਰੱਖੋ: ਸਨੇਪਸ਼ਾਟ, ਇਕ ਚੇਜ਼ ਲਾਗੂ ਕਰੋ, ਮੁੜ-ਟੈਸਟ ਕਰੋ, ਅਤੇ ਜੇ ਨਤੀਜੇ ਸ਼ੋਰ ਵਾਲੇ ਜਾਂ ਬੁਰੇ ਹੋਣ ਤਾਂ ਵਾਪਸ ਲੈ ਆਓ।
ਯੋਜਨਾ ਬਣਾਉਣ ਜਾਂ ਸਮੀਖਿਆ ਵਿੱਚ ਇੱਕ ਸਵਾਲ ਸਭਿਆਚਾਰ ਨੂੰ ਤੰਦਰੁਸਤ ਰੱਖਦਾ ਹੈ: "ਅਸੀਂ ਕੀ ਮਾਪਿਆ, ਅਤੇ ਇਸ ਨਾਲ ਕੀ ਬਦਲਿਆ?"
ਕਿਉਂਕਿ ਤੁਸੀਂ ਆਸਾਨੀ ਨਾਲ ਉਨ੍ਹਾਂ ਚੀਜ਼ਾਂ 'ਤੇ ਘੰਟਿਆਂ ਖਰਚ ਕਰ ਸਕਦੇ ਹੋ ਜੋ ਹਕੀਕਤ ਵਿੱਚ ਦੇਰ ਦਾ ਕਾਰਨ ਨਹੀਂ ਹੁੰਦੀਆਂ। ਪਹਿਲਾਂ ਇਹ ਸਾਬਤ ਕਰੋ ਕਿ ਸਮਾਂ ਕਿੱਥੇ ਲੱਗ ਰਿਹਾ ਹੈ (ਨੈੱਟਵਰਕ, ਸਰਵਰ, ਮੁੱਖ ਥ੍ਰੈਡ, ਰੈਂਡਰਿੰਗ), ਫਿਰ ਸਭ ਤੋਂ ਵੱਡੇ ਬੋਤਲਨੈਕ ਨੂੰ ਟਾਰਗੇਟ ਕਰੋ।
ਇੱਕ ਖਾਸ ਐਕਸ਼ਨ ਅਤੇ ਠੀਕ ਸ਼ਰਤਾਂ ਲਿਖੋ, ਫਿਰ ਇਹ ਨੂੰ ਦੁਹਰਾਓ:
ਜੇ ਤੁਸੀਂ ਇਹ ਦੁਹਰਾਉ ਨਹੀਂ ਸਕਦੇ, ਤਾਂ ਤੁਸੀਂ ਨਤੀਜੇ 'ਤੇ ਭਰੋਸਾ ਨਹੀਂ ਕਰ ਸਕਦੇ।
ਉਹ 1–3 ਮੈਟ੍ਰਿਕਸ ਚੁਣੋ ਜੋ ਉਪਭੋਗਤਾ ਦੇ ਤਜਰਬੇ ਨਾਲ ਮਿਲਦੇ ਹਨ:
ਇੱਕ ਵਾਰੀ ਵਿੱਚ ਬਹੁਤ ਸਾਰੇ ਨੰਬਰ ਟ੍ਰੈਕ ਨਾ ਕਰੋ, ਨਹੀਂ ਤਾਂ ਤુਸੀਂ ਚੇਰੀ-ਪਿਕਿੰਗ ਕਰ ਲਵੋਗੇ।
ਲੈਬ ਡੇਟਾ ਕਾਬੂਵਾਲੇ ਸੈਟਅਪ ਵਿੱਚ ਮਿਲਦਾ ਹੈ (ਖਾਸ ਲੈਪਟੌਪ ਜਾਂ টੈਸਟ ਡਿਵਾਈਸ, ਸਥਿਰ ਨੈੱਟਵਰਕ), ਜੋ ਡੀਬੱਗਿੰਗ ਲਈ ਵਧੀਆ ਹੈ। ਰੀਅਲ ਯੂਜ਼ਰ ਡੇਟਾ ਉਹ ਹੈ ਜੋ ਵਾਸਤਵਿਕ ਲੋਕ ਅਨੁਭਵ ਕਰਦੇ ਹਨ: ਵੱਖ-ਵੱਖ ਡਿਵਾਈਸ, ਇਲਾਕੇ ਅਤੇ ਕਨੈਕਸ਼ਨ ਕੁਆਲਿਟੀ।
ਚੰਗਾ ਨਿਯਮ: ਰੀਅਲ ਯੂਜ਼ਰ ਡੇਟਾ ਨਾਲ ਸਭ ਤੋਂ ਨੁਕਸਾਨਦਾਇਕ ਯਾਤਰਾਵਾਂ ਲੱਭੋ, ਫਿਰ ਲੈਬ ਪ੍ਰੋਫਾਇਲਿੰਗ ਨਾਲ ਸਮਝੋ ਕਿ ਉਹ ਕਿਉਂ ਧੀਮੇ ਹਨ ਅਤੇ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਫਿਕਸ ਟੈਸਟ ਕਰੋ।
ਇਸਨੂੰ ਇੱਕ ਬੱਗ ਰਿਪੋਰਟ ਵਾਂਗ ਸੋਚੋ:
ਇਸ ਨਾਲ ਗੱਲ-ਬਾਤ ਰਾਏਂ ਤੋਂ ਸਬੂਤਤਕ ਵਿਚਾਰਾਂ ਵੱਲ ਬਦਲ ਜਾਂਦੀ ਹੈ।
ਇੱਕ ਪ੍ਰੋਫਾਇਲਰ ਵਿੱਚ ਸੁਸਤ ਇੰਟਰਐਕਸ਼ਨ ਨੂੰ ਰਿਕਾਰਡ ਕਰੋ ਅਤੇ ਸਭ ਤੋਂ ਵੱਡੇ ਸਮੇਂ ਦੇ ਖੰਡ ਲਈ ਦੇਖੋ:
ਫਿਰ ਇੱਕ ਇਕ-ਜੁਮਲੇ ਵਾਲੀ ਹਿਪੋਥੇਸਿਸ ਲਿਖੋ ਜੋ ਤੁਸੀਂ ਟੈਸਟ ਕਰ ਸਕੋ।
ਇਹ ਕਾਰਨ-ਅਸਰ ਸਾਫ਼ ਰੱਖਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਪੰਜ ਚੀਜ਼ਾਂ ਬਦਲੋ ਅਤੇ ਪੇਜ ਤੇਜ਼ ਹੋ ਜਾਵੇ, ਤਾਂ ਤੁਹਾਨੂੰ ਨਹੀਂ ਪਤਾ ਚਲ੍ਹੇਗਾ ਕਿ ਕੀ ਕੰਮ ਕੀਤਾ। ਜੇ ਇਹ ਹੌਲੀ ਹੋ ਜਾਵੇ, ਤਾਂ ਰੋਲਬੈਕ ਮੁਸ਼ਕਲ ਬਣ ਜਾਂਦਾ ਹੈ।
ਇੱਕ ਵਰਤਮਾਨ ਨਿਯਮ: ਇੱਕ ਬਦਲਾਅ ਜੋ ਤੁਸੀਂ ਸਮਝਾ ਸਕੋ, ਇੱਕ ਮੈਟ੍ਰਿਕ ਜੋ ਤੁਹਾਨੂੰ ਲੱਗੇਗਾ ਕਿ ਬਦਲੇਗਾ, ਫਿਰ ਮੁੜ ਮਾਪੋ।
ਉਹੀ ਟੈਸਟ ਸੈਟਅਪ ਦੁਹਰਾਓ ਜੋ ਤੁਸੀਂ ਬੇਸਲਾਈਨ ਲਈ ਵਰਤੇ ਸੀ ਅਤੇ ਪਹਿਲਾਂ/ਬਾਅਦ ਦੀ ਤੁਲਨਾ ਕਰੋ:
ਜੇ ਮੀਡੀਅਨ ਸੁਧਰਦਾ ਹੈ ਪਰ ਵੱਛੋ-ਕੇਸ ਬੁਰਾ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਇਹ ਇੱਕ ਹਕੀਕਤੀ ਟਰੇਡਆਫ ਹੈ — ਫੈਸਲਾ ਕਰੋ ਅਤੇ ਦਰਜ ਕਰੋ।
ਆਮ ਗਲਤੀਆਂ:
ਇੱਕ ਯਾਤਰਾ, ਇੱਕ ਸੈਟਅਪ ਅਤੇ ਇੱਕ ਮਾਪੇ ਨਤੀਜੇ 'ਤੇ ਜ਼ੋਰ ਦਿਓ।
ਉਨ੍ਹਾਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਅਤੇ ਤੁਲਨਾਤਮਕ ਬਣਾਉਣ ਲਈ ਵਰਤੋ:
ਉਪਕਰਣ ਮਦਦ ਕਰਦੇ ਹਨ, ਪਰ ਅਸਲ ਜਿੱਤ ਦਹਰਾਏ ਜਾਣ ਵਾਲੇ ਲੂਪ: ਬੇਸਲਾਈਨ → ਪ੍ਰੋਫਾਈਲ → ਇੱਕ ਬਦਲਾਅ → ਵੈਰੀਫਾਈ ਹੈ।