ubyssey.ca
ubyssey.ca copied to clipboard
ubyssey
Ubyssey Server Response Times (Lighthouse Report)
Posting advice from alumni here as suggestions for next steps forward:
- Tie up any old loose ends between Dispatch and Wagtail
- Use available opportunities to batch SQL queries
- Adding a cache: Memcache or Memorystore
- Investigate feasibility of Google CDN and associated costs
- Django-silk
I added lazy loading (blurry images show up when the page is first rendered) in this branch thinking that it would improve the lighthouse report. At least from what I saw it didn't really and possibly made it worse? So I'm not sure if we should merge this.
https://github.com/ubyssey/ubyssey.ca/tree/1051-improve-lighthouse-report-sam-low
In this branch I changed the image format to webP which is a much more compressed image format than png. The lighthouse report was improved alot by the change
https://github.com/ubyssey/ubyssey.ca/pull/1091
@SamuelmdLow Good idea to use WebP format! I'll check out that PR.
In my opinion it's usually best to avoid lazily loading images because it can create a poor user experience, especially for images that appear above the fold (i.e. visible without scrolling down). If anything I'd add it as a later optimization after working on downsizing/compressing the images like you've already done.
Speaking of images, the Lighthouse report shows that a few of the header images don't have an explicit height and width. I haven't looked into those specific elements and whether it's possible to set their dimensions explicitly, but doing so helps the browser do its own lazy loading because it knows exactly how much space the image will take up. That said, all of the article images (on the homepage at least) have explicit dimensions, which is great!
With all that said, the most concerning thing in the report is the 3.5s server response time. This means it takes the server several seconds to send back the HTML for the page and tell the browser which images to load -- it's basically a bottleneck that blocks all other requests (e.g. images, CSS) and makes most other performance improvements less effective.
Anything over ~500ms will feel slow to a human. But I think it should be possible to get below that threshold!
Unfortunately the performance report can't tell us much about how to improve this metric because the slowdown is happening on the backend, not the frontend.
As a first step, I'd recommend we do some profiling see which parts of the Ubyssey web app are slow. A usual suspect is database queries, especially for a framework like Wagtail/Django that uses an ORM, but there may be other issues too. It's usually best to start with a profile before optimizing specific things.
We could configure the django-silk profiling tool to get a better picture of where things are slow. I haven't used it but I've heard it's quite good.
django-silk looks great, but FYI what I'd usually do in the development environment is hook it to the production server so the debug toolbar plugin we use could get real/realistic profiling data on query response time.
This generally supported the conclusion that there were common DB queries on the homepage and such that could have been made a lot more efficient with software like redis or memcached. Queries on ArticlePages are common and large. They're certainly far more common than writes to the same tables.
Unfortunately, those are relatively complex pieces of software and adding them to our stack was never realistic for the school year...
ALSO on caching software I should issue a warning: The problem is not simply installing them and using them to speed things up. This would actually be the relatively easy part of the project! The difficult part would be determining appropriate rules of cache flushing and validation that fit The Ubyssey's organizational needs. Naively just sticking caching in will cause complaints of the sort: "I updated my article, but it doesn't appear updated on the homepage/in the archives/etc".
The most promising thing in my opinion is to to use django/wagtail hooks to associate flushing and rebuilding the relevant caches with publishing articles. This is likely to make the editor's experience worse in exchange for making readers' experiences better.
I improved the lighthouse performance for the homepage somewhat through this commit
https://github.com/ubyssey/ubyssey.ca/commit/40f99cfcf46f4e928ebf3a0635c70037c6880130
- Separated home styling into its own stylesheet
- Reduced image size and made loading lazy for column and top stories template
- Added defer or async to some scripts but I dunno if that did anything