Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation
 
PerlMonks  

PM CSS and markup optimizations

by kimmel (Scribe)
on Jul 11, 2012 at 19:33 UTC ( [id://981238]=monkdiscuss: print w/replies, xml ) Need Help??

While working on the redesign I became familiar with the existing CSS on PM. When an anonymous user loads the main page two CSS files are downloaded. common.css and Blue web-safe CSS. Using different tools and verifying against a list of 105 PM pages I was able to determine what CSS was not being used. This CSS can be removed which mean less data needs to be sent to the end users.

HTML comments were another thing I found that can be stripped out. Here is the before and after of the main page:

Current version:
$ wc pm_divs.html 
 1545  6537 73719 pm_divs.html

After stripping comments:
$ wc pm_divs.html 
 1515  5942 70317 pm_divs.html

A savings of 3,402 bytes for the main page and similar savings for all other pages on the site as well. Talk about some major bandwidth savings. I also found empty paragraph tags that I stripped out as well. Furthermore I noticed that the content being delivered does not include ‘Content-Encoding gzip’ or any other indication of compressions. As numerous studies have shown compression is a good thing.

So why is there no compression before transmission of a web page?

Edit: Linked to the CSS files.

Replies are listed 'Best First'.
Re: PM CSS and markup optimizations
by cavac (Parson) on Jul 11, 2012 at 22:24 UTC

    Very nice! Good work!

    BTW, you could also copy the original CSS files for editing and use CSS::Minifier::XS on the production file for even more saved bytes.

    I just noticed that some of the Nodelets (like "Other users" and "* Best") are peppered with span-elements for even/odd row coloring. Given that these nodelets are mostly link lists, with the link color provided by the browser, this also seems to achieve nothing else than wasting bandwidth (and the nodelets are not cached, compared to the CSS file which are). Maybe you could take a look at that, too?

    Sorry for any bad spelling, broken formatting and missing code examples. During a slight disagreement with my bicycle (which i lost), i broke my left forearm near the elbow. I'm doing the best i can here...
      Yes, this:
      <span class="other-users-text">Others <span class="other-users-blurb"> +examining</span> the Monastery:</span> (12)<br /><ul class="spacey-li +st"><li><span class='even-row'><span class='item-000'><span class='us +er-level-24'><span class='user-461912'><a href="?node_id=461912" titl +e="GrandFather's home node. Level 24. Member of: janitors, pmdev">Gra +ndFather</a></span></span></span></span></li> <li><span class='odd-row'><span class='item-001'><span class='user-lev +el-20'><span class='user-421114'><a href="?node_id=421114" title="Tan +ktalus's home node. Level 20. Member of: pmdev">Tanktalus</a></span>< +/span></span></span></li> <li><span class='even-row'><span class='item-002'><span class='user-le +vel-18'><span class='user-70929'><a href="?node_id=70929" title="atcr +oft's home node. Level 18">atcroft</a></span></span></span></span></l +i> <li><span class='odd-row'><span class='item-003'><span class='user-lev +el-14'><span class='user-212789'><a href="?node_id=212789" title="the +zip's home node. Level 14">thezip</a></span></span></span></span></li +> <li><span class='even-row'><span class='item-004'><span class='user-le +vel-14'><span class='user-20250'><a href="?node_id=20250" title="pemu +ngkah's home node. Level 14">pemungkah</a></span></span></span></span +></li> <li><span class='odd-row'><span class='item-005'><span class='user-lev +el-14'><span class='user-861371'><a href="?node_id=861371" title="kco +tt's home node. Level 14">kcott</a></span></span></span></span></li> <li><span class='even-row'><span class='item-006'><span class='user-le +vel-11'><span class='user-161890'><a href="?node_id=161890" title="La +dy_Aleena's home node. Level 11">Lady_Aleena</a></span></span></span> +</span></li> <li><span class='odd-row'><span class='item-007'><span class='user-lev +el-10'><span class='user-890813'><a href="?node_id=890813" title="cav +ac's home node. Level 10">cavac</a></span></span></span></span></li> <li><span class='even-row'><span class='item-008'><span class='user-le +vel-8'><span class='user-806480'><a href="?node_id=806480" title="Nei +ghbour's home node. Level 8">Neighbour</a></span></span></span></span +></li> <li><span class='odd-row'><span class='item-009'><span class='user-lev +el-7'><span class='user-971084'><a href="?node_id=971084" title="froz +enwithjoy's home node. Level 7">frozenwithjoy</a></span></span></span +></span></li> <li><span class='even-row'><span class='item-010'><span class='user-le +vel-4'><span class='user-910459'><a href="?node_id=910459" title="kim +mel's home node. Level 4">kimmel</a></span></span></span></span></li> <li><span class='odd-row'><span class='item-011'><span class='user-lev +el-1'><span class='user-243505'><a href="?node_id=243505" title="im2' +s home node. Level 1">im2</a></span></span></span></span></li> </ul><span class='update-time'><small>As of 2012-07-11 23:30 GMT</smal +l></span>
      can be made simpler too. I will make sure to add a CSS rule and strip this all out of the demo version.
Re: PM CSS and markup optimizations
by thomas895 (Deacon) on Jul 12, 2012 at 04:13 UTC

    Some people like comments. I, for one, find them interesting. Others may be interested in how PerlMonks has the HTML structured, and they don't feel like running it though a beautifier every time. After all, we want to encourage learning, and not push away those who are curious, right?

    Sure, it would save bandwidth. I don't know how much the server costs for PM, but if it's one of those "unlimited" plans, then it would be rather useless. Again, we seem to have gotten along just fine with how it is now, so there is no real reason for change.
    I understand that some users have bandwidth restrictions on their end, so perhaps it could be enabled as a setting. That would probably be the best idea.

    ~Thomas~
    confess( "I offer no guarantees on my code." );
      Some people like comments. I, for one, find them interesting. Others may be interested in how PerlMonks has the HTML structured, and they don't feel like running it though a beautifier every time.

      Have you looked at the comments in a PM page? Here are all the comments from the landing page:

      <!-- Took this out for IE6ites "http://www.w3.org/TR/REC-html40/loose. +dtd" --> <!-- Theme : Web safe blue PerlMonks Theme --> <!-- No CSS Link in User Settings --> <!-- No CSS Data in User Settings --> <!-- monktainer --> <!-- monkbar2001 --> <!-- /monkbar2001 --> <!-- Begin title bar --> <!-- superdoc title chooser(1) --> <!-- /superdoc title chooser(1) --> <!-- monktitlebar --> <!-- /monktitlebar --> <!-- superdoc title chooser(2) --> <!-- superdoc title chooser(2) --> <!-- End title bar --> <!-- Begin main (monktainer) --> <!--contained stuff--> <!-- Begin Post --> <!-- embed node with vote container --> <!-- TITLE --> <!-- REPLIES --> <!-- AUTHOR --> <!-- DATE --> <!-- End Post --> <!-- Begin Post --> <!-- embed node with vote container --> <!-- TITLE --> <!-- REPLIES --> <!-- AUTHOR --> <!-- DATE --> <!-- End Post --> <!-- Begin Post --> <!-- embed node with vote container --> <!-- TITLE --> <!-- REPLIES --> <!-- AUTHOR --> <!-- DATE --> <!-- End Post --> <!-- Begin Post --> <!-- embed node with vote container --> <!-- TITLE --> <!-- REPLIES --> <!-- AUTHOR --> <!-- DATE --> <!-- End Post --> <!-- Begin Post --> <!-- embed node with vote container --> <!-- TITLE --> <!-- REPLIES --> <!-- AUTHOR --> <!-- DATE --> <!-- End Post --> <!-- Begin Post --> <!-- embed node with vote container --> <!-- TITLE --> <!-- REPLIES --> <!-- AUTHOR --> <!-- DATE --> <!-- End Post --> <!-- Begin Post --> <!-- embed node with vote container --> <!-- TITLE --> <!-- REPLIES --> <!-- AUTHOR --> <!-- DATE --> <!-- End Post --> <!-- Begin Post --> <!-- embed node with vote container --> <!-- TITLE --> <!-- REPLIES --> <!-- AUTHOR --> <!-- DATE --> <!-- End Post --> <!-- Begin Post --> <!-- embed node with vote container --> <!-- TITLE --> <!-- REPLIES --> <!-- AUTHOR --> <!-- DATE --> <!-- End Post --> <!-- Begin Post --> <!-- embed node with vote container --> <!-- TITLE --> <!-- REPLIES --> <!-- AUTHOR --> <!-- DATE --> <!-- End Post --> <!-- Begin Post --> <!-- embed node with vote container --> <!-- TITLE --> <!-- REPLIES --> <!-- AUTHOR --> <!-- DATE --> <!-- End Post --> <!-- Begin Post --> <!-- embed node with vote container --> <!-- TITLE --> <!-- REPLIES --> <!-- AUTHOR --> <!-- DATE --> <!-- End Post --> <!-- Begin Post --> <!-- embed node with vote container --> <!-- TITLE --> <!-- REPLIES --> <!-- AUTHOR --> <!-- DATE --> <!-- Node text goes above. Div tags should contain sig only --> <!-- End Post --> <!-- Begin Post --> <!-- embed node with vote container --> <!-- TITLE --> <!-- REPLIES --> <!-- AUTHOR --> <!-- DATE --> <!-- End Post --> <!-- Begin Post --> <!-- embed node with vote container --> <!-- TITLE --> <!-- REPLIES --> <!-- AUTHOR --> <!-- DATE --> <!-- Node text goes above. Div tags should contain sig only --> <!-- End Post --> <!-- Begin Post --> <!-- embed node with vote container --> <!-- TITLE --> <!-- REPLIES --> <!-- AUTHOR --> <!-- DATE --> <!-- End Post --> <!-- Begin Post --> <!-- embed node with vote container --> <!-- TITLE --> <!-- REPLIES --> <!-- AUTHOR --> <!-- DATE --> <!-- End Post --> <!-- Begin Post --> <!-- embed node with vote container --> <!-- TITLE --> <!-- REPLIES --> <!-- AUTHOR --> <!-- DATE --> <!-- End Post --> <!-- Begin Post --> <!-- embed node with vote container --> <!-- TITLE --> <!-- REPLIES --> <!-- AUTHOR --> <!-- DATE --> <!-- End Post --> <!--/contained stuff--> <!--nodelet handling code (monktainer)--> <!-- Begin nodelets --> <!-- Nodelet Break --> <!-- Nodelet Break --> <!-- Nodelet Break --> <!-- Nodelet Break --> <!-- Nodelet Break --> <!-- Nodelet Break --> <!-- Nodelet Break --> <!--<li>[http://planet.perl.org/|Planet Perl]</li>--> <!-- Nodelet Break --> <!-- End nodelets --> <!--/nodelet handling code (monktainer)--> <!-- End main (monktainer)--> <!-- /monktainer -->
      That is 168 lines, 3,932 bytes of data sent per page load, less for pages with less content.

      What does that tell us? There is:
      • Commented out code for IE
      • The name of the CSS theme which is already listed at the top of the CSS file.
      • No CSS Link in shows us 2 external sources were not configured. Why does a normal end user need to know this?
      • Information about different parts of the header and title bar
      • Start a Post with TITLE, REPLIES, AUTHOR, DATE fields
      • The post comments repeat with slight variations.
      • Nodelets have breaks!
      • A commented out link
      • Containers are closing

      That reads like a list of debug statements. It is not a good practice to emit debug statements in production software. Commented out code should never stay around, we have version control for tracking changes. In addition, these comments provide no direct value to the general users of PM. Users are here to ask/answer/learn about Perl not focus on the markup for the content that was delivered to them. There are sites specifically designed for that purpose like CSS Zen Garden.

      Sure, it would save bandwidth. I don't know how much the server costs for PM, but if it's one of those "unlimited" plans, then it would be rather useless. Again, we seem to have gotten along just fine with how it is now, so there is no real reason for change.

      So saving bandwidth is good but we should not do it because PM does not need to change. Right. Delivering a smaller HTML page and CSS files makes the PM experience better. Faster page loads always make users happy and slower pages make users look for alternatives.

      I understand that some users have bandwidth restrictions on their end, so perhaps it could be enabled as a setting. That would probably be the best idea.

      This suggestion is not the "best" idea. It would require changes to the server software for processing each page on a per user basis. A simpler solution is just to take snapshots of a few pages, do a writeup and include those pages with the writeup on PM itself which is much easier work then editing the server software to add new features. Users can still study how PM works without sending data that is meaningless to most to all users.

      And then there is this statement: After all, we want to encourage learning, and not push away those who are curious, right?

      A flippant statement to prop up a strawman argument. Making statements like this just makes you look bad, point of fact.

        That reads like a list of debug statements. It is not a good practice to emit debug statements in production software.
        And yet, everybody does it. Our good friends in PHP-land have plenty of well-known applications that emit debug statements in many places, as well. Of course, they are PHP users, and PHP people have a rather narrow mindset(but that is a different story), so that might be acceptable to them.

        Users are here to ask/answer/learn about Perl not focus on the markup for the content that was delivered to them.
        Notice how you basically ruined the foundation of your suggestion?

        By the way, did you know that you could also shorten the class names on the elements using them? For example, instead of .pmsig, we could make it .pms. Oh, we would save so many kilobytes on long threads!

        ~Thomas~
        confess( "I offer no guarantees on my code." );
Re: PM CSS and markup optimizations
by Anonymous Monk on Jul 12, 2012 at 07:18 UTC
Re: PM CSS and markup optimizations
by jdporter (Chancellor) on Jul 14, 2012 at 14:31 UTC

    What exactly is your goal? I've seen you address two different issues: 1. site styling; 2. performance, specifically page load time. These are both worthy, but I think it's a mistake to assume that the most gainful approach will be where they intersect -- namely, CSS.

    The performance of the site, such as manifest in page load time, is almost entirely due to its server-side architecture. You need to learn that before you can hope to address it.

    Styling, otoh, is something that really could use an expert's touch. I say this somewhere in Restyling PerlMonks, iirc.

    I reckon we are the only monastery ever to have a dungeon stuffed with 16,000 zombies.
Re: PM CSS and markup optimizations (compression++)
by tye (Sage) on Jul 14, 2012 at 07:57 UTC

    Thanks for the link direct to a list of "unused" CSS selectors. Just glancing at the list I can tell you that the majority of them are indeed used and so the list has much more to do with what features of the site you have tested / are aware of / can even access. So that work was mostly wasted.

    Talk about some major bandwidth savings.

    I will, but that will have to wait a paragraph or few. 5% seems unlikely to be "major savings" much less savings worthy of an exclamation like "talk about". 5% of $0 is also only $0. Even if we didn't get bandwidth via donation, my expectation would be that a 5% drop would be pretty unlikely to drop a site down to the next lower tier and actually result in any savings at all.

    Similarly, a 5% savings in data download duration is unlikely to be even noticed in terms of page load time at this site. Even a fanciful worst-case scenario would still only lead to "loads 5% faster" which is unlikely to be noticed by a human.

    Now, compression could actually make a difference (on bandwidth used, not what we pay, and on worst-case page loads, not on typical page loads). Compression likely leads to something closer to a 90% reduction, if my memories serve me well and are reasonably applicable.

    I don't currently recall being aware of an actual decision having been made regarding compression. But it seems plausible that compression was not enabled (or even was disabled) quite a long time ago when one of our bottlenecks was sometimes web server CPU.

    I haven't reviewed data on web server CPU covering long spans of time recently, but my spot checks due to other tasks have usually shown rather low usage rates lately. So I suspect enabling compression would not be a problem these days.

    So I plan to look into that (review more data, see how to enable it).

    - tye        

      Now, compression could actually make a difference

      I did some fairly large tests a year or two ago when i implemented it in my Maplat framework. Depending on the page size (i sometimes have fairly large data tables that i use with jQuery), compression even speeds up working within a 100MBit LAN.

      If the user works through a slow link (in this test me accessing the company network from home via an encrypted VPN tunnel), even small pages load quite a lot faster. Server performance degrades only slightly (e.g. the time the server requires to send out the page to the client), on DSL links the pages are still faster to load.

      CPU load isn't greatly increased on my server. Ok, i only get about 50.000-80.000 requests per hour, and only about 10.000 of those from clients that support compression, and it's all very database heavy.

      Sorry for any bad spelling, broken formatting and missing code examples. During a slight disagreement with my bicycle (which i lost), i broke my left forearm near the elbow. I'm doing the best i can here...

        Just to offer some minor clarifications. The reason I don't think compression will make a big difference on typical page load times is that I expect at PerlMonks that most slow page loads are due to slow server response, not due to large amounts to be downloaded. But, yes, for people on slow links, compression could make a big difference even when PerlMonks is being slow to respond.

        I also don't expect compression to be a source of large amounts of CPU consumption. It was just that, at a time when the web servers were often just running out of CPU, taking CPU to compress the pages was as likely to make the server response enough slower that the net result was not an improvement. Even more important, when a web server got overloaded (ran out of CPU), adding to the CPU load for every page delivered would likely mean the overload condition would linger for longer (being slow leads to a build-up of requests which makes things slow...).

        Adding compression should be just a "win" at this point.

        - tye        

Re: PM CSS and markup optimizations
by Argel (Prior) on Jul 12, 2012 at 18:34 UTC
    That's a pretty short list, and a small sample of pages. What if some of these are used, just not that often? For example, spoiler tags are used much less often than e.g. code and readmore tags. And there are four different ways to present spoilers, so maybe it is only used for one of those. I think it's a good idea, but I'm concerned about the small sample size.

    Elda Taluta; Sarks Sark; Ark Arks
    My deviantART gallery

      I ran a new scan, this time with 444 pages instead of just 105 pages. The unused CSS selector count went from 35 to 34. So I am doing a much larger test right now to see if anything else gets picked up.

        Isn't this even irrelevant?

        The PM CSS files are far smaller than most websites. In fact I think you'd be hard pressed to visit any website with smaller CSS files. And more importantly, they are cached by the user's browser never to be requested again until the cache expires. So unless you are a very first time visitor to PM, it plays no part at all in the bandwidth of a PM web page load.

        So it's a small chunk of bytes that rarely get transferred anyway. If we were discussing Perl code instead of CSS markup there would have been several pointers about the pitfalls of pre-mature optimization by now.

        Sweating over the size of a CSS file is misdirected effort IMO.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: monkdiscuss [id://981238]
Approved by ww
Front-paged by cavac
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others pondering the Monastery: (5)
As of 2024-03-19 10:41 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found