Gutenberg: प्रदर्शन: ब्लॉक में टाइप करते समय शुरुआती लोडिंग समय और सुगमता के लिए सुधार करें।

सम्बंधित: # 11770

मैं इसे पुन: प्रस्तुत कर सकता हूं, मैंने अपने ब्लॉग से सबसे लंबे समय तक लेख के साथ इसका परीक्षण किया। इसे क्लासिक ब्लॉक से ब्लॉकों में बदलने में कुछ समय लगता है लेकिन काम करता है, लेकिन पुराने एडिटर में टाइपिंग में एक सेकंड से ज्यादा देरी होती है - बहुत बेहतर (लगभग टाइपिंग में देरी के बिना)। मेरी इंटरनेट स्पीड 36.2 Mbit / s डाउनलोड है और 8.96 Mbit / s अपलोड है। @SchneiderSam की सामग्री के साथ परीक्षण बेहतर काम करता है। यदि यह मदद करता है, तो यहां HTML प्रारूप में पोस्ट की सामग्री है (इसलिए ब्लॉकों में रूपांतरण का परीक्षण किया जा सकता है, भी): https://gist.github.com/florianbrinkmann/4e9e4d23eaefb8b2348bbadddd848196

इसलिए यदि मैं @florianbrinkmann सामग्री

संपादक पृष्ठ पर एक लेख लोड हो रहा है जिसमें @florianbrinkmann द्वारा प्रदान की गई सामग्री है जिसमें 44 सेकंड के लिए एक रिक्त स्क्रीन है और इसके बाद एफओआईटी के दूसरे 56 सेकंड (सफारी 12.0.1 का उपयोग करके)

... और यह परीक्षण एक स्थानीय देव वातावरण में हुआ।

4.3 पुष्टि कर सकते हैं अभी भी लोड करने के लिए एक मिनट के बारे में:

शब्द: 3451
शीर्षकों: 29
अनुच्छेद: 34
ब्लॉक: 218

पोस्ट प्रत्येक कॉलम में चित्र और पैराग्राफ के साथ कॉलम ब्लॉक की एक सूची है।

एक बार भरी हुई टाइपिंग में बहुत देरी हो जाती है।

४.३: हाँ, हम संपादक को भी लंबे पदों पर बड़े पैमाने पर धीमा देख रहे हैं। कॉलम ब्लॉक शामिल होने लगते हैं।

जानकारी का एक अतिरिक्त टुकड़ा, जो उपयोगी हो सकता है, किसी भी साइट पर सक्रिय प्लगइन्स हैं, विशेष रूप से वे जो हाल ही में गुटेनबर्ग G के साथ संगतता जोड़ने के लिए अपडेट किए गए हो सकते हैं।

_ _ यहां एक संभावना को खत्म करने के लिए सोचा जा रहा है जहां एक प्लगइन इस तरह से लागू किया जाता है कि यह संपादकीय_ के प्रदर्शन को प्रभावित कर सकता है

खदान के लिए सीधे Gutenberg के साथ एकीकृत एकमात्र प्लगइन Yoast SEO है, लेकिन इसे निष्क्रिय करने से लोड समय या प्रतिक्रिया समय टाइपिंग में कोई ध्यान देने योग्य अंतर नहीं होता है।

5.0-beta4-43896 और कोई प्लगइन्स के साथ परीक्षण किया गया। एक ही परिणाम। विशेष रूप से फ्लोरियन की

हाल के कई पुल अनुरोध (अभी तक एक प्लगइन रिलीज में शामिल नहीं हैं) जो अद्यतन को अवरुद्ध करने के लिए इंटरफ़ेस अपडेट से संबंधित कुछ प्रदर्शन गिरावट को संबोधित करना चाहते हैं (जैसे कि एक अनुच्छेद में लिखना):

• # 11845
• # 11844
• # 11,843
• # 11842
• # 11,841

एक अतिरिक्त अपराधी मैंने देखा है कि विशेष रूप से एक नेस्टेड संदर्भ (जैसे कॉलम) के भीतर ब्लॉक अपडेट करते समय, कुछ बेकार / अनावश्यक अपडेट होता है जो ब्लॉक के पूर्वजों के लिए होता है।

_ (ऊपर GIF रिएक्ट DevTools "हाइलाइट अपडेट" सुविधा का उपयोग करता है) _

क्या इन पीआरओं के पहले और बाद में कोई बेंचमार्क हैं?

@aduth और @youknowriad - GB 4.4 के साथ परीक्षण किया गया और यह अभी भी धीमा है। कृपया जारी रखें, यह जीबी को स्थापित करने के लिए एक लेखक के रूप में मेरे लिए कोई मतलब नहीं है अगर मैं ठीक से नहीं लिख सकता हूं। मुझे उम्मीद है कि यह Wordpress 5.0 से पहले तय हो जाएगा।

क्या मुझे बहुत ज्यादा उम्मीद है?

क्या मुझे बहुत ज्यादा उम्मीद है?

हरगिज नहीं। मैं पुष्टि कर सकता हूं, 4.4.0 पर मेरी वास्तविक दुनिया की सामग्री का नमूना अभी भी संपादित करने के लिए असामान्य रूप से धीमा है।

उम्मीद है कि अन्य संबंधित पीआर-एस कुछ कर सकते हैं, और हम यहां एक विशाल वास्तुकला समस्या से नहीं निपट रहे हैं।

हाल के कई पुल अनुरोध (अभी तक एक प्लगइन रिलीज में शामिल नहीं हैं) जो अद्यतन को अवरुद्ध करने के लिए इंटरफ़ेस अपडेट से संबंधित कुछ प्रदर्शन गिरावट को संबोधित करना चाहते हैं (जैसे कि एक अनुच्छेद में लिखना):

• # 11845
• # 11844
• # 11,843
• # 11842
• # 11,841

सभी उल्लेख पीआर 4.4 के साथ तय किए गए थे - यही कारण है कि मैंने फिर से लिखा। इससे मुझे चिंता होती है:

https://github.com/WordPress/gutenberg/pull/11811#issue -230464225

लेकिन अच्छी तरह से मैं यहाँ किसी का भी वशीकरण नहीं करना चाहता हूँ, लेकिन मुझे सिर्फ पेट दर्द है: अभी तक मैं GB का बहुत बड़ा प्रशंसक था, लेकिन यह कोई मज़ेदार बात नहीं है।

बेहतर प्रदर्शन की दिशा में काम जारी है। इसलिए यह मुद्दा खुला क्यों है।

आपको नवीनतम के साथ बने रहने के लिए प्रदर्शन लेबल देखने में रुचि हो सकती है: https://github.com/WordPress/gutenberg/pulls?utf8=%E2%9C%93&q=is%3Apr+live%3APerformance+

ठीक है, इतनी मेहनत करने के लिए धन्यवाद। कृपया अच्छा काम जारी रखिए। जैसा कि मैंने कहा, चिंता केवल इसलिए होती है क्योंकि हम रिलीज से दो सप्ताह पहले नहीं हैं।

धन्यवाद!!!

गुटेनबर्ग 4.4 के साथ सेवानिवृत्त, सामग्री @florianbrinkmann द्वारा फिर से लंबा लेख है और गुटेनबर्ग केवल 4.9.8 पर स्थापित किया गया है जो फ्लाईव्हील द्वारा स्थानीय पर चल रहा है। 35 सेकंड की सफेद स्क्रीन और दूसरी 33 सेकंड की एफओआईटी।

ज़रा सुनिए सभी! इस पर कुछ खोजी कार्य के बाद, यह मुझे लगता है कि टाइपिंग के साथ समस्या का एक बड़ा हिस्सा धीमा होता जा रहा है क्योंकि ब्लॉक की संख्या जिस तरह से बढ़ती है वह राज्य का पेड़ है।

ब्लॉक की जानकारी state.editor.present.blocks में संग्रहीत की जाती है, प्रत्येक व्यक्ति ब्लॉक के लिए state.editor.present.blocks.byClientId तहत जानकारी के साथ। state.editor.present.blocks.order , जो दस्तावेज़ में ब्लॉक ऑर्डर का ट्रैक रखता है।

blocks: {
   byClientId: { [ clientId ] : { name, attributes, isValid ... } },
   order: [ ... ]
}

जब कोई उपयोगकर्ता वर्तमान पैराग्राफ ब्लॉक में टाइप करता है, तो यह state.editor.present.blocks.byClientId[id].attributes.content को संशोधित करता है। इसका अर्थ है कि कोई भी चयनकर्ता जो state.editor.present.blocks या state.editor.present.blocks.byClientId हर कीस्ट्रोके पर अमान्य होगा, यह निर्भर करने के लिए पेड़ की एक महंगी शाखा बना देगा।

अब, कुछ चयनकर्ता हैं जो इसके बजाय state.editor.present.blocks.order आधार पर इसे प्राप्त करने में सक्षम हैं। हालाँकि, केवल वास्तविक जानकारी ब्लॉक आईडी है, इसलिए getGlobalBlockCount जैसे चयनकर्ताओं के लिए जो फ़िल्टर करने के लिए एक वैकल्पिक नाम लेते हैं, यह एक वैध विकल्प नहीं है। इसका मतलब है कि getGlobalBlockCount वर्तमान में state.editor.present.blocks.byClientId पर निर्भर करता है और इस प्रकार प्रत्येक कीस्ट्रोक पर अमान्य हो जाता है। एक ही स्थिति में कई अन्य चयनकर्ता हैं।

मैं जो उपाय @youknowriad के सुझाव पर देख रहा हूं, वह पेड़ की संरचना में अपने वर्तमान स्थान से विशेषताओं को हटा रहा है, और state.editor.present.blocks.attributesByClientId में रखने के बजाय। यह पेड़ की संरचना को एक सस्ती शाखा में विभाजित करेगा जो केवल तभी अपडेट होती है जब ब्लॉक जुड़ जाते हैं / हटा दिए जाते हैं, या जब ब्लॉक के लिए ब्लॉक प्रकार बदलता है ( byClientId ); और एक महंगी शाखा जो हर कीस्ट्रोके ( attributesByClientId ) पर अपडेट हो जाती है।

blocks: {
   byClientId: { [ clientId ] : { name, isValid, ... } },  // Cheap
   attributesByClientId: { [ clientId ] : attributes },    // Expensive
   order: [ ... ]
}

इसके बाद चयनकर्ताओं को byClientId , attributesByClientId , या दोनों पर निर्भर किया जा सकता है, यह इस बात पर निर्भर करता है कि आपको क्या चाहिए।

इससे चल रहे अनावश्यक काम की मात्रा कम होनी चाहिए, लेकिन यह अनुमान लगाना कठिन है कि प्रदर्शन लाभ क्या होगा। इस समय हर कीस्ट्रोके साथ Redux पर महत्वपूर्ण समय बिताया जा रहा है, हालांकि, ऐसा लगता है कि यह कहीं और ले जा सकता है।

यह सकारात्मक लगता है। क्या पहले से ही एक मार्चिंग दिशा है? 5.0 से पहले तय किया जाएगा?

मैं मैट द्वारा टिप्पणी के बारे में सोच रहा हूँ:

गुटेनबर्ग के लिए सफलता के कुछ अच्छे उपाय:

....
क्या वे ऐसी चीजें बना सकते हैं जो वे पहले नहीं बना पाए थे?

मुझे वह एक दिलचस्प कथन लगता है। यह निश्चित रूप से कुछ गुटेनबर्ग नहीं कर सकता है और इसमें काफी खामियां हैं। लेखकों और ऑनलाइन विपणक के लिए यह एक मस्टियर है, अन्यथा मैं पूरी तरह से जीबी के बिना कर सकता हूं।

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

उम्मीद है कि यह जल्द ही ठीक हो जाएगा। हम उपन्यास लेखक और अनुवादक हैं। हमारे संपादक जीबी की धीमी गति टाइपिंग से बीमार हैं कि वे इसे वर्ड में कॉपी करते हैं, संपादित करते हैं और फिर इसे वापस डालते हैं। दुर्भाग्य से हमने संगतता बनाए रखने के लिए हमारी मुफ्त योजना साइटों पर जीबी में स्विच किया ...

हमारे पास प्रत्येक पोस्ट में पैराग्राफ की एक पागल राशि नहीं है, शायद लगभग 60-80 और 2 विभाजक ब्लॉक। लगभग 7-8 पेज की सामग्री। अभी भी टाइपिंग या विलोपन एक अवधारणात्मक देरी के साथ होता है।

हम सभी के पास 15-50Mbps कनेक्शन हैं।

@brazenvoid साझा करने के लिए धन्यवाद। यह किसी भी मामले में तय किया जाना है। मैं इस तरह काम नहीं कर सकता।

कोई लेबल बग नहीं?

यह कोई बग नहीं है?

गुटेनबर्ग 4.5.1, WP 4.9.8

मैंने गुटेनबर्ग 4.5.1, वर्डप्रेस 4.9.8 (कोई अन्य प्लगइन्स) के साथ परीक्षण नहीं किया है। @Florianbrinkmann के पाठ के साथ, मैंने HTML को क्लासिक संपादक (पाठ दृश्य) में डाला, सहेजा, इसे गुटेनबर्ग ब्लॉक्स में बदल दिया। रूपांतरण में 12 सेकंड की अवधि थी। अब जब मैं एक ब्लॉक में टाइप करता हूं, तो हर अक्षर को 1 सेकंड से ज्यादा की जरूरत होती है।

विकास संस्करण (5.0-RC1-43944)

--- बीटा परीक्षक प्लगइन की तुलना में कुछ और स्थापित नहीं है ---
नई पोस्ट, क्लासिक -> HTML के रूप में संपादित करें -> फ्लोरियन की कॉपी की गई HTML डालें, प्रकाशित करें। ब्लॉक (12 सेकंड) में कनवर्ट करता है, एक ब्लॉक में टाइप करें, हर एक अक्षर को 1 सेकंड से अधिक की आवश्यकता होती है।

मुझे नहीं पता, अगर इसकी कोई प्रासंगिकता है:
MySQL संस्करण 5.7.19
PHP संस्करण 7.2.11-2+0~20181015120510.9+jessie~1.gbp8105e0
PHP max_execution_time 360
परीक्षण किया PHP अधिकतम निष्पादन समय 260 सेकंड
रिपोर्ट की गई PHP मेमोरी लिमिट 2048M (स्थानीय) / 2048M (मास्टर)
परीक्षण किया गया PHP मेमोरी लिमिट 1716 MB
PHP अधिकतम फ़ाइल अपलोड आकार (सर्वर-रिपोर्ट) 50 एमबी
पोस्ट मैक्स का आकार: 50M
मैक्स इनपुट वार्स: 1000

मेरी इंटरनेट स्पीड 150 Mbit / s डाउनलोड है और 10 Mbit / s अपलोड है

मैंने भी अपने 10 से 15 चित्र, एक या एक से अधिक तालिकाओं के साथ अपने कुछ लंबे लेखों 2500+ शब्दों को आजमाया है। गुटेनबर्ग में परिवर्तित होने में प्रत्येक लेख के लिए 15 सेकंड से अधिक समय लगता है। टाइपिंग बाद में लेखों में सबसे कम 2550 शब्दों के लिए धीमी है, और 4121 शब्दों (प्रत्येक अक्षर के लिए एक से अधिक सेकंड) के साथ लेख के लिए अनुपयोगी है, क्रोम (और फ़ायरफ़ॉक्स में एक ही, दोनों नवीनतम संस्करण), मेमोरी उपयोग तेजी से चढ़ता है, और सीपीयू उपयोग 50% के करीब जाता है। यह सब i5 8gen CPU और 8GB RAM के साथ लेनोवो लैपटॉप पर क्लीन WP 5.0 RC इंस्टॉल, डिफॉल्ट थीम और अन्य प्लगइन्स के साथ किया गया है। मैं विवरण में नहीं जा रहा था कि क्रोम कंसोल क्या दिखाता है, लेकिन यह अनुपयोगी है।

इसे बग के रूप में चिह्नित किया जाना है, और इसे हल करना होगा इससे पहले कि आप यह भी सोच सकते हैं कि गुटेनबर्ग संपादक कहीं भी प्रयोग करने योग्य है। यदि यह 5.0 में रहता है, तो आप 1000 तक के ग्रंथों के साथ गुटेनबर्ग और ब्लॉक की एक मध्यम संख्या का उपयोग कर सकते हैं। मैंने किसी भी पाठ के साथ धीमेपन पर ध्यान दिया, मैंने कोशिश की कि थोड़ा लंबा हो जाए।

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

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

मैं फ़ायरफ़ॉक्स नाइटली का उपयोग कर रहा हूं, वर्तमान में 65.0a1 (2018-11-25) (64-बिट) (विंडोज 10 पर) संस्करण।

मुझे यकीन नहीं है कि हर कोई अपनी इंटरनेट स्पीड क्यों पोस्ट कर रहा है

लोग यहाँ हमेशा तकनीकी विवरणों को नहीं समझते हैं, इसलिए संभवतः इसे सामान्य "धीमी" दृष्टिकोण से ही पोस्ट कर रहे हैं।

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

यह भी ध्यान दिया जाना चाहिए कि संपूर्ण संपादक धीमा है, न कि केवल रिचटेक्स्ट तत्व। पर्मलिंक स्लग (दस्तावेज़ सेटिंग्स में) या कुछ और जो इनपुट लेता है, को अपडेट करना धीमा है।

जहाँ तक मैं देख रहा हूँ सुधार के 3 क्षेत्र हैं:

• प्रारंभिक पार्सिंग और प्रतिपादन का समय - पहली बातचीत का समय।
• ब्लॉक के साथ टाइपिंग / इंटरेक्शन (# 12312)
• बाकी संपादक के साथ बातचीत

@spencerfinnell PR # 12312 का दूसरे और तीसरे दोनों बिंदुओं पर प्रभाव होना चाहिए।

मैंने आज इसे @SchneiderSam द्वारा प्रदान की गई सामग्री और समस्या मेरे लिए बनी रहती है। मैंने इसे वर्तमान आरसी में फ़ायरफ़ॉक्स के साथ-साथ रात के निर्माण प्लगइन और wp 4.9.8 के साथ परीक्षण किया। मैंने क्रोम के साथ भी इसका परीक्षण किया। वहाँ यह थोड़ा ठीक है, लेकिन फ़ायरफ़ॉक्स के साथ उतना बुरा नहीं है।

यहाँ मेरे xp के साथ एक पेंचकस है: https://www.youtube.com/watch?v=yIV6REWM5tE

उबंटू 14.04
ब्राउज़र जानकारी:
नाम फ़ायरफ़ॉक्स
संस्करण 63.0.3
बिल्ड-आईडी 20181116161301
उपयोगकर्ता-एजेंट मोज़िला / 5.0 (X11; Ubuntu; लिनक्स x86_64; आरवी: 63.0) गेको / 20100101 फ़ायरफ़ॉक्स / 63.0
ऑपरेटिंग सिस्टम लिनक्स 4.4.0-139-जेनेरिक

शायद बहुत अधिक नई जानकारी नहीं है जैसा कि मैं देख रहा हूं, इस विषय पर चर्चा काफी विकसित हुई है, इसे वैसे भी छोड़ना चाहते थे।

बहुत सारे शब्दों के साथ लेख सम्मिलित किए बिना भी ऐसा होता है। गुटेनबर्ग की वर्तमान रिलीज़ बस सभी जगह बुरी तरह से लटकी हुई है, चाहे आप कुछ भी करें। आप अपने ब्राउज़र को पुनरारंभ कर सकते हैं और उम्मीद कर सकते हैं कि यह लगभग आधे घंटे तक सुचारू रूप से काम करे।

मेरे पास 16 जीबी की रैम है। मेरे पास एक 1080 TI है। मेरे पास i7 हैसवेल प्रोसेसर है। मैं एक पाठ संपादक में किसी भी समय का अनुभव नहीं होना चाहिए।

फ़्लायव्हील और फ्लोरियन ब्रिंकमैन सैंपल आर्टिकल द्वारा लोकल के साथ सफारी 12.0.1 के साथ रिटायर्ड आरसी 2 (वर्डप्रेस बीटा टेस्टर प्लगइन और क्लासिक एडिटर प्लगइन को छोड़कर कोई प्लग इन स्थापित नहीं किया गया था लेकिन बाद वाले को पहले टेस्ट के दौरान निष्क्रिय कर दिया गया था)।

68 सेकंड के लिए व्हाइट स्क्रीन
एक और 35 सेकंड के लिए फिट

क्लासिक संपादक को पुनः सक्रिय करने और लेख को पुनः लोड करने के बाद:

बॉडी मेटा बॉक्स में कोई सामग्री 12 सेकंड में नहीं
एक और 2 सेकंड के लिए फिट

लगता है कि चीजें खराब रहीं या गुटनबर्ग के साथ लेख को लोड करना और भी बदतर हो गया।

मेरी सामग्री + 4.6 के साथ परीक्षण किया गया और प्रदर्शन अपरिवर्तित है। जिस तरह से यह दिखता है, यह 5.0 से हल नहीं है। बहुत बुरा है, लेकिन ठीक है आप इस पर काम कर रहे हैं। आपका बहुत बहुत धन्यवाद!

फ़्लायव्हील और फ्लोरियन ब्रिंकमैन सैंपल आर्टिकल द्वारा लोकल के साथ सफारी 12.0.1 में आरसी 3 के साथ रिटायर्ड किया गया (वर्डप्रेस बीटा टेस्टर प्लगइन और क्लासिक एडिटर प्लगइन को छोड़कर कोई प्लग इन स्थापित नहीं किया गया था लेकिन बाद वाले को पहले टेस्ट के दौरान निष्क्रिय कर दिया गया था)।

41 सेकंड के लिए व्हाइट स्क्रीन
52 सेकंड के लिए एफओआईटी

दो दिनों में नई रिलीज की तारीख के संदर्भ में उत्पादन तैयार प्रदर्शन के पास कहीं भी।

दो दिनों में नई रिलीज की तारीख के संदर्भ में उत्पादन तैयार प्रदर्शन के पास कहीं भी।

हाँ। मुझे यकीन नहीं है कि उनके लेख https://ma.tt/2018/11/a-gutenberg-faq/ में वास्तव में @ का क्या अर्थ है:

हमारे पास एक स्थिर RC1 है, जो पहली रिलीज के उम्मीदवार के लिए खड़ा है, और हमारे दूसरे को करने के बारे में है। वर्तमान में केवल एक ज्ञात अवरोधक है और यह कॉस्मेटिक है।

मुझे बनाता है, एक के लिए, जाओ: सोच:

जब तक यह बिंदु # 12312 हल नहीं होगा, मैं अपडेट के साथ इंतजार करूंगा। यह मेरे लिए कोई मतलब नहीं है।

@sgomes और co: कृपया अच्छा काम जारी रखें। मैं कल्पना कर सकता हूं कि आपको हर जगह से दबाव मिलता है। इस पर काम करने के लिए धन्यवाद! दुर्भाग्य से मैं केवल अपने शब्दों के साथ मदद कर सकता हूं! आप बहुत अच्छा काम कर रहे हैं !!!

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

• # 11851
• # 11,899
• # 12356
• # 12379
• # 12,384
• # 12,386
• # 12402
• # 12,460
• # 12477
• # 12480
• # 11,602
• # 12521
• # 12542

@ महान तुम महान हो। यह देखना वास्तव में अच्छा है कि आप कम्यूनिटी की इच्छाओं पर विचार करते हैं और उन्हें गंभीरता से लेते हैं। कृपया कई नकारात्मक टिप्पणियों को आप को ख़त्म न करने दें। एक समुदाय के रूप में हमारी भी जिम्मेदारी है कि आप डेवलपर्स का समर्थन करें। फिलहाल यह थोड़ा कम है और मुझे इसमें अपनी नाक मिलानी होगी।

इसलिए: सभी अंगूठे ऊपर !!!! तुम महान हो!

अभी भी इन बहुत धीमी गति से लोड मुद्दों के रूप में अच्छी तरह से कर रहे हैं। पिछले एक हफ्ते से समाधान देख रहे हैं। मैं सबसे अद्यतित संस्करण का उपयोग करता हूं: गुटेनबर्ग संस्करण 4.6.1, और वर्डप्रेस 4.9.8।

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

अब मुझे क्लासिक संपादक का उपयोग करना है और मेरे बहुत से लिंक अब अच्छे पूर्वावलोकन के साथ एम्बेडेड नहीं हैं कि 'गुटेनबर्ग के पास है और रिक्ति सभी से दूर है जब मैंने अच्छा गुटेनबर्ग मंच का उपयोग किया था।

तो इस बिंदु पर, मैं या तो

1. गूटेनबर्ग का उपयोग करें और भविष्य की अद्यतन की उम्मीद में धीमी गति से निपटें और फिर योस्ट को हटा दें और एसईओ और मेटा विवरण के लिए अन्य समाधान का पता लगाएं।
2. या बेहतर संपादक का पता लगाएं जो लोड की गति में बाधा के बिना गुटेनबर्ग की नकल करता है।

यहां किसी भी अंतर्दृष्टि को बहुत सराहना की जाएगी कि मैं सबसे अच्छा कैसे आगे बढ़ सकता हूं। @aduth @SchneiderSam

यहाँ मेरे धागे के साथ वास्तव में कहीं नहीं मिला:
https://github.com/WordPress/gutenberg/issues/12508#issuecomment -443919417

@aduth क्या आपने फ्लोरियन ब्रिंकमैन लेख (https://github.com/WordPress/gutenberg/issues/11782#issuecomment-438217916) की सामग्री के साथ एक पोस्ट लोड करने के खिलाफ लागू किए गए उन पैच के साथ एक निर्माण का परीक्षण किया है? क्या यह अब TinyMCE के उन लोगों के बराबर है? और उस लेख के भीतर टाइपिंग और संपादन वास्तविक समय में संभव है? और जिज्ञासा से बाहर उन पैच 5.0 में क्यों नहीं बनाया है?

अभी भी इन बहुत धीमी गति से लोड मुद्दों के रूप में अच्छी तरह से कर रहे हैं। पिछले एक हफ्ते से समाधान देख रहे हैं। मैं सबसे अद्यतित संस्करण का उपयोग करता हूं: गुटेनबर्ग संस्करण 4.6.1, और वर्डप्रेस 4.9.8।

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

अब मुझे क्लासिक संपादक का उपयोग करना है और मेरे बहुत से लिंक अब अच्छे पूर्वावलोकन के साथ एम्बेडेड नहीं हैं कि 'गुटेनबर्ग के पास है और रिक्ति सभी से दूर है जब मैंने अच्छा गुटेनबर्ग मंच का उपयोग किया था।

तो इस बिंदु पर, मैं या तो

1. गूटेनबर्ग का उपयोग करें और भविष्य की अद्यतन की उम्मीद में धीमी गति से निपटें और फिर योस्ट को हटा दें और एसईओ और मेटा विवरण के लिए अन्य समाधान का पता लगाएं।
2. या बेहतर संपादक का पता लगाएं जो लोड की गति में बाधा के बिना गुटेनबर्ग की नकल करता है।

यहां किसी भी अंतर्दृष्टि को बहुत सराहना की जाएगी कि मैं सबसे अच्छा कैसे आगे बढ़ सकता हूं। @aduth @SchneiderSam

यहाँ मेरे धागे के साथ वास्तव में कहीं नहीं मिला:
# 12508 (टिप्पणी)

नमस्ते,

इसलिए मुझे लगता है कि डेवलपर्स इस पर काम कर रहे हैं। इस लेख पर एक नज़र डालें। अगले अद्यतन 4.7 और 4.8 के साथ यह उम्मीद की जानी चाहिए कि इसे हल किया जाए। मैं आपको पूरी तरह से समझता हूं। फिलहाल मैं केवल छोटे लेख लिख रहा हूं क्योंकि यह कोई मजेदार बात नहीं है। केवल एक चीज जो मैं अभी कर रहा हूं वह है धैर्य रखना और डेवलपर्स को प्रतिक्रिया के साथ प्रेरित करना।

वैसे: मैं एक डेवलपर नहीं हूँ, मैं आप की तरह एक छोटा लेखक हूँ ;-)

उच्च प्राथमिकता को चिह्नित करना और अगले छोटे रिलीज के लिए असाइन करना।

Https://adithub.com/WordPress/gutenberg/issues/11782#issuecomment -444144278 में

यह स्पष्ट नहीं है कि इस मुद्दे को हल करने के लिए क्या कार्रवाई करने की आवश्यकता है। प्रदर्शन का काम कभी भी "समाप्त" नहीं होता है। अभी के लिए, मैं इस मुद्दे को 5.0.2 पर ले जा रहा हूं ताकि हम आगे के प्रदर्शन सुधारों पर नज़र रख सकें।

@noisysocks का आकलन करना आसान है। फ्लोरियन ब्रिंकमैन लेख का उपयोग करें। जैसे ही कैशिंग डिसेबल के साथ आर्टिकल को लोड करना tinyMCE की तुलना में अधिक सम्‍मिलित या तेज होता है और टायमिंग के साथ टाईपिंग बिना वास्तविक समय में सम्‍मिलित और हाइपअप के बिना होती है, तब मैं इस मुद्दे को हल करने पर विचार करूंगा।

पिछले कुछ दिनों के लिए 5.0 के साथ परीक्षण, और मेरे पास कोई प्रदर्शन समस्या नहीं है। मैंने उस पाठ के साथ परीक्षण किया जिसमें 300+ ब्लॉक, 15000+ शब्द, 50+ चित्र हैं, संपादक के साथ, या टाइपिंग के साथ कोई ध्यान देने योग्य देरी नहीं है। लेकिन, ब्राउज़र रैम का उपयोग 2GB के करीब बढ़ता है, जिसमें CPU लगभग 15% का उपयोग करता है, और यह देखते हुए कि सामग्री संपादक कितना संभालता है, यह एक मुद्दा नहीं है। लेनोवो लैपटॉप पर 2 कोर आई 5 सीपीयू (हाइपरथ्रेडिंग, जेन 7 के साथ) और 8 जीबी रैम के साथ टेस्ट किया गया। मेरे पास बीटा और RC1 के मुद्दे मेरे लिए हल हैं।

पिछले कुछ दिनों के लिए 5.0 के साथ परीक्षण, और मेरे पास कोई प्रदर्शन समस्या नहीं है।

मैं इसकी पुष्टि नहीं कर सकता। 5.0 धीमा है। 5.0.1 की प्रतीक्षा करें

मैं इसकी पुष्टि नहीं कर सकता। 5.0 धीमा है। 5.0.1 की प्रतीक्षा करें

मेरा मानना ​​है कि बाहरी प्रभाव हैं जो कुछ उपयोगकर्ताओं के ठीक काम करने का कारण बनते हैं, और कुछ के लिए प्रदर्शन के मुद्दे हैं, और यह बिल्कुल आश्चर्यजनक नहीं है, यह देखते हुए कि यह ज्यादातर जावास्क्रिप्ट और प्रतिक्रिया शक्ति है। जब मैं किसी भी फेसबुक पेज पर जाता हूं, तो मेरा लैपटॉप इतना धीमा लगता है, जैसे यह 10 साल पुरानी मशीन हो। और मुझे आश्चर्य है कि 5.0 में गुटेनबर्ग मेरे लिए ठीक काम करता है, लेकिन मुझे आश्चर्य नहीं है कि यह कई अन्य उपयोगकर्ताओं के लिए टूट गया है।

मुझे वास्तव में उम्मीद है कि गुटेनबर्ग के प्रदर्शन के मुद्दों को सभी उपयोगकर्ताओं के लिए हल किया जा सकता है, लेकिन इस बिंदु पर, मैं उस पर निश्चित नहीं हूं। अगर सिस्टम को विस्तार या दो, कुछ प्लगइन्स के प्रभाव से तोड़ा जा सकता है, तो यह मूलभूत रूप से खराब डिज़ाइन है।

फिर भी, मैंने अभी तक अपनी वेबसाइटों को अपडेट नहीं किया है, मैंने 5.0.1 की प्रतीक्षा करने का विकल्प भी चुना है।

Yoast प्लगइन स्थापित किए बिना कोई प्रदर्शन परीक्षण नहीं किया जाना चाहिए और ग्रामरली ब्राउज़र एडऑन सक्षम होना चाहिए क्योंकि यह एक सामान्य उपयोग की स्थिति है। यदि यह उनमें से किसी के बिना पूरी तरह से ठीक करता है, लेकिन दूसरा आप उनमें से एक को स्थापित करते हैं, तो यह पूरी तरह से काम नहीं करता है, फिर पूरी बात अस्थिर है।

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

गुटेनबर्ग मेरे i3 लैपटॉप, मेरे i5 iMac, या मेरे i7 / 1080 Ti डेस्कटॉप पर पाठ संपादन के लिए, प्लगइन्स के साथ या बिना काम नहीं करता है। प्लगइन्स के बिना, यह असहनीय रूप से खराब प्रदर्शन है, उनके साथ, यह पूरी तरह से बेकार है, हम यहां प्रति 5 सेकंड में एक फ्रेम की बात कर रहे हैं।

मुझे वास्तव में समझ में नहीं आ रहा है कि किसी भी अंतराल को स्वीकार्य क्यों माना जा रहा है ?? यह तब नहीं होता है जब आप बस एक बनाते हैं। कभी कोई अंतराल, कभी, अवधि नहीं है। यदि कोई JS frontend किसी textarea के प्रदर्शन से मेल नहीं खा सकता है, तो इसका उपयोग नहीं किया जाना चाहिए। इस समस्या को हल करने के रूप में चिह्नित किया जाना चाहिए केवल अगर अंतराल वास्तव में चला गया है, जो मुझे नहीं लगता कि ऐसा होगा, इसलिए वास्तव में, इस मुद्दे को कभी भी वैध रूप से हल नहीं किया जा सकता है।

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

मैं वास्तव में हैरान हूं कि 5.0 मेरे लिए काम करता है, लेकिन मुझे आश्चर्य नहीं है कि यह अन्य उपयोगकर्ताओं के लिए काम नहीं करता है। संपादक के एक केंद्र बिंदु के रूप में जावास्क्रिप्ट और प्रतिक्रिया का उपयोग करना एक बुरा विचार है, और मैं शुरू से कह रहा हूं कि यहां हम हैं।

एक घंटे पहले, मैंने एक क्लाइंट वेबसाइट को 5.0 में अपडेट किया (उसने जोर दिया), उसने Yoast Pro प्लगइन का उपयोग किया और अधिकांश भाग के लिए, यह ठीक काम करता है। लेकिन, जैसे ही मैंने एक लंबी पोस्ट को बदलने की कोशिश की, उसके पास (लगभग 4000 शब्दों के साथ कुछ ट्यूटोरियल), रूपांतरण प्रक्रियाओं के दौरान भी संपादक टूट जाता है। कुछ प्रयासों के बाद, यह रूपांतरण समाप्त करने का प्रबंधन करता है, लेकिन संपादन बहुत धीमा और मुश्किल से उपयोग करने योग्य है। एक बार योस्ट प्लगइन अक्षम हो जाने के बाद, यह उम्मीद के मुताबिक काम करता है। मुझे यकीन नहीं है कि दोष किसका है, सबसे अधिक संभावना है कि गुटेनबर्ग और योस्ट दोनों (जो मैं समझता हूं कि योआस्ट कैसे काम करता है, इस पर संपादक की हर सामग्री में खुद को हुक करना पड़ता है), हालांकि, अधिक प्लगइन्स गुटेनबर्ग से बाहर निकलना शुरू हो जाते हैं। , चीजें केवल बदतर हो सकती हैं।

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

जैसा कि https://noithub.com/WordPress/gutenberg/issues/11782#issuecomment -445691324 में डाउनलोड ( प्रत्यक्ष डाउनलोड ) के लिए उपलब्ध हैं ।

Yoast के बारे में विशेष रूप से, इसमें # 12161 और # 12741 (# 12186) भी शामिल हैं, जो @wordpress/annotations पैकेज के लिए एक महत्वपूर्ण प्रदर्शन गिरावट को संबोधित करता है जो वर्तमान में स्टॉक इंस्टॉलेशन में उपयोग नहीं किया जाता है, लेकिन अपनी पठनीयता के लिए Yoast द्वारा लीवरेज किया गया है विश्लेषण।

मैंने सिर्फ रिलीज़ उम्मीदवार को स्थापित किया। जिस हद तक यह प्रदर्शन में सुधार करता है, वह संभवतः ओवरस्टैट नहीं किया जा सकता है। मैंने वास्तव में नहीं सोचा था कि इस तरह का सुधार आगामी होगा। मैं और भी अधिक अविश्वास में हूं कि इन सुधारों के लिए अंतिम रिलीज को स्थगित नहीं किया गया था, लेकिन मैं भी अत्यधिक राहत की स्थिति में हूं कि मैं दोषों को मौलिक और अक्षम्य होने के बारे में गलत था।

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

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

मैं इसकी पुष्टि नहीं कर सकता। दोनों मेरे साथ, और फ्लोरिनब्रिंकमैन की

Neww RC 4.7 RC-1 के साथ टेस्ट करें। कृपया इसे देखें: http://recordit.co/k5qszezoFQ

मुझे इस विषय पर इतनी चिंता है कि मैंने अब और परीक्षण किए हैं। मैं वास्तव में जीबी को अनुकूलित करने में मदद करना चाहता हूं और इसलिए अपने परीक्षण प्रकाशित करना चाहता हूं:

पहले मैंने पूरी तरह से नए WP 5.0 संस्करण + 4.7.0-आरसी -1 का परीक्षण किया।

• मेरी सामग्री के साथ परिणाम: बहुत अच्छा। तो फिर से लिखना मजेदार है!
• फ्लोरियनब्रिंकमैन की सामग्री के साथ परिणाम: ब्लॉकों में परिवर्तित होने से अनंत काल होता है।
• ब्लॉक के अंदर माउस के साथ बदलना: एक आपदा।
• बैकएंड जम गया है। आप बिल्कुल नहीं लिख सकते।

फिर मैंने एक मौजूदा WP 5.0 संस्करण + 4.7.0-आरसी -1 + 27 प्लगइन्स का परीक्षण किया।

• मेरी सामग्री के साथ परिणाम: कीस्ट्रोक प्रति 5-10 सेकंड देरी। लिखना बेहद अप्रिय है।
• फ्लोरियनब्रिंकमैन की सामग्री के साथ परिणाम: ब्लॉकों में परिवर्तित होने से अनंत काल होता है।
• ब्लॉक के अंदर माउस के साथ बदलना: एक आपदा।
• बैकएंड जम गया है। आप बिल्कुल नहीं लिख सकते।

यहाँ तक मेरे लिए यह सवाल उठता है: मैं एक ताजा इंस्टॉलेशन के साथ बहुत अच्छी तरह से क्यों लिख सकता हूं, लेकिन अपनी संलग्न वेबसाइट के साथ नहीं। तो यह प्लगइन्स होना चाहिए।

मैंने एक के बाद एक प्लगइन निष्क्रिय किए। मेरा परिणाम: wpSEO समस्या है।
_Setup: WP 5.0 संस्करण + 4.7.0-rc-1 + 26 सक्रिय प्लगइन + wpSEO निष्क्रिय ।_

लेकिन: यदि मैं एक नया WP 5.0 संस्करण + 4.7.0-rc-1 + wpSEO स्थापित करता हूं, तो यह फिर से काम करता है और मैं सामान्य रूप से लिख सकता हूं। और मैं अपनी सीमा में आता हूं: यह कैसे हो सकता है?

अगर मैं ताजा स्थापना के दौरान wpSEO को छोड़कर सब कुछ सक्रिय करता हूं: अद्भुत। समस्या wpSEO है।
अगर मैं केवल एक ताज़ा WP 5.0 संस्करण + 4.7.0-rc-1 + wpSEO सक्रिय करता हूँ: अद्भुत

लब्बोलुआब यह है: एसईओ प्लगइन्स खराब प्रदर्शन के लिए जिम्मेदार हैं। लेकिन हमेशा भी नहीं। मैं SEO फ्रेमवर्क और YOAST जैसे अन्य एसईओ प्लगइन्स का परीक्षण और रिपोर्ट करूंगा। GB के पास अभी भी प्रदर्शन के साथ समस्या है, विशेष रूप से florianbrinkmann की सामग्री के साथ।

_edit: SEO फ्रेमवर्क ठीक काम करता है! यहां तक ​​कि इस सेटअप के साथ: WP 5.0 संस्करण + 4.7.0-आरसी -1 + 26 सक्रिय प्लगइन + एसईओ फ्रेमवर्क। जिससे wpSEO को निष्क्रिय किया जाना चाहिए ।_

अच्छा निदान @SchneiderSam । मैं यह कहने के लिए इतनी दूर नहीं जाऊंगा कि यह व्यापक रूप से एसईओ प्लगइन्स को प्रभावित करता है; यह संभवतः Gutenberg के साथ एक प्लगइन के विशिष्ट एकीकरण के लिए अधिक बारीक है। एसईओ प्लगइन्स "एनोटेशन" मॉड्यूल का लाभ उठाने के लिए अधिक इच्छुक हो सकता है, लेकिन चूंकि यह मोटे तौर पर 4.7.0 तक सुधार किया जाना चाहिए, यह कुछ और हो सकता है अगर यह अभी भी समस्याग्रस्त है जब रिलीज उम्मीदवार के साथ परीक्षण किया गया।

दुर्भाग्य से, wpSEO अपने कोड (कम से कम अपने जावास्क्रिप्ट) को स्वतंत्र रूप से आगे की जांच के लिए उपलब्ध नहीं कराता है। उन्होंने कहा, उनके छोटे कोड में, मैंने इस समस्याग्रस्त कोड को स्पॉट किया:

wp.data.subscribe(function(){var a={postContent:wp.data.select("core/editor").getEditedPostContent()};wpseo_inspect(a)})

यह बहुत गैर-निष्पादित होने की संभावना है कि यह प्रत्येक ब्लॉक को संपादक में होने वाले किसी भी परिवर्तन पर अपने सहेजे गए परिणाम की गणना करने के लिए मजबूर करेगा। उनके लिए (ए) ब्लॉक ऑब्जेक्ट्स पर खुद को संचालित करना बेहतर होगा और (बी) केवल अगर ब्लॉक वास्तव में बदलते हैं। मैं इस मुद्दे पर उन्हें निर्देश देने वाली उनकी वेबसाइट के माध्यम से समर्थन अनुरोध प्रस्तुत करने के लिए एक नोट करूँगा।

_ संपादित करें (2018-12-12): उनके समर्थक लोगों ने एक नोट के साथ जवाब दिया है कि प्लगइन का एक नया संस्करण जल्द ही बनाने की योजना है।

4.7 एक महान सुधार है - लेकिन मुझे यह मुद्दा खुला रहना पसंद है क्योंकि मुझे अभी भी लगता है कि यह क्लासिक संपादक का 1: 1 नहीं है।

अच्छा कार्य! यह मूल रूप से अनुपयोगी से बहुत संवेदनशील हो गया।

@SchneiderSam यदि एक एसईओ प्लगइन संपादन अनुभव को धीमा कर देता है, तो यह इसलिए है क्योंकि कुछ अंतर्निहित मुद्दे हैं, जो सौभाग्य से पहले से ही स्कूप हैं। 4.7 वास्तव में पहले से ही प्रदर्शन में एक महान सुधार है।

फिर से फ्लावरव्हील के साथ वर्डप्रेस 5.0.1 और गुटेनबर्ग 4.7 के साथ फ्लोरियन ब्रिंकमैन लेख का परीक्षण किया। कोई प्लगइन्स नहीं एक तरफ स्थापित कुछ भी नहीं। बस एक ताजा कंटेनर निकाल दिया और सफारी 12.0.2 में लेख को लोड करने की कोशिश की

सफेद स्क्रीन: 41 सेकंड लेख लोड हो रहा है
एफओआईटी: 0 सेकंड (नॉटो का उपयोग नहीं किया गया था जो इस कारण हो सकता है कि कोई फिट नहीं है)

स्क्रॉलिंग धीमी है और टाइपिंग में अभी भी अंतराल है। मुद्दा कहीं भी नियत नहीं है। फिर भी प्रयोग करने योग्य उत्पाद नहीं। और मुझे संपादक को अब बंद करना है, क्यूज मेरे कान उस शोर से प्राप्त कर रहे हैं जो नोटबुक प्रशंसक बना रहे हैं जो पोस्ट लोड होने के बाद पूरी गति से तेजी से चल रहे हैं।

अपडेट करें:
मुझे परीक्षा फिर से देनी पड़ी। मैंने देखा कि मैं अपने भक्तों को यह ध्यान रखना भूल गया कि कोई कैश का उपयोग नहीं किया जा रहा है। अब परिणाम पिछले परीक्षण की तुलना में खराब हैं और एफओआईटी वापस आ गया है।

सफेद स्क्रीन: 86 सेकंड लेख लोड हो रहा है
FOIT: 59 सेकंड

संपादित करें (2018-12-12): उनके समर्थन के लोगों ने ध्यान दिया है कि प्लगइन के एक नए संस्करण को जल्द ही जारी करने की योजना है।

तो wpSEO 4.5.3 सिर्फ जीबी 4.7 (मेरी सामग्री) के साथ परीक्षण किया गया: बहुत तेजी से सोओ। ऐसा ही होना है। आप सभी को बहुत - बहुत धन्यवाद!

अब प्रसिद्ध "द फ्लोरियन ब्रिंकमैन लेख" का भी परीक्षण किया। लोडिंग समय के 15 सेकंड के बाद दिया। किसी भी संपादक को 5 सेकंड से अधिक नहीं लोड करना चाहिए? अधिक लोड समय?
यह एक संपादन अनुभव के लिए व्यवहार्य नहीं है!
एफएफ 64, उबंटू

मैं इस समस्या को उन लेखों के साथ भी अनुभव कर रहा हूं जो 2,000 से अधिक शब्दों या उससे अधिक लंबे समय तक, मेरी मैकबुक पर Mojave के साथ दोनों स्थानीय संस्थापनों पर परीक्षण करते हुए शुरू में कई महीनों पहले Gutenberg प्लगइन के साथ अपना परीक्षण शुरू कर रहे हैं और फिर हाल ही में WP 5.0 पर चलने वाली साइटों पर ये पिछले कुछ दिनों से हैं। 1।

यहाँ कुछ खास बातें हैं जो मैं नोटिस करता हूँ जब यह पिछड़ने लगता है:
टाइपिंग में कम से कम 5-7 कीस्ट्रोक्स की देरी होती है
पोस्ट के ऊपर से संपादक के नीचे तक स्क्रॉल करने का प्रयास करना दर्दनाक है
नए ब्लॉक जोड़ने का प्रयास करते समय देरी होती है
पैराग्राफ़ फॉर्मेटिंग को किसी सूची या शीर्षक में बदलने का प्रयास करते समय देरी होती है
पोस्ट को सहेजना और बाहर निकालना अंतराल समय को ठीक नहीं करता है - यह पोस्ट स्क्रीन से पुनः लोड करने के लिए पोस्ट के लिए काफी अधिक समय लेता है।

मेरा वर्तमान सिद्धांत संपादक में बिताया गया अधिक समय, पोस्ट का आकार जितना बड़ा है, और पोस्ट की उच्च संख्या इसे प्राप्त करने वाले धीमे को संशोधित करती है।

मुझे यकीन नहीं है कि यह एक सटीक सिद्धांत है, लेकिन मेरे परीक्षण में मुझे पता चला है कि यदि आप शीर्षकों, लिंक, सूचियों आदि के साथ मार्कडाउन में पाठ के 7,000 शब्दों को कॉपी / पेस्ट करते हैं, तो आप बिना किसी समस्या के सहेज सकते हैं और प्रकाशित कर सकते हैं। । क्रोम की तुलना में सफारी काफ़ी तेज़ है, लेकिन दोनों अक्सर काम करने योग्य हैं।

हालाँकि, एक बार जब आप अपना लेख पेस्ट कर लेते हैं और फिर संपादक स्वरूप पाठ या फ़ोटो में 20 मिनट से अधिक समय बिताते हैं, तो आप चीजों को अधिक से अधिक धीमा देखना शुरू कर देंगे।

यह समस्या और भी बदतर हो जाती है अगर आपको अन्य व्याकुलताएं होती हैं जो आपका ध्यान संपादक से दूर ले जाती हैं, जैसे कि बच्चे, माता-पिता, पालतू जानवर, गृहिणी, एक फोन, त्वरित संदेश, एक पति या पत्नी, या जब "ऐसा होगा। बस एक मिनट ले "अनुसंधान या एक स्टॉक फोटो के लिए खोज सिर्फ एक मिनट से अधिक समय लगता है।

मैंने देखा है कि धीमे अंतराल के समय और स्वचालित पोस्ट संशोधनों की संख्या / आवृत्ति के बीच एक संबंध हो सकता है। यह # rel५०२ में चर्चा किए गए ऑटोसैव संशोधन से संबंधित हो सकता है।

संपादक विंडो के खुले होने के लगभग 20 मिनट के भीतर, मेरे पास 7 पोस्ट रिवीजन हैं और मेरा 7,000 शब्द का लेख बहुत ही धीमी गति से आगे बढ़ने और संपादित करने के लिए धीमा हो गया है। संशोधनों को मैन्युअल रूप से साफ़ करने और क्रोम / सफारी को पुनः आरंभ करने के बाद मैं फिर से संपादित और काम करने में सक्षम हूं - लेकिन सीमित समय के लिए इससे पहले कि यह एक बार फिर से शुरू हो जाए और अधिक स्वचालित पोस्ट संशोधन हो।

मैं संशोधन सेटिंग्स को समायोजित करने के लिए wp-config संपादन का प्रयास करने जा रहा हूं और परीक्षण कर रहा हूं कि यह देखने के लिए कि क्या कम से कम अब उन साइटों पर वर्कअराउंड प्रदान करेगा जो लाइव हैं और WP 5.0.1 चला रहे हैं। अगर कुछ और है जो मैं परीक्षण कर सकता हूं या कृपया जानकारी प्रदान कर सकता हूं तो कृपया मुझे बताएं कि मैं उस जानकारी या परीक्षण पर प्रतिक्रिया दे सकता हूं जो उपयोगी हो सकती है।

इस पिछले वर्डकैम्प यूएस के योगदानकर्ता दिवस पर एक अनौपचारिक चर्चा हुई थी, जो कि आपको @chellestein का अनुभव करने से संबंधित हो सकती है, विशेष रूप से कि कैसे गुटेनबर्ग पूर्ववत् / Redo इतिहास को स्नैपशॉट के एक संचित सेट के रूप में प्रबंधित करता है।

# 415 में मूल कार्यान्वयन इतिहास में ट्रैक की गई प्रविष्टियों की संख्या पर एक सीमा सहित पता लगाया गया था, लेकिन इसे बाद में हटा दिया गया। वर्तमान में, संपादक एक संपादक सत्र में आपके परिवर्तनों की संपूर्णता को याद रखेगा। मुझे लगता है कि इसे किसी भी तरह से तर्क दिया जा सकता है, लेकिन असीमित पूर्व इतिहास को प्राप्त करने के लिए कुछ वैधता है। एक शब्द संसाधक या IDE में खुद के लिए बोलना, मेरे लिए Cmd + Z को पकड़ना और पहले से मौजूद सैकड़ों इतिहास प्रविष्टियों को फिर से बहाल करना असामान्य नहीं है।

वर्डकैंप यूएस में विशिष्ट चर्चा इस बिंदु पर थी कि क्या संचयित स्नैपशॉट ब्राउज़र में बहुत अधिक मेमोरी पर कब्जा करके प्रदर्शन में बाधा डाल सकते हैं। चर्चा कुछ उम्मीद पर निष्कर्ष निकाला गया था कि एक ब्राउज़र इंजन का आंतरिक कार्यान्वयन अपरिवर्तनीय मूल्यों (ब्लॉकों) की स्मृति आवंटन का पुन: उपयोग करेगा, जहां प्रत्येक इतिहास प्रविष्टि बड़े पैमाने पर स्मृति में एकल साझा ऑब्जेक्ट के लिए सूचक के रूप में काम करेगी।

यह सच हो सकता है या नहीं भी हो सकता है, और आपके अनुभव इसे अभी भी समस्याग्रस्त होने का उपाख्यान मान सकते हैं (इसे _is_ Undo / Redo इतिहास प्रदर्शन में गिरावट का कारण बनता है)। मुझे लगता है कि यह एक नज़दीकी नज़र के लायक है, और शायद एक पुनर्विचार के समानांतर कि कैसे इतिहास को सामान्य रूप से एक अधिक कुशल कार्यान्वयन की तरह प्रबंधित किया जाता है (जैसे कि एक अंतर पर आधारित, पूर्ववत स्तरों की बारीकता को ट्विक करना)। और, ज़ाहिर है, यह ध्यान रखना महत्वपूर्ण है कि यह समग्र प्रदर्शन के बड़े विषय का केवल एक हिस्सा है।

इस बीच, जबकि यह निश्चित रूप से एक आदर्श उपयोगकर्ता वर्कफ़्लो नहीं है, आप पा सकते हैं कि पृष्ठ को हर बार पुनः लोड करने से अक्सर मदद मिलेगी।

संकीर्ण करने का एक तरीका है कि क्या "संशोधनों की संख्या" एक कारक है कि क्या संपादक के भार के बाद कई संशोधनों के साथ एक पद तुरंत गैर-निष्पादित है। मुझे संदेह है कि यह संपादक के प्रदर्शन में अधिक भूमिका नहीं निभा सकता है।

ब्राउज़र स्मृति सीमाओं निश्चित रूप से एक संभव योगदान कारक @aduth हो सकता है, खासकर जब आप कई लोगों के हैं, जबकि वर्डप्रेस में काम कर एकाधिक ब्राउज़र टैब खोलने के लिए और अन्य साइटों को खोलने के लिए हो सकता है। यह भी समझा सकता है कि "परीक्षण मोड" में मुझे जो दिखाई देता है, वह तब क्यों होता है जब मैं वास्तव में लाइव साइटों पर प्रकाशित करने की कोशिश करता हूं, जहां वर्कफ़्लो निश्चित रूप से भिन्न होता है।

मुझे यकीन नहीं है कि अगर यह मदद करता है, लेकिन एक चीज है जो मैंने अपने ब्लॉग पर बहुत लंबे पोस्ट पर काम करते समय देखी। यह mySQL को दुर्घटनाग्रस्त करता रहा इसलिए मैंने अपने VPS में लॉग इन किया (यह DO पर सबसे छोटा है) और top ।

मैंने देखा कि जब भी मैंने पोस्ट को संपादित किया, उसने एक साथ कई बड़ी संख्या में php प्रक्रियाएँ खोलीं, जिन पर मुझे संदेह था कि शायद mySQL मारी जाए।

मैंने Mojave में क्रोम और फ़ायरफ़ॉक्स दोनों में इसका परीक्षण किया है। मेरा सर्वर Ubuntu 7.0 के साथ 16.04 रन करता है - मैंने इसे php7.1 और 7.2 के साथ समान मुद्दों पर परीक्षण किया है।

एक मुद्दा मैंने देखा है कि विशेष रूप से बड़े पदों के साथ, पृष्ठ लोड के साथ पोस्ट डेटा का बूटस्ट्रैपिंग एक अड़चन बन जाता है, खासकर जब एक पोस्ट के "रेंडर" और "कच्चे" सामग्री विविधताओं के बीच क्लाइंट को भेजे गए डेटा की अतिरेक पर विचार किया जाता है ( ये REST API के माध्यम से प्रदान किए गए डिफ़ॉल्ट फ़ील्ड हैं)।

जब ब्लॉक एडिटर लोड होता है, तो बहुत से REST API एंडपॉइंट्स सर्वर-साइड चलाए जाते हैं, और उनके परिणाम Gutenberg को प्रदान किए जाते हैं। इसमें पोस्ट डेटा शामिल है:

https://github.com/WordPress/gutenberg/blob/6d5a5374a0d2c42e18f113a5c056d4cfa1481290/lib/client-assets.php#L1085

यह वास्तव में _improve_ को लोड किए गए अनुभव को प्रदर्शित किए जा रहे पृष्ठ और संपादित की जा रही सामग्री के बीच देरी से बचने के लिए अभिप्रेत है।

हालांकि, एक बड़े पद के लिए, पोस्ट समापन बिंदु परिणाम महत्वपूर्ण है। इसके अलावा, गुटेनबर्ग वास्तव में content.raw मूल्य को मानते हैं, न कि rendered परिणाम को, जो समस्याग्रस्त है क्योंकि:

1. हम बेकार में पर्याप्त सामग्री स्ट्रिंग पर the_content फ़िल्टर चला रहे हैं
2. हस्तांतरित अतिरिक्त बाइट्स सर्वर से विलंबित लोड और पेज मार्कअप की ब्राउज़र पार्स व्याख्या में योगदान करते हैं

इसे देखते हुए, यह विकल्प तलाशने लायक हो सकता है:

• REST API कंट्रोलर को कुछ क्वेरी पैरामीटर द्वारा raw और rendered वैकल्पिक रूप से छोड़ने की अनुमति देने के लिए बढ़ाया जा सकता है?
  
  
  
  • _fields फ़िल्टरिंग के समान, लेकिन नेस्टेड content संपत्ति पर
  
  
  • गुटेनबर्ग तब केवल raw का उपयोग करने के अपने इरादे को स्पष्ट रूप से बता सकते थे
  
  
• क्या गुटेनबर्ग को पद छोड़ने से बचना चाहिए?
  
  
  
  • यह मेरे लिए स्पष्ट नहीं है कि क्या इसका कोई प्रभाव पड़ेगा। यह नकारात्मक हो सकता है, वास्तव में। इसके विपरीत, यह डैशबोर्ड के तेज़-से-पहले-पेंट के लिए अनुमति दे सकता है, कम से कम एक बेहतर कथित प्रदर्शन दे रहा है, भले ही वास्तव में पोस्ट लोड होना बाकी है।
  
  
• क्या गुटेनबर्ग को एक कस्टम ऑब्जेक्ट शेप के साथ बूटस्ट्रैप करना चाहिए जो स्पष्ट रूप से content ड्यूल नेस्टेड गुणों से बचा जाता है?
  
  
  
  • यह या तो असंगतता को जोड़ने में नकारात्मक प्रभाव डाल सकता है कि पोस्ट कैसे संदर्भित किया जाता है, या अतिरेक यदि गुटेनबर्ग / अन्य प्लगइन अलग से REST एपीआई से पोस्ट इकाई का अनुरोध करता है।
  
  

संपादित करें: संबंधित # कोर-रेस्टापी सुस्त चर्चा ( लिंक के लिए पंजीकरण की आवश्यकता है )

नेस्टेड फ़ील्ड्स को निर्दिष्ट करने के लिए _fields आसपास पिछली चर्चा थी, कोर ट्रेक टिकट parent.child dot syntax प्रस्तावित किया, @danielbachhuber ने parent[child] सुझाव दिया, JMESPath का संबंधित प्लगइन उपयोग के आधार पर कुछ कर्षण था। हम उस टिकट पर इस चर्चा के उस हिस्से को जारी रख सकते हैं, हम जहाँ भी हम कर सकते हैं, हमें सामग्री पार्सिंग पर सहेजते हुए देखना अच्छा लगेगा!

यहां अपडेट, 4.9 प्रदर्शन के मामले में एक महान रिलीज थी। लंबे पदों के लिए मुख्य मुद्दे अब तय हो गए हैं। अभी भी कुछ सुधार हैं जो यहां और वहां किए जा सकते हैं लेकिन मुझे लगता है कि हमें जल्द ही इस मुद्दे को बंद करना चाहिए।

क्या आपने कुख्यात "द फ्लोरियन ब्रिंकमैन लेख" की कोशिश की है। परीक्षण के लिए?

मेरे द्वारा लिखे गए ग्रंथ (1000-2000 शब्द) अब काफी अच्छे से संपादित किए जा सकते हैं। बहुत धन्यवाद और एक महान काम! डेवलपर्स के लिए धन्यवाद!

अभी भी प्रदर्शन की समस्याएं हैं जब मैं लंबे ग्रंथों को ब्लॉकों में प्रारूपित करता हूं या यदि मैं ब्लॉकों को आगे और पीछे ले जाता हूं, लेकिन इस मुद्दे की समस्या हल हो गई है। पुनः आपका बहुत - बहुत धन्यवाद!

_Me_ से कोई भी इस समस्या को बंद कर सकता है।

@wpaustria हाँ, मेरे लिए सब अच्छा है।

रूहिग, बहादुर!
फिर भी कुछ काम नहीं आया! लगभग असीमित प्रदर्शन VPS पर Brandnew देव इंस्टा।
सीएमडी + सी और सीएमडी + वी के साथ पाठ की प्रतिलिपि बनाने की कोशिश की और संदर्भ मेनू के साथ अतिरिक्त।
काम कुछ भी नहीं!

मेरे पेंचकस पर एक नजर:
https://youtu.be/lttL0TxPFbU

मैंने इंतजार करना छोड़ दिया। अब यह 10 मिनट हो गया है क्योंकि मैंने स्क्रैंकास्ट बनाया है और कुछ भी नहीं दिखाई देता है। "द फ्लोरियन ब्रिंकमैन लेख" से कोई सामग्री नहीं दिखाई गई है।

विभिन्न ब्राउज़रों में मेरे लिए बहुत अच्छा काम करता है, आपके पास एक मुद्दा कहीं होना चाहिए, एक प्लगइन या कुछ और।

हाँ! 4 यकीन है कि यह मेरा देव इंस्टा होना चाहिए ...

परीक्षण प्रणाली € 100 VPS है, इंस्टा ब्रैंडन्यू है।
अब मैंने सभी प्लगइन्स को निष्क्रिय कर दिया है - जैसा कि आप मेरे द्वारा बनाए गए स्क्रीन कास्ट के वीडियो से देख सकते हैं

https://youtu.be/HwFnG77QOvk

फिर भी कुछ काम नहीं आता ।।
यकीन है कि यह मेरी गलती है।

मुझे खेद है कि यह आपके लिए काम नहीं करता है। मैं यह नहीं कह रहा कि यह आपकी गलती है, मैं सिर्फ यह जानने की कोशिश कर रहा हूं कि क्या गलत है। अगर आप चाहते हैं कि मैं यह दर्शाने के लिए एक पेंचकस रिकॉर्ड करूं कि यह मेरे लिए काम करता है, तो मैं कर सकता हूं।

यदि कुछ भी नहीं दिखता है, तो शायद एक जेएस त्रुटि कहीं है, जो ब्राउज़र आप उपयोग कर रहे हैं?

हौसले से स्थापित (*) एफएफ 64 सक्षम उबॉक मूल के साथ।
यहां कुछ भी नहीं फैंसी।

(*) कारण है कि मैंने खुद को एक नया लैपटॉप खरीदा है - और मैं इसे गर्मजोशी से सुझा सकता हूं - यह एसर स्विफ्ट 5 एसएफ 515 - डीडी;

@wpaustria आपको लगता है कि नवीनतम संस्करण का परीक्षण करने के लिए गुटेनबर्ग प्लगइन को स्थापित करने और सक्रिय करने की आवश्यकता है।

मैंने सिर्फ गुटेनबर्ग 4.9 के साथ अपने लेख का परीक्षण किया और यह अब बहुत बेहतर है (अभी भी एक छोटी सी देरी है (लेकिन एक प्रकार की देरी से दूर है जिसे सेकंड में मापा जा सकता है), और एक क्लासिक ब्लॉक से एकल ब्लॉकों में परिवर्तित होने में अभी भी कुछ समय लगता है और फ़ायरफ़ॉक्स पूछता है कि क्या पेज को रोका जाना चाहिए)।

मुझे लगता है कि मुझे यह मुद्दा मिल गया है।

TypeError: Node.removeChild का तर्क 1 कोई वस्तु नहीं है।

क्या यह आपको कंसोल पर दिखाई देता है? मुझे लगता है कि वहाँ शायद एक जावास्क्रिप्ट त्रुटि कहीं पूरी तरह से चिपकाने को अवरुद्ध है, लेकिन प्रदर्शन से संबंधित कुछ भी नहीं है। चलो इसके लिए एक अलग मुद्दा खोलें।

इसे नए सिरे से स्थापित क्रोमियम पर आज़माया गया:

https://youtu.be/gTMHEAs68Mc

और @florianbrinkmann के प्रस्ताव पर विचार करते हुए, मैंने Gutenberg प्लगइन स्थापित किया और पुनः प्रयास किया।
उस प्रयास पर एक नज़र डालें जो पाठ की नकल करने के लिए नेतृत्व नहीं करता है:

https://youtu.be/W-X6hPB4OfY

एक जेएस समस्या है जैसा कि आप कंसोल में देख सकते हैं ...

@Wpaustria परीक्षणों के लिए धन्यवाद, पेस्ट करते समय मेरे पास एक ही त्रुटि है। यदि आप प्रदर्शन का प्रयास करना चाहते हैं, तो आप html संपादक को चिपकाने और फिर ब्लॉकों में परिवर्तित करने का प्रयास कर सकते हैं।

मैं इसे अभी के लिए बंद कर रहा हूँ।

यहाँ जे एस बग मुद्दा https://github.com/WordPress/gutenberg/issues/13527 है

@youknowriad किस संस्करण या बिल्ड नंबर के साथ आप इस मुद्दे को तय मानते हैं? मैंने उस मुद्दे को देखने के बाद फिर से कोशिश की है जिसे नवीनतम प्लगइन संस्करण 4.9.0 के साथ तय माना गया है और फ्लोरियन ब्रिंकमैन लेख के साथ सेवानिवृत्त हुआ है। 40 सेकंड की सफेद स्क्रीन और एक और 64 सेकंड की फ़ॉइलव्हील द्वारा लोकल टेस्ट इंस्टाल के साथ एफओआईटी। अभी भी प्रारंभिक लोड imho के लिए तय से कहीं भी पास है। टाइपिंग परफॉर्मेंस कम से कम स्टालिंग और फ्रीजिंग नहीं है, लेकिन रियल टाइम टाइपिंग के अनुभव से बहुत दूर है। धीमी गति से चलती है।

@youknowriad क्या आपने 18 दिन पहले मेरा प्रश्न देखा है ?!

मैंने फिर से परीक्षण करने की कोशिश की, मुझे लगता है कि शुरुआती लोडिंग समय में अभी भी सुधार करने की आवश्यकता है, मैं सहमत हूं। मुझे अभी भी लगता है कि बड़े प्रदर्शन के मुद्दे तय हैं। प्रदर्शन पर काम नहीं रुक रहा है।

तो क्या आपके कंप्यूटर पर फ्लोरिअन ब्रिंकमैन के लेख के साथ आपके लोडिंग समय हैं? और फ्लोरीन ब्रिंकमैन लेख के साथ टिनिअम के साथ लोडिंग समय के साथ गुटेनबर्ग एन बराबर के साथ लोडिंग बार हैं? तब मैं लोडिंग के समय को तय मानूंगा। लेकिन मेरी तरफ से मैं अभी भी 40 सेकंड सफेद स्क्रीन और 64 सेकंड के बारे में कहा है कि अगर मुझे सही ढंग से याद है, तो टिनिम्स के साथ लगभग 12 सेकंड की तुलना में गुटेनबर्ग के साथ फुसफुसाए।

मेरे लिए लोडिंग समय गुटेनबर्ग के लिए 15 सेकंड और क्लासिक संपादक के लिए 6 सेकंड हैं।

लेकिन अभी भी TinyMCE की तुलना में 2,5 गुना धीमा है। लेकिन अधिक चिंता का विषय यह है कि आपके लोडिंग का समय 15 सेकंड के साथ है मेरी तुलना में 104 सेकंड (btw क्या आपने कैश को आगे बढ़ाया है?)। मुझे नहीं पता कि आप किस कंप्यूटर और स्थानीय सेटअप का उपयोग कर रहे हैं, लेकिन मेरे परीक्षण MBP 13 "जल्दी 2011 में चलाए गए थे, जिसमें फ्लाईव्हील से 8 जीबी रैम स्थानीय पर चल रहा था। मुझे लगता है कि कंप्यूटर और डिवाइस को भी काम करते समय ध्यान में रखा जाना चाहिए। लोडिंग समय और प्रदर्शन के साथ। इसलिए मैं मानता हूं कि प्रदर्शन पर काम कभी नहीं रुकता है, लेकिन प्रदर्शन के लिए बेंचमार्क पुराने कम शक्तिशाली कंप्यूटर और नवीनतम नवीनतम शक्तिशाली डिवाइस नहीं होना चाहिए। मैं टिकट पर विचार करूंगा और बाद में सुधार और पुनरावृत्ति के लिए तैयार हूं। जैसा कि गुटेनबर्ग पुराने कम शक्तिशाली मशीनों और उपकरण पर लोड करने के समय के साथ सम्‍मिलित हैं, क्योंकि पुराने कम शक्तिशाली मशीनों और उपकरणों पर फ्लोरिअन ब्रिंकमैन ने कैश के साथ साफ किया था।

@youknowriad ok अभी 5.1 के साथ

गुटेनबर्ग के साथ:
59,2 दूसरी सफेद स्क्रीन
78 सेकंड एफओआईटी
कुल मिलाकर 137,2 सेकंड

स्थापित क्लासिक संपादक 1.4 बाद में (फिर से साफ किया कैश फिर से)
कुल मिलाकर 11,78 सेकंड लोडिंग समय

गुटेनबर्ग को अभी भी कम से कम 125,42 सेकेंड की कटौती करने की आवश्यकता है ताकि इस टिकट को निश्चित इम्हो माना जा सके।

@rpkoller क्या आप प्रारंभिक लोडिंग समय के बारे में एक अलग मुद्दा बना सकते हैं, मैं मानता हूं कि अभी भी कुछ काम हैं जो हमें वहां करने चाहिए। यह मुद्दा इस समय योगदानकर्ताओं के लिए बहुत लंबा और कठिन है, इसलिए मुझे लगता है कि एक नया मुद्दा बेहतर है।