मेरे HTML लोड होने से पहले 'प्रतीक्षा' समय क्या है?

12

मेरे पास एक वेबसाइट है जो बहुत धीरे-धीरे लोड होती है। जब मैं इस पर एक गति परीक्षण चलाता हूं तो मुझे लगता है कि HTML लोड होने से पहले एक 6 सेकंड का अंतर है। उस बिंदु के बाद छवियाँ और JS स्क्रिप्ट बहुत तेज़ी से लोड होती हैं।

आप पीली 'प्रतीक्षा समय' सलाखों के नीचे की तस्वीर में देख सकते हैं:

HTML फ़ाइल को लोड करने में 5 सेकंड से अधिक का समय लगा, जबकि अन्य परिसंपत्तियों का अधिकांश भाग 1 सेकंड से कम है

इससे कोई फर्क नहीं पड़ता कि पृष्ठ पर HTML सामग्री क्या है।

यह साइट CMS (ModX Revo) का उपयोग कर रही है इसलिए HTML वास्तव में SQL डेटाबेस में संग्रहीत है और PHP द्वारा आगे लाया गया है, लेकिन मैंने इस मुद्दे को पहले कभी अनुभव नहीं किया है।

किसी को पता होगा कि यह क्या कारण है और मैं इसे कैसे गति दे सकता हूं?

performance

— MeltingDog
स्रोत

क्या यह कोई नई बात है? यही है, क्या इन पृष्ठों ने पहले सामान्य रूप से प्रदर्शन किया है और अब खराब प्रदर्शन करता है? या यह एक नया स्थापित / साइट है? क्या आप हमें और बता सकते हैं?

— क्लोजनेटोक

1

जब तक कुछ मध्यस्थ नेटवर्क इस पर पकड़ बना रहा है, तो यह उस समय प्रतीत होगा जब आपका सर्वर प्रतिक्रिया उत्पन्न करने के लिए ले जा रहा है? आप कहते हैं "कोई फर्क नहीं पड़ता कि HTML सामग्री क्या है" - आपके सीएमएस के माध्यम से HTML सामग्री, या सचमुच एक स्थिर HTML पृष्ठ? यदि आप पहले से ही नहीं है, तो मैं निश्चित रूप से एक सरल "हैलो वर्ल्ड" स्टेटिक HTML पेज आज़माऊंगा। यह भी ध्यान दें कि पीएसटीएच के सर्वर दुनिया के दूसरी तरफ ऑस्ट्रेलिया में हैं (जो मुझे लगता है कि आप कहां होस्ट किए गए हैं)?

— मृद्वीथ

1

IMO समस्या मुख्य रूप से उस एक पृष्ठ के साथ है - आपका सर्वर / सीएमएस प्रतिक्रिया उत्पन्न करने में एक लंबा समय ले रहा है। अक्षम SQL क्वेरी ?? आपकी साइट के अन्य पृष्ठ अपेक्षाकृत जल्दी दिखाई देते हैं। (?)

— MrWhite

13

प्रतीक्षा के लिए तकनीकी शब्द को पहले बाइट के रूप में समय-समय पर संदर्भित किया जाता है और एक वेब सर्वर या अन्य नेटवर्क संसाधनों की जवाबदेही निर्धारित करता है।

कुछ सामान्य कारण जिन्हें आप पहले बाइट के लिए देख सकते हैं:

ओवरलोड नेटवर्क (आमतौर पर साझा होस्टिंग)
गलतफहमी सर्वर
आपसे और सर्वर से दूरी (भू स्थान एक छोटी भूमिका निभाता है)
सर्वर त्रुटियां (हॉप्स)

आम तौर पर यह समस्या अक्सर साझा होस्टिंग में देखी जाती है क्योंकि वेबसाइटों की सरासर राशि और उन्हें देखने वाले लोग जो नेटवर्क बाइट समय को बढ़ाते हैं। एक और संभावित कारण कहीं न कहीं नेटवर्क पर एक त्रुटि है, एक हॉप की तरह या क्योंकि आपका सर्वर आपके लक्षित दर्शकों के स्थान के भीतर नहीं है, उदाहरण के लिए 'GOOD' UK सर्वर के पास उपयोगकर्ताओं को लक्षित करने वाले अमेरिकी सर्वर की तुलना में कम बाइट समय होगा। यूके, इस दूरी के कारण कि डेटा को भेजने और प्राप्त करने की आवश्यकता होती है (सामान्य रूप से लगभग 100-200ms की वृद्धि)।

शायद एक नया मेजबान पाने का समय

अतीत में मुझे सर्वर से सर्वर पर स्थानांतरित करना पड़ता है क्योंकि पहले बाइट के लिए समय की कमी के कारण, आप एक नया वेब होस्ट चुनने या अपने वर्तमान पैकेज को अपग्रेड करने की स्थिति में हो सकते हैं।

विश्वसनीय परीक्षण

आपके होम ब्रॉडबैंड से आपकी वेबसाइट की गति का परीक्षण करना बहुत ही पक्षपाती है क्योंकि यह आपके ब्रॉडबैंड की वेबसाइट पर प्रतिक्रिया न देने की समस्या हो सकती है। आपको कई सर्वरों से कई कनेक्शनों का उपयोग करके अपनी वेबसाइट का परीक्षण करना चाहिए ... मैं वेब पेज परीक्षण और विभिन्न स्थानों से एक बार में कई परीक्षण चलाने और लक्षित भू दर्शकों में कई की सिफारिश करता हूं । यह आपको व्हाट्सएप का एक बेहतर अवलोकन देगा, अगर इसकी पहली बाइट है तो मैं आपको कुछ भी करने से पहले अपने वेब होस्ट से संपर्क करने की सलाह देता हूं।

पिंगिंग और ट्रेस सर्वर को रूट करता है

यदि आप सर्वर पर एक पिंग को चलाने का प्रयास करते हैं तो परिणाम प्रदर्शित हो सकते हैं या नहीं हो सकते हैं, पिंग ICDP के बजाय ICMP का उपयोग करता है या इसका अर्थ है कि पोर्ट 80 पर सर्वर को क्वेरी करना पसंद नहीं है, जिस पर आपका httpd चल रहा होगा। आप उस मार्ग पर किसी भी सर्वर की पहचान करने के लिए ट्रेस मार्ग का उपयोग कर सकते हैं जो पहले बाइट को बढ़ाने का कारण बन सकता है, फिर से ... यह पोर्ट 80 पर httpd सर्वर को क्वेरी नहीं करता है और यदि विंडोज का उपयोग करते हुए ट्रेसरआउट आईसीएमपी और मैक / लिनक्स का उपयोग करेगा मशीनें यूडीपी का उपयोग करेंगी। यह परीक्षण के लायक है क्योंकि इसकी इतनी जल्दी और आसान बात है, लेकिन यदि परिणाम ठीक आते हैं, तो इसका मतलब यह नहीं है कि कहीं कोई समस्या नहीं है।

— साइमन हेटर
स्रोत

हाय @SunWKim मैंने जो भी पूछा है उससे आपने अपना जवाब अपडेट किया है। मेरे उत्तर के निचले भाग को देखो।

— साइमन हैटर

मैं पहली बार बाइट के लिए आपके सामान्य कारणों पर सहमत हूं। इस उदाहरण में, हालांकि; मेरा मानना है कि इसका जावास्क्रिप्ट कोड के साथ अधिक होना है।

— सूर्य

पहला बाइट कई प्रकार की चीजों के कारण हो सकता है लेकिन जावास्क्रिप्ट उनमें से एक नहीं है क्योंकि शीर्ष लेख प्रतिक्रिया जावास्क्रिप्ट, सीएसएस, चित्र और इतने पर इनलाइन तत्वों से पहले है। वास्तविक तत्वों और फ़ाइलों .. समझ बैठते हैं पहले नहीं बाइट है

— साइमन हैटर

मैं दोनों को भ्रमित नहीं कर रहा हूं। हो सकता है कि अगर आप mbff.com.au पर गए और अपने लिए देखा, तो आप आश्वस्त हो सकते हैं कि यह पहली बाइट का समय नहीं है। पहले हेडर प्रतिक्रिया के बाद देरी हो रही है।

— सूर्य

1

The delay is occurring after the first header responseतब वह पहली बाइट नहीं है। पहला बाइट पहली प्रतिक्रिया है।

— साइमन हैटर

4

1) आपके पास Adobe TypeKit है जो वर्तमान कोड के साथ अतुल्यकालिक लोड नहीं कर रहा है। इसे उन्नत अतुल्यकालिक कोड के साथ बदलने का प्रयास करें: http://help.typekit.com/customer/portal/articles/649336-embed-code

यह मानक एम्बेड कोड इस तथ्य का लाभ उठाता है कि टैग पृष्ठ के आगे के प्रतिपादन को रोकने में मदद करता है ताकि FOUT [फ्लैश ऑफ अनस्टील्ड टेक्स्ट] को रोका जा सके। जबकि टाइपेकिट स्क्रिप्ट लोड हो रही है, पृष्ठ का रेंडरिंग अवरुद्ध है, इसलिए पाठ फालबैक फोंट के साथ प्रस्तुत करना शुरू नहीं करेगा।

2) नए टाइपकिट के साथ टेस्ट करें। अब लोडिंग का समय कैसा है? बेहतर? चरण 3 पर जाएं।

3) अपने Google Analytics को एक अद्यतन जावास्क्रिप्ट के साथ बदलें जो नवीनतम एसिंक्रोनस सिंटैक्स प्रदान करता है: https://developers.google.com/analytics/devguides/collection/gajs/

4) टेस्ट। क्या पेज लोड करना अभी भी बेहतर है?

5) अंत में, प्रतिमानों को अनुकूलित करने पर विचार करें जैसे कि पैटर्न। जेपीजी। मैंने इसे पीएनजी में बदल दिया और फ़ाइल का आकार 199kB से 56kB तक कम करने में सक्षम था। यह फ़ाइल प्राप्त करने का समय कम कर देता है: https://www.dropbox.com/s/i06jx509bmprhhh/pattern.png?dl=0

आशा है कि ये आपकी मदद करेगा।

— रवि
स्रोत

3

PHP बनाम गैर-PHP तत्व

यदि आप अपने गैर-PHP परिसंपत्ति लोड समय की तुलना अपने PHP आधारित लोड समय से करते हैं, तो आप देखेंगे कि सर्वर तेजी से प्रतिक्रिया करता है यदि PHP शामिल नहीं है।

यह आमतौर पर आपके PHP स्क्रिप्ट के लिए आंतरिक मुद्दों को इंगित करता है।

समस्या PHP लेयर या डेटाबेस के भीतर हो सकती है। XDebug या NewRelic जैसे उन्नत डिबगिंग टूल का उपयोग करने से आपको अड़चन को जल्दी से दूर करने में मदद मिल सकती है।

पहली बाइट समस्याओं के लिए समय हार्डवेयर की कमी, खराब कॉन्फ़िगरेशन या अक्षम कोड के कारण हो सकता है। साझा होस्टिंग पर, हार्डवेयर की कमी और खराब कॉन्फ़िगरेशन सबसे अधिक संभावना है।

किसी भी मामले में, समस्या को हल करने का आमतौर पर एक या सभी का मतलब है:

अधिक हार्डवेयर
बेहतर प्रोग्रामिंग
कैशिंग जोड़ें

यदि आप पहले से ही समर्पित संसाधनों पर हैं तो तेज़ हार्डवेयर एक स्पष्ट लेकिन अक्सर महंगा समाधान है।

यदि आप कोड को बनाए नहीं रखते या डेवलपर संसाधनों का अभाव करते हैं, तो समस्या का समाधान करना बेहतर हो सकता है।

कैशिंग अनुरोधों की संख्या को कम करके मदद करता है जो अंतर्निहित, खराब प्रदर्शन करने वाले संसाधनों से टकराते हैं।

परिक्षण

परीक्षण उपकरण का उपयोग करते समय कई रन करना सुनिश्चित करें। नेटवर्क और अस्थायी सर्वर स्पाइक्स आसानी से आपको गलत रास्ते पर ले जा सकते हैं, इसलिए आप इन्हें औसत करने की कोशिश करना चाहते हैं।

मेजबानी

यदि आप एक साझा होस्टिंग खाते पर हैं, तो क्लाउड या वीपीएस प्रकार सेवाओं पर जाने पर विचार करें ताकि आपके पास प्रदर्शन के मुद्दों में बेहतर जानकारी हो। जब तक आप कैशिंग तकनीक (CDN या Cloudflare प्रकार सेवा) का उपयोग नहीं करते हैं, बड़े पैमाने पर साझा होस्टिंग सिस्टम पर प्रदर्शन के मुद्दों को सही करना बहुत चुनौतीपूर्ण हो सकता है क्योंकि आपके पास सर्वर के पर्याप्त नियंत्रण की कमी होती है।

— jeffatrackaid
स्रोत

-1

केवल देखे जाने के लिए तृतीय पक्ष कुकी सेट करने का प्रयास करें।

— टॉम
स्रोत