If you are going to use HTTPS, use it for everything please


Recommended Posts

Out of interest, why is making CSS inline an advantage? On generated pages, that would just mean sending the same hunk of CSS/JS every time - which would be rather pointless IMO.

 

Just because the page is generated (WordPress, Invision and any other PHP will share the same fate in terms of page loads and even if the template is loaded through MySQL), the page is loaded within one shot. Generated pages are transferred and THEN loaded (only takes 20ms-100ms to generate depending on how light or heavy the SQL queries are), it doesn't JUST come out like a printer. When you load CSS/JS through inline code instead of <link> and <script>, it lets all other elements after it load or else using those two objects will block anything before it until if finishes loading. Which means, the rest of the page must wait in line until the rest of any other source based object is loaded. This is why asynchronous javascript has been created, to load objects the same time as all the others and not worry about "render-blocking".

 

Generated means nothing if the server is fast. But it's the browser and your network's own responsibility to load such CSS and Scripts that are being loaded from another domain or directory. So making all the load load within one HTML page makes it load drastically faster because you have less HTTP calls to make. iFrames are apparently also render blocking. I can easily give you the whole heads up through my own sites as I'm developing a new sneaker website that demonstrates performance as well as maintaining aesthetics.

Link to comment
Share on other sites

Just because the page is generated (WordPress, Invision and any other PHP will share the same fate in terms of page loads and even if the template is loaded through MySQL), the page is loaded within one shot. Generated ages are transferred and THEN loaded, it doesn't JUST come out like a printer. When you load CSS/JS through inline code instead of <link> and <script>, it lets all other elements after it load or else using those two objects will block anything before it until if finishes loading. Which means, the rest of the page must wait in line until the rest of any other source based object is loaded. This is why asynchronous javascript has been created, to load objects the same time as all the others and not worry about "render-blocking".

 

Generated means nothing if the server is fast. But it's the browser and your network's own responsibility to load such CSS and Scripts that are being loaded from another domain or directory. So making all the load load within one HTML page makes it load drastically faster because you have less HTTP calls to make. iFrames are apparently also render blocking. I can easily give you the whole heads up through my own sites as I'm developing a new sneaker website that demonstrates performance as well as maintaining aesthetics.

 

Having all of that code inline would massively increase the size of each page being loaded. Once the CSS and JS files are loaded, they're then cached on the client's browser, and don't need to be loaded again on each request. This saves a lot of bandwidth, and makes the pages load quicker than they would if you inlined everything.

Link to comment
Share on other sites

Having all of that code inline would massively increase the size of each page being loaded. Once the CSS and JS files are loaded, they're then cached on the client's browser, and don't need to be loaded again on each request. This saves a lot of bandwidth, and makes the pages load quicker than they would if you inlined everything.

 

But let's take it from a WordPress perspective. You're running Nginx, PHP-FPM, MySQL and WP Super Cache. Using WP Super Cache and you can make all the pages load through pure HTML (no SQL) and make sure Nginx loads the HTML pages through URI requests, and if they're not yet created, lead to the real site and have the real site generate the HTML pages. That right there murders performance. I'm talking making 5k users run on a $5 Digital Ocean server (trust me, I've accomplished it). Such HTML pages with all the inline code that are conditioned from server to cached pages will be no more than 50-100kb tops. So the size of the page is not even a worry. Especially when everything is being minimized left and right. Cloudflare, Gzip, keep-alive and all.

 

Inline code is small, and not all JS can be loaded internally no thanks to companies like Google AdSense. So inlining an asynchronous request is also of benefit. And don't forget that there are sites, I have sites where 80% of the users are new visitors as the site grows with 1000s of new users every week. So cache is not always useful on the first visit. With inline, I loaded the site immediately instead of waiting for the rest of the lines to show up.

Link to comment
Share on other sites

But let's take it from a WordPress perspective. You're running Nginx, PHP-FPM, MySQL and WP Super Cache. Using WP Super Cache and you can make all the pages load through pure HTML (no SQL) and make sure Nginx loads the HTML pages through URI requests, and if they're not yet created, lead to the real site and have the real site generate the HTML pages. That right there murders performance. I'm talking making 5k users run on a $5 Digital Ocean server (trust me, I've accomplished it). Such HTML pages with all the inline code that are conditioned from server to cached pages will be no more than 50-100kb tops. So the size of the page is not even a worry. Especially when everything is being minimized left and right. Cloudflare, Gzip, keep-alive and all.

 

Inline code is small, and not all JS can be loaded internally no thanks to companies like Google AdSense. So inlining an asynchronous request is also of benefit. And don't forget that there are sites, I have sites where 80% of the users are new visitors as the site grows with 1000s of new users every week. So cache is not always useful on the first visit. With inline, I loaded the site immediately instead of waiting for the rest of the lines to show up.

Taking a quick look, we have ~150KB of CSS (just looking at the resources used on this page). Given that they're separate files, the browser will cache those files, meaning they have to be downloaded once. Bandwidth: 150KB per user, every time the file is changed, or the user does a hard refresh.

If that was inlined, because the page content changes, it can't be cached, meaning we'd have to send that 150KB with every request. I'm not talking about the time it takes to generate the page, I'm talking about the actual bandwidth. I have no idea what our stats are right now, but say your site has 1,000 page views per minute (to keep the numbers nice). That's 150MB/minute in additional bandwidth, which would equate to roughly 6.4TB/month in additional traffic - simply because the CSS wasn't being cached by the browser.

Link to comment
Share on other sites

Taking a quick look, we have ~150KB of CSS (just looking at the resources used on this page). Given that they're separate files, the browser will cache those files, meaning they have to be downloaded once. Bandwidth: 150KB per user, every time the file is changed, or the user does a hard refresh.

If that was inlined, because the page content changes, it can't be cached, meaning we'd have to send that 150KB with every request. I'm not talking about the time it takes to generate the page, I'm talking about the actual bandwidth. I have no idea what our stats are right now, but say your site has 1,000 page views per minute (to keep the numbers nice). That's 150MB/minute in additional bandwidth, which would equate to roughly 6.4TB/month in additional traffic - simply because the CSS wasn't being cached by the browser.

 

150kb makes me cry sometimes, but I suppose that's the way general content is designed. Leverage is a huge factor yes, I'll take cache into consideration if the file is large. But imagine, how do we load large, cached CSS/JS without render blocking? For a lot of sites that use Google AdSense, it's more crucial to get AdSense to show as fast as possible. But having to wait for everything to load is a pain, especially when you're behind Cloud...wait, are you guys using CloudFlare/Railgun?

Link to comment
Share on other sites

  • 1 month later...

HTTPS is not supported for non-subscribers/staff. If you are experiencing issues trying to use the site over HTTPS rather than plain HTTP (aside from login, where HTTPS is supported for all), then simply switch to HTTP, as that is the only supported way to use the site.

Notification block generated from forum thread has https links for both the user and the thread link.

Link to comment
Share on other sites

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.