14
10 Comments

Why Is Indie Hackers slow in fetching data?

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.

  1. 9

    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:

    • Server-rendered static HTML files served from Cloudflare edges. Response times don't get much faster than that.
    • No huge JS or CSS payloads to download. You're only getting JS and CSS for the page you're looking at.
    • No need for Ember to render the UI after the page loads, because we're not even including Ember.
    • No need for Firebase to authenticate you, because this is only for anonymous visitors.
    • No need to load any data from Firebase, since the page was rendered on the server.

    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:

    98 out of 100

    1. 1

      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.

    2. 1

      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.

  2. 5

    I think there are two reasons:

    1. Its heavy use of external calls to Firebase, etc + caching
    2. It's using a heavy JS framework, even for content pages. This page we're commenting on loads over 5MB of just JS and CSS.

    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.

    1. 1

      What if they use React js or any other framework instead of using ember, handlebars and gsap, since the website has grown pretty much.

  3. 2

    Looks like the below requests all need to finish before that top and bottom right loaders go away.

    1. Load the quotes ~200ms
    2. Authentication ~ 500ms-1 second - Blocks below requests
    3. Fetch the last 40 of the author's posts, using Algolia ~200ms
    4. Fetch the last 40 posts from the posts group (Developer), using Algolia ~200ms
    5. Some secret thing? ~200ms

    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.

    1. 1

      The quotes could be a static array instead of pulling from firebase like what I’m assuming.

  4. 2

    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

    1. 2

      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.

  5. 1

    Afaik indie hackers is on ember.js. that might be the reason. maybe framework has some limitations?

  6. 1

    This comment was deleted 3 months ago.

Recommended Posts