While reading this [1] and observing how other website load large pages without freezing my computer, I was just wondering why progressive loading of items was not an option for Wikidata.
Is it too difficult to implement? Or impossible with mediawiki? Or just undesirable for some other reasons?
Thanks! Micru
[1] docforge.com/wiki/Web_application/Progressive_loading
On Tue, Feb 25, 2014 at 8:55 PM, David Cuenca dacuetu@gmail.com wrote:
While reading this [1] and observing how other website load large pages without freezing my computer, I was just wondering why progressive loading of items was not an option for Wikidata.
Is it too difficult to implement? Or impossible with mediawiki? Or just undesirable for some other reasons?
We've just made a huge improvement like 2 minutes ago ;-) More will follow.
Cheers Lydia
Just noticed about it! Yesterday I took me almost 5min and many "unresposive script errors" to load Russia, now it is under a minute of computer freeze :) https://www.wikidata.org/wiki/Q159
Not optimal but definitely a big leap forward. Great work!
Still curious about progressive loading (at least for big items).
Cheers, Micru
On Tue, Feb 25, 2014 at 8:58 PM, Lydia Pintscher < lydia.pintscher@wikimedia.de> wrote:
On Tue, Feb 25, 2014 at 8:55 PM, David Cuenca dacuetu@gmail.com wrote:
While reading this [1] and observing how other website load large pages without freezing my computer, I was just wondering why progressive
loading
of items was not an option for Wikidata.
Is it too difficult to implement? Or impossible with mediawiki? Or just undesirable for some other reasons?
We've just made a huge improvement like 2 minutes ago ;-) More will follow.
Cheers Lydia
-- Lydia Pintscher - http://about.me/lydia.pintscher Product Manager for Wikidata
Wikimedia Deutschland e.V. Tempelhofer Ufer 23-24 10963 Berlin www.wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Wow, that IS a big difference!
Looking at the network load for Q1339, there is still a four-second period where JavaScript does ... something it doesn't need to do.
But, the site has regained its usefulness! Congrats, honestly!
Cheers, Magnus
On Tue, Feb 25, 2014 at 8:07 PM, David Cuenca dacuetu@gmail.com wrote:
Just noticed about it! Yesterday I took me almost 5min and many "unresposive script errors" to load Russia, now it is under a minute of computer freeze :) https://www.wikidata.org/wiki/Q159
Not optimal but definitely a big leap forward. Great work!
Still curious about progressive loading (at least for big items).
Cheers, Micru
On Tue, Feb 25, 2014 at 8:58 PM, Lydia Pintscher < lydia.pintscher@wikimedia.de> wrote:
On Tue, Feb 25, 2014 at 8:55 PM, David Cuenca dacuetu@gmail.com wrote:
While reading this [1] and observing how other website load large pages without freezing my computer, I was just wondering why progressive
loading
of items was not an option for Wikidata.
Is it too difficult to implement? Or impossible with mediawiki? Or just undesirable for some other reasons?
We've just made a huge improvement like 2 minutes ago ;-) More will follow.
Cheers Lydia
-- Lydia Pintscher - http://about.me/lydia.pintscher Product Manager for Wikidata
Wikimedia Deutschland e.V. Tempelhofer Ufer 23-24 10963 Berlin www.wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
-- Etiamsi omnes, ego non
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
On Tue, Feb 25, 2014 at 9:53 PM, Magnus Manske magnusmanske@googlemail.com wrote:
Wow, that IS a big difference!
Looking at the network load for Q1339, there is still a four-second period where JavaScript does ... something it doesn't need to do.
Yeah there are still some things to work on including loading some of the widgets only when needed. We'll tackle that next.
But, the site has regained its usefulness! Congrats, honestly!
\o/ Thanks!
Cheers Lydia
On Tue, Feb 25, 2014 at 9:07 PM, David Cuenca dacuetu@gmail.com wrote:
Just noticed about it! Yesterday I took me almost 5min and many "unresposive script errors" to load Russia, now it is under a minute of computer freeze :) https://www.wikidata.org/wiki/Q159
Not optimal but definitely a big leap forward. Great work!
Still curious about progressive loading (at least for big items).
We should probably look into the possibility of this. But first there are a few other speed improvements to do first. Once those are done I will shift focus more to the UI redesign, queries and Commons though for a while.
Cheers Lydia
Am 25.02.2014 22:03, schrieb Lydia Pintscher:
On Tue, Feb 25, 2014 at 9:07 PM, David Cuenca dacuetu@gmail.com wrote:
Just noticed about it! Yesterday I took me almost 5min and many "unresposive script errors" to load Russia, now it is under a minute of computer freeze :) https://www.wikidata.org/wiki/Q159
Not optimal but definitely a big leap forward. Great work!
Still curious about progressive loading (at least for big items).
To clarify: the problem is not loading data, but initializing widgets. The browser isn't waiting for the server, it's frantically running in circles trying to get all the JS widgets set up. Which, of course, we should avoid. We are working on it. Sorry for the inconvenience.
-- daniel
On Wed, Feb 26, 2014 at 2:00 PM, Daniel Kinzler <daniel.kinzler@wikimedia.de
wrote:
To clarify: the problem is not loading data, but initializing widgets. The browser isn't waiting for the server, it's frantically running in circles trying to get all the JS widgets set up. Which, of course, we should avoid. We are working on it. Sorry for the inconvenience.
Is there any way to initialize only those widgets visible on the screen?
Micru
Am 27.02.2014 01:30, schrieb David Cuenca:
On Wed, Feb 26, 2014 at 2:00 PM, Daniel Kinzler <daniel.kinzler@wikimedia.de mailto:daniel.kinzler@wikimedia.de> wrote:
To clarify: the problem is not loading data, but initializing widgets. The browser isn't waiting for the server, it's frantically running in circles trying to get all the JS widgets set up. Which, of course, we should avoid. We are working on it. Sorry for the inconvenience.Is there any way to initialize only those widgets visible on the screen?
Tricky, and it would make scrolling horribly annoying.
No, much better not to initialize them at all until they are needed for editing. There's no reason we can't generate the full view as static HTML. We just have to finish implementing that.
-- daniel
Lydia Pintscher, 25/02/2014 22:03:
We should probably look into the possibility of this. But first there are a few other speed improvements to do first. Once those are done I will shift focus more to the UI redesign, queries and Commons though for a while.
Is there a tracking bug to follow for this? Russia is freezing my browser right now so I can't look myself. :p Ah, this seems the closest match: https://bugzilla.wikimedia.org/show_bug.cgi?id=54098
Nemo
On Thu, Feb 27, 2014 at 12:51 AM, Federico Leva (Nemo) nemowiki@gmail.com wrote:
Is there a tracking bug to follow for this? Russia is freezing my browser right now so I can't look myself. :p Ah, this seems the closest match: https://bugzilla.wikimedia.org/show_bug.cgi?id=54098
Yes that's the one.
Cheers Lydia