Follow

Google on quite a decent PC: *takes a while to load*
My website on a single-core Atom N270 with 1GB of RAM: *done nearly instantly*

10/10 optimizations.

· · Web · 1 · 0 · 2

@finlaydag33k
What's wrong with your decent pc then? Google is one of the quickest things loading on my 2013 pc.

@sexybiggetje That's kinda the thing... I have absolutely no clue.
Google takes about 6 seconds to fully load and is (along with other "I use way too fucking much JS" sites like Fuckbook) among the slowest websites to load.
So could be something related to JS.

@finlaydag33k I have a DOMContentLoaded of 132ms and Load of 212ms on the search result page. It takes a bit longer for all resources to get there, but full result is 1.2s. Which is just a little bit slower than my own site that's statically served with caddy. So not bad IMHO.

I'm assuming the JS is CPU bound, I'm running this on an i7-3770 from 2012 (bought in 2013) on Win 10 Pro with latest Chrome.

@sexybiggetje My PC runs a Ryzen 3600 (overclocked) but full result for the DOM content load takes about 836ms with the rest of the load finishing around 6 seconds.
My website takes a DOM content load of 125ms and the rest of the load finishes around 340ms in Edge.

@finlaydag33k well the rest of the load are assets mainly loaded after initial js parsing, so it must be JS execution time or other way of blocking.

If you want to get to the bottom of this, a lighthouse test in the devtools and some of the newer perf tools might provide some insight as why you need the 4 extra seconds.

I'm not on Facebook, so I just have to assume that it is even worse :D

@sexybiggetje Yea, their JS is HUGE, so I wouldn't be surprised if that's the issue.
Their JS is about the size as my entire site (with images and all) is :p

Facebook is an even more massive dumpsterfire indeed.

@finlaydag33k I took a look at your site's loading performance; I think you can gain some more.

The link preload for css/js doesn't do much in this setup. You could benefit slightly from passing them in the header as a preload. But not much gain there.

Your assets aren't minified. You could shave some bytes and parse time there. (If you worry about readability for curious people, link the source).

Your second analytics.js is small, it frees up 1 socket if you concat it to app.js. 1/2

@finlaydag33k

Your font-awesome loading is early and blocks subsequent requests. You could benefit from loading default.css and yourlogo.webp before them. (As they have more render impact above the fold).

I hope you like the feedback! Your site is already fast, it could be even faster! 2/2

@sexybiggetje I have tested preloading css/js vs not-preloading and it did help quite a bit.
Using the preload header might be an option, I'll test it out :)

Minification was still on the "todo list" (in my head), the source is on GitLab anyways so linking that won't be needed.

The 2nd analytics is left as a separate JS intentionally to prevent it from "accidentally" executing when people have opted-out.
Though I could find something else for this as well

(1/2)

@sexybiggetje If I'm not mistaken, using preload on the FA shouldn't block either but I'd need to double check

(2/2)

@finlaydag33k according to the network panel it does. The subsequent scripts seem to await available sockets. Maybe I could tune http pipelining settings, but I want to keep my chrome as stock as possible

@sexybiggetje Yea, keeping Chrome as stock as possible is the way to go for testing these kinds of things.
Odd tho that it blocks because it shouldn't (that's the entire reason that preload is a thing).

Mind providing me a screenshot of where you see that it blocks because I can't find anything over here that it does either.

@finlaydag33k sure, no problemo. After taking a screenshot I thought you might like a HAR as well, so I captured another HAR file on a subsequent request. Pasted it here; bin.veracry.pt/?60476d783cb454

@sexybiggetje There indeed appears to be something unintended going on there.
I have changed some things which should make it all load a bit more smoothly.
It probably still "blocks" due to the connection limit (which, I sadly cannot get around), however, by swapping some things around, I did manage to make some things a bit smoother (by "delaying" the JS a bit and prioritizing things needed for actually displaying).

testing.finlaydag33k.nl <-- You can see the changes here.

@sexybiggetje Ran some more testing through it... Didn't really seem to impact anything in reality (except now the site "flashes" due to the lack of CSS early on lmao)

@finlaydag33k doesn't seem much different no. It does however provide another insight. If you inline your background color on the html and body tag, you can shorten the white paint frame. Which is a small win on slow computers, which we did years ago as a trick :D

Sign in to participate in the conversation
Linux.Pizza

A instance dedicated - but not limited - to people with an interest in the GNU+Linux ecosystem and/or general tech. Sysadmins to enthusiasts, creators to movielovers - Welcome!