It’s amazing how much work goes into shaving off just a few ms of website load time

With google starting to down grade slow sites it might be worth it.

@Voxera my current goal is to deliver a loading screen in <50 ms and the rest of the content in <200ms but I feel that that still may be a bit slow

@FelisPhasma that should be good enough for most ;)

I read that stachexchange had page loads down to 28 ms :)

And that was 2013
https://nickcraver.com/blog/2013/...

@FelisPhasma
Well my school's interactive learning platform takes about 8 seconds for the first meaningful paint...

So I think you are doing fine :D

@FelisPhasma yeah man, I'm trying to do the same thing. Load the whole first page within 400 - 500 ms.
How would you go about loading the page (loading screen) first, and then loading the content? I haven't figured that out...

@hacker
* Bake some basic CSS into the top of your html
* Bake some basic JS into the top of your html (or don't if you don't really need it for initial load)
* Build the initial view with baked in CSS/(js)
* Add more advanced logic and stuff later with a script tag at the bottom of the HTML file or with the async attribute set
* ...
* Profit!

The point is to have the HTML file contain everything for initial load (make sure not to bloat it) since that gets loaded first and then render stuff like background, navbar, basic page structure and the like off of that. How much you bake in vs leave for later is for you to decide. Just don't bake in too much or you'll make the HTML file so heavy that load times get slow again

And for the love of God don't do this manually. Use Webpack or something, there are tools for that 😄

@hacker I looked at your repo but didn't 100% understand what you're doing with page loading stuff there. Could you explain it?

(I woke up literally like 2 min ago, opened my eyes 2 min ago, so my brain is kind of toast at the moment 😄)

@Froot oh no, I don't wish to torture you by having you look at my un-optimized code.
But, I'll explain it and you can read this later, if you want (I'm about to head to sleep, almost 11 pm here...):
Well, I checked the network waterfall and guess what, the most time is being taken loading the files in the picture attached. I know I shouldn't be loading my favicon from GitHub's servers, but that was just a quick hack to see if everything worked haha (will fix ASAP). So, back to your suggestion, I should "bake" some of my CSS into my templates, so it will reduce the number of requests from the server. I guess I can do that for smaller files such as "normalize.min.css"...

@Froot the good news is, I've managed to get these amazing times (look at the picture below).
However, this happens if the user visits the site more than once (because of my caching mechanism paired with some nifty Gzip compression)

@hacker careful with caching. If you update those files the client’s browser won’t fetch you’re new files

Maybe set you cache lifetime to something like a day?

@FelisPhasma Use hashnames for your resources. Facebook does it, it's great.
Basically what it means is that your resources come out with a new name on every build and thus whenever they change, their names change. That way you can allow unlimited caching and still have everything up to date.

Also, there are tools for that so don't do it manually or you'll go insane 😄

@hacker Yep. Basically have inlined CSS at the top of your file for initial load. You can do the same with js but I don't know why you'd need js for your initial load, unless you want to have a fancy loader or something.

@Froot wow, hashnames sound cool. I've seen them on a couple of people's sites and was confused as to why there were a bunch of random stuff in the file names. However, is it a different file on every site release/update or everytime someone comes to the site? Because if it were the latter, it would defeat the purpose of caching..

@FelisPhasma ah, good point.

@FelisPhasma also, I haven't deployed the site, yet. When I do, I might do that. But, I was researching this and I found that additing "?version=1.0.0" and the end of the URL for your static files can also achieve the same thing. I'll could just do that when I deploy and increase the number (perhaps server-side) when I update the files. Is that a good idea? What do you think, @Froot?

@hacker Hashnames Are generated on build. You use something like Webpack to build your site and it gives you a new hashname every time. It also takes care of making sure the name of the file and it's representation in the html match, it's all automatic. Well, it's not Webpack itself but a Webpack plugin if I'm not mistaken, Google it, should be easy to find.

Version numbers might also work but use a builder for that. Don't go inventing custom logic in your server or even worse doing it manually, it's a waste of time. There are tools for that (Webpack)

The hashname is the same for every visitor as long as the file is the same. As soon as you rebuild the file, it gets a new name and thus all visitors will redownload it

Go read up on Webpack and modern web development tooling. There's alot of stuff that makes your life way easier like CSS autoprefixer and JS transpilers for older browsers. And you only set it up once, after that it does it's thing on the background. Great stuff