View profile

What can slow down a website - Software Shots - Issue #11

What can slow down a website - Software Shots - Issue #11
By Karn • Issue #11 • View online
It’s always fun to go to a new site and just give it like some kind of audit, like a very high level view of what’s going on with it.

Let’s group them into backend and frontend. Obviously, these don’t always hold true as things get complicated with serverless sites and separate services, but I’ll try to give you an overall idea of how I audit a completely new website as a user.
  • Database calls - I’ve seen it often when you have a lightning fast server and a really slow database. That’s just gonna slow down your requests. Also while freelancing I noticed, the amount of folks putting their RDS instances and EC2 in separate AWS regions is just a lot. For the love of all that is pure and mighty, stop doing it.
  • The servers - can be slow, or it’s just not enough of them or the resources allocated is not enough. If your lambda requests are too slow, try allocating more memory, if it’s still slow start optimizing at the code level.
  • Network: This goes for both frontend and backend, either some calls between services can be slow or the call from the frontend to the backend can be slow. And these are very interesting to fix, may be you can put your static assets out on a CDN. There are also a lot of serverless technologies that let’s you host your code in multiple places, basically like a CDN for dynamic stuff. A lot of bigger companies have data centres located strategically all over the world or they’ll buy dedicated instances in certain areas to make connections faster.
  • Compression: A quick shout out to gzip and brotli. These are two compression schemes that a browser can understand, which technically means if you compress your code in one of these schemes, browser doesn’t need any sort of extension to uncompress your code and read it back out.
Well, the way I see the frontend industry growing. We’re gonna see a lot of perf issues coming up. Some I have listed down here:
  • Bundle Size: Really large JavaScript Bundle Size is probably the biggest reason why your frontend ain’t performing well. I’d say 90% of the cases.
People say like keep it under 300-400 KB of JS but slowly when you’re an NPM freak, it’ll easily jump to 5-6MB of JS. Some common solutions would be, reducing the dependencies, optimizing your bundler and taking advantage of all the modern things. Webpack is very flexible.
  • Too Many Files: If you enable the Waterfall mode in Chrome Dev Tools, you can see at one point of time only 6 requests will get fired(sent to server) and rest all will be in pending mode. So if you have like 700 images that need to come down, it’s just gonna be queued and affect your page loads. So I’d say please make your image loads asynchronous. May be add a lightweight placeholder div until the image loads, or use this:
  • Images: Okay I’m guilty of this in the past, but I still see this all around. You have an image, in the css you set it’s width and height to say 500. But when you hover over the image and see the actual dimension it’ 2400 by 2400. Why? Why’d you send such a huge image when you’re not planning to use it. Save user’s bandwidth and increase the perf. Please!!! Also use an image optimizer to trim all the metadata off the images that you put up on the web. Any image that’s been through a lot of Photoshop projects, will have a shit ton of metadata on it.
  • Compress your images: If you don’t want to lose the quality, use a lossless compression algorithm.
  • Unused JS+CSS: Very tricky, chrome dev tools will sort of tell you unused JS and CSS, but usually you’ll have some CSS styles that are waiting to be applied to a hidden Modal. So it’s not really unused but it hasn’t been used yet. So the way to handle this is bundle async stuff. Configure your webpack to handle dynamic imports.
  • CSS in the document Body: CSS in the body will be async, i.e. a lower priority load as compared to head tag. But scripts like analytics (Google/Plausible) will block your load as they’re required to be put in the head. Just choose Plausible, it has a lower footprint and much more privacy friendly. Although I have seen departments at companies making decisions only on Google Analytics, so you might want to convey them about their job becoming obsolete. 😂
  • Not using Browser Cache: Set Cache-Control, etag headers. It’s usually important for business requirements to understand how etag works. -> Go here they did a better job of explaining it. lighthouse report lighthouse report
There’s a lot of insights that Lighthouse gives as well for improving your frontend. It’s awesome to see it integrated to chrome console.
What else?
Let me know what you usually look for when checking out a website’s performance.
Have a good week. Ciao 👋
Did you enjoy this issue?
By Karn

I build and create things. As of now, I work as a Software Engineer at SendX/SendPost.

If you don't want these updates anymore, please unsubscribe here.
If you were forwarded this newsletter and you like it, you can subscribe here.
Powered by Revue
Gyan Karn, Delhi, India - 110039