Caching is done automatically by the browser unless it is prevented for one reason or another. However, I donât understand why it doesnât seem to be cached. Maybe a web developer can chime in here?
not sure what âservice workerâ in the âTransferredâ column means. Usually it should say how many bytes were transferred or âcachedâ if that resource is cached. Anyone know what this means?
Okay, nevermind. I found the documentation for the Transferred column - in a nutshell âservice workerâ means that the caching is handled by a service worker and that no bytes were transferred. The developer tools in Edge are clearer in that it also displays the bytes transferred
In conclusion, it doesnât seem to be a caching issue at all. What is always transferred without cache is the html page itself, but this page for example is just 40kB.
Depending on where you are, that might be the case. In some places that might be enough to make using this site financially impossible.
Separately from that I find that even on a fast mobile broadband connection (31Mbps down) it takes about 5 seconds to load the first page, and 4-5 seconds to load subsequent ones**, following a link from an email. A snappy conversation it is not - if any of the systems I used to work on back in the 80s were that slow on every page load theyâd have been thrown out.
** Firefox, Nokia 6.1, Android 10. On a newer phone (Nokia X10, Android 13) itâs about 3 and 2 seconds respectively. better; but still not great.
While I sympathise with anyone having issues with the caching / download size issues with the website, we are running a fairly standard install of discourse. Any issue will likely need to be fixed upstream.
Modern browsers use the brotli compressed assets. Older browsers use gzip compressed assets. Make sure to use network transferred bytes, rather than uncompressed asset size when using web developer tools.
I have briefly tested using the latest Chrome and Firefox, after an initial large set of JS/CSS etc downloads, the subsequent pages load using less than 100KB of new downloads.
I canât reproduce that though. It takes about 1 second on an Android 11, Firefox, with 1 of 4 bars of 4G connectivity. Which is plausible given that on reload, something like 40kB or so are actually transmitted.
I will agree here. In fact, OSM instance opening random thread even seems to load noticeably faster (2.5s largest contentful paint) then discourse own instance (4.2s largest contentful paint).
Thus I would suggest that people who are having performance issues on community.openstreetmap.orgtry meta.discourse.org too. If that instance is noticeably faster then OSM one, than there are things that can be addressed here. If it is about the same slowness, than any request for performance improvements should be taken with Discourse developers.
This webpagetest.org waterfall graph shows about half the time of that 8 seconds is just javascript pegging up the CPU without any data even attempting to load. You may also wish to test and compare your hardware+browser rendering speed in Speedometer 2.0 (e.g. my laptop gets 112 runs/min in Firefox, 178 in Chromium; P30Pro only 35 in IceCat and 40 in Firefox Klar; and Galaxy S II only manages 7 runs per minute).
Discourse is unfortunately Javascript-based beast, which means that it offloads much of the work to the client, which means the slower the device (read: mobile phones, especially the ones that are not newest top-of-the-line ones) are likely going to suffer.
For example:
on my Huawei P30 Pro, clicking on random no-yet-visited thread on OSM instance on 50Mbps Internet link, takes about 2.2s to fill the screen with data (i.e. largest contentful paint).
on my old Samsung Galaxy S II, using that same Internet link, that same page shows in about 3.8s. (and complains about unsupported browser, likely meaning not all functionality has been loaded. It displays article just fine, though).
Grim statistic offered by Chrome Lighthouse (available via F12 keypress) while it evaluates performance say than almost 70% of mobile pages take almost 7s to load (and then proceed to say how much conversions you are likely to lose because of that).
Itâs the beast part I have trouble with here. Itâs loading and displaying text and a few sporadic images, a thing browsers already do and have done for the last 25 years. Most of the fancy functions donât have to do anything until you click on them. Why must everything get bloated until it feels like dialup?
I wonder how hard it would be to crawl the site or part of it periodically to provide static HTML for a few key areas? A wget of this thread definitely looks like an improvement - relative links to e.g. https://map.atownsend.org.uk/categories obviously donât work on that page but I find the presentation there vastly superior to the presentation here (all the text is there, the only pictures are the ones that matter, no silly boxes asking âhas your question been answeredâ, â2 Likesâ instead of silly symbols, etc.).
Well, me too. Unfortunately, that discussion either:
shouldâve been made before Discourse was implemented as solution for community.osm.org, or
should take place at meta.discourse.org now that we already use Discourse.
Yeah⊠The problem is developers usually have beast of computers, and make programs which work OK-ish on them (which means they work quite bad for most everybody else). My solution was that it should be required by law that any software developer must be forced to use at least 10 year old technology (or older) and be denied access to newer tech. That way that specific problem with bloat would solve itself automagically (although it might induce other tiny problems, like nobody wanting to be a developer )
I wonder how hard it would be to crawl the site or part of it periodically to provide static HTML for a few key areas?
Not too hard I guess, but looking at that example of yours seems to completely break Discourse navigation (which, in any thread with more than dozen messages, is absolutely vital to be able to make sense od Discourse discussion at all, much less participate in it). While who replied to what could be simulated with regular HTML anchors, it would need something little more advanced than wget.
Perhaps additional extra-light Discourse theme (akin to mbasic.facebook.com) would be better suited (have anybody looked if something like that exists?)
(for those wanting that pute wget behaviour, then can have it already by simply disabling javascript for this site, for example with uBlock-origin, NoScript or similar browser add-ons).
For me itâs still struggling on a combination of poor wifi plus poor cellular coverage, but I suspect thatâs a fundamental design issue of the âeverything in Javascriptâ design.
No, seems to be âabout the sameâ. Tapping a link on a phone with good 4G coverage still takes about 5-7 seconds for the page to appear. Same phone as above.
Same here, crawling on desktop browser and it feels like getting slowe as the threads build up over time not to speak of long threads, thankfully thereâs the near invisible to me (white background) short scrollbar to drag the thread down to the last post. Opposed, snappy on mobile phone, model circa 2021 on Android.
Bit of testing, dark theme on Mozilla Firefox with their Gecko engine is substantially faster than Vivaldi which uses the Chrome engine. Short thread scrollbar is much better visible.
Iâll let you in on a secret: one of OSM Americanaâs developers (yours truly) just finally moved on from a more-than-decade-old Mac on its last legs. Me clutching to that computer hasnât done much to keep the application from getting more bogged down and bloated than weâd like. Iâd contend that feedback from mobile phone users serves as a better forcing function anyhow.
)