Arthur Haine
Rank: #14405
42Views
8Comments
Solved
How can I avoid long id's on elements (and reduce HTML output page size)
Question

Hi,

Can anyone advise me on how to reduce the length of the ID's as rendered in HTML?

We are building a website where performance is important.


Here is my case:

OutSystems uses the hierarchical block names. When nesting blocks (as we need to do I guess)  the whole hierarchy becomes a part of the name. 

For example:

I have a header block, in the header placeholder of the layout ,which has a menu item that opens a custom dropdown menu that contains tabs, and on each tab content there is a gallery of categories and subcategories with links.

Because we use nested lists we have nested web blocks (each represented as a span with an even longer ID).

To give an idea, the subcategories end up with ID's like these (just for reference):

id="XXXXXXX_Theme_wtDetailPage_block_OutSystemsUIWeb_wt15_block_wtHeader_wtHeader_XXXXXXX_WI_wt18_block_wt61_wtMenuContainer_OutSystemsUIWeb_wtCategoriesContent_block_wtTabs_Content_wtListTabContent_ctl00_OutSystemsUIWeb_wt26_block_wtContent_wtsubcatlist_wtListSubCategories_ctl00_wt3_wtListSub_SubCategories"

These ID's will take 50% of the HTML output for that menu. As we have a lot of categories and this menu is on every page this will become a performance penalty.

Any idea's?

I have tried naming the blocks and elements with short names but this only gets the space used to avbout 40%.

 
 

0
0
on 2019-08-06
Copy link to comment
Ruben Goncalves
mvp_badge
MVP
Rank: #10
Solution

Hi Arthur,

How are you measuring performance?
How have you notice performance impact with those IDs?

I've stumbled and being concerned with this in the past, however, I came to the conclusion that actually that is not relevant and has no impact in the website performance.

Why?

If your server is well configured, it means it will compressing the content before leaving the server (e.g. using GZIP). And this will reduce your html to a irrelevant size (typically in KB).

There are other things that you should be concern about, much more than that.

Cheers,

RG

2
0
on 2019-08-06
Copy link to comment
Kilian Hekhuis
mvp_badge
MVP
Rank: #2

It indeed looks like premature optimization. And in addition to what Ruben says, modern HTML pages are typically pretty large compared to the text of a few identifiers. Think of JavaScript, CSS, cookies, viewstate etc., not all of which you can control.

I would advise you to check the statistics for the page in LifeTime, and you'll probably see that client and server time is much, much larger than network time (as is typical).

1
0
on 2019-08-06
Copy link to comment
Arthur Haine
Rank: #14405

I guess I'm used to keeping my HTML output as clean as possible (background in CMS development). 

Indeed there are other things I should perhaps be more concerned about. 

Thanks for the quick replies! 


1
0
on 2019-08-06
Copy link to comment
Kilian Hekhuis
mvp_badge
MVP
Rank: #2

You're welcome, good luck!

1
0
on 2019-08-07
Copy link to comment
Miguel 'Kelter' Antunes
mvp_badge
MVP
Rank: #3

Sorry to bring back this topic... But let me disagree with what was said here, and let me explain why.

Currently, we're having performance issues with one application, and that is mainly because of the huge ids that lead to huge HTML.

While rendering a page this is "not that important", that's not the same when we talk about Ajax Refresh!

We have a complex table records, and when we do filter, we have an Ajax Refresh to refresh the table, this will be called through one XHR call by the platform, as shown below:

This response contains all the HTML that was changed due to the filtering, and is "returned" from the Ajax Refresh, and as I said our table is a bit complex, making this response size around 1.8mb (and trust me, it was already highly refactored to have fewer nodes as possible).

While the server might compress the payload, we still have to process this 1.8mb! 

The platform first injects this 1.8mb in the HTML document, and after that the OsJSONUpdate still needs to process 1.8mb of data, and part of that process will be writing back the html to the page.

That being said, if we had smaller Ids, we would have way less than 1.8mb of HTML to process!

That are my 2 cents on this matter :)

1
0
on 8th Jan
Copy link to comment
Kilian Hekhuis
mvp_badge
MVP
Rank: #2

Have you checked what percentage of that 1.8MiB is the Ids, and what could be the size reduction if smaller Ids were used (given that all Ids must still be unique)? "Way less" is your educated guess, but not very scientific :).

0
0
on 11th Jan
Copy link to comment
Miguel 'Kelter' Antunes
mvp_badge
MVP
Rank: #3

Replying to Kilian Hekhuis' comment on 11 Jan 2021 08:10:59

Sure I did, each table line have around 37kb of HTML with all the Ids. After cleaning up the HTML from that long generated Ids I got each line to be around 13kb, that's a 46% less HTML.

0
0
on 11th Jan
Copy link to comment
Kilian Hekhuis
mvp_badge
MVP
Rank: #2

Replying to Miguel 'Kelter' Antunes' comment on 11 Jan 2021 15:03:32

That's indeed quite some reduction. Perhaps time for an Idea? :)

0
0
on 11th Jan
Copy link to comment