It makes me smile when someone raves about how fast this website loads, because that's no accident. We put a lot of effort into making it so. It is...
For further actions, you may consider blocking this person and/or reporting abuse
Have you seen Grade by @benhowdle? You might be able to show a gradient instead of a solid background color while the images are loading, which doesn't have an impact on the loading time but looks gorgeous!
Interesting. But is that data available before the image is loaded? The background color example here is to provide a color background on initial render, because the image won't show up at first.
But the gradient look still could be the right call, it would just be done on the sever once ahead of time instead of calculated on the client. That is the general idea with most of the app's structure. More work at write time, less work at read time.
Yes exactly, I didn't mean to use that exact library client-side, but to take inspiration from the algorithm and use it on the server.
It's certainly a lot nicer than just a plain color!
Ah yes. Right on, good call.
Now moved to benhowdle89.github.io/grade/
And I found something interesting. Hovering to any dev.to links loads the page contents even if you didn't click it.
Not only. I think it also uses Service Workers for that. And also have some delay before it will actually start to fetch because if you move around link very fast you will see that after every request is red hence canceled. While if you move and keep your mouse for another ms more, it will end up in success :)
So it looks like that.
prntscr.com/hb4pxp
See, this is why I love this site. Not because of the performance per sey, but because the way this performance is achieved is just thrown out there for all of us to enjoy. Most times you have to ask the team behind an open source project how they did stuff, and the answer is usually "Well, only our sponsors and Patreon supporters are privy to that information wink wink hint hint". But with @ben and the team it's like "Hey, our site is fast as balls because (detailed description of all steps). Cheers." Like it's no big deal. Gotta love that kind of transparency! 😁😁
i am very interested in this topic but felt that this article was a bit too high level. i was left wanting more detail. in particular would be very interested in objective tools to measure and identify bottlenecks in page speed. what websites do you use? what are the numbers that really matter? would love more on that. maybe pick a website you use and do a "what i would do if i were you" post?
Don't inline styles make HTML load slower on uncached load of the user logged-in view? I believe you'd be able to rely on your CDN less, and have to do more work on your backend in this case.
And isn't HTTP2 meant to load CSS for you as if CSS were inlined, with the benefit of being able to cache the CSS and HTML separately?
Yes and yes to an extent.
It's possible that we should remove this strategy for logged-in users. A huge amount of the traffic is still fresh users via Google or elsewhere.
HTTP2 Server Push would possibly help in the way you're describing but it's still not clear whether that tech is all the way there to avoid headaches.
I think in the next little while we will see how we plan to evolve our strategy.
I'm saying the first thing because I'm surprised the website is so blazing fast even if I'm logged in. Okay I see that if I disable JS, there's some basic stuff loaded that probably would be the safe for all users, but even so, the rest of it seems to load so fast; the database calls in the backend (on first look there didn't seem to be a lot of caching there, but I might have seen wrong), and also the fact that Ruby is quite a slow language as far as I know. I tend to have speed issues running Laravel, but then again I'm a cheapskate that runs it on $5-10 Digital Ocean servers :P
I apologize if this is answered somewhere else but what do you use to serve the blog, blogging software-wise?
also wondering this!
We built our own CMS 🙃
With Rails, specifically.
Even more impressive that it is as fast as it is then!
I have wondered how dev.to could be this fast. Thanks for sharing insights on how you approached the whole thing!
Nice! There is more I didn't cover here, that is mentioned in some of those older posts. Of course, this covers some of the stuff not covered before.
I'll write about this more often. I'm constantly looking for new ways to improve, or at least new ways to think about and express why this stuff is important.
I can't find the old post any more. dev.to/t/web-performance seems to be empty. Could you please update the link? Thanks! This is super helpful!
ah, nvm, found that dev.to/t/webperformance was the correct tag.
Hi Ben, you mentioned "A typical request first returns a fully-cached, pre-gzipped HTML page served from the closest Fastly node if one is available."
How do you make Fastly cache this response? (Headers?)
And, let's say you cached a dev.to post. Then, the author edits it. How do you update the cached page?
Thanks for the great article. I'm waiting for a response :)
Identifying bottlenecks is a key to solving performance problems in general not just on the web :-)
dev.to is amazingly fast!
How exactly are you generating the static files for each post?
This part's my favorite. This really is a life tip. :laughing: It feels so much faster!! Thank you!
Is there an origin story behind the motivations for the creation of dev.to?
Yes, I should tell it again though. Coming soon.
Very good article, helped me understand some concepts.
But then I inspected code of the page, and a question appeared. Why this?
!(pasteboard.co/GPo6g5T.png)
That's a relic of the fact that we're basically using the default Google Analytics copy/paste which thinks the script should be appended to the
head, but on every page nav, it re-appends it. Since the script is cached in the browser and re-appending it doesn't really affect the user experience, we haven't gotten around to doing anything about this.Sorry I couldn't quite get it how to inline an image...
Incredible job!
You mentioned images are in webP format. But in the source code, and when inspecting any image in dev.to site, I only find pngs.
How is it done?
I believe this depends on browser. If you open in chrome all the images are webp format. It's a feature of cloudinary to detect the browser and serve the image in the format which is best for the requesting browser. It can be done by using f_auto flag in your cloudinary image request urls.
@ben, good article.
By the way, the first hyperlink on this post to the URL dev.to/t/web-performance is broken. It's going to 404.
I thought that I should share this.
Best regards
This link --> dev.to/t/web-performance is not working? Was it moved somewhere else?