Timeline for Deprecating our mobile views
Current License: CC BY-SA 4.0
20 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 27, 2021 at 18:58 | comment | added | ruffin | This topic tangentially makes me wonder if the issue is that mobile views have less/different advertisements and SO's trying to have one delivery mechanism. AD ALL THE THINGS!!1! (Would also be nice if the SO iOS app received some love, but not holding my breath.) | |
| Jul 26, 2021 at 17:53 | comment | added | Jonas Czech | And if you don't like mobile Firefox, there are Chromium forks which do enable real extension support on Android. Kiwi Browser is one open-source one, although it's usually a couple of Chromium versions behind. @TylerH | |
| Jul 21, 2021 at 18:25 | comment | added | TylerH | @Mast Yes, I use it sometimes, but there are things/sites that Chrome mobile just handles better, unfortunately. | |
| Jul 21, 2021 at 18:09 | comment | added | Sonic the Anonymous Hedgehog | @Mast There are also separate apps that block ads across all apps, such as Blokada, which I use. | |
| Jul 21, 2021 at 16:57 | comment | added | Mast | @TylerH Firefox for Android does, hint hint, nudge nudge. | |
| Jul 21, 2021 at 16:30 | comment | added | TylerH | @VictorStafusa If only Chrome for Android and iOS supported extensions... | |
| Jul 21, 2021 at 6:39 | comment | added | Victor Stafusa | This is a good reason to aggressively block ads! | |
| Jul 21, 2021 at 2:24 | comment | added | Journeyman Geek Mod | Crappy CDMA dongle thing actually. I would not consider this a reasonable baseline in 2021 of course, I didn't in 2012 - but working out what is the worst worth supporting would be a good idea. | |
| Jul 21, 2021 at 2:09 | comment | added | Sonic the Anonymous Hedgehog | @JourneymanGeek Only had a 28.8k modem handy? | |
| Jul 21, 2021 at 2:05 | comment | added | Journeyman Geek Mod | Back in 2012, I spent a couple of weeks with what was literally a 16-20 kbps connection. While that's extreme, testing against what you might expect to be a reasonably potato connection. There's tools that simulate these IIRC - and might be worth looking at. As a bonus, a fast site on a slow connection is even faster site on a fast connection | |
| Jul 20, 2021 at 2:55 | history | edited | This_is_NOT_a_forum | CC BY-SA 4.0 | A rate. |
| Jul 19, 2021 at 20:43 | comment | added | Sebastian Simon | Another thing that can be optimized: raster graphics are often served with a higher resolution to devices with high-DPI screens, which of course requires more bandwidth. Fortunately, there’s a <picture> element supported in all of Stack Exchange’s supported browsers which addresses this issue. Currently, Stack Exchange doesn’t seem to use it. | |
| Jul 19, 2021 at 20:34 | comment | added | Sonic the Anonymous Hedgehog | @zcoop98 I have several old computers running modern operating systems; on such systems, the speed test shows a fast connection, but it takes time because the CPU has to render the page. Also, the staff answer to my prior question mainly talks about that, so I thought Aaron was talking of the same here. | |
| Jul 19, 2021 at 20:31 | comment | added | Sebastian Simon | Most graphical assets on Stack Exchange are SVGs, but some site themes do use PNGs. The SVGs look quite well-optimized already. Some PNGs can still be optimized using tools like Trimage (PNGCrush, OptiPNG, etc.), e.g. the header and footer graphic here on MSE (by 49.5 %, from 31.1 KB to 15.7 KB). But then again, the MSE header background can also be remade as an SVG. Some other PNGs are already maximally optimized. | |
| Jul 19, 2021 at 20:27 | comment | added | zcoop98 | @Sonic Not sure if it counts for all that much, but I work with front end web professionally, and I definitely read "page weight", "smaller page load", and "reduc[ing] the amount of HTML we’re serving over the wire" in the post as referring to bandwidth concerns almost exclusively... in addition, CPU performance for loading web pages just isn't a big concern or constraint in this area; that's an extremely uncommon bottleneck. I totally agree with highlighting this concern though, it's a really major one. | |
| Jul 19, 2021 at 20:19 | history | edited | Sonic the Anonymous Hedgehog | CC BY-SA 4.0 | deleted 26 characters in body |
| Jul 19, 2021 at 20:15 | comment | added | Sonic the Anonymous Hedgehog | @Catija It wasn't clear to me that that was mostly referring to bandwidth, but rather client-side loading (as in CPU performance to render a particular HTML). While there was a reference to reducing HTML size, it didn't say anything about assets (e.g. images), which have a much larger size than HTML (on the whole). | |
| Jul 19, 2021 at 20:13 | history | edited | Sonic the Anonymous Hedgehog | CC BY-SA 4.0 | added 306 characters in body; added 66 characters in body |
| Jul 19, 2021 at 20:13 | comment | added | Catija StaffMod | Maybe I'm missing it but the question seems to explicitly cite that slimming down the responsive view is necessary and even gives the example of the footer being hefty to download. Is there something about the question that you feel doesn't address this issue? | |
| Jul 19, 2021 at 20:11 | history | answered | Sonic the Anonymous Hedgehog | CC BY-SA 4.0 |