http requests and modules

[Guest]

recently, all the rage for fast websites is about lowering the numbers of http requests. I'm sure you're aware of that.

I was wondering: each module creates in fact an http request, right?

I'm using quite a few modules, especially web contents (for footer, header, navigation…) with the idea of making my site very "modular".

Would that be then a case of wrong tools implementation?

[Liam Dilley]

Hey there. I think you need to read up a bit more on http requests  . Optimizing you site us nothing new and BC modules a d tags are system tags which are rendered server side not by http requests. You can see what is going on through the console for example.

Do some googling on the topic 🙂

[Guest]

Right Liam,

you're always telling me to study more.

I agree but just be patient.

I  think you have forgotten how much there is to learn!

I'm actually full of admiration about how you people can keep up with all this new stuff!

I'm back to the Web from the nineties when you didn't have to worry much besides tables and images optimization which, by the way, was understood in a totally opposite way.

(Then) big images? slice them up!

(Now) many small images? squeeze them together (less http reqs).

And there was no question about javascript, because most people were afraid of javascript...

As always, thank you for your kindness. Good community here at BC!

[kenneth_rapp]

If you want to reduce http requests I suppose you could look at consolidating your javascript. I've seen a lot of sites pepper their jquery throughout their page, for instance, instead of in a single file. I don't know how BC handles caching either but that could help as well.

[Liam Dilley]

One of the things the BC team are good at is the tech and the core system code and I know they do a good job there. Is just  the actual web stuff they can miss a bit sometimes for us and our clients 🙂

Ken is right in terms of what you can do and reducing what you call in the head to help keep those requests down.

Optimising the way you call and run your JavaScript is a big one. Keeping it out the head, lazy loading and well optimised scripting, especially with BC is essential.

[Guest]

Hi Liam, I'm happy you trust so much BC people.

I'm not mocking you here, believe me.

I know very little  about this platform yet  and I got the impression (just the impression) that it is somewhat bulky.

I like BC and I know Adobe generally does a very good job with their products (even though, if you divide the universe into "features rich" and "fast" you mostly find them in the first group)

What I'm saying here is: I'm happy to be wrong!

Happy Xmas to both of you (and, why not, to the BC team)!

[Guest]

thank you Kenneth,

consolidating the javascript is not a problem.

In fact my question was kind of a theoretical (I did not do any speed test or whatever).

I'm not even sure if I understand exactly what http requests are. I thought: "if an image is an http request then also a module should be!"

Anyway, what in essence you and Liam are telling me is: use as many modules as you like because there won't be  any speed issue whatsoever... correct?

[kenneth_rapp]

There may or may not be a lag issue IRT the time it takes the server to compile html from the modules and, of course, in terms of the number of embedded requests in the resulting page itself. One of the staff can talk about this further but being Adobe I'm comfortable assuming they have that whole part of the process as optimized as they can. They probably precompile the html periodically and distribute the pages across servers to balance load, or any number of crazy dark-magical big data things I couldn't even begin to understand.   Modules aren't accessible by http request because they operate 'behind the scenes' as it were and the user at home is only aware of the result of their processes. Your browser can't request a module directly, but can request what the module generates (a blog, whatever.)   The issue with 'using as many modules as you like' is only that doing so results in bulkier pages, which, themselves, might load more slowly with their required scripts and whatnot. All you can really optimize here in that regard is the html/javascript code itself, and even then BC doesn't currently give you access to all of your frontend code, so there's a ground state you can't affect.  I wouldn't worry too much about this either (although it's always a good idea to optimize page loads where you can) and in my opinion (barring IE6 and maybe 7) you should put more effort into compatibility and usability than optimizing for speed.

[Guest]

thank you Kenneth,

I think I understand what you are saying here*.

So, then I'm right in being a little wary about modules!

I was trying to modularize my site using the web contents modules (one for the header, one for each footer, one for the navigation etc.) but then I felt it was better to use a good template system instead...

I agree about compatibility/usability (I'm deep into responsive stuff now - not easy!) but I also worry about fast downloading (especially for  mobiles).

That's what  makes the web so damn complicated nowadays: so many things are important. Not easy to strike the right balance...

And what do you mean with the IE6/7 bit?

That they are slow no matter or that we might forget about them (unfortunately I do not think I can)?**

*besides IRT. I found: Indiana Repertory Theatre, International Racehorse Transport, International Racquetball Tour ... which one?

... oh, forgive my cheap joke! But really: what does it mean?

**I hate IE (I'm in a mac). I thought I was almost ready with my site but when I tested it in IE it was a total mess.

I have to start all over again probably with the help of some framework (like Bootstrap or Foundation or maybe the interesting Semantic Grid Sytsem... we will see)

[Liam Dilley]

Nope

Run a test on a page with heaps of modules and then not. You wont see any difference other then the content rendering such as images etc that the extra content getting produced from modules (which is what people will say not thinking its the content). Unless you have a test of a flat page and same page as a module.

Of course certain modules producing certain content IF that content was done manually may cause more HTTP requests but in both cases they would.

It is more that modules have a server side process which in terms of minute time ( Milliseconds) will have a render time but not associated fully with the requests just server rendering.

Your also not on Apache here, your on the full Windows .NET environment and the server process is very streamlined due to its enclosed nature.

And yes, slow browsers will render pages slower. Even up to windows 9 not a lot of people realise but you have HEAVY Caching in IE. If you do a partial refresh of a page using ajax, all browsers work fine but IE wont update images through this method without some silly randomisation of url calls. Why? Because to similulate better perfomance IE caches a lot heavier to fake speed. LOL

In terms of Building an awesome BC site there are far more things to focus on to be honest.

[kenneth_rapp]

Liam is right. If you were running, say, Wordpress on a shared server then it might matter when you could actually get at the php code and mess around with headers and static caching and such, but I think you're attempting to overoptimize in this case, just using BC makes that mostly not your problem.

   IRT = in regards to.

Old versions of IE are notorious for their lack of support for certain css/js features, bugginess (the z-index bug for instance) and needing ugly workarounds and hacks just to get them to support or pretend to support or not die horribly in the presence of modern standards-compliant code.

IE6 in particular is important because it's very buggy AND prevalent in enterprise environments, where for various reasons, upgrading to a new browser is all but impossible (which means if you're building a site meant to be viewed by businesses, IE6 support is expontentially more important than if, say, you're putting up a blog and don't really care.) Although most modern frameworks like Boostrap and Skeleton, and js syntactic libraries like jQuery, are built with this in mind and abstract the issue away by including those hacks themselves, sooner or later you'll run into some kind of code that works brilliantly in every single browser you try... except the old versions of Internet Explorer (and then you end up looking around Stackoverflow for an hour or two looking for the fix.) 

Currently various sites and even Microsoft are trying to phase out support for IE6. I personally think if you're using IE6 you should just be willing to deal with broken websites in the same way that if I drive a Ford Model-T onto the highway I should soon expect to  have a broken car. But understandably, sites that might lose money not supporting IE6 have to deal with it.

[Liam Dilley]

Lots of things are dropping IE7 or already have such as google.

In terms of optimising headers, who should be doing this? If your building a big website with some core features for a big company in house which may have extranet features etc. OR if you were building a web application yourself you would.

BC is not for that, BC do that for you. It is their focus and their role to optimise this side of things in the system so you do not have to worry about it. It is one of the things about BC that is appealing

[Guest]

Liam and Kenneth.

Ok, then. I feel like I can relax now (about BC).

Thank you for your enlightening and thorough explanations.

Really interesting. I always learn a lot asking questions in this forum. Even beyond the scope of the original question.

Adobe should give you prizes for your dedication. Maybe they do but if they don't, they should!

Oh my, I did not notice that I could reward you myself with points. Sorry, I'll do immediately...

best wishes and enjoy a nice holiday