Hello Dev Stuff,
This is an open discussion addressed to Dev.to engineers especially, regarding the deployment architecture. I was amazed a few mo...
For further actions, you may consider blocking this person and/or reporting abuse
You might be interested in this post from Ben:
Making dev.to Incredibly fast
Ben Halpern γ» Feb 2 '17 γ» 5 min read
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:
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.
Another neat thing we do if you're curious... π
Instant Webpages and Terabytes of Data Savings Through the Magic of Service Workers β¨
Ben Halpern γ» Dec 18 '19 γ» 5 min read
Thank you Ben. I'll get back with more questions :)
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.
true ..
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!!
Thanks for noticing the article.
Having a stable & fast service in production is quite a hard thing to achieve. Nice topic.
Thank you! .. <('_')> ..
Good question! I'm also interested to find out more regarding the service deployment architecture.
Hooray!