27 ਨਵੰ 2025·8 ਮਿੰਟ
100k ਰੋਜ਼ਾਂ ਵਾਲੀਆਂ ਤੇਜ਼ ਡੈਸ਼ਬੋਰਡ ਲਿਸਟ: ਪਹਿਲਾਂ ਕੀ ਕਰੋ
ਪੇਜੀਨੇਸ਼ਨ, ਵਰਚੁਅਲਾਈਜ਼ੇਸ਼ਨ, ਸਮਝਦਾਰ ਫਿਲਟਰ ਅਤੇ ਬਿਹਤਰ ਕੁਐਰੀਜ਼ ਵਰਤ ਕੇ 100k ਰੋਜ਼ਾਂ ਵਾਲੀਆਂ ਡੈਸ਼ਬੋਰਡ ਲਿਸਟਾਂ ਕਿਵੇਂ ਤੇਜ਼ ਬਣਾਈਆਂ ਜਾਣ — ਤਾਂ ਜੋ ਅੰਦਰੂਨੀ ਟੂਲ ਤੇਜ਼ ਰਹਿਣ।
ਪੇਜੀਨੇਸ਼ਨ, ਵਰਚੁਅਲਾਈਜ਼ੇਸ਼ਨ, ਸਮਝਦਾਰ ਫਿਲਟਰ ਅਤੇ ਬਿਹਤਰ ਕੁਐਰੀਜ਼ ਵਰਤ ਕੇ 100k ਰੋਜ਼ਾਂ ਵਾਲੀਆਂ ਡੈਸ਼ਬੋਰਡ ਲਿਸਟਾਂ ਕਿਵੇਂ ਤੇਜ਼ ਬਣਾਈਆਂ ਜਾਣ — ਤਾਂ ਜੋ ਅੰਦਰੂਨੀ ਟੂਲ ਤੇਜ਼ ਰਹਿਣ।
ਲਿਸਟ ਸਕ੍ਰੀਨ ਅਕਸਰ ਠੀਕ ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ ਤਕ਼ਦੀਰੋ ਜਦੋਂ ਨਹੀਂ ਹੁੰਦੀ। ਯੂਜ਼ਰ ਛੋਟੀ-ਛੋਟੀ ਰੁਕਾਵਟਾਂ ਮਹਿਸੂਸ ਕਰਨ ਲੱਗਦੇ ਹਨ: ਸਕ੍ਰੋਲ ਸਟਟਰ ਕਰਦਾ ਹੈ, ਹਰ ਅਪਡੇਟ ਤੋਂ ਬਾਅਦ ਪੇਜ ਥੋੜ੍ਹਾ ਫਸਦਾ ਹੈ, ਫਿਲਟਰ ਸੈਕਂਡ ਲੈਂਦੇ ਹਨ ਅਤੇ ਹਰ ਕਲਿੱਕ 'ਤੇ ਸਪਿੰਨਰ ਆ ਜਾਂਦਾ ਹੈ। ਕਈ ਵਾਰੀ ਬ੍ਰਾਊਜ਼ਰ ਟੈਬ ਫ੍ਰੀਜ਼ ਲੱਗਦੀ ਹੈ ਕਿਉਂਕਿ UI ਥ੍ਰੈੱਡ ਰੁਝਿਆ ਹੋਇਆ ਹੁੰਦਾ ਹੈ।
100k ਰੋਜ਼ ਇੱਕ ਆਮ ਮੋੜ ਹੈ ਕਿਉਂਕਿ ਇਹ ਸਿਸਟਮ ਦੇ ਹਰ ਹਿੱਸੇ 'ਤੇ ਦਬਾਅ ਪਾਉਂਦਾ ਹੈ। ਡੇਟਾਸੇਟ ਡੇਟਾਬੇਸ ਲਈ ਆਮ ਹੈ, ਪਰ ਇਹ ਇੰਨਾ ਵੱਡਾ ਹੁੰਦਾ ਹੈ ਕਿ ਛੋਟੀ-ਛੋਟੀ ਅਣਗਿਣਤੀਆਂ ਬਰਾਊਜ਼ਰ ਅਤੇ ਨੈੱਟਵਰਕ ਵਿੱਚ ਸਪੱਸ਼ਟ ਹੋ ਜਾਂਦੀਆਂ ਹਨ। ਜੇ ਤੁਸੀਂ ਸਭ ਕੁਝ ਇਕੱਠੇ ਦਿਖਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋਗੇ ਤਾਂ ਸਾਦਾ ਸਕ੍ਰੀਨ ਭਾਰੀ ਪਾਈਪਲਾਈਨ ਬਣ ਜਾਂਦੀ ਹੈ।
ਲਕੜੀ ਦਾ ਮਕਸਦ ਸਾਰੀਆਂ ਰੋਜ਼ਾਂ ਰੇਂਡਰ ਕਰਨਾ ਨਹੀਂ ਹੈ। ਮਕਸਦ ਕਿਸੇ ਨੂੰ ਜਲਦੀ ਉਹ ਚੀਜ਼ ਲੱਭਣ ਵਿੱਚ ਮਦਦ ਕਰਨਾ ਹੈ ਜੋ ਉਹ ਚਾਹੁੰਦਾ ਹੈ: ਸਹੀ 50 ਰੋਜ਼, ਅਗਲਾ ਪੇਜ, ਜਾਂ ਫਿਲਟਰ ਅਧਾਰਤ ਇੱਕ ਨਿੱਘੀ ਸਲਾਈਸ।
ਕੰਮ ਨੂੰ ਚਾਰ ਹਿੱਸਿਆਂ ਵਿੱਚ ਵੰਡਣਾ ਮਦਦਗਾਰ ਹੁੰਦਾ ਹੈ:
ਜੇ ਕੋਈ ਇੱਕ ਹਿੱਸਾ ਮਹਿੰਗਾ ਹੈ ਤਾਂ ਪੂਰੀ ਸਕ੍ਰੀਨ ਧੀਮੀ ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ। ਇੱਕ ਸਧਾਰਨ ਸਰਚ ਬਾਕਸ ਇੱਕ ਐਸਾ ਰਿਕਵੇਸਟ ਟ੍ਰਿਗਰ ਕਰ ਸਕਦਾ ਹੈ ਜੋ 100k ਰੋਜ਼ਾਂ ਸੋਰਟ ਕਰਦਾ, ਹਜ਼ਾਰਾਂ ਰਿਕਾਰਡ ਵਾਪਸ ਭੇਜਦਾ ਅਤੇ ਫਿਰ ਬ੍ਰਾਊਜ਼ਰ ਨੂੰ ਉਨ੍ਹਾਂ ਨੂੰ ਰੇਂਡਰ ਕਰਨ ਲਈ ਬਲਵਾਂ ਦੇਦਾ। ਇਹ ਹੀ ਕਾਰਨ ਹੈ ਕਿ ਟਾਈਪਿੰਗ ਲੈਗੀ ਹੋ ਜਾਂਦੀ ਹੈ।
ਜਦੋਂ ਟੀਮਾਂ ਅੰਦਰੂਨੀ ਟੂਲ ਤੇਜ਼ੀ ਨਾਲ ਬਣਾਉਂਦੀਆਂ ਹਨ (ਇਸ ਵਿੱਚ ਵੈਬ-ਕੋਡ ਫਲੈਵਰ ਵਾਲੀਆਂ ਪਲੇਟਫਾਰਮਾਂ ਜਿਵੇਂ Koder.ai ਵੀ ਸ਼ਾਮਿਲ ਹਨ), ਲਿਸਟ ਸਕ੍ਰੀਨ ਅਕਸਰ ਪਹਿਲੀ ਥਾਂ ਹੁੰਦੀ ਹੈ ਜਿੱਥੇ ਅਸਲ ਡੇਟਾ ਦੀ ਵਾਧਾ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ "ਡੈਮੋ ਡੇਟਾਸੇਟ 'ਤੇ ਚੱਲਦਾ ਹੈ" ਅਤੇ "ਹਰ ਰੋਜ਼ ਤੁਰੰਤ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ" ਵਿੱਚ ਫ਼ਰਕ ਹੈ।
ਅਪਟਮਾਈਜ਼ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਫ਼ੈਸਲਾ ਕਰੋ ਕਿ ਇਸ ਸਕ੍ਰੀਨ ਲਈ ਤੇਜ਼ ਦਾ ਕੀ ਮਤਲਬ ਹੈ। ਬਹੁਤ ਟੀਮਾਂ throughput (ਸਭ ਕੁਝ ਲੋਡ ਕਰਨ) ਦਾ ਪਿੱਛਾ ਕਰਦੀਆਂ ਹਨ ਜਦੋਂ ਯੂਜ਼ਰ ਜ਼ਿਆਦਾਤਰ ਘੱਟ ਲੈਟੇੰਸੀ (ਜਲਦੀ ਅਪਡੇਟ ਵੇਖਣਾ) ਦੀ ਲੋੜ ਰੱਖਦੇ ਹਨ। ਇੱਕ ਲਿਸਟ ਤੁਰੰਤ ਮਹਿਸੂਸ ਹੋ ਸਕਦੀ ਹੈ ਭਾਵੇਂ ਇਹ ਕਦੇ ਵੀ 100k ਰੋਜ਼ ਸਾਰਿਆਂ ਨੂੰ ਲੋਡ ਨਾ ਕਰੇ, ਜੇਕਰ ਸਕ੍ਰੋਲ, ਸੋਰਟ ਅਤੇ ਫਿਲਟਰ ਤੇ ਰਿਸਪਾਂਸ ਤੇਜ਼ ਹੋ।
ਇੱਕ ਵਰਤਣਯੋਗ ਟਾਰਗੇਟ ਹੈ ਪਹਿਲੀ ਪੰਗਤੀ ਤੱਕ ਦਾ ਸਮਾਂ, ਨਾ ਕਿ ਪੂਰੀ ਤਰ੍ਹਾਂ ਲੋਡ ਹੋਣ ਦਾ ਸਮਾਂ। ਯੂਜ਼ਰ ਪੇਜ 'ਤੇ ਭਰੋਸਾ ਕਰਦੇ ਹਨ ਜਦੋਂ ਉਹ ਪਹਿਲੀਆਂ 20 ਤੋਂ 50 ਪੰਗਤੀਆਂ ਜਲਦੀ ਵੇਖ ਲੈਂਦੇ ਹਨ ਅਤੇ ਇੰਟਰੈਕਸ਼ਨ ਸਮੂਥ ਰਹਿੰਦੇ ਹਨ।
ਹਰ ਵਾਰੀ ਤੁਸੀਂ ਕਿਸੇ ਚੀਜ਼ ਨੂੰ ਬਦਲੋ ਤਾਂ ਕੁਝ ਛੋਟੇ ਨੰਬਰ ਚੁਣੋ ਜੋ ਤੁਸੀਂ ਟ੍ਰੈਕ ਕਰ ਸਕੋ:
COUNT(*) ਅਤੇ ਵੱਡੇ SELECTs)ਇਹ ਨੰਬਰ ਆਮ ਲੱਛਣਾਂ ਨਾਲ ਮੇਪ ਹੁੰਦੇ ਹਨ। ਜੇ ਬ੍ਰਾਊਜ਼ਰ CPU ਸਕ੍ਰੋਲ ਕਰਦੇ ਸਮੇਂ ਸਪਾਈਕ ਕਰਦਾ ਹੈ ਤਾਂ ਫਰੰਟਐਂਡ ਹਰ ਰੋਜ਼ ਬਹੁਤ ਜ਼ਿਆਦਾ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ। ਜੇ ਸਪਿੰਨਰ ਉਡੀਕ ਕਰਦਾ ਹੈ ਪਰ ਸਕ੍ਰੋਲਿੰਗ ਠੀਕ ਹੈ ਤਾਂ ਆਮ ਤੌਰ 'ਤੇ ਬੈਕਏਂਡ ਜਾਂ ਨੈੱਟਵਰਕ ਦੀ ਸਮੱਸਿਆ ਹੁੰਦੀ ਹੈ। ਜੇ ਰਿਕਵੇਸਟ ਤੇਜ਼ ਹੈ ਪਰ ਪੇਜ ਫਿਰ ਵੀ ਫ੍ਰੀਜ਼ ਹੁੰਦਾ ਹੈ ਤਾਂ ਇਹ ਲਗਭਗ ਹਮੇਸ਼ਾ ਰੇਂਡਰਿੰਗ ਜਾਂ ਭਾਰੀ ਕਲਾਇੰਟ-ਸਾਈਡ ਪ੍ਰੋਸੈਸਿੰਗ ਹੈ।
ਇਕ ਸਧਾਰਨ ਪ੍ਰਯੋਗ ਕਰੋ: UI ਨੂੰ ਉਹੀ ਰੱਖੋ, ਪਰ ਅਸਥਾਈ ਤੌਰ 'ਤੇ ਬੈਕਐਂਡ ਨੂੰ ਸਿਰਫ 20 ਰੋਜ਼ ਵਾਪਸ ਕਰਨ ਲਈ ਸੀਮਿਤ ਕਰੋ ਇੱਕੋ ਹੀ ਫਿਲਟਰਾਂ ਨਾਲ। ਜੇ ਇਹ ਤੇਜ਼ ਹੋ ਜਾਂਦਾ ਹੈ ਤਾਂ ਤੁਹਾਡੀ ਬੋਤਲਗਰਹ ਲੋਡ ਸਾਈਜ਼ ਜਾਂ ਕੁਐਰੀ ਸਮਾਂ ਹੈ। ਜੇ ਇਹ ਫਿਰ ਵੀ ਧੀਮਾ ਹੈ ਤਾਂ ਰੇਂਡਰਿੰਗ, ਫਾਰਮੇਟਿੰਗ ਅਤੇ ਪ੍ਰਤੀ-ਰੋਜ਼ ਕੰਪੋਨੈਂਟ ਵੇਖੋ।
ਉਦਾਹਰਨ: ਇੱਕ ਅੰਦਰੂਨੀ Orders ਸਕ੍ਰੀਨ ਜਾਂ ਜੋਖਤ ਲੱਗਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਸਰਚ ਵਿੱਚ ਟਾਈਪ ਕਰਦੇ ਹੋ। ਜੇ API 5,000 ਰੋਜ਼ ਵਾਪਸ ਕਰਦਾ ਹੈ ਅਤੇ ਬ੍ਰਾਊਜ਼ਰ ਹਰ ਕੀ-ਪ੍ਰੈਸ 'ਤੇ ਉਹਨਾਂ ਨੂੰ ਫਿਲਟਰ ਕਰਦਾ ਹੈ, ਤਾਂ ਟਾਈਪਿੰਗ ਲੈਗ ਕਰੇਗੀ। ਜੇ API COUNT ਕਵੇਰੀ ਦੀ ਵਜ੍ਹੇ 2 ਸਕਿੰਟ ਲੈਂਦੀ ਹੈ ਕਿਉਂਕਿ ਫਿਲਟਰ 'ਤੇ ਇੰਡੈਕਸ ਨਹੀਂ ਹੈ ਤਾਂ ਤੁਸੀਂ ਕਿਸੇ ਵੀ ਪੰਗਤੀ ਦੇ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਉਡੀਕ ਵੇਖੋਗੇ। ਵੱਖ-ਵੱਖ ਫਿਕਸ, ਪਰ ਇਕੋ ਯੂਜ਼ਰ ਸ਼ਿਕਾਇਤ।
ਬ੍ਰਾਊਜ਼ਰ ਅਕਸਰ ਪਹਿਲਾ ਬੋਤਲ-ਗਰਹ ਹੈ। API ਤੇਜ਼ ਹੋਣ ਦੇ ਬਾਵਜੂਦ ਵੀ ਇੱਕ ਲਿਸਟ ਧੀਮੀ ਮਹਿਸੂਸ ਹੋ ਸਕਦੀ ਹੈ, ਸਧਾਰਨ ਤੌਰ 'ਤੇ ਕਿਉਂਕਿ ਪੇਜ ਬਹੁਤ ਜ਼ਿਆਦਾ ਪੇਂਟ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਿਹਾ ਹੈ। ਪਹਿਲਾ ਨਿਆਮ ਸਧਾਰਨ ਹੈ: ਇੱਕ ਵਾਰੀ ਵਿੱਚ ਹਜ਼ਾਰਾਂ ਰੋਜ਼ DOM ਵਿੱਚ ਰੇਂਡਰ ਨਾ ਕਰੋ।
ਪੂਰੀ ਵਰਚੁਅਲਾਈਜ਼ੇਸ਼ਨ ਲਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਵੀ ਹਰ ਰੋਜ਼ ਨੂੰ ਹਲਕਾ ਰੱਖੋ। ਇੱਕ ਰੋਜ਼ ਜਿਸ ਵਿੱਚ ਨੈਸਟਡ ਰੈਪਰ, ਆਇਕਨ, ਟੂਲਟਿਪ ਅਤੇ ਹਰ ਸੈੱਲ ਵਿੱਚ ਜਟਿਲ ਸ਼ਰਤੀ ਸਟਾਈਲ ਹੋਵੇ, ਉਹ ਹਰ ਸਕ੍ਰੋਲ ਅਤੇ ਹਰ ਅਪਡੇਟ 'ਤੇ ਮਿਹਣਗਾ ਪਏਗਾ। ਸਧਾਰਨ ਟੈਕਸਟ, 2-3 ਛੋਟੇ ਬੈਜ ਅਤੇ ਇੱਕ ਜਾਂ ਦੋ ਇੰਟਰਐਕਟਿਵ ਤੱਤ ਪ੍ਰਤੀ ਰੋਜ਼ ਪਸੰਦ ਕਰੋ।
ਸਥਿਰ ਰੋਜ਼ ਉਚਾਈ ਸੋਚਣ ਤੋਂ ਜ਼ਿਆਦਾ ਮਦਦ ਕਰਦੀ ਹੈ। ਜਦੋਂ ਹਰ ਰੋਜ਼ ਦੀ ਉਚਾਈ ਇੱਕੋ ਹੁੰਦੀ ਹੈ, ਬ੍ਰਾਊਜ਼ਰ ਲੇਆਓਟ ਦੀ ਭਵਿੱਖਬਾਣੀ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਸਕ੍ਰੋਲਿੰਗ ਸਮੂਥ ਰਹਿੰਦੀ ਹੈ। ਵੈਰੀਏਬਲ-ਹਾਈਟ ਰੋਜ਼ (ਲਪੇਟਦੇ ਵੇਰਣ, ਫੈਲਣ ਵਾਲੇ ਨੋਟ, ਵੱਡੇ ਐਵਟਾਰ) ਵਾਧੂ ਮਾਪ ਅਤੇ ਰੀਫ਼ਲੋ ਸਿਰਜਦੇ ਹਨ। ਜੇ ਤੁਹਾਨੂੰ ਵਧੇਰੇ ਵੇਰਵਾ ਚਾਹੀਦਾ ਹੈ ਤਾਂ ਸਾਈਡ ਪੈਨਲ ਜਾਂ ਇੱਕ ਐਕਸਪੈਂਡੇਬਲ ਏਰੀਆ ਤੇ ਵਿਚਾਰ ਕਰੋ, ਨਾ ਕਿ ਪੂਰਾ ਮਲਟੀ-ਲਾਈਨ ਰੋਜ਼।
ਫਾਰਮੇਟਿੰਗ ਵੀ ਇੱਕ ਚੁਪ ਚੁਪ ਟੈਕਸ ਹੈ। ਤਾਰੀਖਾਂ, ਮੁਦਰਾ ਅਤੇ ਭਾਰੀ ਸਟਰਿੰਗ ਕੰਮ ਜਦੋਂ ਕਈ ਸੈੱਲਾਂ ਵਿੱਚ ਦੁਹਰਾਏ ਜਾਂਦੇ ਹਨ ਤਾਂ ਇਹ ਜੋੜਦਾ ਹੈ।
ਜੇ ਇੱਕ ਮੁੱਲ ਦਿਖਾਈ ਨਹੀਂ ਦੇ ਰਿਹਾ ਤਾਂ ਹੁਣੇ ਹੀ ਇਸ ਨੂੰ ਗਣਨਾ ਨਾ ਕਰੋ। ਮਹਿੰਗੀ ਫਾਰਮੇਟਿੰਗ ਨਤੀਜਿਆਂ ਨੂੰ ਕੈਸ਼ ਕਰੋ ਅਤੇ ਮੰਗ 'ਤੇ ਗਣਨਾ ਕਰੋ—ਉਦਾਹਰਣ ਲਈ ਜਦੋਂ ਰੋਜ਼ ਵਿਖਾਈ ਦੇਣ ਲੱਗੇ ਜਾਂ ਯੂਜ਼ਰ ਇੱਕ ਰੋਜ਼ ਖੋਲ੍ਹੇ।
ਇੱਕ ਤੇਜ਼ ਪਾਸ ਜੋ ਅਕਸਰ ਨਜ਼ਰ ਆਉਂਦਾ ਹੈ:
ਉਦਾਹਰਨ: ਇੱਕ ਅੰਦਰੂਨੀ Invoices ਟੇਬਲ ਜੋ 12 ਕਾਲਮ ਦੀ ਮੁਦਰਾ ਅਤੇ ਤਾਰੀਖ ਫਾਰਮੈਟਿੰਗ ਕਰਦੀ ਹੈ, ਸਕ੍ਰੋਲ 'ਤੇ ਸਟਟਰ ਕਰੇਗੀ। ਹਰ ਇਨਵੌਇਸ ਲਈ ਫਾਰਮੈਟ ਕੀਤੇ ਮੁੱਲਾਂ ਨੂੰ ਕੈਸ਼ ਕਰਕੇ ਅਤੇ ਆਫ-ਸਕ੍ਰੀਨ ਰੋਜ਼ਾਂ ਲਈ ਕੰਮ ਨੂੰ ਦੇਰੀ ਨਾਲ ਕਰਕੇ ਇਹ ਤੁਰੰਤ ਮਹਿਸੂਸ ਹੋ ਸਕਦਾ ਹੈ, ਭਾਵੇਂ ਡੀਪ ਬੈਕਐਂਡ ਕੰਮ ਤੋਂ ਪਹਿਲਾਂ।
ਵਰਚੁਅਲਾਈਜ਼ੇਸ਼ਨ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਟੇਬਲ ਸਿਰਫ਼ ਉਹੀ ਰੋਜ਼ਾਂ ਡ੍ਰਾ ਕਰਦੀ ਹੈ ਜੋ ਤੁਸੀਂ ਦਿਖਾਈ ਦੇ ਰਹੀਆਂ ਹੋ (ਥੋੜ੍ਹਾ ਬਫ਼ਰ ਉੱਪਰ-ਥੱਲੇ ਨਾਲ)। ਜਦੋਂ ਤੁਸੀਂ ਸਕ੍ਰੋਲ ਕਰਦੇ ਹੋ, ਇਹ ਇੱਕੋ DOM ਐਲੀਮੈਂਟਾਂ ਨੂੰ ਰੀ-ਯੂਜ਼ ਕਰਦਾ ਹੈ ਅਤੇ ਉਨ੍ਹਾਂ ਵਿੱਚ ਡੇਟਾ ਸਵੈਪ ਕਰਦਾ ਹੈ। ਇਸ ਨਾਲ ਬ੍ਰਾਊਜ਼ਰ ਨੂੰ ਦਹਾਂ ਹਜ਼ਾਰਾਂ ਰੋਜ਼ ਕਾਪੋਨੈਂਟ ਇੱਕ ਵਾਰੀ ਵਿੱਚ ਪੇਂਟ ਕਰਨ ਤੋਂ ਰੋਕਿਆ ਜਾਂਦਾ ਹੈ।
ਵਰਚੁਅਲਾਈਜ਼ੇਸ਼ਨ ਲੰਬੀਆਂ ਲਿਸਟਾਂ, ਚੌੜੀਆਂ ਟੇਬਲਾਂ ਜਾਂ ਭਾਰੀ ਰੋਜ਼ਾਂ (ਐਵਟਾਰ, ਸਟੇਟਸ ਚਿਪ, ਐਕਸ਼ਨ ਮੈਨੂ, ਟੂਲਟਿਪ) ਲਈ ਚੰਗੀ ਫਿੱਟ ਹੁੰਦੀ ਹੈ। ਇਹ ਉਨ੍ਹਾਂ ਸਥਿਤੀਆਂ ਲਈ ਵੀ ਉਪਯੋਗੀ ਹੈ ਜਿੱਥੇ ਯੂਜ਼ਰ ਬਹੁਤ ਸਕ੍ਰੋਲ ਕਰਦੇ ਹਨ ਅਤੇ ਲਗਾਤਾਰ, ਸਮੂਥ ਨਜ਼ਰਾ ਉਮੀਦ ਕਰਦੇ ਹਨ ਬਜਾਏ ਪੇਜ-ਬਾਈ-ਪੇਜ ਜ਼ੰਪ ਕਰਨ ਦੇ।
ਇਹ ਜਾਦੂ ਨਹੀਂ ਹੈ। ਕੁਝ ਚੀਜ਼ਾਂ ਅਕਸਰ ਹੈਰਾਨੀ ਪੈਦਾ ਕਰਦੀਆਂ ਹਨ:
ਸਭ ਤੋਂ ਸਧਾਰਨ ਰਵੱਈਆ ਨਿਰਾਸ਼ਜਨਹੀਨ ਹੈ: ਫਿਕਸ ਰੋਜ਼ ਉਚਾਈ, ਭਵਿੱਖਬਾਣੀਯੋਗ ਕਾਲਮ ਅਤੇ ਹਰ ਰੋਜ਼ ਵਿੱਚ ਜ਼ਿਆਦਾ ਇੰਟਰਐਕਟਿਵ ਵਿਜਟ ਨਹੀਂ।
ਤੁਸੀਂ ਦੋਹਾਂ ਨੂੰ ਮਿਲਾ ਸਕਦੇ ਹੋ: ਸਰਵਰ ਤੋਂ ਜੋ ਤੁਸੀਂ ਫੈਚ ਕਰਦੇ ਹੋ ਉਸਨੂੰ ਸੀਮਤ ਕਰਨ ਲਈ ਪੇਜੀਨੇਸ਼ਨ (ਜਾਂ ਕਰਸਰ-ਅਧਾਰਿਤ load more) ਵਰਤੋ, ਅਤੇ ਫੈਚ ਕੀਤੇ ਸਲਾਈਸ ਦੇ ਅੰਦਰ ਰੇਂਡਰਿੰਗ ਸਸਤੀ ਰੱਖਣ ਲਈ ਵਰਚੁਅਲਾਈਜ਼ੇਸ਼ਨ ਵਰਤੋ।
ਇੱਕ ਵਰਤਣਯੋਗ ਪੈਟਰਨ ਹੈ ਕਿ ਇੱਕ ਆਮ ਪੇਜ਼ ਸਾਈਜ਼ (ਅਕਸਰ 100 ਤੋਂ 500 ਰੋਜ਼) ਫੈਚ ਕਰੋ, ਉਸ ਪੇਜ਼ ਦੇ ਅੰਦਰ ਵਰਚੁਅਲਾਈਜ਼ ਕਰੋ, ਅਤੇ ਪੇਜਾਂ ਦਰਮਿਆਨ ਸਪਸ਼ਟ ਕੰਟਰੋਲ ਦਿਓ। ਜੇ ਤੁਸੀਂ ਇਨਫਿਨਿਟ ਸਕ੍ਰੋਲ ਵਰਤ ਰਹੇ ਹੋ ਤਾਂ ਇੱਕ ਵਿਖਾਈ ਦੇਣ ਵਾਲਾ "Loaded X of Y" ਇੰਡੀਕੇਟਰ ਸ਼ਾਮਿਲ ਕਰੋ ਤਾਂ ਕਿ ਯੂਜ਼ਰ ਸਮਝ ਸੱਕਣ ਕਿ ਉਹ ਸਭ ਕੁਝ ਨਹੀਂ ਦੇਖ ਰਹੇ।
ਜੇ ਤੁਹਾਨੂੰ ਇੱਕ ਐਸੀ ਲਿਸਟ ਚਾਹੀਦੀ ਹੈ ਜੋ ਡੇਟਾ ਵਧਣ 'ਤੇ ਵੀ ਵਰਣਯੋਗ ਰਹੇ, ਪੇਜੀਨੇਸ਼ਨ ਆਮ ਤੌਰ 'ਤੇ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਸੁਰੱਖਿਅਤ ਡਿਫੌਲਟ ਹੈ। ਇਹ ਪੇਸ਼ਗੀ, ਐਡਮਿਨ ਵਰਕਫਲੋ ਲਈ ਚੰਗਾ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਆਮ ਜ਼ਰੂਰਤਾਂ ਨੂੰ ਸਹਾਇਕ ਬਣਾਉਂਦਾ ਹੈ ਜਿਵੇਂ "ਇਹ ਫਿਲਟਰਾਂ ਨਾਲ ਪੇਜ 3 ਐਕਸਪੋਰਟ ਕਰੋ"। ਬਹੁਤੀਆਂ ਟੀਮਾਂ ਜ਼ਿਆਦਾਤਰ ਐਡਵਾਂਸ ਸਕ੍ਰੋਲ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਤੋਂ ਬਾਅਦ ਮੁੜ ਪੇਜੀਨੇਸ਼ਨ 'ਤੇ ਆਉਂਦੀਆਂ ਹਨ।
ਇਨਫਿਨਿਟ ਸਕ੍ਰੌਲ ਕੈਜ਼ੂਅਲ ਬ੍ਰਾਊਜ਼ਿੰਗ ਲਈ ਚੰਗੀ ਲੱਗ ਸਕਦੀ ਹੈ ਪਰ ਇਸਦੇ ਲੁਕਵੇਂ ਖ਼ਰਚ ਹੁੰਦੇ ਹਨ। ਲੋਕ ਆਪਣੀ ਥਾਂ ਗੁਆ ਲੈਂਦੇ ਹਨ, ਬੈਕ ਬਟਨ ਅਕਸਰ ਉਹਨਾਂ ਨੂੰ ਉਹੇ ਸਥਾਨ ਤੇ ਵਾਪਸ ਨਹੀਂ ਲੈ ਆਉਂਦਾ, ਅਤੇ ਲੰਬੇ ਸੈਸ਼ਨ ਜ਼ਿਆਦਾ ਰੋਜ਼ਾਂ ਲੋਡ ਹੋਣ ਨਾਲ ਮੈਮੋਰੀ ਵਧਾ ਸਕਦੇ ਹਨ। Load more ਬਟਨ ਇੱਕ ਮੱਧ ਰਾਹ ਹੈ ਜੋ ਫਿਰ ਵੀ ਪੇਜਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ ਤਾਂ ਕਿ ਯੂਜ਼ਰ ਓਰੀਏਂਟੇਡ ਰਹਿਣ।
Offset ਪੇਜੀਨੇਸ਼ਨ ਕਲਾਸਿਕ page=10&size=50 ਤਰੀਕਾ ਹੈ। ਇਹ ਸਧਾਰਨ ਹੈ, ਪਰ ਵੱਡੀਆਂ ਟੇਬਲਾਂ 'ਤੇ ਇਹ ਧੀਮਾ ਹੋ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਡੇਟਾਬੇਸ ਨੂੰ ਬਾਅਦ ਵਾਲੀਆਂ ਪੇਜਾਂ ਤੱਕ ਪੁੱਜਣ ਲਈ ਕਈ ਰੋਜ਼ਾਂ ਨੂੰ ਸਕਿਪ ਕਰਨਾ ਪੈ ਸਕਦਾ ਹੈ। ਇਹ ਨਵੇਂ ਰਿਕਾਰਡ ਆਉਣ 'ਤੇ ਪੇਜਾਂ ਦੇ ਵਿਚਕਾਰ ਆਈਟਮਾਂ ਦਾ ਸਥਾਨ ਬਦਲ ਜਾਣ ਨਾਲ ਵੀ ਅਜੀਬ ਲੱਗ ਸਕਦਾ ਹੈ।
Keyset (ਅਕਸਰ ਕਰਸਰ ਪੇਜੀਨੇਸ਼ਨ ਕਹਿੰਦੇ ਹਨ) "ਆਖਰੀ ਵੇਖੇ ਗਏ ਆਈਟਮ ਤੋਂ ਅੱਗੇ 50 ਰੋਜ਼" ਮੰਗਦਾ ਹੈ, ਆਮ ਤੌਰ 'ਤੇ id ਜਾਂ created_at ਵਰਤ ਕੇ। ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਤੇਜ਼ ਰੱਖਦਾ ਹੈ ਕਿਉਂਕਿ ਇਸ ਨੂੰ ਗਿਣਤੀ ਅਤੇ ਸਕਿਪ ਕਰਨ ਦੀ ਲੋੜ ਘੱਟ ਹੁੰਦੀ ਹੈ।
ਇੱਕ ਵਰਤਣਯੋਗ ਨਿਯਮ:
ਯੂਜ਼ਰ ਟੋਟਲ ਵੇਖਣਾ ਪਸੰਦ ਕਰਦੇ ਹਨ, ਪਰ ਸਭ ਮੈਚਿੰਗ ਰੋਜ਼ਾਂ ਦੀ ਪੂਰੀ COUNT ਮਹਿੰਗੀ ਹੋ ਸਕਦੀ ਹੈ। ਵਿਕਲਪ: ਲੋਕਪ੍ਰਿਯ ਫਿਲਟਰਾਂ ਲਈ ਗਿਣਤੀ ਕੈਸ਼ ਕਰੋ, ਪੇਜ ਲੋਡ ਹੋਣ ਤੋਂ ਬਾਅਦ ਪਿੱਛੇ ਹੀ ਗਿਣਤੀ ਅਪਡੇਟ ਕਰੋ, ਜਾਂ ਮੁਮਕੀਨ ਤੌਰ 'ਤੇ ਅਨੁਮਾਨਿਤ ਗਿਣਤੀ ਦਿਖਾਓ (ਉਦਾਹਰਣ: "10,000+").
ਉਦਾਹਰਨ: ਇੱਕ ਅੰਦਰੂਨੀ Orders ਸਕ੍ਰੀਨ keyset ਪੇਜੀਨੇਸ਼ਨ ਨਾਲ ਤੁਰੰਤ ਨਤੀਜੇ ਦਿਖਾ ਸਕਦੀ ਹੈ, ਫਿਰ ਯੂਜ਼ਰ ਰੁਕਣ 'ਤੇ ਸਹੀ ਟੋਟਲ ਭਰਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਇਹ Koder.ai ਵਿੱਚ ਬਣਾ ਰਹੇ ਹੋ, ਪੇਜੀਨੇਸ਼ਨ ਅਤੇ ਗਿਣਤੀ ਵਿਹਾਰ ਨੂੰ ਸਕ੍ਰੀਨ ਸਪੀਕ ਦੇ ਤੌਰ 'ਤੇ ਜਲਦੀ ਹੀ ਸਪੈੱਸ ਕਰੋ ਤਾਂ ਕਿ ਜੈਨਰੇਟਡ ਬੈਕਐਂਡ ਕੁਐਰੀਜ਼ ਅਤੇ UI ਸਟੇਟ ਬਾਅਦ ਵਿੱਚ ਇਕ-ਦੂਜੇ ਦੇ ਖ਼ਿਲਾਫ਼ ਨਾ ਆਉਣ।
ਅਧਿਕਤਰ ਲਿਸਟ ਸਕ੍ਰੀਨ ਇਸ ਲਈ ਧੀਮੀਆਂ ਮਹਿਸੂਸ ਹੁੰਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਉਹ ਖੁੱਲ੍ਹੀਆਂ ਸ਼ੁਰੂ ਹੁੰਦੀਆਂ ਹਨ: ਸਭ ਕੁਝ ਲੋਡ ਕਰੋ, ਫਿਰ ਯੂਜ਼ਰ ਨੂੰ ਸੁੰਞਣਾ ਪੈਦਾ ਹੈ। ਇਸਨੂੰ ਉਲਟ ਕਰੋ। ਮੰਨਯੋਗ ਡਿਫੌਲਟ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਇੱਕ ਛੋਟੀ, ਲਾਭਦਾਇਕ ਸੈੱਟ ਵਾਪਸ ਕਰੇ (ਉਦਾਹਰਨ: ਪਿਛਲੇ 7 ਦਿਨ, My items, Status: Open), ਅਤੇ All time ਨੂੰ ਇੱਕ ਸਪਸ਼ਟ ਚੋਣ ਬਣਾਓ।
ਟੈਕਸਟ ਖੋਜ ਇਕ ਹੋਰ ਆਮ ਫੰਸ ਹੈ। ਜੇ ਤੁਸੀਂ ਹਰ ਕੀ-ਪ੍ਰੈਸ 'ਤੇ ਕੁਐਰੀ ਚਲਾਉਂਦੇ ਹੋ ਤਾਂ ਤੁਸੀਂ ਰਿਕਵੇਸਟਾਂ ਦੀ ਬੈਕਲੌਗ ਬਣਾਉਂਦੇ ਹੋ ਅਤੇ UI ਫਲਿਕਰ ਹੋ ਜਾਂਦੀ ਹੈ। ਸਰਚ ਇਨਪੁੱਟ ਨੂੰ ਡੀਬਾਊਂਸ ਕਰੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਸਿਰਫ਼ ਯੂਜ਼ਰ ਦੇ ਠਹਿਰਣ 'ਤੇ ਹੀ ਕੁਐਰੀ ਕਰੋ, ਅਤੇ ਜਦੋਂ ਨਵਾਂ ਰਿਕਵੇਸਟ ਆਵੇ ਪੁਰਾਣੀਆਂ ਰਿਕਵੇਸਟਾਂ ਨੂੰ ਰੱਦ ਕਰੋ। ਸਧਾਰਨ ਨਿਯਮ: ਜੇ ਯੂਜ਼ਰ ਅਜੇ ਵੀ ਟਾਈਪ ਕਰ ਰਿਹਾ ਹੈ ਤਾਂ ਸਰਵਰ ਨੂੰ ਹਿੱਟ ਨਾ ਕਰੋ।
ਫਿਲਟਰ ਤਦ ਹੀ ਤੇਜ਼ ਮਹਿਸੂਸ ਹੁੰਦੇ ਹਨ ਜਦੋਂ ਉਹ ਸਪਸ਼ਟ ਵੀ ਹੁੰਦੇ ਹਨ। ਸਾਰਣੀ ਦੇ ਉੱਪਰ ਫਿਲਟਰ ਚਿਪਸ ਦਿਖਾਓ ਤਾਂ ਕਿ ਯੂਜ਼ਰ ਵੇਖ ਸਕਣ ਕੀ ਐਕਟਿਵ ਹੈ ਅਤੇ ਇੱਕ ਕਲਿੱਕ ਨਾਲ ਹਟਾ ਸਕਣ। ਚਿਪ ਲੇਬਲ ਮਨੁੱਖੀ ਭਾਸ਼ਾ ਵਿੱਚ ਰੱਖੋ, ਕੱਚੇ ਫੀਲਡ-ਨਾਂ ਨਹੀਂ (ਉਦਾਹਰਨ: Owner: Sam ਇੰstead of owner_id=42). ਜਦੋਂ ਕੋਈ ਕਹਿੰਦਾ ਹੈ "ਮੇਰੇ ਨਤੀਜੇ ਗਾਇਬ ਹੋ ਗਏ," ਅਕਸਰ ਉਹ ਇਕ ਅਦਿੱਖ ਫਿਲਟਰ ਹੁੰਦਾ ਹੈ।
ਇਹਨਾਂ ਪੈਟਰਨਾਂ ਨਾਲ ਵੱਡੀਆਂ ਲਿਸਟਾਂ ਰਿਸਪਾਂਸਿਵ ਰਹਿੰਦੀਆਂ ਹਨ ਬਿਨਾਂ UI ਨੂੰ ਜਟਿਲ ਬਣਾਉਣ:
Saved views ਆਹਮ ਹਨ। ਯੂਜ਼ਰਾਂ ਨੂੰ ਹਰ ਵਾਰੀ ਪਰਫੈਕਟ ਫਿਲਟਰ ਕਾਂਬੋ ਬਣਾਉਣ ਦੀ ਸਿੱਖਿਆ ਦੇਣ ਦੀ ਬਜਾਏ, ਉਨ੍ਹਾਂ ਨੂੰ ਕੁਝ ਪ੍ਰੀਸੈਟ ਦੇ ਦਿਓ ਜੋ ਅਸਲ ਵਰਕਫਲੋ ਨਾਲ ਮਿਲਦੇ ਹੋਣ। Ops ਟੀਮ ਸ਼ਾਇਦ Failed payments today ਅਤੇ High-value customers ਵਿਚ ਬਦਲੇ। ਇਹ ਇਕ ਕਲਿੱਕ ਨਾਲ ਹੋ ਸਕਦੇ ਹਨ, ਤੁਰੰਤ ਸਮਝਣਯੋਗ ਅਤੇ ਬੈਕਐਂਡ 'ਤੇ ਤੇਜ਼ ਰੱਖਣ ਯੋਗ।
ਜੇ ਤੁਸੀਂ Koder.ai ਦੀ ਗੱਲ-ਚਲਾਕ ਬਿਲਡਰ ਵਿੱਚ ਅੰਦਰੂਨੀ ਟੂਲ ਬਣਾ ਰਹੇ ਹੋ, ਫਿਲਟਰਾਂ ਨੂੰ ਪ੍ਰੋਡਕਟ ਫਲੋ ਦਾ ਹਿੱਸਾ ਸਮਝੋ, ਨਾ ਕਿ ਇੱਕ ਬੋਲਟ-ਅਨ। ਸਭ ਤੋਂ ਆਮ ਸਵਾਲਾਂ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ, ਫਿਰ ਡਿਫੌਲਟ ਵਿਊ ਅਤੇ saved views ਉਹਨਾਂ ਦੇ ਆਸ-ਪਾਸ ਡਿਜ਼ਾਇਨ ਕਰੋ।
ਲਿਸਟ ਸਕ੍ਰੀਨ ਨਿਰਲਾਜ਼ਕ ਤੌਰ 'ਤੇ ਡੀਟੇਲ ਪੇਜ ਵਰਗਾ ਹੀ ਡੇਟਾ ਨਹੀਂ ਚਾਹੀਦਾ। ਜੇ ਤੁਹਾਡਾ API ਹਰ ਚੀਜ਼ ਵਾਪਸ ਕਰਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਦੋ ਵਾਰੀ ਭੁਗਤਾਨ ਕਰਦੇ ਹੋ: ਡੇਟਾਬੇਸ ਵਧੇਰੇ ਕੰਮ ਕਰਦਾ ਹੈ, ਅਤੇ ਬ੍ਰਾਊਜ਼ਰ ਖ਼ਾਲੀ ਪਾਸੇ ਵੱਧ ਡੇਟਾ ਪ੍ਰਾਪਤ ਅਤੇ ਰੇਂਡਰ ਕਰਦਾ ਹੈ। ਕੁਐਰੀ ਸ਼ੇਪਿੰਗ ਦੀ ਆਦਤ ਹੈ ਕਿ ਸਿਰਫ਼ ਉਹੀ ਮੰਗੋ ਜੋ ਲਿਸਟ ਨੂੰ ਇਸ ਵੇਲੇ ਚਾਹੀਦਾ ਹੈ।
ਸ਼ੁਰੂ ਕਰੋ ਸਿਰਫ ਉਹੀ ਕਾਲਮ ਵਾਪਸ ਕਰਕੇ ਜੋ ਹਰ ਰੋਜ਼ ਨੂੰ ਰੇਂਡਰ ਕਰਨ ਲਈ ਲੋੜੀਂਦੇ ਹਨ। ਜ਼ਿਆਦਾਤਰ ਡੈਸ਼ਬੋਰਡਾਂ ਲਈ ਇਹ ਇੱਕ id, ਕੁਝ ਲੇਬਲ, ਸਟੇਟਸ, ਮਲਿਕ ਅਤੇ ਟਾਈਮਸਟੈਂਪ ਹੁੰਦੇ ਹਨ। ਵੱਡਾ ਟੈਕਸਟ, JSON ਬਲੌਬ ਅਤੇ ਕੈਲਕੁਲੇਟ ਕੀਤੀਆਂ ਫੀਲਡਾਂ ਨੂੰ ਉਪਭੋਗਤਾ ਰੋਜ਼ ਖੋਲ੍ਹਣ 'ਤੇ ਛੱਡ ਦਿਓ।
ਪਹਿਲੇ ਪੇਂਟ ਲਈ ਭਾਰੀ ਜੋਇਨਜ਼ ਤੋਂ ਬਚੋ। ਜੇ ਜੋਇਨਜ਼ ਇੰਡੈਕਸ ਅਤੇ ਛੋਟੇ ਨਤੀਜੇ 'ਤੇ ਹਿੱਟ ਹੁੰਦੇ ਹਨ ਤਾਂ ਠੀਕ ਹਨ, ਪਰ ਜਦੋਂ ਤੁਸੀਂ ਕਈ ਟੇਬਲਾਂ ਨੂੰ ਜੋੜਦੇ ਹੋ ਅਤੇ ਫਿਰ ਜੋਇਨ ਕੀਤੇ ਗਈ ਡੇਟਾ 'ਤੇ ਸੌਰਟ ਜਾਂ ਫਿਲਟਰ ਕਰਦੇ ਹੋ ਤਾਂ ਇਹ ਮਹਿੰਗੇ ਹੋ ਜਾਂਦੇ ਹਨ। ਇੱਕ ਸਧਾਰਨ ਪੈਟਰਨ: ਲਿਸਟ ਇੱਕ ਟੇਬਲ ਤੋਂ ਤੇਜ਼ੀ ਨਾਲ ਫੈਚ ਕਰੋ, ਫਿਰ ਜ਼ਰੂਰਤ ਮੁਤਾਬਕ ਵੇਰਵੇ ਮੰਗੋ (ਜਾਂ ਸਿਰਫ਼ ਦਿੱਖ ਵਾਲੀਆਂ ਪੰਗਤੀਆਂ ਲਈ ਬੈਚ-ਲੋਡ ਕਰੋ)।
ਸੌਰਟ ਵਿਕਲਪ ਸੀਮਿਤ ਰੱਖੋ ਅਤੇ ਇੰਡੈਕਸ ਕੀਤੇ ਕਾਲਮਾਂ ਤੇ ਸੌਰਟ ਕਰੋ। "ਕੋਈ ਵੀ ਕਾਲਮ ਤੇ ਸੌਰਟ" ਲਾਭਦਾਇਕ ਸੁਨਾਈ ਦਿੰਦਾ ਹੈ, ਪਰ ਅਕਸਰ ਇਹ ਵੱਡੇ ਡੇਟਾਸੇਟਾਂ 'ਤੇ ਸੋੱਥੇ ਸੋਰਟ ਮਜਬੂਰ ਕਰ ਦਿੰਦਾ ਹੈ। ਕੁਝ ਪੂਰੀਆਂ ਚੋਣਾਂ ਜਿਵੇਂ created_at, updated_at ਜਾਂ status ਪਸੰਦ ਕਰੋ ਅਤੇ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਇਹ ਕਾਲਮ ਇੰਡੈਕਸ ਹਨ।
ਸਰਵਰ-ਸਾਈਡ ਏਗ੍ਰੀਗੇਸ਼ਨ ਨਾਲ ਸਾਵਧਾਨ ਰਹੋ। COUNT(*) ਇਕ ਵੱਡੇ ਫਿਲਟਰ ਕੀਤੇ ਸੈੱਟ 'ਤੇ, DISTINCT ਇੱਕ ਚੌੜੇ ਕਾਲਮ 'ਤੇ, ਜਾਂ ਪੇਜਾਂ ਦੀ ਕੁੱਲ ਗਿਣਤੀ ਦਾ ਹਿਸਾਬ ਤੁਹਾਡੇ ਰਿਸਪਾਂਸ ਟਾਈਮ ਨੂੰ ਘੇਰ ਸਕਦੀ ਹੈ।
ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਰਵੱਈਆ:
COUNT ਅਤੇ DISTINCT ਨੂੰ ਵਿਕਲਪਿਕ ਮੰਨੋ, ਅਤੇ ਜਦੋਂ ਸੰਭਵ ਹੋ ਤਦ ਕੈਸ਼ ਜਾ ਅਨੁਮਾਨ ਲਿਖੋਜੇ ਤੁਸੀਂ ਅੰਦਰੂਨੀ ਟੂਲ Koder.ai 'ਤੇ ਬਣਾਉਂਦੇ ਹੋ, ਲਿਸਟ ਕੁਐਰੀ ਨੂੰ ਡੀਟੇਲ ਕੁਐਰੀ ਤੋਂ ਅਲੱਗ ਤੌਰ 'ਤੇ ਪਲੈਨਿੰਗ ਮੋਡ ਵਿਚ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ, ਤਾਂ ਜੋ UI ਵਧਦੇ ਡੇਟਾ ਨਾਲ ਤੁਰੰਤ ਰਹੇ।
ਜੇ ਤੁਸੀਂ 100k ਰੋਜ਼ਾਂ 'ਤੇ ਤੇਜ਼ ਲਿਸਟ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਡੇਟਾਬੇਸ ਹਰ ਰਿਕਵੇਸਟ ਤੇ ਘੱਟ ਕੰਮ ਕਰੇ। ਜ਼ਿਆਦਾਤਰ ਧੀਮੀ ਲਿਸਟ "ਬਹੁਤ ਜ਼ਿਆਦਾ ਡੇਟਾ" ਨਹੀਂ ਹੁੰਦੀ; ਉਹ ਗਲਤ ਡੇਟਾ ਐਕਸੈਸ ਪੈਟਰਨ ਹੁੰਦਾ ਹੈ।
ਉਹ ਇੰਡੈਕਸ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਤੁਹਾਡੇ ਯੂਜ਼ਰ ਹਕੀਕਤ ਵਿੱਚ ਵਰਤਦੇ ਹਨ। ਜੇ ਤੁਹਾਡੀ ਲਿਸਟ ਆਮ ਤੌਰ 'ਤੇ status ਨਾਲ ਫਿਲਟਰ ਹੁੰਦੀ ਹੈ ਅਤੇ created_at ਨਾਲ ਸੌਰਟ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਉਹ ਇੰਡੈਕਸ ਜੁੜੇ ਹੋਏ ਪੈਟਰਨ ਨੂੰ ਸਪੋਰਟ ਕਰਦਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਨਹੀਂ ਤਾਂ ਡੇਟਾਬੇਸ ਉਮੀਦ ਤੋਂ ਕਈ ਰੋਜ਼ ਸਕੈਨ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਫਿਰ ਉਨ੍ਹਾਂ ਨੂੰ ਸੌਰਟ ਕਰਦਾ ਹੈ, ਜੋ ਤੇਜ਼ੀ ਨਾਲ ਮਹਿੰਗਾ ਹੋ ਜਾਂਦਾ ਹੈ।
ਅਕਸਰ ਸਭ ਤੋਂ ਵੱਡੇ ਨਤੀਜੇ ਦੇਣ ਵਾਲੇ ਸੁਧਾਰ:
tenant_id, status, created_at).OFFSET ਪੇਜਾਂ ਦੇ ਉਪਰ keyset (ਕਰਸਰ) ਪੇਜੀਨੇਸ਼ਨ ਨੂੰ ਤਰਜੀਹ ਦਿਓ। OFFSET ਡੇਟਾਬੇਸ ਨੂੰ ਕਈ ਰੋਜ਼ਾਂ ਦੇ ਪਾਸ ਕਰਨ 'ਤੇ ਮਜ਼ਬੂਰ ਕਰਦਾ ਹੈ।ਸਧਾਰਨ ਉਦਾਹਰਨ: ਇੱਕ ਅੰਦਰੂਨੀ Orders ਟੇਬਲ ਜੋ customer name, status, amount ਅਤੇ date ਦਿਖਾਉਂਦੀ ਹੈ। ਲਿਸਟ ਵਿਊ ਲਈ ਹਰ ਸੰਬੰਧਤ ਟੇਬਲ ਜੋੜ ਕੇ ਪੂਰੇ order notes ਨਾ ਲਓ। ਸਿਰਫ਼ ਟੇਬਲ ਵਿੱਚ ਵਰਤੇ ਗਏ ਕਾਲਮ ਵਾਪਸ ਕਰੋ, ਅਤੇ ਯੂਜ਼ਰ ਜਦੋਂ ਆਰਡਰ 'ਤੇ ਕਲਿੱਕ ਕਰੇ ਤਾਂ ਬਾਕੀ ਲੋਡ ਕਰੋ।
ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮ ਨਾਲ ਬਣਾ ਰਹੇ ਹੋ, ਇਸ ਸੋਚ ਨੂੰ ਬਰਕਰਾਰ ਰੱਖੋ ਭਲੇ UI ਚੈਟ ਤੋਂ ਜੈਨਰੇਟ ਹੋ ਰਿਹਾ ਹੋਵੇ। ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਜੈਨਰੇਟਡ API endpoints ਕਰਸਰ ਪੇਜੀਨੇਸ਼ਨ ਅਤੇ ਚੁਣਿਆ ਗਿਆ ਫੀਲਡ ਸਪੋਰਟ ਕਰਦੇ ਹਨ, ਤਾਂ ਜੋ ਟੇਬੇਲ ਵਧਣ 'ਤੇ ਡੇਟਾਬੇਸ ਕੰਮ ਪੇਸ਼ਗੋਈਯੋਗ ਰਹੇ।
ਜੇ ਇੱਕ ਲਿਸਟ ਪੇਜ ਅੱਜ ਧੀਮਾ ਮਹਿਸੂਸ ਹੋ ਰਿਹਾ ਹੈ, ਤਾਂ ਹਰ ਚੀਜ਼ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਣ ਨਾਲ ਸ਼ੁਰੂ ਨਾ ਕਰੋ। ਪਹਿਲਾਂ ਇਹ ਲਾਕ ਕਰੋ ਕਿ ਨਾਰਮਲ ਵਰਤੋਂ ਕੀ ਹੈ, ਫਿਰ ਉਸ ਰਾਹ ਨੂੰ ਅਪਟਮਾਈਜ਼ ਕਰੋ।
ਡਿਫੌਲਟ ਵਿਊ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ। ਡਿਫੌਲਟ ਫਿਲਟਰ, ਸੌਰਟ ਕ੍ਰਮ ਅਤੇ ਦਿਖਾਈ ਦੇਣ ਵਾਲੇ ਕਾਲਮ ਚੁਣੋ। ਲਿਸਟ ਉਸ ਵੇਲੇ ਧੀਮੀ ਹੋ ਜਾਂਦੀਆਂ ਹਨ ਜਦੋਂ ਉਹ ਪਹਿਲਾਂ ਤੋਂ ਸਭ ਕੁਝ ਦਿਖਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੀਆਂ ਹਨ।
ਆਪਣੀ ਵਰਤੋਂ ਅਨੁਸਾਰ paging ਸਟਾਇਲ ਚੁਣੋ। ਜੇ ਯੂਜ਼ਰ ਜ਼ਿਆਦਾਤਰ ਪਹਿਲੀਆਂ ਕੁਝ ਪੇਜਾਂ ਸਕੈਨ ਕਰਦੇ ਹਨ ਤਾਂ ਕਲਾਸਿਕ ਪੇਜੀਨੇਸ਼ਨ ਠੀਕ ਹੈ। ਜੇ ਲੋਕ ਡੀਪ (ਪੇਜ 200+) ਤੇ ਜੰਪ ਕਰਦੇ ਹਨ ਜਾਂ ਤੁਹਾਨੂੰ ਕਿਸੇ ਵੀ ਗਹਿਰਾਈ 'ਤੇ ਸਥਿਰ ਪ੍ਰਦਰਸ਼ਨ ਚਾਹੀਦਾ ਹੈ, ਤਾਂ keyset ਪੇਜੀਨੇਸ਼ਨ ਵਰਤੋ (ਚੰਗਾ ਸੋਰਟ ਜਿਵੇਂ created_at + id 'ਤੇ ਆਧਾਰਿਤ)।
ਟੇਬਲ ਬਾਡੀ ਲਈ ਵਰਚੁਅਲਾਈਜ਼ੇਸ਼ਨ ਜੋੜੋ। ਭਾਵੇਂ ਬੈਕਐਂਡ ਤੇਜ਼ ਹੋਵੇ, ਬ੍ਰਾਊਜ਼ਰ ਬਹੁਤ ਸਾਰੀਆਂ ਰੋਜ਼ਾਂ ਰੇਂਡਰ ਕਰਨ 'ਤੇ ਚੋਕ ਹੋ ਸਕਦਾ ਹੈ।
ਖੋਜ ਅਤੇ ਫਿਲਟਰ ਨੂੰ ਤੁਰੰਤ ਮਹਿਸੂਸ ਕਰਵਾਓ। ਟਾਈਪਿੰਗ ਨੂੰ ਡੀਬਾਊਂਸ ਕਰੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਹਰ ਕੀ-ਪ੍ਰੈਸ 'ਤੇ ਰਿਕਵੇਸਟ ਨਾ ਚਲਾਵੋ। ਫਿਲਟਰ ਸਟੇਟ ਨੂੰ URL ਜਾਂ ਇੱਕ ਸਾਂਝੇ ਸਟੇਟ ਸਟੋਰ ਵਿੱਚ ਰੱਖੋ ਤਾਂ ਕਿ ਰਿਫ਼ਰੈਸ਼, ਬੈਕ ਬਟਨ ਅਤੇ ਵਿਊ ਸਾਂਝਾ ਕਰਨ 'ਤੇ ਭਰੋਸੇਯੋਗ ਰਹੇ। ਆਖਰੀ ਸਫਲ ਨਤੀਜੇ ਨੂੰ ਕੈਸ਼ ਕਰੋ ਤਾਂ ਕਿ ਟੇਬਲ ਖਾਲੀ ਨਾ ਹੋ ਕੇ ਚਮਕੇ।
ਮਾਪੋ, ਫਿਰ ਕੁਐਰੀ ਅਤੇ ਇੰਡੈਕਸ ਟਿਊਨ ਕਰੋ। ਸਰਵਰ ਸਮਾਂ, ਡੇਟਾਬੇਸ ਸਮਾਂ, ਪੇਲੋਡ ਆਕਾਰ ਅਤੇ ਰੈਂਡਰ ਸਮਾਂ ਲੌਗ ਕਰੋ। ਫਿਰ ਕੁਐਰੀ ਨੂੰ ਛਾਂਟੋ: ਸਿਰਫ਼ ਉਹੀ ਕਾਲਮ ਚੁਣੋ ਜੋ ਤੁਸੀਂ ਦਿਖਾਉਂਦੇ ਹੋ, ਫਿਲਟਰ ਪਹਿਲਾਂ ਲਗਾਓ, ਅਤੇ ਡਿਫੌਲਟ ਫਿਲਟਰ + ਸੌਰਟ ਲਈ ਇੰਡੈਕਸ ਜੋੜੋ।
ਉਦਾਹਰਨ: 100k ਟਿਕਟਾਂ ਵਾਲਾ ਸਹਾਇਤਾ ਡੈਸ਼ਬੋਰਡ। ਡਿਫੌਲਟ ਕਰੋ Open, ਮੇਰੀ ਟੀਮ ਨੂੰ ਸੌਪਿਆ ਗਿਆ, ਨਵਾਂ ਤੋਂ ਸੌਰਟ ਕੀਤਾ, ਛੇ ਕਾਲਮ ਦਿਖਾਓ ਅਤੇ ਸਿਰਫ਼ ticket id, subject, assignee, status, ਅਤੇ ਟਾਈਮਸਟੈਂਪ ਫੈਚ ਕਰੋ। keyset pagination ਅਤੇ ਵਰਚੁਅਲਾਈਜ਼ੇਸ਼ਨ ਨਾਲ ਤੁਸੀਂ ਡੇਟਾਬੇਸ ਅਤੇ UI ਦੋਹਾਂ ਨੂੰ ਅਨੁਮਾਨਯੋਗ ਰੱਖ ਸਕਦੇ ਹੋ।
ਜੇ ਤੁਸੀਂ Koder.ai 'ਤੇ ਇੰਟਰਨਲ ਟੂਲ ਬਣਾ ਰਹੇ ਹੋ, ਇਹ ਯੋਜਨਾ iterate-and-check ਵਾਰਕਫਲੋ ਨਾਲ ਵਧੀਆ ਮੇਲ ਖਾਂਦੀ ਹੈ: ਵਿਊ ਨੂੰ ਢਾਲੋ, ਸਕ੍ਰੋਲ ਅਤੇ ਖੋਜ ਟੈਸਟ ਕਰੋ, ਫਿਰ ਕੁਐਰੀ ਨੂੰ ਟਿਊਨ ਕਰੋ ਜਦ ਤੱਕ ਪੇਜ ਸਨੈਪੀ ਨਾ ਰਹੇ।
ਲਿਸਟ ਸਕ੍ਰੀਨ ਨੂੰ ਖਰਾਬ ਕਰਨ ਦਾ ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਾ ਇਹ ਮੰਨਣਾ ਹੈ ਕਿ 100k ਰੋਜ਼ ਇੱਕ ਸਧਾਰਣ ਪੇਜ ਵਾਂਗ ਹੈ। ਜ਼ਿਆਦਾਤਰ ਧੀਮੀ ਡੈਸ਼ਬੋਰਡਾਂ ਵਿੱਚ ਕੁਝ ਆਮ ਫਾਂਸ ਹੁੰਦੇ ਹਨ।
ਇਕ ਵੱਡੀ ਗਲਤੀ ਸਾਰੀ ਚੀਜ਼ ਨੂੰ ਰੇਂਡਰ ਕਰਕੇ CSS ਨਾਲ ਛੁਪਾ ਦੇਣਾ ਹੈ। ਭਾਵੇਂ ਇਹ ਦਿਸਦਾ ਹੈ ਕਿ ਸਿਰਫ਼ 50 ਰੋਜ਼ ਦਿਖਾਈ ਦੇ ਰਹੀਆਂ ਹਨ, ਬ੍ਰਾਊਜ਼ਰ ਫਿਰ ਵੀ 100k DOM ਨੋਡ ਬਣਾਉਂਦਾ, ਮਾਪਦਾ ਅਤੇ ਸਕ੍ਰੋਲ 'ਤੇ repaint ਕਰਦਾ ਹੈ। ਜੇ ਲੰਬੀ ਲਿਸਟਾਂ ਦੀ ਲੋੜ ਹੈ ਤਾਂ ਸਿਰਫ਼ ਜੋ ਦਿਖ ਰਿਹਾ ਹੈ ਉਹ ਰੇਂਡਰ ਕਰੋ ( ਵਰਚੁਅਲਾਈਜ਼ੇਸ਼ਨ) ਅਤੇ ਰੋਜ਼ ਕੰਪੋਨੈਂਟ ਨੂੰ ਸਧਾਰਨ ਰੱਖੋ।
ਖੋਜ ਵੀ ਸ਼ਾਂਤ ਢੰਗ ਨਾਲ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਖਰਾਬ ਕਰ ਸਕਦੀ ਹੈ ਜਦੋਂ ਹਰ ਕੀ-ਪ੍ਰੈਸ ਤੇ ਪੂਰੀ ਟੇਬਲ ਸਕੈਨ ਹੁੰਦੀ ਹੈ। ਇਹ ਉਸ ਵੇਲੇ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਫਿਲਟਰ ਇੰਡੈਕਸ ਨਹੀਂ ਕਰਦੇ, ਤੁਸੀਂ ਬਹੁਤ ਸਾਰੀਆਂ ਕਾਲਮਾਂ 'ਤੇ ਭਾਲ ਕਰਦੇ ਹੋ, ਜਾਂ ਬੜੇ ਟੈਕਸਟ ਫੀਲਡਾਂ 'ਤੇ contains ਕਵੇਰੀ ਚਲਾਉਂਦੇ ਹੋ। ਇੱਕ ਚੰਗਾ ਨਿਯਮ: ਯੂਜ਼ਰ ਦਾ ਪਹਿਲਾ ਫਿਲਟਰ ਡੇਟਾਬੇਸ ਲਈ ਸਸਤਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਕੇਵਲ UI ਲਈ ਸੁਖਾਧਾਇਕ ਨਾ।
ਦੂਜੀ ਆਮ ਸਮੱਸਿਆ ਹੈ ਕਿ ਲਿਸਟ ਲਈ ਸੰਪੂਰਨ ਰਿਕਾਰਡ ਫੈਚ ਕਰਨਾ ਜਦ ਕਿ ਲਿਸਟ ਕੇਵਲ ਸੰਖੇਪ ਚਾਹੀਦੀ ਹੈ। ਇੱਕ ਲਿਸਟ ਰੋਜ਼ ਆਮ ਤੌਰ 'ਤੇ 5 ਤੋਂ 12 ਫੀਲਡਾਂ ਦੀ ਲੋੜ ਹੋਂਦੀ ਹੈ, ਨਾ ਕਿ ਪੂਰਾ ऑਬਜੈਕਟ, ਨਾ ਹੀ ਲੰਬੇ ਵੇਰਣ ਅਤੇ ਨਾ ਹੀ ਸੰਬੰਧਿਤ ਡੇਟਾ। ਵੱਧ ਡੇਟਾ ਫੈਚ ਕਰਨਾ ਡੇਟਾਬੇਸ ਕੰਮ, ਨੈੱਟਵਰਕ ਸਮਾਂ ਅਤੇ ਫਰੰਟਐਂਡ ਪਾਰਸਿੰਗ ਵੱਧਾਉਂਦਾ ਹੈ।
ਐਕਸਪੋਰਟ ਅਤੇ ਟੋਟਲ UI ਨੂੰ ਫ੍ਰੀਜ਼ ਕਰ ਸਕਦੇ ਹਨ ਜੇ ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਮੈਨ-ਥ੍ਰੈੱਡ 'ਤੇ ਗਣਨਾ ਕਰੋ ਜਾਂ ਤੇਜ਼ ਰਿਕਵੇਸਟ ਦੇ ਲਈ ਉਡੀਕ ਕਰੋ। UI ਇੰਟਰਐਕਟਿਵ ਰੱਖੋ: ਐਕਸਪੋਰਟ ਪਿੱਛੇ ਸ਼ੁਰੂ ਕਰੋ, ਪ੍ਰੋਗਰੈਸ ਦਿਖਾਓ, ਅਤੇ ਹਰ ਫਿਲਟਰ ਬਦਲਣ 'ਤੇ ਟੋਟਲ ਨੂੰ ਮੁੜ-ਕੈਲਕੁਲੇਟ ਕਰਨ ਤੋਂ ਬਚੋ।
ਅੰਤੀਮ ਤੌਰ 'ਤੇ, ਬਹੁਤ ਸਾਰੇ ਸੌਰਟ ਵਿਕਲਪ ਵਾਪਸ ਹਟ ਸਕਦੇ ਹਨ। ਜੇ ਯੂਜ਼ਰ ਕਿਸੇ ਵੀ ਕਾਲਮ 'ਤੇ ਸੌਰਟ ਕਰ ਸਕਦਾ ਹੈ ਤਾਂ ਤੁਸੀਂ ਵੱਡੇ ਰਿਜਲਟ ਸੈੱਟਾਂ ਨੂੰ ਮੈਮੋਰੀ ਵਿੱਚ ਸੌਰਟ ਕਰਨ ਜਾਂ ਡੇਟਾਬੇਸ ਨੂੰ ਧੀਮੇ ਯੋਜਨਾਵਾਂ 'ਤੇ ਮਜ਼ਬੂਰ ਕਰ ਦੇਓਗੇ। ਸੌਰਟ ਨੂੰ ਇੱਕ ਛੋਟਾ ਸਮੂਹ ਇੰਡੈਕਸ ਕੀਤੇ ਕਾਲਮਾਂ ਤੱਕ ਸਿਮਿਤ ਰੱਖੋ ਅਤੇ ਡਿਫੌਲਟ ਸੌਰਟ ਨੂੰ ਇਕ ਯਥਾਰਥ ਇੰਡੈਕਸ ਨਾਲ ਮਿਲਾਓ।
ਤੇਜ਼ ਜਲਦੀ ਜਾਂਚ:
ਲਿਸਟ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਇੱਕ ਪ੍ਰੋਡਕਟ ਫੀਚਰ ਵਾਂਗ ਸਮਝੋ, ਨਾ ਕਿ ਇੱਕ ਇਕ-ਵਾਰ ਦੀ ਚੀਜ਼। ਇੱਕ ਲਿਸਟ ਸਕਰੀਨ ਤਦ ਹੀ ਤੇਜ਼ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਇਹ ਅਸਲ ਲੋਕਾਂ ਦੁਆਰਾ ਸਕ੍ਰੋਲ, ਫਿਲਟਰ ਅਤੇ ਸੌਰਟ ਕੀਤੇ ਜਾਣ 'ਤੇ ਤੇਜ਼ ਮਹਿਸੂਸ ਕਰਨ।
ਇਸ ਚੈੱਕਲਿਸਟ ਨਾਲ ਇਹ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਤੁਸੀਂ ਸਹੀ ਚੀਜ਼ਾ ਠੀਕ ਕੀਤੀਆਂ ਹਨ:
ਇੱਕ ਸਧਾਰਨ ਹਕੀਕਤ-ਜਾਂਚ: ਲਿਸਟ ਖੋਲ੍ਹੋ, 10 ਸਕਿੰਟ ਲਈ ਸਕ੍ਰੋਲ ਕਰੋ, ਫਿਰ ਇੱਕ ਆਮ ਫਿਲਟਰ (ਜਿਵੇਂ Status: Open) ਲਗਾਓ। ਜੇ UI ਫ੍ਰੀਜ਼ ਹੋ ਜਾਂਦਾ ਹੈ, ਸਮੱਸਿਆ ਆਮ ਤੌਰ 'ਤੇ ਰੇਂਡਰਿੰਗ (ਬਹੁਤ ਸਾਰੇ DOM ਰੋਜ਼) ਜਾਂ ਹਰ ਅਪਡੇਟ 'ਤੇ ਹੋਣ ਵਾਲੀ ਭਾਰੀ ਕਲਾਇੰਟ-ਸਾਈਡ ਟ੍ਰਾਂਸਫਾਰਮ ਹੈ (ਸੌਰਟ, ਗਰੂਪ, ਫਾਰਮੇਟਿੰਗ)।
ਅਗਲੇ ਕਦਮ, ਕ੍ਰਮ ਵਿੱਚ, ਤਾਂ ਜੋ ਤੁਸੀਂ ਫਿਕਸਾਂ ਵਿੱਚ ਤੇਰ-ਬਦਲ ਨਾ ਹੋਵੋ:
ਜੇ ਤੁਸੀਂ Koder.ai (koder.ai) ਨਾਲ ਇਹ ਬਣਾਉਂਦੇ ਹੋ, Planning Mode ਵਿੱਚ ਸ਼ੁਰੂ ਕਰੋ: ਪਹਿਲਾਂ ਲਿਸਟ ਕਾਲਮ, ਫਿਲਟਰ ਫੀਲਡ ਅਤੇ API ਰਿਸਪਾਂਸ ਸ਼ੇਪ ਨਿਰਧਾਰਿਤ ਕਰੋ। ਫਿਰ snapshots ਅਤੇ ਰੋਲਬੈਕ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਇਟਰੇਟ ਕਰੋ ਜਦੋਂ ਕੋਈ ਪ੍ਰਯੋਗ ਸਕ੍ਰੀਨ ਨੂੰ ਧੀਮਾ ਕਰਦਾ ਹੈ ਤਾਂ ਵਾਪਿਸ ਜਾ ਸਕੋ।
ਲਕੜੀ ਕੀਤੇ ਗੋਲ ਨੂੰ “ਸਭ ਕੁਝ ਲੋਡ ਕਰੋ” ਤੋਂ ਬਦਲ ਕੇ “ਪਹਿਲੇ ਲਾਭਦਾਇਕ ਰੋਜ਼ ਤੇਜ਼ੀ ਨਾਲ ਦਿਖਾਓ” ਰੱਖੋ। ਪਹਿਲੀ ਪੰਗਤੀ ਦਰਅਸਲ ਭਰੋਸਾ ਬਣਾਉਂਦੀ ਹੈ—ਇਸ ਲਈ ਫੋਕਸ time to first row ਤੇ ਕਰੋ ਅਤੇ ਇਹ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਫਿਲਟਰ, ਛਾਂਟ ਅਤੇ ਸਕ੍ਰੋਲਿੰਗ ਸਮੂਥ ਹਨ, ਭਾਵੇਂ ਪੂਰਾ ਡੇਟਾਸੇਟ ਇੱਕਠੇ ਨਾ ਲੋਡ ਹੋਵੇ।
ਨਾਪੋ: ਪੇਜ ਖੋਲ੍ਹਣ ਜਾਂ ਫਿਲਟਰ ਬਦਲਣ 'ਤੇ ਪਹਿਲੀ ਪੰਗਤੀ ਆਉਣ ਦਾ ਸਮਾਂ, ਫਿਲਟਰ/ਸੌਰਟ ਅਪਡੇਟ ਦਾ ਸਮਾਂ, ਰਿਸਪਾਂਸ ਪੇਲੋਡ ਆਕਾਰ, ਧੀਮੇ ਡੇਟਾਬੇਸ ਕਵੇਰੀਜ਼ (ਖਾਸ ਕਰਕੇ ਵਾਈਡ SELECTs ਅਤੇ COUNT(*)), ਅਤੇ ਬ੍ਰਾੁਜ਼ਰ ਮੈਨ-ਥ੍ਰੈੱਡ ਸਪਾਈਕ. ਇਹ ਮੈਟਰਿਕਸ ਉਪਭੋਗਤਾ ਅਨੁਭਵ ਨਾਲ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਜੁੜੇ ਹੁੰਦੇ ਹਨ।
ਸਭ ਤੋਂ ਸਿਧਾ ਪਰਖ: ਉਸੇ UI ਨੂੰ ਰੱਖੋ ਪਰ ਬੈਕਐਂਡ ਨੂੰ ਅਸਥਾਈ ਤੌਰ 'ਤੇ ਸਿਰਫ 20 ਰੋਜ਼ ਵਾਪਸ ਕਰਨ ਲਈ ਸੀਮਿਤ ਕਰੋ। ਜੇ ਇਹ ਤੇਜ਼ ਹੋ ਜਾਂਦਾ ਹੈ ਤਾਂ ਬੋਤਲ-ਗਰਹ ਨੈੱਟਵਰਕ/ਕੁਐਰੀ ਜਾਂ ਪੇਲੋਡ ਆਕਾਰ ਹੈ; ਜੇ ਫਿਰ ਵੀ ਧੀਮਾ ਹੈ ਤਾਂ ਰੇਂਡਰਿੰਗ, ਫਾਰਮੇਟਿੰਗ ਜਾਂ ਪ੍ਰਤੀ-ਰੋਜ਼ ਕਲਾਇੰਟ-ਸਾਈਡ ਕੰਮ ਦੇਖੋ।
ਹਜ਼ਾਰਾਂ ਰੋਜ਼ DOM ਵਿੱਚ ਬਿਨਾਂ ਵਰਚੁਅਲਾਈਜ਼ੇਸ਼ਨ ਦੇ ਮਿਲਦਿਆਂ ਰੇਂਡਰ ਹੋ ਰਹੇ ਹੋਣ ਨਾਲ ਬ੍ਰਾੁਜ਼ਰ ਅਕਸਰ ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਬੋਤਲ-ਗਰਹ ਬਣ ਜਾਂਦਾ ਹੈ। ਸਰਲ ਬਦਲਾਅ: ਹਜ਼ਾਰਾਂ ਕਮਪੋਨੈਂਟ ਨਾ ਮਾਉਂਟ ਕਰੋ, ਰੋਜ਼ ਨੂੰ ਸਧਾਰਨ ਰੱਖੋ, ਅਤੇ ਰੋਜ਼ ਉੱਚਾਈ ਨੂੰ ਅਸਥਿਰ ਨਾ ਛੱਡੋ। ਬਾਹਰ-ਸਕ੍ਰੀਨ ਰੋਜ਼ਾਂ ਲਈ ਮਹਿੰਗੀ ਫਾਰਮੇਟਿੰਗ ਨੂੰ ਵਲੰਟਰੀ ਰੱਖੋ ਜਾਂ ਕੈਸ਼ ਕਰੋ।
ਵਰਚੁਅਲਾਈਜ਼ੇਸ਼ਨ ਸਿਰਫ਼ ਦਿਖਾਈ ਦੇ ਰਹੀਆਂ ਪੰਗਤੀਆਂ (ਥੋੜ੍ਹਾ ਬਫ਼ਰ ਸਮੇਤ) ਨੂੰ ਹੀ ਡ੍ਰਾਅ ਕਰਦਾ ਹੈ ਅਤੇ ਸਮਾਨ DOM ਐਲੀਮੈਂਟਾਂ ਨੂੰ ਰੀ-ਯੂਜ਼ ਕਰਦਾ ਹੈ। ਇਹ ਉਨ੍ਹਾਂ ਸਥਿਤੀਆਂ ਲਈ ਚੰਗਾ ਹੈ ਜਿੱਥੇ ਲੋਕ ਜ਼ਿਆਦਾ ਸਕ੍ਰੋਲ ਕਰਦੇ ਹਨ ਜਾਂ ਰੋਜ਼ ‘heavy’ ਹੁੰਦੇ ਹਨ। ਧਿਆਨ ਰੱਖੋ ਕਿ ਇਹ ਠੀਕ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਨ ਲਈ ਰੋਜ਼ ਹਾਈਟ ਸਥਿਰ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਅਤੇ ਕੀਬੋਰਡ ਨੈਵੀਗੇਸ਼ਨ ਤੇ ਫੋਕਸ-ਮੈਨੇਜਮੈਂਟ ਨੂੰ ਠੀਕ ਕੀਤਾ ਜਾਵੇ।
ਪੇਜੀਨੇਸ਼ਨ ਆਮ ਤੌਰ 'ਤੇ ਵੱਡੇ ਡੇਟਾਸੇਟ ਲਈ ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਹੈ—ਇਹ ਉਪਭੋਗਤਾ ਨੂੰ ਦਿਸ਼ਾ ਦਿੰਦੀ ਹੈ ਅਤੇ ਸਰਵਰ ਕੰਮ ਸੀਮਤ ਰੱਖਦੀ ਹੈ। ਇਨਫਿਨਿਟ ਸਕ੍ਰੋਲ ਆਰਾਮਦਾਇਕ ਹੋ ਸਕਦਾ ਹੈ ਪਰ ਨੈਵੀਗੇਸ਼ਨ, ਬੈਕ ਬਟਨ ਅਤੇ ਮੈਮੋਰੀ ਦੇ ਖਰਚੇ ਨੂੰ ਜਟਿਲ ਬਣਾਉਂਦਾ ਹੈ।Load more ਬਟਨ ਇੱਕ ਵਧੀਆ ਮੱਧ ਰਾਹ ਹੈ ਜਿਸ ਨਾਲ ਪੇਜਾਂ ਵਰਤੀ ਜਾਂਦੀਆਂ ਹਨ ਪਰ ਯੂਜ਼ਰ ਓਰੀਏਂਟੇਡ ਰਹਿੰਦਾ ਹੈ।
Offset (page=10&size=50) ਸਧਾਰਨ ਹੈ ਪਰ ਡੀਪ ਪੇਜਾਂ ਤੇ ਧੀਮਾ ਹੋ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਡੇਟਾਬੇਸ ਨੂੰ ਬਹੁਤ ਸਾਰੀਆਂ ਰੋਜ਼ਾਂ ਨੂੰ ਸ.skip ਕਰਨਾ ਪੈਂਦਾ ਹੈ।Keyset/ਕਰਸਰ ਪੇਜੀਨੇਸ਼ਨ (next 50 rows after last seen) ਆਮ ਤੌਰ ਤੇ ਤੇਜ਼ ਰਹਿੰਦੀ ਹੈ ਕਿਉਂਕਿ ਇਸ ਨੂੰ ਸਕਿਪ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਰਹਿੰਦੀ।
ਟੈਕਸਟ ਖੋਜ 'ਤੇ ਹਰ ਕੀਸਟ੍ਰੋਕ ਤੇ ਕੁਐਰੀ ਚਲਾਉਣ ਨਾਲ ਬੈਕਲੌਗ ਬਣਦਾ ਹੈ ਅਤੇ UI ਫਲਿਕਰ ਕਰਨ ਲੱਗਦਾ ਹੈ।ਟਾਈਪ ਨੂੰ ਡੀਬਾਊਂਸ ਕਰੋ, ਜ਼ਰੂਰੀ ਹੋਣ 'ਤੇ ਹੀ ਸਰਵਰ ਨੂੰ ਹਿੱਟ ਕਰੋ, ਅਤੇ ਜਦੋਂ ਨਿਰੀਖਣੀ ਫਿਲਟਰ ਤੇਜ਼ੀ ਨਾਲ ਨਤੀਜੇ ਘਟਾਉਂਦੇ ਹਨ ਤਾਂ ਸ਼ੁਰੂਆਤੀ ਡਿਫ਼ੌਲਟ ਨੈਰੋ ਰੱਖੋ (ਉਦਾਹਰਣ: ਆਖਰੀ 7 ਦਿਨ, My items)।
ਲਿਸਟ ਲਈ API ਸਿਰਫ ਉਹ ਫੀਲਡ ਵਾਪਸ ਕਰੇ ਜੋ ਰੋਜ਼ ਨੂੰ ਰੇਂਡਰ ਕਰਨ ਲਈ ਲੋੜੀਂਦੇ ਹਨ—ਆਮ ਤੌਰ ਤੇ id, ਲੇਬਲ, ਸਟੇਟਸ, ਮਲਿਕ, ਅਤੇ ਟਾਈਮਸਟੈਂਪ।ਲੰਮਾ ਟੈਕਸਟ, JSON ਬਲੌਬ ਅਤੇ ਘਣੇ ਜੁੜੇ ਹੋਏ ਡੇਟਾ ਨੂੰ ਡੀਟੇਲ ਰਿਕਵੇਸਟ ਵਿੱਚ ਛੱਡੋ।
ਡਿਫੌਲਟ ਫਿਲਟਰ ਅਤੇ ਸੌਰਟ ਨੂੰ ਵਾਸਤਵਿਕ ਵਰਤੋਂ ਨੁਸਖੇ ਨਾਲ ਮਿਲਾਓ ਅਤੇ ਫਿਰ ਉਸ ਪੈਟਰਨ ਲਈ ਇੰਡੈਕਸ ਜੋੜੋ।ਕੰਪੋਜਿਟ ਇੰਡੈਕਸ, keyset ਪੇਜੀਨੇਸ਼ਨ, ਰੋਜ਼ਾਂ ਨੂੰ ਪਤਲਾ ਰੱਖਣਾ (ਵੱਡੇ ਟੈਕਸਟ ਜਾਂ JSON ਨਾ ਲੈਣਾ) ਅਤੇ ਗਿਣਤੀ (COUNT) ਨੂੰ ਈਚਛਿਕ ਰੱਖਣਾ ਆਮ ਤੌਰ 'ਤੇ ਵੱਡੇ ਲਾਭ ਦਿੰਦੇ ਹਨ।