ਆਡਿਟ ਕਿਵੇਂ ਕੀਤਾ ਗਿਆ ਸੀ

ਅਸੀਂ 12 ਅਮਰੀਕੀ ਸ਼ਹਿਰਾਂ ਵਿੱਚ ਸਥਾਨਕ ਸੇਵਾਵਾਂ—ਪਲੰਬਰ, ਦੰਦਾਂ ਦੇ ਡਾਕਟਰ, ਸੈਲੂਨ—ਲਈ ਆਰਗੈਨਿਕ ਸਰਚ ਨਤੀਜਿਆਂ ਵਿੱਚ ਦਿਖਾਈ ਦੇਣ ਵਾਲੀਆਂ ਵੈੱਬਸਾਈਟਾਂ ਨੂੰ ਇਕੱਠਾ ਕੀਤਾ। ਅਸੀਂ ਸਿਰਫ਼ ਕਾਰੋਬਾਰਾਂ ਦੇ ਆਪਣੇ ਡੋਮੇਨਾਂ ਨੂੰ ਰੱਖਿਆ ਅਤੇ ਡਾਇਰੈਕਟਰੀਆਂ ਅਤੇ ਰਾਸ਼ਟਰੀ ਚੇਨਾਂ ਨੂੰ ਬਾਹਰ ਰੱਖ ਦਿੱਤਾ। ਅਗਸਤ 2026 ਵਿੱਚ, ਅਸੀਂ ਹਰੇਕ ਸਾਈਟ 'ਤੇ ਇੱਕ ਸਿੰਗਲ Lighthouse ਮੋਬਾਈਲ ਆਡਿਟ ਚਲਾਇਆ, ਜਿਸ ਨਾਲ Google ਨੂੰ Largest Contentful Paint (LCP) ਅਤੇ ਸਮੁੱਚਾ ਪਰਫਾਰਮੈਂਸ ਸਕੋਰ ਗਣਨਾ ਕਰਨ ਦਿੱਤਾ।

ਅੰਕੜੇ ਕੀ ਦੱਸਦੇ ਹਨ

  • Median LCP: 8.9 ਸੈਕਿੰਡ – ਉਹ ਸਮਾਂ ਜੋ ਸਭ ਤੋਂ ਵੱਡੇ ਕੰਟੈਂਟ ਨੂੰ ਦਿਖਾਈ ਦੇਣ ਲਈ ਲੱਗਦਾ ਹੈ।
  • Google ਦੀ "ਚੰਗੀ" ਸੀਮਾ: 2.5 ਸੈਕਿੰਡ।
  • ਸੀਮਾ ਨੂੰ ਪੂਰਾ ਕਰਨ ਵਾਲੀਆਂ ਸਾਈਟਾਂ: 139 ਵਿੱਚੋਂ 4 (3%)।
  • Median JavaScript payload: ਪੇਜ ਦੁਆਰਾ ਉਪਭੋਗਤਾ ਨੂੰ ਜਵਾਬ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ 1.2 MB।
  • Median ਮੋਬਾਈਲ ਪਰਫਾਰਮੈਂਸ ਸਕੋਰ: 57।

ਅਸੀਂ ਜਿਸ ਵੀ ਪਲੇਟਫਾਰਮ ਦੀ ਜਾਂਚ ਕੀਤੀ—WordPress, ਹੋਸਟਡ ਸਾਈਟ ਬਿਲਡਰ, ਹੋਰ CMSs—ਉਨ੍ਹਾਂ ਸਾਰਿਆਂ ਵਿੱਚ ਇੱਕੋ ਜਿਹਾ ਪੈਟਰਨ ਦੇਖਿਆ ਗਿਆ: ਵਾਧੂ ਕੋਡ ਅਤੇ third-party widgets ਪਰਫਾਰਮੈਂਸ ਨੂੰ ਹੇਠਾਂ ਸੁੱਟ ਰਹੇ ਹਨ।

ਇਸ ਲਈ ਕੌਣ ਜ਼ਿੰਮੇਵਾਰ ਹੈ

ਇੱਕ ਅਸੰਗਠਿਤ (fragmented) ਡਿਵੈਲਪਮੈਂਟ ਪ੍ਰਕਿਰਿਆ ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਪੈਦਾ ਕਰਦੀ ਹੈ। ਇੱਕ ਡਿਵੈਲਪਰ ਇੱਕ ਥੀਮ ਪਾਉਂਦਾ ਹੈ, ਦੂਜਾ ਇੱਕ ਚੈਟ ਵਿਜੈਟ ਜੋੜਦਾ ਹੈ, ਤੀਜਾ ਇੱਕ ਬੁਕਿੰਗ ਟੂਲ ਲਗਾਉਂਦਾ ਹੈ, ਅਤੇ ਹਰੇਕ ਬਦਲਾਅ ਦੀ ਜਾਂਚ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਨਤੀਜਾ ਇੱਕ ਭਾਰੀ JavaScript bundle ਅਤੇ ਦੇਰੀ ਨਾਲ ਰੈਂਡਰਿੰਗ ਹੁੰਦਾ ਹੈ, ਭਾਵੇਂ ਕਿ ਕੋਈ ਵੀ ਇੱਕ ਵੱਖਰੀ ਚੀਜ਼ ਆਪਣੇ ਆਪ ਵਿੱਚ ਚਿੰਤਾਜਨਕ ਨਾ ਲੱਗੇ।

ਇੱਕ ਸਾਵਧਾਨੀ ਨੋਟ

ਅਸੀਂ ਹਰੇਕ ਸਾਈਟ 'ਤੇ ਸਿਰਫ਼ ਇੱਕ Lighthouse ਟੈਸਟ ਚਲਾਇਆ ਹੈ, ਇਸ ਲਈ ਨੈੱਟਵਰਕ ਦੀਆਂ ਸਥਿਤੀਆਂ, ਡਿਵਾਈਸ ਹਾਰਡਵੇਅਰ, ਜਾਂ ਸਰਵਰ ਲੋਡ ਦੇ ਨਾਲ ਪਰਫਾਰਮੈਂਸ ਬਦਲ ਸਕਦੀ ਹੈ। ਇਹਨਾਂ ਅੰਕੜਿਆਂ ਨੂੰ ਇੱਕ ਤਸਵੀਰ (snapshot) ਵਜੋਂ ਲਓ, ਨਾ ਕਿ ਹਰ ਛੋਟੇ ਕਾਰੋਬਾਰ ਲਈ ਇੱਕ ਅੰਤਿਮ ਫੈਸਲੇ ਵਜੋਂ।

ਅੱਗੇ ਕੀ ਦੇਖਣਾ ਹੈ

ਆਡਿਟ ਦੇ ਪਿੱਛੇ ਦਾ ਡੇਟਾ ਸੈੱਟ ਜਨਤਕ ਤੌਰ 'ਤੇ ਉਪਲਬਧ ਹੈ—ਤੁਸੀਂ ਅੰਕੜਿਆਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰ ਸਕਦੇ ਹੋ ਜਾਂ ਕਿਸੇ ਹੋਰ ਸ਼ਹਿਰ ਵਿੱਚ ਆਪਣੇ ਟੈਸਟ ਚਲਾ ਸਕਦੇ ਹੋ। ਸਿੱਖਿਆ ਸਪੱਸ਼ਟ ਹੈ: ਜ਼ਿਆਦਾਤਰ ਛੋਟੇ ਕਾਰੋਬਾਰਾਂ ਦੀਆਂ ਸਾਈਟਾਂ ਮੋਬਾਈਲ-ਰੇਡੀ ਹੋਣ ਤੋਂ ਬਹੁਤ ਦੂਰ ਹਨ, ਅਤੇ ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਸੁਧਾਰਨ ਲਈ ਟੁਕੜਿਆਂ ਵਿੱਚ ਫੀਚਰ ਜੋੜਨ ਦੀ ਬਜਾਏ ਇੱਕ ਤਾਲਮੇਲ ਵਾਲੇ, ਪਰਫਾਰਮੈਂਸ-ਪਹਿਲ ਵਾਲੇ ਪਹੁੰਚ ਦੀ ਲੋੜ ਹੋਵੇਗੀ।