ویب سائٹ کو سست کرنے کا کوئی تیز طریقہ نہیں ہے (پن کا مقصد) اس پر جاوا اسکرپٹ کوڈ کا ایک گروپ استعمال کرنے سے زیادہ۔ جاوا اسکرپٹ کا استعمال کرتے وقت، آپ کو چار گنا سے کم منصوبوں کی کارکردگی کے ساتھ اس کی ادائیگی کرنی ہوگی۔ یہاں یہ ہے کہ سائٹ کا جاوا اسکرپٹ کوڈ کس طرح صارفین کے سسٹم کو لوڈ کرتا ہے:
- نیٹ ورک پر فائل ڈاؤن لوڈ کرنا۔
- ڈاؤن لوڈ کے بعد غیر پیک شدہ سورس کوڈ کو پارس کرنا اور مرتب کرنا۔
- جاوا اسکرپٹ کوڈ کا نفاذ۔
- میموری کی کھپت۔
یہ مجموعہ باہر کر دیتا ہے .
اور ہم اپنے پروجیکٹس میں زیادہ سے زیادہ جے ایس کوڈ شامل کرتے ہیں۔ جیسا کہ تنظیمیں ری ایکٹ، ویو اور دیگر جیسے فریم ورک اور لائبریریوں سے چلنے والی سائٹس کی طرف بڑھ رہی ہیں، ہم سائٹس کی بنیادی فعالیت کو جاوا اسکرپٹ پر بہت زیادہ انحصار کر رہے ہیں۔
میں نے جاوا اسکرپٹ فریم ورک کا استعمال کرتے ہوئے بہت سی بھاری سائٹیں دیکھی ہیں۔ لیکن اس معاملے کے بارے میں میرا نقطہ نظر بہت متعصب ہے۔ حقیقت یہ ہے کہ جن کمپنیوں کے ساتھ میں کام کرتا ہوں وہ بالکل میری طرف رجوع کرتی ہیں کیونکہ انہیں سائٹ کی کارکردگی کے میدان میں پیچیدہ مسائل کا سامنا ہے۔ نتیجے کے طور پر، میں اس بارے میں متجسس ہو گیا کہ یہ مسئلہ کتنا عام ہے، اور جب ہم کسی مخصوص سائٹ کی بنیاد کے طور پر ایک یا دوسرے فریم ورک کا انتخاب کرتے ہیں تو ہم کس قسم کے "جرمانے" ادا کرتے ہیں۔
پروجیکٹ نے مجھے اس کا پتہ لگانے میں مدد کی۔ .
ڈیٹا
HTTP آرکائیو پروجیکٹ باقاعدہ ڈیسک ٹاپ سائٹس کے کل 4308655 لنکس اور موبائل سائٹس کے 5484239 لنکس کو ٹریک کرتا ہے۔ ان لنکس سے منسلک بہت سے میٹرکس میں متعلقہ سائٹس پر پائی جانے والی ٹیکنالوجیز کی فہرست ہے۔ اس کا مطلب یہ ہے کہ ہم ہزاروں سائٹس کا نمونہ لے سکتے ہیں جو مختلف فریم ورک اور لائبریریوں کا استعمال کرتی ہیں اور اس بارے میں جانتی ہیں کہ وہ کلائنٹس کو کتنا کوڈ بھیجتے ہیں اور یہ کوڈ صارفین کے سسٹم پر کتنا بوجھ بناتا ہے۔
میں نے مارچ 2020 کا ڈیٹا اکٹھا کیا، جو سب سے حالیہ ڈیٹا تھا جس تک میری رسائی تھی۔
میں نے تمام سائٹس پر جمع HTTP آرکائیو ڈیٹا کا موازنہ React، Vue، اور Angular استعمال کرنے والی سائٹس کے ڈیٹا سے کرنے کا فیصلہ کیا، حالانکہ میں نے دوسرے ماخذ مواد کو بھی استعمال کرنے پر غور کیا۔
اسے مزید دلچسپ بنانے کے لیے، میں نے ماخذ ڈیٹا سیٹ میں jQuery استعمال کرنے والی سائٹیں بھی شامل کیں۔ یہ لائبریری اب بھی بہت مشہور ہے۔ یہ React، Vue اور Angular کی طرف سے پیش کردہ سنگل پیج ایپلیکیشن (SPA) ماڈل کے مقابلے ویب ڈویلپمنٹ کے لیے ایک مختلف نقطہ نظر بھی متعارف کراتا ہے۔
HTTP آرکائیو میں لنکس ان سائٹس کی نمائندگی کرتے ہیں جو دلچسپی کی ٹیکنالوجیز استعمال کرتے ہوئے پائے گئے ہیں۔
فریم ورک یا لائبریری
موبائل سائٹس کے لنکس
باقاعدہ سائٹس کے لنکس
jQuery کے
4615474
3714643
جواب دیں
489827
241023
قول
85649
43691
کونیی
19423
18088
امید اور خواب
اس سے پہلے کہ ہم ڈیٹا کے تجزیہ کی طرف بڑھیں، میں اس کے بارے میں بات کرنا چاہتا ہوں جس کی میں امید کرنا چاہوں گا۔
مجھے یقین ہے کہ ایک مثالی دنیا میں، فریم ورک کو ڈویلپرز کی ضروریات کو پورا کرنے سے آگے جانا چاہیے اور ہماری سائٹس کے ساتھ کام کرنے والے اوسط صارف کو کچھ خاص فائدہ فراہم کرنا چاہیے۔ کارکردگی ان فوائد میں سے صرف ایک ہے۔ یہ وہ جگہ ہے جہاں رسائی اور سیکیورٹی کھیل میں آتی ہے۔ لیکن یہ صرف سب سے اہم ہے۔
لہذا، ایک مثالی دنیا میں، کسی قسم کے فریم ورک کو اعلی کارکردگی والی سائٹ بنانا آسان بنانا چاہیے۔ یہ یا تو اس حقیقت کی وجہ سے کیا جانا چاہئے کہ فریم ورک ڈویلپر کو ایک معقول بنیاد فراہم کرتا ہے جس پر ایک پروجیکٹ بنانا ہے، یا اس حقیقت کی وجہ سے کہ یہ ترقی پر پابندیاں عائد کرتا ہے، اس کے لیے تقاضے پیش کرتا ہے جو کسی چیز کی ترقی کو پیچیدہ بناتا ہے۔ سست ہونا.
بہترین فریم ورک کو دونوں کام کرنے چاہئیں: ایک اچھی بنیاد دیں، اور کام پر پابندیاں لگائیں، جس سے آپ کو ایک معقول نتیجہ حاصل ہو سکے۔
ڈیٹا کی درمیانی قدروں کا تجزیہ کرنے سے ہمیں وہ معلومات نہیں ملیں گی جن کی ہمیں ضرورت ہے۔ اور، حقیقت میں، یہ نقطہ نظر ہماری توجہ سے باہر نکل جاتا ہے . اس کے بجائے، میں نے اپنے پاس موجود ڈیٹا سے فیصد اخذ کیا۔ یہ 10، 25، 50 (میڈین)، 75، 90 پرسنٹائل ہیں۔
مجھے خاص طور پر 10ویں اور 90ویں پرسنٹائل میں دلچسپی ہے۔ 10 واں پرسنٹائل کسی خاص فریم ورک کے لیے بہترین کارکردگی (یا کم از کم کم یا زیادہ بہترین کے قریب) کی نمائندگی کرتا ہے۔ دوسرے لفظوں میں، اس کا مطلب یہ ہے کہ صرف 10% سائٹیں جو کسی خاص فریم ورک کو استعمال کرتی ہیں اسے اس سطح یا اس سے زیادہ تک پہنچاتی ہیں۔ دوسری طرف، 90 واں پرسنٹائل، سکے کا دوسرا رخ ہے - یہ ہمیں دکھاتا ہے کہ چیزیں کتنی بری ہو سکتی ہیں۔ 90 واں پرسنٹائل وہ سائٹس ہیں جو پیچھے چل رہی ہیں — وہ سب سے نیچے والی 10% سائٹیں جن کے پاس سب سے زیادہ JS کوڈ ہے یا مرکزی دھاگے پر اپنے کوڈ کو پروسیس کرنے میں سب سے زیادہ وقت ہے۔
جاوا اسکرپٹ کوڈ کے حجم
شروع کرنے کے لیے، نیٹ ورک پر مختلف سائٹس کے ذریعے منتقل کیے جانے والے JavaScript کوڈ کے سائز کا تجزیہ کرنا سمجھ میں آتا ہے۔
جاوا اسکرپٹ کوڈ (Kb) کی مقدار جو موبائل آلات پر منتقل کی گئی ہے۔
پرسنٹائلز
10
25
50
75
90
تمام سائٹس
93.4
196.6
413.5
746.8
1201.6
jQuery سائٹس
110.3
219.8
430.4
748.6
1162.3
ویو سائٹس
244.7
409.3
692.1
1065.5
1570.7
کونیی سائٹس
445.1
675.6
1066.4
1761.5
2893.2
ردعمل سائٹس
345.8
441.6
690.3
1238.5
1893.6
موبائل آلات پر بھیجے گئے JavaScript کوڈ کی مقدار
جاوا اسکرپٹ کوڈ (Kb) کی مقدار ڈیسک ٹاپ ڈیوائسز پر منتقل کی گئی۔
پرسنٹائلز
10
25
50
75
90
تمام سائٹس
105.5
226.6
450.4
808.8
1267.3
jQuery سائٹس
121.7
242.2
458.3
803.4
1235.3
ویو سائٹس
248.0
420.1
718.0
1122.5
1643.1
کونیی سائٹس
468.8
716.9
1144.2
1930.0
3283.1
ردعمل سائٹس
308.6
469.0
841.9
1472.2
2197.8
ڈیسک ٹاپ ڈیوائسز پر بھیجے گئے JavaScript کوڈ کی مقدار
اگر ہم صرف JS کوڈ کے سائز کے بارے میں بات کرتے ہیں جو سائٹس ڈیوائسز کو بھیجتی ہیں، تو سب کچھ ویسا ہی نظر آتا ہے جیسا کہ آپ کی توقع ہے۔ یعنی، اگر کسی ایک فریم ورک کو استعمال کیا جاتا ہے، تو اس کا مطلب ہے کہ ایک مثالی صورت حال میں بھی، سائٹ کے JavaScript کوڈ کا حجم بڑھ جائے گا۔ یہ حیرت کی بات نہیں ہے - آپ جاوا اسکرپٹ فریم ورک کو کسی سائٹ کی بنیاد نہیں بنا سکتے اور توقع کرتے ہیں کہ پروجیکٹ کے جے ایس کوڈ کا حجم بہت کم ہوگا۔
اس ڈیٹا کے بارے میں جو بات قابل ذکر ہے وہ یہ ہے کہ کچھ فریم ورک اور لائبریریوں کو کسی پروجیکٹ کے لیے دوسروں کے مقابلے میں ایک بہتر نقطہ آغاز سمجھا جا سکتا ہے۔ jQuery والی سائٹیں بہترین نظر آتی ہیں۔ سائٹس کے ڈیسک ٹاپ ورژن پر، وہ تمام سائٹس کے مقابلے میں 15% زیادہ JavaScript پر مشتمل ہیں، اور موبائل پر ان میں 18% زیادہ ہے۔ (اعتراف ہے کہ یہاں ڈیٹا میں کچھ بدعنوانی ہے۔ حقیقت یہ ہے کہ jQuery بہت سی سائٹوں پر موجود ہے، اس لیے یہ فطری ہے کہ ایسی سائٹس سائٹس کی کل تعداد کے ساتھ دوسروں کے مقابلے میں زیادہ قریب سے وابستہ ہیں۔ تاہم، اس سے یہ متاثر نہیں ہوتا کہ خام ڈیٹا ہر فریم ورک کے لیے آؤٹ پٹ ہوتا ہے۔)
جبکہ کوڈ کے حجم میں 15-18% اضافہ ایک قابل ذکر اعداد و شمار ہے، دوسرے فریم ورک اور لائبریریوں کے ساتھ اس کا موازنہ کرتے ہوئے، کوئی یہ نتیجہ اخذ کر سکتا ہے کہ jQuery کی طرف سے عائد کردہ "ٹیکس" بہت کم ہے۔ 10ویں پرسنٹائل میں کونیی سائٹس تمام سائٹس کے مقابلے میں ڈیسک ٹاپ پر 344% زیادہ ڈیٹا اور موبائل پر 377% زیادہ ڈیٹا بھیجتی ہیں۔ React سائٹس اگلی سب سے بھاری ہیں، جو تمام سائٹس کے مقابلے ڈیسک ٹاپ پر 193% زیادہ کوڈ بھیجتی ہیں، اور موبائل پر 270% زیادہ۔
اس سے پہلے، میں نے ذکر کیا تھا کہ اگرچہ ایک فریم ورک کے استعمال کا مطلب یہ ہے کہ اس پراجیکٹ میں کوڈ کی ایک خاص مقدار شامل کی جائے گی، اس پر کام کے بالکل آغاز میں، مجھے امید ہے کہ فریم ورک کسی نہ کسی طرح ڈویلپر کو محدود کرنے کے قابل ہو گا۔ خاص طور پر، ہم کوڈ کی زیادہ سے زیادہ مقدار کو محدود کرنے کے بارے میں بات کر رہے ہیں۔
دلچسپ بات یہ ہے کہ jQuery سائٹس اس خیال کی پیروی کرتی ہیں۔ جب کہ وہ 10ویں پرسنٹائل (15-18% تک) پر تمام سائٹس سے قدرے زیادہ ہیں، وہ ڈیسک ٹاپ اور موبائل دونوں پر 90 فیصد کے قریب 3% پر قدرے ہلکے ہیں۔ اس کا مطلب یہ نہیں ہے کہ یہ ایک بہت اہم فائدہ ہے، لیکن یہ کہا جا سکتا ہے کہ jQuery سائٹس، کم از کم، ان کے سب سے بڑے ورژن میں بھی جاوا اسکرپٹ کوڈ کے بڑے سائز نہیں رکھتے ہیں۔
لیکن دوسرے فریم ورک کے بارے میں بھی یہی نہیں کہا جا سکتا۔
بالکل اسی طرح جیسے 10ویں پرسنٹائل کے معاملے میں، Angular اور React پر 90ویں پرسنٹائل سائٹس دیگر سائٹس سے مختلف ہیں، لیکن بدقسمتی سے، بدتر کے لیے ان میں فرق ہے۔
90ویں پرسنٹائل پر، انگولر سائٹس تمام سائٹس کے مقابلے میں 141% زیادہ ڈیٹا موبائل پر اور 159% زیادہ ڈیسک ٹاپ پر بھیجتی ہیں۔ رد عمل والی سائٹیں تمام سائٹوں کے مقابلے ڈیسک ٹاپ پر 73% زیادہ اور موبائل پر 58% زیادہ بھیجتی ہیں۔ 90ویں پرسنٹائل پر React سائٹس کا کوڈ سائز 2197.8 KB ہے۔ اس کا مطلب یہ ہے کہ ایسی سائٹیں Vue پر مبنی اپنے قریبی حریفوں کے مقابلے موبائل آلات پر 322.9 KB زیادہ ڈیٹا بھیجتی ہیں۔ Angular اور React اور دیگر سائٹس پر مبنی ڈیسک ٹاپ سائٹس کے درمیان فرق اور بھی بڑا ہے۔ مثال کے طور پر، ڈیسک ٹاپ ری ایکٹ سائٹیں مساوی Vue سائٹس کے مقابلے میں آلات کو 554.7 KB زیادہ JS کوڈ بھیجتی ہیں۔
مرکزی تھریڈ میں جاوا اسکرپٹ کوڈ پر کارروائی کرنے میں لگنے والا وقت
مندرجہ بالا اعداد و شمار واضح طور پر اشارہ کرتا ہے کہ مطالعہ کے تحت فریم ورک اور لائبریریوں کو استعمال کرنے والی سائٹس میں بڑی مقدار میں JavaScript کوڈ ہوتا ہے۔ لیکن یقینا، یہ ہماری مساوات کا صرف ایک حصہ ہے۔
جاوا اسکرپٹ کوڈ براؤزر میں آنے کے بعد، اسے قابل عمل حالت میں لانے کی ضرورت ہے۔ خاص طور پر بہت سے مسائل ان اعمال کی وجہ سے ہوتے ہیں جو مین براؤزر تھریڈ میں کوڈ کے ساتھ انجام پاتے ہیں۔ مرکزی دھاگہ صارف کے اعمال کی پروسیسنگ، طرزوں کا حساب لگانے، صفحہ کی ترتیب بنانے اور ڈسپلے کرنے کے لیے ذمہ دار ہے۔ اگر آپ جاوا اسکرپٹ کے ٹاسکس کے ساتھ مین تھریڈ کو مغلوب کرتے ہیں تو اسے باقی کاموں کو وقت پر مکمل کرنے کا موقع نہیں ملے گا۔ یہ صفحات کے کام میں تاخیر اور "بریک" کی طرف جاتا ہے.
HTTP آرکائیو ڈیٹا بیس میں معلومات موجود ہے کہ V8 انجن کے مرکزی دھاگے میں جاوا اسکرپٹ کوڈ پر کارروائی کرنے میں کتنا وقت لگتا ہے۔ اس کا مطلب ہے کہ ہم یہ ڈیٹا اکٹھا کر سکتے ہیں اور یہ معلوم کر سکتے ہیں کہ مرکزی تھریڈ کو مختلف سائٹس کے جاوا اسکرپٹ پر کارروائی کرنے میں کتنا وقت لگتا ہے۔
موبائل آلات پر اسکرپٹ پروسیسنگ سے متعلق پروسیسر کا وقت (ملی سیکنڈ میں)
پرسنٹائلز
10
25
50
75
90
تمام سائٹس
356.4
959.7
2372.1
5367.3
10485.8
jQuery سائٹس
575.3
1147.4
2555.9
5511.0
10349.4
ویو سائٹس
1130.0
2087.9
4100.4
7676.1
12849.4
کونیی سائٹس
1471.3
2380.1
4118.6
7450.8
13296.4
ردعمل سائٹس
2700.1
5090.3
9287.6
14509.6
20813.3
موبائل آلات پر اسکرپٹ پروسیسنگ سے متعلق پروسیسر کا وقت
پروسیسر کا وقت (ملی سیکنڈ میں) ڈیسک ٹاپ ڈیوائسز پر اسکرپٹ پروسیسنگ سے متعلق
پرسنٹائلز
10
25
50
75
90
تمام سائٹس
146.0
351.8
831.0
1739.8
3236.8
jQuery سائٹس
199.6
399.2
877.5
1779.9
3215.5
ویو سائٹس
350.4
650.8
1280.7
2388.5
4010.8
کونیی سائٹس
482.2
777.9
1365.5
2400.6
4171.8
ردعمل سائٹس
508.0
1045.6
2121.1
4235.1
7444.3
ڈیسک ٹاپ ڈیوائسز پر اسکرپٹ پروسیسنگ سے متعلق پروسیسر کا وقت
یہاں آپ کو بہت مانوس چیز نظر آتی ہے۔
شروعات کرنے والوں کے لیے، jQuery والی سائٹیں دیگر سائٹس کے مقابلے مین تھریڈ پر JavaScript پروسیسنگ پر نمایاں طور پر کم خرچ کرتی ہیں۔ 10ویں پرسنٹائل پر، تمام سائٹس کے مقابلے، موبائل پر jQuery سائٹس مرکزی تھریڈ پر JS کوڈ پر کارروائی کرنے میں %61 زیادہ وقت صرف کرتی ہیں۔ ڈیسک ٹاپ jQuery سائٹس کے معاملے میں، پروسیسنگ کے وقت میں 37% اضافہ ہوتا ہے۔ 90ویں پرسنٹائل پر، jQuery سائٹس مجموعی اسکور کے بہت قریب اسکور کرتی ہیں۔ خاص طور پر، موبائل ڈیوائسز پر jQuery سائٹس تمام سائٹس کے مقابلے مین تھریڈ پر 1.3% کم وقت اور ڈیسک ٹاپ ڈیوائسز پر 0.7% کم وقت گزارتی ہیں۔
ہماری درجہ بندی کے دوسری طرف وہ فریم ورک ہیں جن کی خصوصیت مرکزی دھاگے پر سب سے زیادہ بوجھ ہے۔ یہ، دوبارہ، کونیی اور رد عمل ہے۔ دونوں کے درمیان فرق صرف یہ ہے کہ جب Angular سائٹس React سائٹس کے مقابلے براؤزرز کو زیادہ کوڈ بھیجتی ہیں، Angular سائٹس کوڈ پر کارروائی کرنے میں CPU کا کم وقت لگتا ہے۔ کہیں کم.
10ویں پرسنٹائل پر، ڈیسک ٹاپ انگولر سائٹس مرکزی تھریڈ پروسیسنگ JS کوڈ پر تمام سائٹس کے مقابلے میں 230% زیادہ وقت صرف کرتی ہیں۔ موبائل سائٹس کے لیے، یہ تعداد 313% ہے۔ ری ایکٹ سائٹس بدترین کارکردگی کا مظاہرہ کرنے والی ہیں۔ ڈیسک ٹاپ پر، وہ تمام سائٹوں کے مقابلے 248% زیادہ وقت کوڈ پر عملدرآمد کرتے ہیں، اور 658% زیادہ موبائل پر۔ 658% کوئی ٹائپنگ نہیں ہے۔ 10ویں پرسنٹائل پر، React سائٹس اپنے کوڈ پر کارروائی کرنے میں 2.7 سیکنڈ مین تھریڈ ٹائم صرف کرتی ہیں۔
90 واں پرسنٹائل، جب ان بڑی تعدادوں کے مقابلے میں، کم از کم تھوڑا بہتر لگتا ہے۔ تمام سائٹس کے مقابلے میں، انگولر پروجیکٹس مین تھریڈ میں ڈیسک ٹاپ ڈیوائسز پر 29% زیادہ وقت اور موبائل ڈیوائسز پر 27% زیادہ وقت گزارتے ہیں۔ React سائٹس کے معاملے میں، وہی اعداد و شمار بالترتیب 130% اور 98% کی طرح نظر آتے ہیں۔
90ویں پرسنٹائل کے لیے فیصد انحراف 10ویں پرسنٹائل کے لیے ملتے جلتے قدروں سے بہتر نظر آتے ہیں۔ لیکن یہاں یہ یاد رکھنے کے قابل ہے کہ وقت کی نشاندہی کرنے والی تعداد کافی خوفناک لگتی ہے۔ آئیے کہتے ہیں کہ ری ایکٹ کے ساتھ بنی ویب سائٹ کے مرکزی موبائل تھریڈ پر 20.8 سیکنڈ۔ (میرے خیال میں اس دوران اصل میں کیا ہوتا ہے اس کی کہانی ایک الگ مضمون کے لائق ہے)۔
یہاں ایک ممکنہ پیچیدگی ہے (شکریہ اس خصوصیت کی طرف میری توجہ مبذول کرانے کے لیے، اور اس نقطہ نظر سے ڈیٹا پر غور کرنے کے لیے)۔ حقیقت یہ ہے کہ بہت سی سائٹیں کئی فرنٹ اینڈ ٹولز استعمال کرتی ہیں۔ خاص طور پر، میں نے React یا Vue کے ساتھ ساتھ jQuery کا استعمال کرتے ہوئے بہت ساری سائٹیں دیکھی ہیں، کیونکہ وہ سائٹس jQuery سے دوسرے فریم ورک یا لائبریریوں میں منتقل ہو رہی ہیں۔ نتیجے کے طور پر، میں نے دوبارہ ڈیٹا بیس کو مارا، اس بار صرف ان لنکس کو منتخب کر رہا ہوں جو ان سائٹس سے مطابقت رکھتے ہیں جو صرف React، jQuery، Angular، یا Vue استعمال کرتی ہیں، لیکن ان کا کوئی مجموعہ نہیں۔ مجھے جو ملا وہ یہ ہے۔
پروسیسر کا وقت (ملی سیکنڈ میں) موبائل آلات پر اسکرپٹ کی پروسیسنگ سے متعلق ایسی صورتحال میں جہاں سائٹس صرف ایک فریم ورک یا صرف ایک لائبریری استعمال کرتی ہیں۔
پرسنٹائلز
10
25
50
75
90
وہ سائٹیں جو صرف jQuery استعمال کرتی ہیں۔
542.9
1062.2
2297.4
4769.7
8718.2
وہ سائٹس جو صرف Vue استعمال کرتی ہیں۔
944.0
1716.3
3194.7
5959.6
9843.8
وہ سائٹس جو صرف کونیی استعمال کرتی ہیں۔
1328.9
2151.9
3695.3
6629.3
11607.7
وہ سائٹس جو صرف React کا استعمال کرتی ہیں۔
2443.2
4620.5
10061.4
17074.3
24956.3
پروسیسر کا وقت موبائل آلات پر اسکرپٹس کی پروسیسنگ سے متعلق ایسی صورتحال میں جہاں سائٹیں صرف ایک فریم ورک، یا صرف ایک لائبریری استعمال کرتی ہیں۔
سب سے پہلے، کوئی ایسی چیز جو حیران کن نہیں ہے: جب کوئی سائٹ صرف ایک فریم ورک یا ایک لائبریری کا استعمال کرتی ہے، تو ایسی سائٹ کی کارکردگی اکثر بہتر ہوتی ہے۔ ہر آلہ 10ویں اور 25ویں پرسنٹائل پر بہتر کارکردگی کا مظاہرہ کرتا ہے۔ یہ سمجھ میں آتا ہے. جو سائٹ ایک فریم ورک کا استعمال کرتے ہوئے بنائی گئی ہے اسے اس سائٹ سے بہتر کارکردگی دکھانی چاہیے جو دو یا زیادہ فریم ورک یا لائبریریوں کا استعمال کرتے ہوئے بنائی گئی ہو۔
درحقیقت، مطالعہ کیے گئے ہر فرنٹ اینڈ ٹول کی کارکردگی تمام معاملات میں بہتر نظر آتی ہے، سوائے ایک دلچسپ استثنا کے۔ جس چیز نے مجھے حیران کیا وہ یہ تھا کہ 50 ویں پرسنٹائل اور اس سے اوپر کی سائٹیں React کا استعمال کرنے والی سائٹیں اس وقت بدتر کارکردگی کا مظاہرہ کرتی ہیں جب React واحد لائبریری ہے جسے وہ استعمال کرتے ہیں۔ ویسے، یہی وجہ تھی کہ میں یہ ڈیٹا یہاں پیش کرتا ہوں۔
یہ تھوڑا سا عجیب ہے، لیکن میں پھر بھی اس عجیب و غریب کی وضاحت تلاش کرنے کی کوشش کروں گا۔
اگر کوئی پروجیکٹ React اور jQuery دونوں کو استعمال کرتا ہے، تو پھر وہ پروجیکٹ jQuery سے React میں منتقلی کے دوران آدھے راستے پر ہونے کا امکان ہے۔ شاید اس کا کوڈ بیس ہے جہاں ان لائبریریوں کو ملایا گیا ہے۔ چونکہ ہم پہلے ہی دیکھ چکے ہیں کہ jQuery سائٹس React سائٹس کے مقابلے مین تھریڈ پر کم وقت گزارتی ہیں، اس لیے یہ ہمیں بتا سکتا ہے کہ jQuery میں کچھ فعالیت کو نافذ کرنے سے سائٹ کو کچھ بہتر کارکردگی دکھانے میں مدد ملتی ہے۔
لیکن جیسا کہ پروجیکٹ jQuery سے React میں منتقل ہوتا ہے اور React پر زیادہ انحصار کرتا ہے، چیزیں بدل رہی ہیں۔ اگر سائٹ واقعی اعلیٰ معیار کی ہے، اور سائٹ کے ڈویلپرز React کو احتیاط سے استعمال کرتے ہیں، تو ایسی سائٹ کے ساتھ سب کچھ ٹھیک ہو جائے گا۔ لیکن اوسط React سائٹ کے لیے، React کے وسیع استعمال کا مطلب ہے کہ مرکزی دھاگہ بہت زیادہ بوجھ کے نیچے ہے۔
موبائل اور ڈیسک ٹاپ ڈیوائسز کے درمیان فرق
ایک اور نقطہ نظر جس سے میں نے تحقیق شدہ ڈیٹا کو دیکھا اس کا مطالعہ کرنا تھا کہ موبائل اور ڈیسک ٹاپ ڈیوائسز پر سائٹس کے ساتھ کام کرنے کے درمیان کتنا بڑا فرق ہے۔ اگر ہم جاوا اسکرپٹ کوڈ کے حجم کا موازنہ کرنے کے بارے میں بات کرتے ہیں، تو اس طرح کا موازنہ خوفناک چیز کو ظاہر نہیں کرتا ہے۔ بلاشبہ، ڈاؤن لوڈ کے قابل کوڈ کی کم مقدار دیکھنا اچھا لگے گا، لیکن موبائل اور ڈیسک ٹاپ کوڈ کی مقدار میں زیادہ فرق نہیں ہے۔
لیکن اگر ہم کوڈ پر کارروائی کے لیے درکار وقت کا تجزیہ کریں تو موبائل اور ڈیسک ٹاپ ڈیوائسز کے درمیان ایک بہت بڑا فرق نمایاں ہو جاتا ہے۔
ڈیسک ٹاپ کے مقابلے موبائل آلات پر اسکرپٹس کی پروسیسنگ سے متعلق وقت (فیصد) میں اضافہ
پرسنٹائلز
10
25
50
75
90
تمام سائٹس
144.1
172.8
185.5
208.5
224.0
jQuery سائٹس
188.2
187.4
191.3
209.6
221.9
ویو سائٹس
222.5
220.8
220.2
221.4
220.4
کونیی سائٹس
205.1
206.0
201.6
210.4
218.7
ردعمل سائٹس
431.5
386.8
337.9
242.6
179.6
اگرچہ ایک فون اور لیپ ٹاپ کے درمیان کوڈ پروسیسنگ کی رفتار میں کچھ فرق کی توقع کی جانی چاہئے، اتنی بڑی تعداد مجھے بتاتی ہے کہ جدید فریم ورک کم طاقت والے آلات کو کافی حد تک نشانہ نہیں بنا رہے ہیں، اور وہ اس خلا کو ختم کرنے کی کوشش کر رہے ہیں جو انہوں نے دریافت کیا ہے۔ 10ویں پرسنٹائل پر بھی، React سائٹس موبائل مین تھریڈ پر ڈیسک ٹاپ مین تھریڈ کے مقابلے میں 431.5% زیادہ وقت گزارتی ہیں۔ jQuery میں سب سے چھوٹا فرق ہے، لیکن یہاں بھی متعلقہ اعداد و شمار 188.2% ہے۔ جب ویب سائٹ کے ڈویلپرز اپنے پروجیکٹ اس طرح بناتے ہیں کہ ان کی پروسیسنگ میں زیادہ پروسیسر کا وقت درکار ہوتا ہے (اور ایسا ہوتا ہے، اور یہ وقت کے ساتھ ساتھ مزید خراب ہوتا جاتا ہے)، تو کم طاقت والے آلات کے مالکان کو اس کی قیمت ادا کرنی پڑتی ہے۔
کے نتائج
اچھے فریم ورک کو ڈویلپرز کو ویب پراجیکٹس کی تعمیر کے لیے اچھی بنیاد فراہم کرنی چاہیے (سیکیورٹی، رسائی، کارکردگی کے لحاظ سے)، یا ان میں پہلے سے موجود پابندیاں ہونی چاہیے جو ان پابندیوں کی خلاف ورزی کرنے والی کوئی چیز بنانا مشکل بناتی ہیں۔
ایسا لگتا ہے کہ یہ ویب پروجیکٹس کی کارکردگی پر لاگو نہیں ہوتا ہے (اور شاید ان پر نہیں۔ ).
یہ بات قابل غور ہے کہ صرف اس وجہ سے کہ React یا Angular سائٹس دوسروں کے مقابلے کوڈ کی تیاری میں زیادہ CPU وقت صرف کرتی ہیں اس کا لازمی طور پر یہ مطلب نہیں ہے کہ React سائٹیں چلتے وقت Vue سائٹس کے مقابلے زیادہ CPU کی حامل ہوتی ہیں۔ درحقیقت، ہم نے جس ڈیٹا کا جائزہ لیا ہے وہ فریم ورک اور لائبریریوں کی آپریشنل کارکردگی کے بارے میں بہت کم بتاتا ہے۔ وہ ترقی کے طریقوں کے بارے میں مزید بات کرتے ہیں کہ، شعوری طور پر یا نہیں، یہ فریم ورک پروگرامرز کو آگے بڑھا سکتے ہیں۔ ہم فریم ورک کے لیے دستاویزات کے بارے میں، ان کے ماحولیاتی نظام کے بارے میں، عام ترقی کی تکنیکوں کے بارے میں بات کر رہے ہیں۔
یہ بات بھی قابل ذکر ہے کہ ہم نے یہاں اس کا تجزیہ نہیں کیا، یعنی سائٹ کے صفحات کے درمیان نیویگیٹ کرتے وقت ڈیوائس جاوا اسکرپٹ کوڈ پر عمل کرنے میں کتنا وقت صرف کرتی ہے۔ SPA کے حق میں دلیل یہ ہے کہ ایک بار براؤزر میں سنگل پیج ایپلیکیشن لوڈ ہو جانے کے بعد، صارف نظریاتی طور پر سائٹ کے صفحات کو تیزی سے کھولنے کے قابل ہو جائے گا۔ میرا اپنا تجربہ بتاتا ہے کہ یہ حقیقت سے بعید ہے۔ لیکن ہمارے پاس اس مسئلے کو واضح کرنے کے لیے ڈیٹا نہیں ہے۔
جو بات واضح ہے وہ یہ ہے کہ اگر آپ ویب سائٹ بنانے کے لیے ایک فریم ورک یا لائبریری کا استعمال کر رہے ہیں، تو آپ ابتدائی طور پر پروجیکٹ کو لوڈ کرنے اور اسے جانے کے لیے تیار کرنے کے معاملے میں سمجھوتہ کر رہے ہیں۔ یہ سب سے زیادہ مثبت منظرناموں پر بھی لاگو ہوتا ہے۔
مناسب حالات میں کچھ سمجھوتہ کرنا بالکل ممکن ہے، لیکن یہ ضروری ہے کہ ڈویلپر ایسے سمجھوتے شعوری طور پر کریں۔
لیکن ہمارے پاس پرامید ہونے کی وجہ بھی ہے۔ میں یہ دیکھ کر بہت پرجوش ہوں کہ کروم ڈویلپرز کچھ فرنٹ اینڈ ٹولز کے ڈویلپرز کے ساتھ کتنے قریب سے کام کر رہے ہیں جن کا ہم نے ان ٹولز کی کارکردگی کو بہتر بنانے میں مدد کرنے کی کوشش میں جائزہ لیا ہے۔
تاہم، میں ایک عملی آدمی ہوں۔ نئے فن تعمیرات کارکردگی کے مسائل کو جتنی بار حل کرتے ہیں پیدا کرتے ہیں۔ اور کیڑے ٹھیک کرنے میں وقت لگتا ہے۔ جس طرح ہمیں توقع نہیں رکھنی چاہیے۔ کارکردگی کے تمام مسائل حل کر دے گا، آپ کو ہمارے پسندیدہ فریم ورک کے نئے ورژن سے اس کی توقع نہیں کرنی چاہیے۔
اگر آپ اس مضمون میں زیر بحث فرنٹ اینڈ ٹولز میں سے کسی ایک کو استعمال کرنا چاہتے ہیں، تو اس کا مطلب ہے کہ آپ کو اس دوران اپنے پروجیکٹ کی کارکردگی کو نقصان نہ پہنچانے کے لیے اضافی کوشش کرنی ہوگی۔ نیا فریم ورک شروع کرنے سے پہلے غور کرنے کے لیے یہاں کچھ باتیں ہیں:
- عقل سے اپنے آپ کو پرکھیں۔ کیا آپ کو واقعی منتخب کردہ فریم ورک کو استعمال کرنے کی ضرورت ہے؟ خالص جاوا اسکرپٹ آج بہت کچھ کرنے کے قابل ہے۔
- کیا منتخب کردہ فریم ورک کا کوئی ہلکا متبادل ہے (جیسے Preact، Svelte یا کچھ اور) جو آپ کو اس فریم ورک کی 90% صلاحیتیں دے سکتا ہے؟
- اگر آپ پہلے سے ہی ایک فریم ورک استعمال کر رہے ہیں، تو غور کریں کہ کیا کوئی ایسی چیز ہے جو بہتر، زیادہ قدامت پسند، معیاری اختیارات پیش کرتی ہے (مثلاً Vue کی بجائے Nuxt.js، React کی بجائے Next.js، وغیرہ)۔
- آپ کا کیا ہوگا جاوا اسکرپٹ کی کارکردگی؟
- تم کیسے کرسکتے ہو ایک ترقیاتی عمل جس سے کسی پروجیکٹ میں زیادہ جاوا اسکرپٹ کوڈ لگانا بالکل ضروری ہو؟
- اگر آپ ترقی کی آسانی کے لیے کوئی فریم ورک استعمال کر رہے ہیں تو غور کریں۔ گاہکوں کو فریم ورک کوڈ بھیجیں۔ ہوسکتا ہے کہ آپ سرور پر موجود تمام مسائل کو حل کرسکیں؟
عام طور پر یہ آئیڈیاز دیکھنے کے قابل ہوتے ہیں، قطع نظر اس کے کہ آپ نے فرنٹ اینڈ ڈیولپمنٹ کے لیے بالکل کیا انتخاب کیا ہے۔ لیکن یہ خاص طور پر اس وقت اہم ہوتے ہیں جب آپ کسی ایسے پروجیکٹ پر کام کر رہے ہوتے ہیں جس میں شروع سے ہی کارکردگی کا فقدان ہو۔
پیارے قارئین! آپ مثالی جاوا اسکرپٹ فریم ورک کو کیسے دیکھتے ہیں؟
ماخذ: www.habr.com