No more pre-loading of TinyMCE editor please, saves page load

Luxus

Well-known member
*UPDATE*

After I seeing not much enthusiasm towards this suggestion, I suggest this to be added the way, that you can choose in the ACP between a pre-loaded quick reply editor and a not pre-loaded quick reply editor. I'm positive that this would please everyone :)




I figured that the TinyMCE editor in "quick reply mode" has its own share of loading time. Whenever someone with posting permission visits a thread, the TinyMCE editor gets pre-loaded. This process takes some time and can even cause lags. You can't expect every user to post in a thread when visited. Many users are just going to read and then leave.

Users would get a more pleasant reading experience if the TinyMCE editor is only loaded when clicking at it. IPB is doing this and in my opinion XenForo should do this too.

That's how the Editor looks in IPB:
editor.webp

And this is how the Editor looks like after clicking at the empty white field:
editor2.webp

Please show your support for this as everyone would benefit from a better performance.
Cheers
 
Upvote 0
Not a bad idea, but I wonder just how much of a performance increase this would bring. The things that I see causing the most problems are the Social networking links.
 
Not a bad idea, but I wonder just how much of a performance increase this would bring. The things that I see causing the most problems are the Social networking links.
On my local installation I notice a cleary decrease of loading time on closed threads.

Also imagine you have daily 1000 thread clicks from registered users without one of them replying. The smiley sprite sheet is 8KB big, the editor folder is 15kb big. You would save 23000 KB a day, not including javascirpt and custom smilies.
 
On my local installation I notice a cleary decrease of loading time onclosed threads.

Also imagine you have daily 1000 thread clicks from registered users without one of them replying. The smiley sprite sheet is 8KB big, the editor folder is 15kb big. You would save 23000 KB a day, not including javascirpt and custom smilies.
Don't forget that a browser will cache things like the smiley sprite sheet and other images/files. So if a user visits an XF-powered site once, when they return, those items will be already in their browser's cache and will be used instead of retrieving from the server.
 
On my local installation I notice a cleary decrease of loading time onclosed threads.

Also imagine you have daily 1000 thread clicks from registered users without one of them replying. The smiley sprite sheet is 8KB big, the editor folder is 15kb big. You would save 23000 KB a day, not including javascirpt and custom smilies.
The JS is cached though so it's not being loaded every time, it's being loaded once and then retrieved from cache?
 
True, I somehow forgot that images and js can be cached. But still, threads load faster without a quick reply editor or with one disabled.
 
Having the full editor available looks more inviting, draws the eye and attracts people to post.

Without caching enabled it loaded for me in 48ms.

Not going to lose sleep over it!
 
The social networking crap at the bottom of the screen creates a lot more loading problems than TinyMCE. When we convert to our "big board," I plan on disabling most of the calls to external services. On a 12Mbps using a recent computer, load times are pretty much instant on my end. Disable too much and it's back to the archaic days of vbulletin.
 
I consider this suggestion a win-win situation without any disadvantages. It reduces the page load and it enhances the user experience. Small chicken lay eggs too :P
 
I consider this suggestion a win-win situation without any disadvantages. It reduces the page load and it enhances the user experience. Small chicken lay eggs too :p
How does this enhance the UX? Just wondering how you came to that conclusion.
 
I consider this suggestion a win-win situation without any disadvantages. It reduces the page load and it enhances the user experience. Small chicken lay eggs too :p
It does have disadvantages and it doesn't enhance the user experience for the very reasons I already mentioned:

"Having the full editor available looks more inviting, draws the eye and attracts people to post."
 
How does this enhance the UX? Just wondering how you came to that conclusion.
I allready pointed that out. Page load will be reduced for registered users. The loading of threads will be faster and more smooth, hence why the user experience will be enhanced.

It does have disadvantages and it doesn't enhance the user experience for the very reasons I already mentioned:

"Having the full editor available looks more inviting, draws the eye and attracts people to post."
That's simply a subjective opinion that is not true. I am an active member of an IPB board with ~300000 registered users, a user record of ~20000 users online at the same time and over 4 million posts. I can tell from experience that there is no difference in attracting people to post with a pre-loaded editor and a no pre-loaded editor. People will still see the quick reply box and they still need at least one click to write something in this box. The only difference is that a no pre-loaded editor lacks UI buttons, saves page load and a pre-loaded not.
 
I allready pointed that out. Page load will be reduced for registered users. The loading of threads will be faster and more smooth, hence why the user experience will be enhanced.


That's simply a subjective opinion that is not true. I am an active member of an IPB board with ~300000 registered users, a user record of ~20000 users online at the same time and over 4 million posts. I can tell from experience that there is no difference in attracting people to post with a pre-loaded editor and a no pre-loaded editor. People will still see the quick reply box and they still need at least one click to write something in this box. The only difference is that a no pre-loaded editor lacks UI buttons, saves page load and a pre-loaded not.
Removing the pre-load of the editor would have a negative impact on the UX, not a positive one. Just because you're a member on a big board, that doesn't mean you know better than anyone else.

Requiring a click to active the editor would be a UI fail, as it isn't quick, and requires an extra action on the end of the user.
 
Removing the pre-load of the editor would have a negative impact on the UX, not a positive one. Just because you're a member on a big board, that doesn't mean you know better than anyone else
I didn't say that I know better than anyone else. I say that I can tell from my personal experience that there is no difference. Can you or the others tell from your own experience?

Requiring a click to active the editor would be a UI fail, as it isn't quick, and requires an extra action on the end of the user.

How is it a UI fail when there is absolutely no difference in the amount of time a user has to click the quick reply box with a pre-loaded and a no pre-loaded editor? Can you write something in the quick reply box without actually clicking at it once? Also it requires only a second for the editor to be ready after you click it. But you don't have to wait that second. You can always start writing immediately after the click. Do you actually tried the editor of IPB and gained experience to support your claim?
 
I didn't say that I know better than anyone else. I say that I can tell from my personal experience that there is no difference. Can you or the others tell from your own experience?



How is it a UI fail when there is absolutely no difference in the amount of time a user has to click the quick reply box with a pre-loaded and a no pre-loaded editor? Can you write something in the quick reply box without actually clicking at it once? Also it requires only a second for the editor to be ready after you click it. But you don't have to wait that second. You can always start writing immediately after the click. Do you actually tried the editor of IPB and gained experience to support your claim?
Yeah, I'm only a web/graphic designer who's main focus is UI/UX. I'd say I have some experience with UI/UX.

It's the fact that you require an additional event to activate the rich editor. Currently I can just hit the tab key to go straight to the editor, and type immediately in the rich editor. While your suggestion can do the same, the fact is that pre-loading the editor has very little impact on page load time in comparison to the social media widgets, and that pageload really isn't all that high to require changing the pre-loading of the editor.
 
Yeah, I'm only a web/graphic designer who's main focus is UI/UX. I'd say I have some experience with UI/UX.
That was not the question. The question was if you have experience with the current editor of IPB.

It's the fact that you require an additional event to activate the rich editor. Currently I can just hit the tab key to go straight to the editor, and type immediately in the rich editor.
Both a pre-loaded and a no pre-loaded editor require 1 event to be activated. The difference is with a pre-loaded one the event happens automatically once you visit a thread with posting permission, which can be a good thing (for very active posters/supporters that post in almost any thread) and not a good thing (for your ordinary posters). Now do you think sites have generelly more active posters or ordinary posters?

While your suggestion can do the same, the fact is that pre-loading the editor has very little impact on page load time in comparison to the social media widgets, and that pageload really isn't all that high to require changing the pre-loading of the editor.
Besides the fact this suggestion hasn't anything to do with social media widgets, your opinion seems to have changed slightly. First you said making a quick reply editor not pre-load is a UI fail and now you are basically saying there is nothing wrong with making a quick reply editor not pre-load but it isn't worth the work because the performance improvement isn't big enough.
 
I'm agreeing with Forsaken.

Sure we could just not pre-load it but then I have to click the textarea, wait for it to load (there will be a waiting time as it loads up) and then reply. This is unintuitive as it forces the user to wait before posting.

Now, we pre-load it and they can reply quickly.
 
Besides the fact this suggestion hasn't anything to do with social media widgets, your opinion seems to have changed slightly. First you said making a quick reply editor not pre-load is a UI fail and now you are basically saying there is nothing wrong with making a quick reply editor not pre-load but it isn't worth the work because the performance improvement isn't big enough.

Bringing up social media widgets is to point out that they have a bigger impact than the editor, which you ignore every time it is brought up.

My opinion has not changed, the fact of the matter is that there is no benefit to not pre-loading the editor as their isn't much of an impact on pageload (Again, pageload is increased more by the social media widgets than the editor), so there is no need to stop pre-loading the editor.

I'm agreeing with Forsaken.

Sure we could just not pre-load it but then I have to click the textarea, wait for it to load (there will be a waiting time as it loads up) and then reply. This is unintuitive as it forces the user to wait before posting.

Now, we pre-load it and they can reply quickly.

(y).
 
Top Bottom