اس بارے میں ریسرچ ہوتی ہے اور رپورٹس شائع ہوتی ہیں کہ انٹرنیٹ کے صارفین کے صبر کا پیمانہ دن بدن محدود ہوتا چلا جا رہا ہے۔ اگر کسی ویب سائیٹ کے صفحات ڈاؤن لوڈ ہونے میں توقع سے زیادہ وقت لینے لگ جائیں تو صارفین کوئی متبادل ویب سائیٹ تلاش کرتے ہیں۔ چنانچہ بڑی کمپنیاں اپنی ویب سائیٹس تیار کرتے وقت اس بات کو مدنظر رکھتی ہیں کہ کیا ان کی ویب سائیٹ کے صفحات ڈاؤن لوڈ ہونے میں ان کے مد مقابل کمپنی کی ویب سائیٹ کے صفحات سے زیادہ وقت تو نہیں لے رہے۔ اگر ایسا ہو رہا ہو تو پھر وہ اس کا حل تلاش کرتے ہیں۔ ویب سرورز کے لیے بہتر سے بہتر ہارڈ ویئرز منتخب کیے جاتے ہیں، تیز سے تیز رفتار انٹرنیٹ کنکشنز حاصل کیے جاتے ہیں، اور ویب سائیٹ کے صفحات کو ہلکا پھلکا بنانے کی کوشش کی جاتی ہے تاکہ صارفین تیز رفتاری کے ساتھ ویب سائیٹ کے صفحات وزٹ کر سکیں۔
خصوصاً موبائل ڈیوائسز کے حالیہ انقلاب نے تو اس بات کی اہمیت اور بھی بڑھا دی ہے کہ ویب پیجز صرف ڈیسک ٹاپ اور لیپ ٹاپ کمپیوٹرز ذہن میں رکھ کر نہ بنائے جائیں۔ اگرچہ آج کے ٹیبز اور سمارٹ فونز کے ہارڈویئرز چند سال پہلے کے لیپ ٹاپس سے بہتر ہیں، لیکن سب صارفین کے پاس ایسی تیز رفتار ڈیوائسز نہیں ہوتیں۔ اور پھر جن صارفین کا زیادہ انحصار ڈیٹا پلانز پر ہوتا ہے وہ لمبے چوڑے ویب پیجز کی حامل ویب سائیٹس وزٹ کرنے سے ہچکچاتے ہیں۔
آئیں سست رفتار ڈاؤن لوڈنگ کی وجوہات اور ان کے حل کے متعلق بات کرتے ہیں۔
- ڈاؤن لوڈنگ کی رفتار سست کیسے ہوتی ہے؟
- انٹرنیٹ کی ٹریفک اور ڈاؤن لوڈنگ کی رفتار
- ویب سائیٹ کے ویب پیجز کیسے تیار کیے جا رہے ہیں؟
- آخری الفاظ
ڈاؤن لوڈنگ کی رفتار سست کیسے ہوتی ہے؟
اگر کسی ویب سائیٹ کے ویب پیجز سست رفتاری کے ساتھ ڈاؤن لوڈ ہو رہے ہیں تو اس کی دو بڑی وجوہات ہو سکتی ہیں۔ پہلی وجہ یہ کہ صارف اور ویب سرور کے درمیان نیٹ ورک پر کوئی مسئلہ موجود ہے جس نے ان دونوں کے درمیان ڈیٹا کی ترسیل کی رفتار سست کر دی ہے۔ دوسری وجہ یہ کہ ویب سائیٹ کے ویب پیجز کو Optimize نہیں کیا گیا، یعنی انہیں تیز رفتاری کے ساتھ ڈاؤن لوڈ ہونے کے لیے ہلکا پھلکا بنانے کی کوشش نہیں کی گئی۔
اس تحریر کا اصل مقصد دوسری وجہ پر بات کرنا ہے کہ بحیثیت ویب ڈیویلپر آپ اپنی ویب سائیٹ کے ویب پیجز کو تیز رفتار بنانے کے لیے کیا کر سکتے ہیں۔ پہلی وجہ پر چونکہ عام ویب ڈیویلپر کا کچھ زیادہ کنٹرول نہیں ہوتا ،اس لیے اس کا صرف تعارفی انداز میں تذکرہ کیا جائے گا۔
انٹرنیٹ کی ٹریفک اور ڈاؤن لوڈنگ کی رفتار
انٹرنیٹ کی ٹریفک بھی گاڑیوں کی ٹریفک کی طرح کام کرتی ہے۔ دن کے وقت جب لوگ اپنے روز مرہ کاموں کے لیے سفر کر رہے ہوتے ہیں تو سڑکیں بھری ہوتی ہیں اور گاڑیاں بہت سست رفتاری کے ساتھ آگے بڑھ رہی ہوتی ہیں۔ لیکن رات کے وقت سڑکیں خالی ہوتی ہیں اور گاڑیوں کو بلا ضرورت کہیں بریک لگانے کی ضرورت کم ہی پیش آتی ہے۔ اسی طرح اگر صارف آپ کی ویب سائیٹ ایسے وقت میں دیکھ رہا ہے جب انٹرنیٹ پر زیادہ ٹریفک موجود نہیں ہے تو پھر ویب پیجز صارف کی منشا کے مطابق تیز رفتاری کے ساتھ ڈاؤن لوڈ ہوں گے اور اسے کسی قسم کی پریشانی کا سامنا نہیں کرنا پڑے گا۔ لیکن اگر صارف ایسے وقت میں آپ کی ویب سائیٹ وزٹ کر رہا ہے جب دوسرے بہت سے لوگ انٹرنیٹ پر موجود ہیں تو پھر سست ڈاؤن لوڈنگ کی درج ذیل وجوہات ہو سکتی ہیں:
- جس کمپیوٹر (Server) پر آپ کی ویب سائیٹ ہوسٹ ہے، اس پر ٹریفک کتنی ہے۔ ممکن ہے سرور پر دیگر بہت سے سافٹ ویئرز انسٹال کیے گئے ہوں جو نہ صرف سرور کے ہارڈ ویئر ریسورسز، بلکہ مختلف مقاصد کے لیے انٹرنیٹ کنکشن بھی استعمال کر رہے ہیں۔ ایسی صورت میں یہ دیکھنا ہوگا کہ صارف کا مطلوبہ ویب پیج بھیجنے کے لیے سرور کے پاس کتنا وقت ہے۔
- ویب سرور جس ISP کا انٹرنیٹ کنکشن استعمال کر رہا ہے اس کے نیٹ ورک پر کتنی ٹریفک ہے، وہ بھی ڈاؤن لوڈنگ کی رفتار پر اثر انداز ہوگی۔
- انٹرنیٹ کے جن راستوں سے گزر کر ویب سائیٹ کا ڈیٹا صارف کے براؤزر تک پہنچ رہا ہے انہیں دوسرے لوگ بھی استعمال کر رہے ہیں، ان راستوں پر زیادہ لوگوں کی موجودگی سے بھی ڈاؤن لوڈنگ کی رفتار میں کمی آئے گی۔ نیز ممکن ہے ان میں سے کسی راستے پر کوئی گیٹ وے، کوئی برج خراب ہوگیا ہو، جس کے نتیجے میں ان کی ٹریفک متبادل ہارڈ ویئر پر منتقل ہوگئی ہو۔ اس سے بھی ڈیٹا کی ترسیل کی رفتار سست ہو سکتی ہے۔
- وہ ISP جس سے صارف نے انٹرنیٹ کنکشن لیا ہوا ہے اس کے نیٹ ورک پر اس وقت کتنی ٹریفک موجود ہے، اس سے ڈاؤن لوڈنگ کی رفتار میں فرق پڑے گا۔
- صارف کس ڈیوائس پر یہ ویب پیج دیکھ رہا ہے، اس لیے کہ ڈیسک ٹاپ اور لیپ ٹاپ کمپیوٹرز کی کمپیوٹنگ پاور عموماً سمارٹ فونز وغیرہ سے بہتر ہوتی ہے۔ اور پھر صارف کی ڈیوائس کی صحت کیسی ہے، اس کا انٹرنیٹ کنکشن مزید کن سروسز اور ایپلی کیشنز کے لیے استعمال ہو رہا ہے۔
ان میں سے زیادہ تر وجوہات ایسی ہیں جن پر ویب ڈیویلپر کچھ زیادہ مغز کھپائی نہیں کر سکتا۔ اس لیے کہ انٹرنیٹ کے راستوں پر اس کا کوئی کنٹرول نہیں ہے، وہ یہ اندازہ تو کر سکتا ہے کہ یہ راستے کس وقت ٹریفک سے بھرتے ہیں لیکن اس کا کوئی حل وہ نہیں کر سکتا۔ پھر انٹرنیٹ پر گاہے بگاہے ہونے والی خرابیوں کا اسے کچھ علم نہیں ہے کہ کب کسی گیٹ وے کی خرابی کی وجہ سے ٹریفک متبادل راستہ اختیار کیے ہوئے ہے۔ اسی طرح وہ اپنی ویب سائیٹ کے صارفین کو اس بات پر مجبور نہیں کر سکتا کہ وہ ایک ISP کا کنکشن چھوڑ کر کسی دوسرے کا کنکشن حاصل کریں، یا یہ کہ ویب سائیٹ وہ اپنے سمارٹ فون پر نہیں بلکہ لیپ ٹاپ پر دیکھیں۔
البتہ پہلی وجہ ایسی ہے جس کے متعلق ویب ڈیویلپر کچھ کر سکتا ہے۔ یعنی وہ اپنی ویب ہوسٹنگ تبدیل کر کے ویب سائیٹ ایسے ویب سرور پر ہوسٹ کر سکتا ہے جس کے متعلق اس کا خیال ہے کہ اس کا ہارڈ ویئر بہت تیز رفتار ہے اور اس پر آنے والی تمام ٹریفک کو حسب ضرورت ریسورسز مل جاتے ہیں۔ نیز ویب ڈیویلپر یہ کر سکتا ہے کہ ویب سائیٹ اس ملک میں ہوسٹ کرے جہاں یہ زیادہ وزٹ کی جاتی ہے۔ مثلاً اگر یہ ویب سائیٹ پاکستان میں سب سے زیادہ وزٹ کی جاتی ہے تو اسے پاکستان میں ہوسٹ ہونا چاہیے۔ ترقی یافتہ ممالک میں ویب ڈیویلپرز کے ہاں یہ عمومی رجحان ہے کہ وہ ذاتی پراجیکٹس کی ویب سائیٹس اپنے گھر پر ہی ہوسٹ کر لیتے ہیں۔ لیکن پاکستان میں سروسز کی غیر معیاری سپورٹ کی وجہ سے ویب ڈیویلپرز نہ تو گھروں یا دفاتر میں ویب سائیٹس ہوسٹ کرتے ہیں اور نہ مقامی ویب ہوسٹنگ کمپنیوں پر انحصار کرنے کا رسک لیتے ہیں۔ چنانچہ عام طور پر ڈیویلپرز کوشش کرتے ہیں کہ ایسی ہوسٹنگ کمپنی منتخب کی جائے جو پاکستان کے قریب ترین کسی ملک سے ویب سائیٹ دستیاب کر سکے۔
ویب سائیٹ کے ویب پیجز کیسے تیار کیے جا رہے ہیں؟
اس کے متعلق ہم نسبتاً تفصیل سے بات کریں گے کیونکہ یہ وہ وجہ ہے جسے ایک ویب ڈیویلپر کافی حد تک دور کر سکتا ہے۔ اس سلسلے میں پہلے ہم یہ دیکھیں گے کہ جب صارف ویب پیج کے لیے ویب سرور کی طرف درخواست بھیجتا ہے، تو کیا سرور اس وقت یہ ویب پیج نئے سرے سے بناتا ہے، یا پھر سرور پہلے سے بنا بنایا ویب پیج کیش میں سے اٹھا کر صارف کی طرف بھیجتا ہے۔ پھر ہم یہ دیکھیں گے کہ براؤزر ایک مکمل ویب پیج حاصل کرنے کے لیے ویب سرور پر کتنی کالز بھیجتا ہے۔ اس کے بعد ہم یہ دیکھیں گے کہ کیا ویب پیجز میں کوئی ایسا غیر ضروری مواد موجود ہے جسے بآسانی ہٹایا جا سکتا ہو۔ ان تینوں مسائل کا ذکر کرتے ہوئے ان کے قابل عمل حل پیش کرنے کی بھی کوشش کی جائے گی۔
(1)ویب پیج نئے سرے سے بنا کر بھیجا جا رہا ہے، یا یہ پہلے سے تیار شدہ حالت میں موجود ہے؟
صارف براؤزر میں ویب سائیٹ کے کسی لنک پر کلک کرتا ہے جس کے نتیجے میں براؤزر اس ویب سائیٹ کو ہوسٹ کرنے والے ویب سرور کی طرف درخواست بھیجتا ہے کہ مجھے یہ ویب پیج چاہیے۔ سوال یہ ہے کہ ویب سرور کی طرف سے یہ ویب پیج بالکل نئے سرے سے بنا کر بھیجا جا رہا ہے یا پھر یہ ویب پیج کیش میں تیار شدہ موجود ہے، اور وہاں سے بھیجا جا رہا ہے۔ اس لیے کہ ڈیٹابیس کی مدد سے مکمل ویب پیج تیار کرنے کی صورت میں یہ صارف تک دیر سے پہنچے گا، جبکہ اس کے برعکس کیش سے بھیجا جانے والا ویب پیج جلد پہنچ جائے گا۔
یوں سمجھ لیں کہ میں کسی برگر کی دکان پر جاتا ہوں اور دکاندار سے کہتا ہوں کہ مجھے فلاں برگر چاہیے۔ وہ کہتا ہے کہ بھئی یہ برگر میں نے تازہ بنا کر رکھا ہوا ہے، لے جائیں۔ میں پیسے ادا کر کے برگر اٹھاتا ہوں اور دکان سے نکل جاتا ہوں۔ لیکن اگر دکاندار کہے کہ بھئی ذرا صبر کریں، برگر تیار نہیں ہے میں ابھی آپ کو بنا کر دیتا ہوں۔ اب میں وہاں بیٹھ کر انتظار کروں گا۔ میرے سامنے وہ شامی کباب تلے گا، پھر انڈہ بنائے گا، پھر چھری کے ساتھ درمیان سے سینڈ وچ کی بریڈ کاٹے گا، سب چیزوں کو بریڈ پر رکھ کر ان پر سالاد اور چٹنی ڈالے گا، پھر بریڈ کے دونوں حصے برابر جوڑ کر برگر لفافے میں ڈالے گا اور میرے حوالے کر دے گا۔ میرے پاس اگر اور کوئی کام نہیں ہے تو انتظار کرنے میں کوئی حرج نہیں ہے، لیکن اگر میرا وقت قیمتی ہے تو چند منٹ پہلے بنا ہوا برگر لینا میرے لیے زیادہ فائدہ مند ہ ہے، اس لیے کہ جتنی دیر میں دکاندار نے برگر بنایا ہے میں اتنے وقت میں موٹر بائیک پر اپنے شہر کے دوسرے حصے میں پہنچ سکتا ہوں۔
ویب سرور پر بھی یہی صورت حال ہے۔ کیش میں اگر تیار شدہ ویب پیج موجود ہے تو ویب سرور اسے اٹھا کر براؤزر کی طرف بھیج دے گا۔ لیکن یہ ویب پیج اگر کیش میں موجود نہیں تو پھر ڈیٹابیس کی مدد سے پہلے یہ ویب پیج تیار کیا جائے گا اور پھر براؤزر کی طرف بھیجا جائے گا۔ یعنی پہلے ویب سرور فائل سسٹم سے ویب پیج کی فائل کال کرے گا جس کے نتیجے میں اسکرپٹنگ لینگوئج مثلاً PHP کا کوڈ پڑھا جائے گا، اس کوڈ میں موجود بہت سے فنکشنز کال کیے جائیں گے، بہت سی ڈیٹا پراسیسنگ ہوگی جس کے تحت ڈیٹابیس سے مواد حاصل کر کے اسے HTML ٹیگز کے ساتھ مکس کر کے ویب پیج کی شکل دی جائے گی، اس کے بعد یہ ویب پیج براؤزر کی طرف بھیجا جائے گا۔ آپ سمجھ سکتے ہیں کہ اس پر اضافی وقت لگ جائے گا۔
عموماً ویب پیجز کی کیش تین طریقے سے تیار ہوتی ہے:
- ایک طریقہ یہ ہے کہ ڈیٹابیس کی مدد سے مکمل ویب پیجز تیار کر کے ڈیٹابیس ہی کے کیش کے ٹیبل میں انہیں محفوظ کر دیا جاتا ہے۔
- دوسرا طریقہ یہ ہے کہ ڈیٹابیس کی مدد سے ویب پیجز بنا کر فائلز کی شکل میں ڈسک پر رکھ دیے جاتے ہیں۔
- تیسرا طریقہ یہ ہے کہ ویب پیجز کی کیش تیار کر کے میموری میں محفوظ کر دی جاتی ہے جو کہ سب سے تیز رفتار طریقہ ہے لیکن یہ بڑے پیمانے کی ایپلی کیشنز کے لیے استعمال کیا جاتا ہے۔
چنانچہ جب ویب سرور کو کسی ویب پیج کے لیے درخواست موصول ہوتی ہے تو وہ ڈیٹابیس کے ٹیبل سے یا پھر ڈسک سے، اور یا پھر میموری سے ویب پیج کی کیش حاصل کر کے براؤزر کی طرف بھیج دیتا ہے۔ ڈیٹابیس سے جنریٹ ہونے والے ویب پیج اور کیش سے حاصل کیے جانے والے ویب پیج کی تیاری کے وقت میں کتنا فرق ہوتا ہے، آئیں اس کے لیے درج ذیل اسکرین شاٹس دیکھتے ہیں۔
پہلا اسکرین شاٹ: Chrome کے ڈیویلپر ٹولز میں دیکھا جا سکتا ہے کہ ورڈ پریس کا ویب پیج حاصل کرنے کے لیے براؤزرکی جانب سے ویب سرور کی طرف 10 کالیں بھیجی گئی ہیں۔ جبکہ یہ ویب پیج اور اس میں استعمال کیے گئے تمام ایلی منٹس ویب سرور کی طرف سے 5.43 سیکنڈز میں بھیجے گئے ہیں۔
دوسرا اسکرین شاٹ: ورڈ پریس کے اس ویب پیج کی Profiling کرنے پر معلوم ہوا کہ ڈیٹابیس سے ڈیٹا حاصل کر کے ویب پیج تیار کرنے کے لیے PHP کے 848 فنکشنز کئی ہزار مرتبہ کال کیے گئے ہیں۔ جبکہ انڈیکس فائل اور اس کے ذریعے چلنے والے اسکرپٹس نے تقریباً 4.3 سیکنڈز لیے ہیں۔
پروفائلنگ کے عمل میں یہ دیکھا جاتا ہے کہ پروگرام کا کونسا حصہ اپنا کام مکمل کرنے کے لیے کتنا وقت لے رہا ہے۔ اگر ڈیٹابیس کی کوئیری یا پروگرام کا کوئی حصہ زیادہ وقت لے رہا ہو تو اس کا کوڈ تبدیل کر کے اس کی پرفارمنس بہتر بنانے کی کوشش کی جاتی ہے۔
تیسرا اسکرین شاٹ: جب ورڈ پریس کے لیے W3 Total Cache پلگ ان استعمال کیا گیا، تو اس ویب پیج کو ریفریش کرنے پر ویب سرور کی طرف 10 کالیں بھیجی گئی ہیں، لیکن اس دفعہ ویب سرور کی طرف سے یہ ویب پیج 1.08 سیکنڈ میں بھیج دیا گیا ہے۔ وقت کا یہ فرق جاننے کے لیے چوتھا اسکرین شاٹ دیکھیں۔
چوتھا اسکرین شاٹ: کیش کا پلگ ان استعمال کرنے کے بعد جب ورڈ پریس کے ویب پیج کی پروفائلنگ کی گئی تو PHP کے 152 فنکشنز کال کیے گئے ہیں۔ جبکہ انڈیکس فائل اور اس کے ذریعے چلنے والے اسکرپٹس نے 205 ملی سیکنڈز کا وقت لیا ہے جو کہ ایک سیکنڈ کا پانچواں حصہ ہے۔ یعنی بالکل نئے سرے سے بننے والے ویب پیج نے چار سیکنڈز سے زیادہ کا وقت لیا ہے، جبکہ کیش سے حاصل ہونے والے ویب پیج نے ایک سیکنڈ کا پانچواں حصہ وقت لیا ہے۔
(2) براؤزر مکمل ویب پیج کے لیے ویب سرور کی طرف کتنی کالز بھیج رہا ہے؟
Web جو ہے یہ Stateless ہے۔ مطلب یہ ہے کہ براؤزر کی ویب سرور کی طرف بھیجی گئی ہر درخواست ایک دوسرے سے الگ ہوتی ہے، ان کا آپس میں کوئی تعلق نہیں ہوتا۔ ان درخواستوں کو آپس میں متعلق اور مربوط بنانے کے لیے پروگرامنگ لینگویجز Sessions اور Cookies کی تکنیک استعمال کرتی ہیں۔ مثلاً ویب سرور پر چلنے والی ایپلی کیشن Login کرنے والے صارف کی ڈیوائس پر Cookie محفوظ کرتی ہے۔ صارف اس کے بعد سرور کی طرف جو کالز بھیجتا ہے، ہر کال کے ساتھ اس Cookie کی ویلیو سرور کی طرف بھیجی جاتی ہے جس سے ایپلی کیشن اس صارف کو پہچانتی ہے۔ سیشن ہائی جیکنگ بھی اسی تکنیک کا غلط فائدہ اٹھا کر کی جاتی ہے، جس میں صارف کے کمپیوٹر سے وہ Cookie چرا لی جاتی ہے جس کی مدد سے اس کا کسی ایپلی کیشن کے ساتھ سیشن قائم ہے۔ اور پھر ہیکر اس Cookie کی مدد سے ویب ایپلی کیشن کے ساتھ اپنا سیشن قائم کر لیتا ہے۔
یعنی ایسا نہیں ہوتا کہ براؤزر درخواست بھیجتے ہوئے ویب سرور سے کہے کہ بھئی یہ ویب پیج اور اس کے اندر جو چیزیں (تصاویر، اسٹائل شیٹ اور جاوااسکرپٹ وغیرہ کی فائلز) استعمال کی گئی ہیں ان سب کا پیکیج بنا کر ایک ہی بار میں بھیج دو۔ بلکہ براؤزر ویب پیج کی درخواست الگ بھیجتا ہے، اس میں استعمال کی گئی اسٹائل شیٹ کی درخواست الگ، جاوا اسکرپٹ فائل کی درخواست الگ، اور ہر تصویر کی درخواست الگ بھیجتا ہے۔ اس سے آپ سمجھ سکتے ہیں کہ ایک ویب پیج میں جتنے زیادہ ایلی منٹس استعمال کیے جائیں گے، یہ ویب پیج مکمل طور پر ڈاؤن لوڈ ہونے میں اتنا ہی زیادہ وقت لے گا۔
جب کوئی صارف ویب سائیٹ کا پہلا صفحہ ڈاؤن لوڈ کرتا ہے تو اس ویب پیج میں استعمال کی گئی فائلز مثلاً اسٹائل شیٹس، جاوا اسکرپٹس، اور تصاویر وغیرہ براؤزر کی کیش میں محفوظ ہو جاتی ہیں۔ اس کے بعد جب صارف ویب سائیٹ کے مزید صفحات وزٹ کرتا ہے تو ان کے لیے براؤزر اپنی کیش سے وہ فائلز استعمال کرتا ہے جو پہلے سے ڈأؤن لوڈ ہو چکی ہوتی ہیں۔ یعنی وہ فائلز جو ویب سائیٹ کے تمام یا بہت سے صفحات میں استعمال کی گئی ہیں، انہیں براؤزر ہر صفحے کے ساتھ ویب سرور سے ڈاؤن لوڈ نہیں کرتابلکہ اپنی کیش سے وہ فائلز استعمال کر لیتا ہے۔ ہاں اگر صارف ویب پیج ریفریش کرے گا تو براؤزر اپنی کیش کو نظر انداز کر کے ویب سرور کی طرف ویب پیج کے تمام ایلی منٹس کے لیے نئے سرے سے کالز بھیج دے گا۔ لیکن یہ ضروری نہیں ہے کہ ویب سرور وہ تمام ایلی منٹس دوبارہ سے بھیج دے۔ اگر ویب سرور پر Cache headers کی مناسب سیٹنگز کی گئی ہیں تو پھر ویب سرور جواب میں براؤزر سے یہ کہہ سکتا ہے کہ جس ایلی منٹ کی درخواست آپ نے بھیجی ہے اسے آپ پہلے بھی منگوا چکے ہیں، اور تب سے اس ایلی منٹ میں کوئی تبدیلی نہیں کی گئی، چنانچہ اپنی کیش سے ہی یہ ایلی منٹ استعمال کریں۔ یہ موازنہ کرنے کے لیے کہ براؤزر کی کیش میں بالکل وہی ایلی منٹ موجود ہے جو ویب سرور پر موجود ہے، Etags استعمال کیے جاتے ہیں۔
ایک ویب ڈیویلپر کی حیثیت سے آپ کو ضرور یہ کوشش کرنی چاہیے کہ مکمل ویب پیج ڈاؤن لوڈ کرنے کے لیے ویب سرور کی طرف براؤزر کم سے کم درخواستیں بھیجے۔ اگر آپ کسی ویب ایپلی کیشن پر کام کر رہے ہیں تو کوشش کریں کہ
- تمام اسٹائل رولز مختلف فائلوں کی بجائے ایک ہی اسٹائل شیٹ فائل میں موجود ہوں۔البتہ اگر کوئی ویب ایپلی کیشن ایک آدھ پیج پر ہی مشتمل ہے تو اسٹائل رولز ویب پیج کے ہیڈ سیکشن میں رکھ کر ایک HTTPکال بچائی جا سکتی ہے۔ لیکن بہتر الگ فائل ہی رہتی ہے، کیونکہ وہ ایک ہی دفعہ ویب سرور سے ڈأٔون لوڈ ہو کر بعد کی کالز کے لیے استعمال ہوتی ہے۔ جبکہ اسٹائل رولز ویب پج کے ہیڈ سیکشن میں رکھنے سے صفحہ کا سائز زیادہ ہو جائے گا، جو کہ ضرورت سے زیادہ بینڈوتھ استعمال کرے گا۔
- ایپلی کیشن میں استعمال کیا جانے والا تمام جاوا اسکرپٹ کوڈ بھی ایک ہی فائل میں موجود ہونا چاہیے۔
- اگر ایپلی کیشن میں jQuery یا اس طرح کی کوئی لائبریری استعمال کی جا رہی ہے تو اسے اپنی ویب سائیٹ پر رکھنے کی بجائے اس کے لیے کسی معروف سروس کا لنک استعمال کریں۔ مثلاً گوگل اور اس جیسی دوسری سروسز یہ کرتی ہیں کہ معروف لائبریریز اپنے سرور پر ہوسٹ کر کے ڈیویلپرز کو یہ سہولت دیتی ہیں کہ وہ اپنے ویب پیجز میں ان کے سرورز سے یہ لائبریریز شامل کر لیں۔ ایسا کرنے کا ایک فائدہ یہ ہوتا ہے کہ آپ کی ویب سائیٹ کی بینڈوتھ کم استعمال ہوتی ہے۔ دوسرا فائدہ یہ ہوتا کہ اگر صارف نے پہلے سے کوئی ایسی ویب سائیٹ وزٹ کی ہوئی ہے جس نے گوگل سے jQuery اٹھائی ہے، تو آپ کی ویب سائیٹ کے لیے یہ لائبریری نئے سرے سے صارف کی ڈیوائس پر ڈاؤن لوڈ نہیں ہوتی، اور یوں ویب پیج ڈاؤن لوڈ ہونے کا وقت کم ہو جاتا ہے۔
- کچھ گرافکس ایسی ہوتی ہیں جو ویب سائیٹ کے بہت سے صفحات پر استعمال کرنے کی ضرورت پیش آتی ہے، مثلاً بلٹس، ایروز، سیمبلز، اور بٹنز وغیرہ۔ ایسی تصاویر کے لیے Image sprites کی تکنیک استعمال کی جا سکتی ہے، جس کے تحت بہت سی تصاویر کو ملا کر ایک ہی تصویر بنا لی جاتی ہے، اور پھر جہاں ضرورت پیش آتی ہے وہاں CSS کی مدد سے اس تصویر کا وہی حصہ دکھایا جاتا ہے جس میں مطلوبہ سیمبل موجود ہوتا ہے۔ یوں ان تمام گرافکس کو ڈاؤن لوڈ کرنے کے لیے ویب سرور کی طرف الگ الگ کالیں بھیجنے کی بجائے صرف ایک کال بھیجی جاتی ہے۔
- اگر آپ کا بلاگ یا ویب سائیٹ بہت زیادہ وزٹ کی جاتی ہے تو آپ یوں کر سکتے ہیں کہ ویب سائیٹ ایک ڈومین پر ہوسٹ کریں، جبکہ اس کے اندر استعمال کی جانے والی فائلز مثلاً اسٹائل شیٹس، جاوا اسکرپٹس اور تصاویر وغیرہ کسی دوسرے ڈومین پر ہوسٹ کریں۔ جیسا کہ Yahoo اپنی ویب سائیٹ پر استعمال ہونے والی تصاویر yimg.com کے سب ڈومینز پر ہوسٹ کرتا ہے۔ اس کا ایک فائدہ یہ ہوگا کہ جب مرکزی ڈومین ہوسٹ کرنے والا ویب سرور صرف ٹیکسٹ پر مشتمل ویب پیجز بھیجے گا تو وہ بہت تیز رفتاری کے ساتھ ڈاؤن لوڈ ہوں گے۔ دوسرا فائدہ یہ ہوگا کہ براؤزرز کی Parallel downloads کی لمٹ بڑھ جائے گی۔
اسی طرح اگر آپ کسی ویب سائیٹ پر کام کر رہے ہیں تو بعض CMS تمام اسٹائل شیٹ اور جاوا اسکرپٹ فائلز کو یکجا (Combine) اور مختصر (Minify) کرنے کی سہولت دیتے ہیں۔ مثلاً Drupal میں یہ سہولت موجود ہے کہ وہ ویب سائیٹ کی ٹیمپلیٹ اور ماجولز کی تمام اسٹائل شیٹ فائلز کو یکجا کر کے کم سے کم فائلز بنا کر کیش میں محفوظ کر لیتا ہے۔ ڈروپل میں فائلز کو یکجا کرنے کی سہولت کو Aggregate کہا جاتا ہے جبکہ فائلز کو مختصر کرنے کے لیے Compress کا نام استعمال کیا جاتا ہے۔ درج ذیل اسکرین شاٹ میں دیکھا جا سکتا ہے کہ جب ڈروپل کی یہ سہولت استعمال نہیں کی گئی تو ایک مکمل ویب پیج حاصل کرنے کے لیے براؤزر سے ویب سرور کی طرف 19 کالیں بھیجی گئی ہیں۔
اسی طرح درج ذیل اسکرین شاٹ میں دیکھا جا سکتا ہے کہ جب ڈروپل کی فائلز کو یکجا کرنے کی سہولت استعمال کی گئی ہے تو مکمل ویب پیج کے حصول کے لیے ویب سرور کی طرف 7 کالیں بھیجی گئی ہیں۔ چنانچہ آپ اپنی ویب سائیٹ جس CMS کی مدد سے بھی بنا رہے ہیں، اس کے لیے ایسی سہولت ضرور استعمال کریں۔
(3)کیا ویب پیجز میں غیر ضروری مواد موجود ہے؟
ایک ویب ڈیویلپر کے لیے اپنی ویب سائیٹ کی صحت کا خیال رکھنا بہت ضروری ہے۔ صحت کا مطلب یہ نہیں ہے کہ ویب پیجز موٹے تازے ہوں، بلکہ اس کا مطلب یہ ہے کہ جو ویب پیج جس مقصد کے لیے بنایا گیا ہے اس سے وہ مقصد پورا ہو رہا ہو۔ اس سلسلے میں درجٍ ذیل باتوں کا خیال رکھیں:
تصاویر:
- کسی ویب پیج پر بہت زیادہ گرافکس استعمال نہ کریں۔ زیادہ گرافکس استعمال کرنے کا ایک نقصان یہ ہوتا ہے کہ براؤزر کی طرف سے ویب سرور کی طرف اتنی ہی زیادہ کالز بھیجی جاتی ہیں۔ پھر اس کا ایک اثر یہ بھی ہوتا ہے کہ ویب پیج کا اصل مواد مطلوبہ توجہ نہیں حاصل کر پاتا۔ صارفین صفحہ کے گرد پھیلے ہوئے رنگا رنگ بینرز اور اشتہارات میں محو ہو جاتے ہیں اور صفحہ کا اصل مواد پڑھے بغیر ہی کسی تصویر پر کلک کر کے کہیں اور پہنچ جاتے ہیں۔
- ایسا کرنا بھی بہتر ہوگا کہ بڑے بینرز جو ویب سائیٹ کی مکمل چوڑائی میں پھیلے ہوتے ہیں، انہیں صرف ویب سائیٹ کے پہلے صفحہ پر استعمال کیا جائے، جبکہ ذیلی صفحات پر چھوٹے بینر استعمال کیے جائیں۔ ہر صفحہ کے لیے بڑا بینر استعمال نہ کرنے کی ایک وجہ یہ ہے کہ وہ ڈاؤن لوڈ ہونے میں زیادہ وقت لے گا۔ دوسری وجہ یہ ہے کہ بہت سے صارفین کے پاس چھوٹے لیپ ٹاپس، ٹیبز یا سمارٹ فونز ہوتے ہیں۔ جب ایک ویب پیج لوڈ ہوتا ہے تو اس میں موجود بڑا بینر اسکرین کی ساری جگہ لے لیتا ہے، جس کا نتیجہ یہ ہوتا ہے کہ صارف کو ویب سائیٹ کے ہر صفحہ کا اصل مضمون دیکھنے کے لیے نیچے اسکرول کرنا پڑتا ہے جو کہ کوفت والا کام ہے۔
- بغیر ضرورت ویب پیج پر بڑے سائز کی ایسی تصاویر استعمال نہ کریں جنہیں CSS کی مدد سے چھوٹا کر کے دکھایا گیا ہو۔ بعض اوقات یوں ہوتا ہے کہ ہم فون یا کیمرے کی مدد سے بڑے سائز کی تصویر لیتے ہیں اور پھر یہ تصویر اسی حالت میں ویب پیج پر ڈال دیتے ہیں۔ اگر تھوڑا سا وقت لگا کر گرافک ایڈیٹنگ سافٹ ویئر کی مدد سے اس تصویر کا سائز حسب ضرورت چھوٹا کر لیا جائے تو اس سے صارفین کا بہت سا وقت بچایا جا سکتا ہے جنہیں مکمل تصویر ڈاؤن لوڈ ہونے کے لیے کافی انتظار کرنا پڑتا ہے۔ یا پھر CMS میں موجود ٹولز استعمال کر کے تصویر کا سائز تبدیل کیا جا سکتا ہے۔ نیز ویب پیج پر استعمال کی جانے والی تصاویر کا سائز تبدیل کرتے وقت انہیں حسب ضرورت کمپریس ضرور کریں، اتنا کہ دیکھنے میں تصویر کی کوالٹی برقرار رہے۔ آپ جانتے ہیں کہ کمپریشن کی مدد سے تصویر کا فائل سائز غیر معمولی طور پر کم کیا جا سکتا ہے، جس کا نتیجہ یہ ہوگا کہ تصویر مختصر عرصے میں ڈاؤن لوڈ ہو جائے گی-
- آپ نے ایسے ویب پیجز ضرور وزٹ کیے ہوں گے جن کے مکمل ڈاؤن لوڈ ہونے تک ان کا مواد ایک جگہ نہیں ٹھہرتا۔ مثلاً جب آپ کسی لنک پر کلک کرنے کی کوشش کرتے ہیں تو وہ نیچے چلا جاتا ہے۔ مطلوبہ لنک ڈھونڈنے کے لیے آپ کو پھر نیچے اسکرول کرنا پڑتا ہے۔ ایسا اس لیے ہوتا ہے کہ ویب پیج میں موجود تصاویر کا سائز متعین نہیں کیا گیا ہوتا۔ ایسا اس لیے ہوتا ہے کہ براؤزر ویب پیج کا ٹیکسٹ تو ڈاؤن لوڈ کر کے دکھا دیتا ہے، لیکن جب تک ویب پیج میں استعمال کی گئی تصاویر موصول نہیں ہوتیں براؤزر کو پتہ نہیں چلتا کہ ان کا سائز کیا ہوگا۔ اس لیے جیسے ہی کوئی تصویر مکمل ڈاؤن لوڈ ہوتی ہے براؤزر اس کی جگہ بنانے کے لیے ویب پیج کے باقی مواد کو نیچے دھکیل دیتا ہے۔ چنانچہ اگر img ٹیگز میں تصاویر کا سائز متعین کر دیا جائے تو پھر ویب پیج کے ڈاؤن لوڈ ہوتے ہی براؤزر ان کے لیے جگہ مخصوص کر دیتا ہے، پھر جیسے جیسے تصاویر ڈاؤن لوڈ ہوتی چلی جاتی ہیں، اپنی اپنی جگہ پر ویب پیج میں شامل ہوتی چلی جاتی ہیں۔
ضرورت سے زیادہ کوڈ:
- ویب سائیٹ کے لیے جو ٹیمپلیٹ استعمال کی جائے اس کے بارے میں تسلی کریں کہ اس میں غیر ضروری کوڈ موجود نہیں ہے۔ بعض دفعہ ٹیمپلیٹ کے ایسے سیکشنز جو فی الحال ہم استعمال نہیں کرنا چاہتے انہیں ہم کامنٹس میں تبدیل کر دیتے ہیں۔ کوڈ کے یہ حصے صارفین کو تو نظر نہیں آتے لیکن ویب پیج کا حصہ ہونے کی وجہ سے ہر نئی درخواست کے ساتھ ڈاؤن لوڈ ہوتے ہیں۔ اگر آپ کے خیال میں ویب پیج کے یہ سیکشنز مستقبل میں کبھی استعمال کرنے کی ضرورت پیش آسکتی ہے تو اس صورت میں یہ کریں کہ ٹیمپلیٹ کی ایک نقل بنا کر محفوظ رکھیں، جبکہ زیر استعمال ٹیمپلیٹ میں سے یہ حصے ختم کر دیں۔ فرض کریں اگر ٹیمپلیٹ میں سے پانچ سو حروف پر مشتمل کوڈ ختم کیا جائے جو کہ صرف چند لائنیں بنتی ہیں، تو پچاس ہزار پیجز ڈاؤن لوڈ ہونے پر تقریباً 25ایم بی ڈیٹا ٹرانسفر بچایا جا سکتا ہے۔ آپ سمجھ سکتے ہیں کہ پچیس ایم بی میں کتنے مزید صارفین کو ویب سائیٹ کی بینڈ وتھ میں سے حصہ مل جائے گا۔ اور پچاس ہزار کوئی بڑا نمبر نہیں ہے، بہت سے لوگ ایسے بلاگز چلاتے ہیں جنہیں اس تعداد میں ماہانہ ٹریفک مل جاتی ہے۔
- اگر آپ ایسی ایپلی کیشن بنا رہے ہیں جسے آپ کے خیال میں ایک دن میں ہزاروں افراد وزٹ کریں گے، تو ایک کام یہ کیا جا سکتا ہے کہ ویب پیج میں سے خالی جگہ (White space) ختم کر دی جائے۔ اس سے ایک ویب پیج کے سائز میں تو معمولی فرق پڑے گا لیکن جب اسے آپ لاکھوں سے ضرب دیں گے تو خالی جگہ کا یہ ڈیٹا کئی میگا بائٹ بن جائے گا۔ یوں بہت سے مزید افراد کو ویب سائیٹ کی بینڈوتھ میں سے حصہ مل جائے گا۔ اس کام کے لیے درج ذیل PHP کوڈ استعمال کیا جا سکتا ہے جس میں ریگولر ایکسپریشنز کی مدد سے HTML ٹیگز کے درمیان اسپیس، ٹیب اور لائن بریک کے نشانات ختم کیے گئے ہیں۔
<?php
$data = preg_replace('/\s+/S', " ", $data);
?>
آخری الفاظ
جن تکنیکس کا میں نے ذکر کیا ہے، یہ زیادہ تر ویب سائیٹس اور ویب ایپلی کیشنز کے لیے کارآمد ہیں۔ لیکن اگر آپ ایسی ایپلی کیشن بنا رہے ہیں جس کے فیس بک یا ٹویٹر کی طرح بے شمار صارفین ہوں گے، تو پھر ایسی ایپلی کیشنز کو تیار کرنے اور Deploy کرنے کی تکنیکس عام معمول سے ہٹ کر ہوتی ہیں۔ پھر Scalability کی تکنیکس استعمال کی جاتی ہیں۔ مثلاً براؤزر ویب سرور سے مکمل ویب پیج منگوانے کی بجائے Ajax کی تکنیک استعمال کرتے ہوئے ویب پیج کے صرف وہی حصے منگواتا ہے جن کی ضرورت ہوتی ہے۔ ایپلی کیشن میں استعمال کی جانے والی ڈیٹابیس کی پارٹیشنز بنائی جاتی ہیں۔ ایسی ایپلی کیشنز کے لیے الگ کیش سرورز رکھے جاتے ہیں جن پر ایپلی کیشن سرورز ایک مخصوص وقفے کے ساتھ پرانی کیش ختم کر کے نئی کیش محفوظ کرتے رہتے ہیں۔ اور ڈیٹا کیش کرنے کے لیے ڈسک کی بجائے کمپیوٹر کی میموری استعمال کی جاتی ہے۔ اسی طرح بڑی ایپلی کیشنز کا نیٹ ورک انفرااسٹرکچر بھی ان کی ضرورت کے مطابق مختلف ہوتا ہے۔ عموماً بہت سے ویب سرورز ایک Load balancerکے پیچھے رکھے جاتے ہیں۔ لوڈ بیلنسر کا کام یہ ہوتا ہے کہ وہ ایپلی کیشن کے کسی بھی صارف کی درخواست وصول کر کے اپنے نیٹ ورک میں موجود ایسے ویب سرور کی طرف بھیجے جو اس صارف کا ڈیٹا تیز رفتاری کے ساتھ مہیا کر سکتا ہو۔ اور پھر صارف دنیا کے جس علاقے سے تعلق رکھتا ہے، یہ درخواست اس کے قریب ترین کسی ڈیٹا سینٹر کی طرف بھی بھیجی جا سکتی ہے۔ یوں ایپلی کیشن کی ٹریفک بہت سے ویب سرورز پر تقسیم ہو جاتی ہے اور صارفین کو مطلوبہ ویب پیجز حاصل کرنے کے لیے قطار میں کھڑے ہو کر انتظار نہیں کرنا پڑتا۔ بہرحال یہ موضوع تفصیل طلب بھی ہے اور میرے لیے تحقیق طلب بھی، اس پر مستقبل میں کبھی بات کی جائے گی۔
Modified: Mon, 04/30/2018 - 19:13