Towards a responsive UI
pwr.news lacks snappiness. It is slow to load, slow to use and slow to respond. This has been the most common comment about the app over the last months. Up until now! Read on for a little more background and speed improvements.
pwr.news lacks snappiness. It is slow to load, slow to use and slow to respond. This has been the most common comment about the app over the last months. Up until now! Read on for a little more background and speed improvements, or read the next blog post on more responsive UI elements.
Background
In the early days of pwr.news, when it was known as sprout.host, life was simple. Effort was put into writing robust crawlers to fetch data reliably, a little less effort went to writing a web service querying and returning this data, and the remaining late night coding hours went into hacking together something that some brave souls could call a UI. Not only was decent code on the backend more important as it was there where bugs would result in missing or broken data, it was also not clear what would be the best way to visualise the large emerging dataset. So, I happily continued hacking together different ways to visualise and validate what was fetched and processed.
No frameworks were used for this as it was not clear what problems they should focus on solving. d3 was used to render things, and a little bit jQuery and
Bootstrap was sprinkled on top of it to make my life a bit easier. But a fully fledged framework like Angular or Ember seemed complete overkill.
Fast forward to recent times. The amount of fetched data has greatly increased as crypto space boomed and pwr.news reached a higher coverage of the space. Server side changes were made to keep the tool from falling apart speed-wise. Meanwhile, more hacks were applied to keep the front-end from crumbling. Page loads increased as more and more modules were needed, and as some aggregate functions such as the sentiment cloud ran in the browser, keeping a tab open on pwr.news became heavier and heavier. Coding-wise it became harder and harder to optimise, update layouts or introduce new features altogether.
Speeding things up with react & redux
Up until now! Over the last month, the front-end code got some much needed love: many parts were rewritten using react and redux. Layouts are now broken up into reusable templates, only needed data is fetched and updated when necessary, and lots of deprecated code that was interwoven with core components finally could be purged altogether. Oh, and the code got finally minified. Of course, some of these things would also be possible without using react/redux, but they acted as a very helpful yet minimal guideline for taming the monster that had been created over time.
You will rather "feel" the results than immediately see it: page loads got up to 88% faster, and keeping a browser tab open won't drain your (mobile) data anymore with up to 98% reduced traffic 😎
then | now | reduced | |
page load (worst case) | 6946 kb | 56,28 kb | 99,18% |
25,46s | 3,51s | 86,20% | |
page load (cached) | 4900 kb | 49,1 kb | 98,99% |
11,4s | 1,3s | 88,60% | |
Page update (every 5 minutes) | 4200 kb | 49,1 kb | 98,83% |
Some numbers (tested on Brave, Intel i7-7560U, 16G memory, 2MB/s connection)
There is still room for improvements, but this should bring a bit snappiness back into your pwr.news browser experience!
Next up: new UI goodies!