DEV Community

Cover image for Dev.to is fast - But ... How?
Sm0ke
Sm0ke

Posted on • Edited on

Dev.to is fast - But ... How?

Hello Dev Stuff,

This is an open discussion addressed to Dev.to engineers especially, regarding the deployment architecture. I was amazed a few months ago to see that one of my posts React Dashboards - Open-Source and Free ** has more than 50k views and is the first item returned by Google for a super competitive keyword react dashboards in front of companies like **ColorLib, MadeWithReact or Creative-Tim.

The content of the article is not optimized at all, has a lot of text, images, and gifs loaded from Github and despite this, the article has a 100 Lighthouse score.

I have a huge thanks, If someone from Dev stuff can provide more information regarding the production deployment (Proxy Server, Caching, Load balancing, Database, Distributed Servers, if any .. etc).

I'll drop some stats regarding my article:

Google search - Pos #1 since Sept.2019

React Dashboards Dev Article - Google results.

Lighthouse score - Desktop

React Dashboards Dev Article - Lighthouse score for Desktop.

Lighthouse score - Mobile

React Dashboards Dev Article - Lighthouse score for Mobile.

React Dashboards - Dev.to stats

React Dashboards Article - Dev stats.


Thanks again! Just keep up the good work & superfast deployments.

Top comments (12)

Collapse
 
terabytetiger profile image
Tyler V. (he/him)
Collapse
 
sm0ke profile image
Sm0ke • Edited

Thanks for the link. The article explains some basic stuff, useful indeed but unrelated to the macro architecture used by the service.
Also, I noticed that the content is displayed contextually. If you access Dev.to using incognito mode in browser the information is different compared to authenticated sessions.
I might be wrong, but the information is personalized based on (at least) two factors:

  • followed channels (this is a common technique)
  • cover item is updated if you already read that topic and refresh the page (I might be wrong on this)

This kind of "decision" should inject some decisional delay in the service speed. Well, Dev.to still scores 100 on Lighthouse, witch is amazing IMO.

Collapse
 
ben profile image
Ben Halpern
Thread Thread
 
sm0ke profile image
Sm0ke

Thank you Ben. I'll get back with more questions :)

Collapse
 
blair2004 profile image
Blair Jersyer

According to recent studies and based on my personal experience, speed doesn't have a huge impact on SEO ranking. You should note Dev.to has a very huge domain score, pretty much post published here are referenced like within 1 hour and is available on Google. While I'm not saying speed doesn't matter, it looks like it's not the most important aspect that improves your ranking.

Collapse
 
sm0ke profile image
Sm0ke

true ..

Collapse
 
iggredible profile image
Igor Irianto

Some of my posts also made it to Google's top page. Part of it, I am sure, is due to Dev's awesome page speed. Good question!!

Collapse
 
sm0ke profile image
Sm0ke

Thanks for noticing the article.

Collapse
 
admindashboards profile image
admin-dashboards

Having a stable & fast service in production is quite a hard thing to achieve. Nice topic.

Collapse
 
sm0ke profile image
Sm0ke

Thank you! .. <('_')> ..

Collapse
 
crearesite profile image
WebsiteMarket

Good question! I'm also interested to find out more regarding the service deployment architecture.

Collapse
 
sm0ke profile image
Sm0ke

Hooray!