Optimise images. This isn’t really a code challenge, but it’s a big performance win with very little effort. The least you can do is drag and drop all your app’s images into ImageOptim or a similar app. Got a bit more time? You might want to build image optimisation into your asset pipeline (Gulp, Grunt, or whatever you use).
Use srcset to add responsive images throughout your app, including user-generated content. If you don’t already have the ability to generate different sizes, consider using a service like https://zimage.io to generate the smaller sizes.
Really like this suggestion. So often do really helpful updates to libraries not get incorporated because of the requisite work to get used to any small changes. Might just make a point to do this one even if it’s not part of the actual main challenge.
Maybe somewhat controversial: add comments to your Gemfile (or equivalent) to explain why/how you are using libraries – especially if the library name is not clear as to what it does (Ruby is notoriously bad at this).
I’ve heard this suggestion before, but I’ve never heard the reasoning behind it. From my POV, if the test does a number of actions before the asserts, repeating those actions for each assert is going to be much slower, especially with a system test.
I’ve always thought it would be useful if one test could start out in the state another test ended in.
I was imagining this more in a unit test context. It’s a tradeoff, as you have identified, between speed (more tests, maybe more costly setup) and clarity (more focused tests, easy to suss out what is being tested). There is a similar tradeoff when setup becomes complicated: extract a helper function or factory to improve readability at the cost of more indirection.
Oftentimes, the code smell occurs in the test name. itCallsStripeAndEnqueuesAnalyticsJobAndNotifiesAdmin is probably a test that could benefit from being split.
I was reading these, and there are some great suggestions. I’m late to the party, but I wast thinking: Find one test that hits the database and doesn’t need to, and refactor it to use mocks or stubs, as applicable.
One more thing… You can remove unused dependencies.
At work, we switched JavaScript asset build tool to webpacker from sprockets in a Rails app. As result, we had unused JS assets gems in Gemfile. I just removed those gems a couple days ago.
.