https://metacpan.org/author/PERLANCAR takes a long time to display here.

[shlomif]

Hi all,

I am using firefox-45.0.1-3.mga6 on Mageia Linux x86-64 v6 and am connected to the Internet using Bezeq International with a 10 mega-bit downstream / 1 mega-bit upstream ADSL connection. Now, viewing https://metacpan.org/author/PERLANCAR takes a long time to load and Firefox complains about an unresponsive script.

Looking at the downloaded HTML page (using wget), it seems that it has some unnecessary markup bloat, e.g:

• Unnecessary leading (indentation/etc. or trailing whitespace )
• Unnecessary empty lines.
• Long HTML/CSS "class=" names - these can be shortened using the CSS ".wrapper .${short_class_name_here}" idiom or possibly removed entirely using CSS 3.x or jQuery.
• An excessive number of title="..." or sort="..." HTML attributes that are identical to the content of their containing element.
• Verbose and overly detailed date strings.

People have been complaining about the sizes of web pages becoming larger:

• https://twitter.com/xbs/status/626781529054834688
• https://www.reddit.com/r/programming/comments/3z0hg2/the_website_obesity_crisis/

I'm willing to try to send some pull-requests to help rectify the situation on metacpan.org if there's some consensus that what I say has merit.

Regards, -- @shlomif

[haarg]

The real issue here is that there is a javascript function that converts the dates into a more friendly format. Looping through all of the dates to convert them is taking a lot of time. I haven't looked into how that function could be optimized.

[shlomif]

@haarg : thanks for your comment.

[haarg]

My last comment was incorrect. The actual slowdown is from the code that abbreviates the release name column. I don't believe we'll be able to fix that without losing some functionality, so I don't have a suggested fix at this time.

[oalders]

I guess we could look at paginating results for a page of this size.

[gordon-fish]

Would it not be worth considering doing the abbreviation conversion on the server side if that's what's slowing things down so much? Not everything is suitable for off-loading onto the client. Things like this would probably be far more efficiently handled by the server than in client-side js.

In fact, this seems to be the sort of trap that a lot of web-sites these days fall into: off loading too much onto the client-side. One of the primary goals of web-design used to be to have as uniform an experience across the board as possible, but from I've been seeing in the wild the past couple years, relying too much on the speed of the client-side can really hinder that.

People used to be able to just hand down an older computer for web-browser and email tasks, which were considered to be very light duty, but now it seems one needs an almost top of the line system to render some sites in a usable capacity.

[ranguard]

@gordon-fish how would the server side know the browser width and therefor where to chop the abstract at?

[ranguard]

I guess one could use JS to work it out, then set a cookie or something, and then have every page reload if the cookie isn't set - but that still requires JS and a lot of faffing around and the page would look broken as you resided the window, then you'd also have to change the cookie.. oh and reload the page if the size did change....

I get your point, somethings can/should be done server side... but this isn't one of them.

[szr8]

@ranguard Could you please elaborate? If I load the page with and without JS enabled, the only difference I see if the Favorites table is not sorted in the former case (where the page loads instantly.)

[ranguard]

This bit here gets truncated depending on browser window size

[gordon-fish]

@ranguard That doesn't seem to be what's causing the slow down. From what I can tell it's the sorting of the Favorites table.

[ranguard]

Oh, well if thats it, then sounds like server side would be good - we love pull requests :)

[haarg]

@gordon-fish what are you basing that on?

The abbreviation that causes problems is the release names, not the abstract. It doesn't make sense at all to do in on the server.

[kentfredric]

@szr8 also, this part of the page is computed by some javascript brute force, and can't be done server-side because of font-metrics, proportional kerning[1] and rendering-engine specific behaviour:

And this is a fine example why it needs to be infix shortening, not suffix shortening, as only the suffixes are different.

1: Proportional font not shown as I force a fixed-width one locally.