Discussioni utente:Krinkle

Contenuti della pagina non supportati in altre lingue.
Da Wikivoyage.

Benvenuto

Ciao Krinkle!

Benvenuta/o su Wikivoyage in lingua italiana! Stiamo realizzando un'attendibile guida turistica mondiale libera e aggiornabile. Aiutaci anche tu! Se hai appena conosciuto Wikivoyage e non sai come funziona e in che modo puoi aiutarci, poni le tue domande nella Lounge, il punto d'incontro dei wikiviaggiatori, oppure consulta le nostre pagine di aiuto.

Potrai trovare risposte ai tuoi dubbi anche nelle pagine delle domande frequenti e dei consigli per i nuovi arrivati.

Ricordati soprattutto che è vietato copiare testi protetti da copyright. Il nostro obiettivo non è proporre contenuti copiati da altri siti, ma scrivere una nuova guida turistica di nostro pugno.


--Andyrom75 (discussioni) 14:27, 28 ott 2019 (CET)[rispondi]

Page loading time[modifica]

Hi Krinkle, sorry for bothering you. Would you mind to check the overall performance of the it.wikivoyage page? The loading time is definitely higher than en.wikivoyage or it.wikipedia and I don't know which improvement I should apply in the pages that I can affect as an admin (e.g. commons, gadgets, etc.). Also any change server side that you can apply would be appreciated. Please let me know, --Andyrom75 (discussioni) 19:19, 16 mar 2020 (CET)[rispondi]

@Andyrom75: Hi. I have made a number of improvements to the JavaScript cost and performance. There is one more thing I recommend that you do, which is to change MediaWiki:Common.css. Right now it imports many pages on the browser side (not server-side). This is relatively slow and inefficient. I recommend to combine the CSS pages into MediaWiki:Common.css for better performance. The MediaWiki:Common.css page gets automatically optimized (and gadget JS too), but the other CSS pages cannot be optimized. --Krinkle (discussioni) 19:35, 19 mar 2020 (CET)[rispondi]
Are you referring to the various "@import url"? In the affirmative case, there's a way to keep the code in separate file to improve the maintainance or I'm force to integrate the whole code inside common.css? --Andyrom75 (discussioni) 00:16, 20 mar 2020 (CET)[rispondi]
@Andyrom75: Yes. For a gadget, the multiple files listed at MediaWiki:Gadgets-definition are combined and optimised together on the server. The @import syntax in CSS is an instruction for the web browser, not for MediaWiki. This instruction does one-by-one and separate unoptimized requests for each extra CSS wiki page. I would recommend never to use that!
I understand keeping it all in one big file is not nice. There is another way: Create a gadget is "default", and "hidden" and "styles-only". That is basically the same as Common.css but with the extra ability that you can separate the files in a way that does not cause slow page loading.
I have converted MediaWiki:Common.css for you as first step. As next steps, I recommend moving the other pages also to a Gadget-sitestyles-*.css title, then remove the @import rule, and instead add the title to sitestyles gadget in MediaWiki:Gadgets-definition. --Krinkle (discussioni) 00:02, 26 mar 2020 (CET)[rispondi]
Could you explain me better why the various gadget will not work for logged-out users with cached HTML? --Andyrom75 (discussioni) 19:54, 26 mar 2020 (CET)[rispondi]
When a page is edited, it is cached for some days. The page is in control of what CSS and JS is loaded. The page is informed by gadgets, and by MW extension which modules should load. For example, if I enable gadget "A" by default. Then from now on, every page that is edited, will include gadget "Foo" in the list of gadgets that load on that page. Pages last edited before now will, for 7 days, not yet load gadget "A". In general for MediaWiki/ResourceLoader, a module or a gadget, should combine anything that is related to the same audience, instead of the same purpose. For example, gadget "site" is all JS code for all users/pages. Gadget "sitestyles" is all CSS code for all users/pages. Once that is enabled and remembered by all pages over 7 days, then you can change what is inside of it any time you want without issue.
To see what I mean, you can view source on any wiki page and look for head … script … RLPAGEMODULES= which is the list of JS modules and gadgets for this page, and link rel=stylesheet … modules= which are lists of CSS modules and gadgets to load on this page. --Krinkle (discussioni) 21:32, 26 mar 2020 (CET)[rispondi]

99th listing patch[modifica]

I've read your comment on MediaWiki:Common.js, but I'm not sure to have understood how I should fix the numbering in a page like Parchi_nazionali_in_Africa. Could you advise? --Andyrom75 (discussioni) 00:53, 20 mar 2020 (CET)[rispondi]

MediaWiki:Mobile.css[modifica]

How should I treat the script inside here and how I can avoid conflict between these ones and the one that we moved from MediaWiki:Common.css into the hidden gadget? --Andyrom75 (discussioni) 17:58, 6 apr 2020 (CEST)[rispondi]

@Andyrom75 You can use skins=vector,monobook in the gadget definition to limit it to desktop skins. The name of the mobile skin is minerva. See also mw:Extension:Gadgets#Options. --Krinkle (discussioni) 21:19, 17 apr 2020 (CEST)[rispondi]
Inside the link you suggested I've found both the parameter skin that you mentioned and the apparently more appropriate parameter targets whose value can be:
  • desktop (default)
  • mobile
  • desktop,mobile.
Which one would you suggest me to use between skin and targets?
Furthermore, in MediaWiki:Mobile.css I've seen that I can centralize:
  • Gadget-QuickbarStyles-common.css
  • Gadget-ContainerEInfoboxStyles-common.css
  • Gadget-TabelleStyles-common.css
These 3 files are currently included in sitestyles where are listed other files dedicated to the desktop version.
Do I have to rename sitestyles into desktopstyles and move those 3 files into a new sitestyles that use the proper skin/targets parameters or there is a more appropriate way to proceed? Let mw know, --Andyrom75 (discussioni) 16:51, 25 apr 2020 (CEST)[rispondi]
If you could find any of your spare time to guide me, I would be very grateful. Thanks, --Andyrom75 (discussioni) 10:23, 11 mag 2020 (CEST)[rispondi]
@Andyrom75 Sorry, I don't think I'll be able to find the time to help you further. Any of these options are a big improvement. Which ever works easiest for you is fine. --Krinkle (discussioni) 18:19, 11 mag 2020 (CEST)[rispondi]

I'm trying to empty all the mw tracking categories but I am a bit surprised with the behavior of the one in the subject.

  1. Erice (disambigua), Baratti
  2. Arquata, Appiano

1 is almost identical to 2, but 1 is included in the category while 2 don't. Why? --Andyrom75 (discussioni) 20:23, 26 mag 2020 (CEST)[rispondi]

LUA performance issue[modifica]

On page I borghi più belli d'Italia I have almost 700 call to LUA modules that interact with around 350 Wikidata entities though 2 templates: {{marker}} and {{getBestImage}}.

Do you see in Modulo:Marker, Modulo:Image or maybe in Modulo:Pagebanner (that is used just once) any expensive code that can be written differently?

In case it's just a matter of the high number of Wikidata interactions there is any work around applicable to this specific page/article?

PS 50% of the times the page is just slow but it's perfectly rendered, but on the other 50% of the times I got LUA error in the bottom of the page.

Thanks advance for sharing your insights, --Andyrom75 (discussioni) 11:21, 3 dic 2021 (CET)[rispondi]


@Andyrom75 I am not an expert in Wikidata nor in optimising Lua code. I made a dummy edit to this page and analysised it with XHGui (see captured profile). Another source of information is the parser performance report which is included in the HTML source when viewing an article:

CPU time usage: 0.140 seconds
Real time usage: 0.201 seconds

100.00%  155.628      1 -total
 49.47%   76.993      1 Template:Quickfooter
 45.78%   71.254      1 Template:Pagebanner
 24.80%   38.591      1 Template:Navbox
  4.59%    7.145      1 Template:Da_aggiornare
  1.78%    2.766      2 Template:MESE2
  1.42%    2.209     27 Template:·

The second column is milliseconds, so in total it took 0.155 seconds (almost 0.2 seconds) to render. That seems reasonably fast. --Krinkle (discussioni) 18:17, 19 gen 2022 (CET)[rispondi]

Thanks for the reply. Now it's fast because without a solution I've divided the content of the article in 3 sub-articles. The original version can be found in Special:permalink/739377. --Andyrom75 (discussioni) 19:22, 19 gen 2022 (CET)[rispondi]