Note: I am on 10mbps of internet speed.
If you notice fetching data requires more time than other websites, what would be the reason?
I actually want the technical reason to be honest, that what does it cost to fetch such data? is it CSS or is it firebase or is it anything else. Please tell me the answer.
One of the biggest issues lies with database load. I've got lots of scripts that run periodically, and I suspect there are egregiously inefficiently-written queries from many years ago that are causing our database load to spike when they run. When db load spikes in Firebase, it can take a long time for it to process queries. What this looks like to you as a user is the site locking up for a bit, taking a long time to load data. I need to find and rewrite these queries. I've rewritten a few in recent weeks.
Everybody loves to hate on single-page apps and Ember.js in particular, which I think is both fair and a bit exaggerated. All the JS and CSS for the entire site gets loaded at once, which compressed is like 1.1MB. That's not the biggest deal in the world, but it's higher than I'd like. Probably the best fix at this point is code splitting, which Ember didn't support well for the longest time (as in, core maintainers recommended me against using earlier solutions). But it may be time for me to look into it again. I'd probably split off all the JS and CSS for rarely-visited and rarely-changed pages, and cache that aggressively.
Beyond download time, the bigger cost of the large JS payload is simply rendering. The bigger your single-page app payload, the longer it takes the browser to load it into memory and run it to render what's on your screen. That's a decent percentage of what's happening when you open IH and see the blue bar across the top of the screen. A very small Ember app's render time is almost imperceptible.
The other thing that happens during that blue bar phase is Firebase authentication and data retrieval — basically, logging you into Firebase, then retrieving data. There's not much I can do to improve auth times, but I don't think that's super slow anyway. Data retrieval also isn't that bad, except (a) when the db is under heavy load, and (b) on posts with hundreds of comments, where I'm using a poorly optimized algorithm to load data.
These are all solvable problems over time. I just don't have much time. I probably spend 3-4 days a week just on podcast stuff and other responsibilities, and we only recently (finally!) hired a second developer besides me.
If you want to see a fast version of IH, browse the homepage or posts while logged out. I made both of those pages entirely static for that use case, and manually split the code to only include relevant JS and CSS. That means:
When Google browses the site its bots are obviously not logged in, so they get the fast stuff, so the homepage and post pages score high on their speed rankings. Yes, page load speed is still very much a concern with Google, @alchemist!
Here's the PageSpeed Insights score of the desktop version of this page:
Ah, bummer. I don't think any of my sites are that slow, but there's something about the idea of content overcoming all that I found inspiring.
Congrats on the massive improvements to the Google PageSpeed score, though! It was way lower when I checked it last year.
Best Answer!!! Now I can also look into this problems when building any website. Thanks.
And TBH , i didn't know that you were the single dev in this website(kuddos man for developing such awesome community), i thought that after teaming up with stripe you would get more devs to improve the community.
I think there are two reasons:
The first issue will slow down the site for you regardless of your hardware and bandwidth. However, the second issue will be dependent on both.
In my case, bandwidth isn't an issue at all. However one of my devices, my Android phone, often takes 15 and sometimes 45+ seconds to render a page. In contrast, that same page renders almost instantly on my Mac, so the only slowdown is due to the first issue.
I remember commenting on it three or four years ago but even at that point, Courtland felt it was already to late to transition it into a more traditional server-rendered site.
One thing I've learned from observing this is that page loading speed is clearly not a deal breaker for SEO or organic growth! IH has had the worst UX of any site I regularly use almost since the forum started, and yet its growth has been amazing. It's a gold case study for the, "Content is king" idea. If people want your content enough, they'll put up with a lot.
What if they use React js or any other framework instead of using ember, handlebars and gsap, since the website has grown pretty much.
Looks like the below requests all need to finish before that top and bottom right loaders go away.
The authentication step seems to have some room for improvement, not sure if that's a firebase issue. If the related posts and comments had their own loaders, it would improve the perceived speed.
The quotes could be a static array instead of pulling from firebase like what I’m assuming.
Always it could be the data storage , or the server processing . I suspect for you the delay might be your proximity to the server location also , since it’s fast for me so that my first hunch .
If you are using chrome open dev tools and open network tab which will show if the network calls take time
Yes Server location could be the reason, I am in asia-south1 as per firebase, and indie hackers will have it in us, so may be that could be the problem. I thought that, much of css involved in this website could be a problem for fetching files.
Afaik indie hackers is on ember.js. that might be the reason. maybe framework has some limitations?
This comment was deleted 2 years ago.