Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

As LTT doesn't have it's own website app yet, I have been facing issues with this site that it takes a very long time to load, specially the staff page.

So I thought why not try this on Google PageSpeed tools.

Here's the result...

To be fair, even Youtube has nearly the same score, but it still feels snappy.

Maybe developers can try this website for tips, because I found this website amazing.

 

Anyways, make this website fast if not into an app!

Screenshot_20170717-174708.png

Screenshot_20170717-174656.png

Screenshot_20170717-174548.png

Screenshot_20170717-174542.png

-- BSOD : ( --

Link to post
Share on other sites

Lets see what you got there:

  • Optimize images. How? Most of images are from external sources already so they don't really have effect. It would be same as loading any other page with images. You can turn off content loading from browser.
  • Reduce server response times. Unlike YT, this forum is run from single location in US. We actually do have turbo mode which is usually used to counter DDoS attacks. And users hate it since it blocks some of features. Like real-time notifications.
  • Eliminate render-blocking JavaScript and CSS in above-the-fold content. I have no clue what that means. But blocking either would result more bad than good.

I have experienced few slowtimes past week. But generally its like it has been almost since beginning. IPB3 was snappier on mobile, but UI was just horrible in comparison. So I would take bit of loading over bad UI anytime.

^^^^ That's my post ^^^^
<-- This is me --- That's your scrollbar -->
vvvv Who's there? vvvv

Link to post
Share on other sites
32 minutes ago, LoGiCalDrm said:

...

Well, I'm new to website dev. and still at early stages of learning it.
But I thought this might be helpful, when you open the site, they give you some JS optimization tips and image optimization tips/tricks (never opened the links though.
And my main point was to attract attention towards making the site load faster, maybe local store the images for faster load?

And for server, isn't the backup server at linus' home is the second server?

PS - maybe "show how to fix" can help?

I'd love to hear and learn more on this.

Capture.JPG

-- BSOD : ( --

Link to post
Share on other sites
2 minutes ago, Zackbare said:

Well, I'm new to website dev. and still at early stages of learning it.
But I thought this might be helpful, when you open the site, they give you some JS optimization tips and image optimization tips/tricks (never opened the links though.

 

Trust me, I've seen the whole chance from alpha version of IPB4 to current stage. The guys doing developer stuff on our side of argument (IPS (forum software devs) being others) are good on what they do. They might not have time, like Mortis balancing between forum, FPC and personal life/projects. But this is as well optimized as it can be.

 

2 minutes ago, Zackbare said:

And my main point was to attract attention towards making the site load faster, maybe local store the images for faster load?

And for server, isn't the backup server at linus' home is the second server?

No, forums are run from US based server host and screened through network of Cloudflare servers. It might be Cloudflare causing some of slowness, but it also keeps site up better than not having it there. In past year there has been only one major DDoS incident. Though, this is what is known/told to users. I'm not official dev or anything like that. I just follow closely what happens on forums.

 

And in case you wonder would app help, answer is not much. Content loaded would be essentially same. Cache might make it faster but also take more space on device.

^^^^ That's my post ^^^^
<-- This is me --- That's your scrollbar -->
vvvv Who's there? vvvv

Link to post
Share on other sites
1 hour ago, LoGiCalDrm said:
  • Eliminate render-blocking JavaScript and CSS in above-the-fold content. I have no clue what that means. But blocking either would result more bad than good.

That basically means that Javascript and CSS that are not needed when the page loads should be at the bottom of the body, rather than in the header. It has nothing to do with blocking anything, just making it so that when the page loads, only the external requests that are required for the page to function loads, then the page content, then the scripts that are not necessary, but help improve the UI. 

Spoiler

Denali (Personal PC):

CPU - Ryzen 7 1700X | Motherboard - Asus CROSSHAIR VI HERO ATX AM4  | RAM - G.Skill Trident Z RGB 16GB (2x8GB) DDR4-3200 | Storage - Samsung 850 EVO - 500GB Boot SSD & 2TB Seagate Barracuda Storage HDD | GPU - Asus GeForce GTX 1080 Ti 11GB | PSU - Corsair HX Platinum 750W | Case - NZXT S340 (Black) | KeyboardRazer Blackwidow Ultimate 2016 - Razer Greens | Mouse -  A normal mouse.

Mist Server (unRAID Server):

CPU - (2) Intel Xeon E5-2690 v3 @ 3.2GHz | Motherboard - Asus Z10PE-D16 WS | RAM - Kingston 56GB (7x8GB) | Storage - (2) Samsung 960 Pro 1.0TB M.2-2280 SSD | GPU - NVIDIA Tesla M60 | PSU - Corsair AX1500i 1500W | Case - iStarUSA 3U Stylish Zinc-Coated Steel Rackmount Server Chassis | Keyboard - CHERRY G80-3000 MX Blue Stem Keyboard | Mouse -  A normal mouse.

 

Link to post
Share on other sites
2 hours ago, aidanapple said:

That basically means that Javascript and CSS that are not needed when the page loads should be at the bottom of the body, rather than in the header. It has nothing to do with blocking anything, just making it so that when the page loads, only the external requests that are required for the page to function loads, then the page content, then the scripts that are not necessary, but help improve the UI. 

Well, once the CSS & JS is in your browser's cache it will make almost no conceivable difference to the end user after the first load.

The slowest things on the page are external/user images which aren't optimized or compressed (which I would argue, should be done by the user before uploading).

Ideally, a bunch of those files would be concatenated but the number of them makes almost no difference when using http2.

The wait time on the main page load is quite slow though, averaging out at 600ms for myself. But considering I'm halfway across the world from the server it's not terrible.

Link to post
Share on other sites

Of the points made by Google Pagespeed, the only one that it's actually possible to fix is optimise images (the others are either impossible for a site like this or are about resources that we have no control over, such as ones hosted by Google themselves). Unfortunately optimising images (which means resizing them to be the size that they are displayed on the page) is actually impractical to implement because it involves storing multiple (about 6 I think) copies of each image, which then doesn't necessarily result in a speed improvement because you can't cache them as effectively. Not to mention that it would be very difficult to implement in the fourm software.

We do keep an eye on testers like this, but usually we have exhausted a lot of the optimisation options that there are.

HTTP/2 203

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×