<?xml version="1.0" encoding="UTF-8"?>
 <rdf:RDF xmlns="http://purl.org/rss/1.0/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:cc="http://web.resource.org/cc/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://pinboard.in">
    <title>Pinboard (Aetles)</title>
    <link>https://pinboard.in/u:Aetles/public/</link>
    <description>recent bookmarks from Aetles</description>
    <items>
      <rdf:Seq>	<rdf:li rdf:resource="https://web.dev/"/>
	<rdf:li rdf:resource="https://premium.wpmudev.org/wp-checkup/"/>
	<rdf:li rdf:resource="https://css-tricks.com/building-website-performance-monitor/"/>
	<rdf:li rdf:resource="http://rmurphey.com/blog/2015/11/25/building-for-http2"/>
	<rdf:li rdf:resource="http://daverupert.com/2015/11/framework-cost/"/>
	<rdf:li rdf:resource="https://fsdata.se/blogg/optimera-hela-din-wordpress-hemsida/"/>
	<rdf:li rdf:resource="http://sixrevisions.com/web-performance/improve-website-speed/"/>
	<rdf:li rdf:resource="http://www.smashingmagazine.com/2014/09/08/improving-smashing-magazine-performance-case-study/"/>
	<rdf:li rdf:resource="http://daverupert.com/2014/07/rwd-bloat-part-ii/"/>
	<rdf:li rdf:resource="http://filamentgroup.com/lab/performance-rwd.html"/>
	<rdf:li rdf:resource="http://csstriggers.com/"/>
	<rdf:li rdf:resource="http://www.portent.com/blog/internet-marketing/research-site-speed-hurting-everyones-revenue.htm"/>
	<rdf:li rdf:resource="https://www.igvita.com/2014/05/20/script-injected-async-scripts-considered-harmful/"/>
	<rdf:li rdf:resource="http://addyosmani.com/blog/removing-unused-css/"/>
	<rdf:li rdf:resource="http://www.millwoodonline.co.uk/blog/drupal-7-performance-gains-with-views-cache"/>
	<rdf:li rdf:resource="http://24ways.org/2012/responsive-responsive-design/"/>
	<rdf:li rdf:resource="http://drupal.org/sandbox/drewish/1820184"/>
	<rdf:li rdf:resource="http://jtaby.com/2012/04/23/modern-web-development-part-1.html"/>
	<rdf:li rdf:resource="http://blog.engineering.kiip.me/post/20988881092/a-year-with-mongodb"/>
	<rdf:li rdf:resource="http://2bits.com/caching/overcoming-long-views-rendering-time-drupal-sites.html"/>
	<rdf:li rdf:resource="http://online.wsj.com/article/SB122426318874844933.html"/>
	<rdf:li rdf:resource="http://davidbcalhoun.com/2011/mobile-performance-manifesto"/>
	<rdf:li rdf:resource="http://support.cloudflare.com/cgi/discussions/suggestions/78-optimal-settings-for-drupal-based-web-sites"/>
	<rdf:li rdf:resource="http://www.lullabot.com/articles/varnish-multiple-web-servers-drupal"/>
	<rdf:li rdf:resource="http://blitz.io/"/>
	<rdf:li rdf:resource="http://pinboard.in/blog/173/"/>
	<rdf:li rdf:resource="http://www.midwesternmac.com/blogs/jeff-geerling/drupal-7-front-end-performance"/>
	<rdf:li rdf:resource="http://www.mysqlperformanceblog.com/2011/02/21/death-match-ebs-versus-ssd-price-performance-and-qos/"/>
	<rdf:li rdf:resource="http://highervisibilitywebsites.com/convert-your-mysql-database-myisam-innodb-and-get-ready-drupal-7-same-time"/>
	<rdf:li rdf:resource="http://tag1consulting.com/blog/drupal-performance-next-step"/>
	<rdf:li rdf:resource="http://blog.benstrong.com/2010/11/google-and-microsoft-cheat-on-slow.html"/>
	<rdf:li rdf:resource="http://www.webperformanceinc.com/load_testing/blog/2010/09/optimizing-drupal-from-baseline-drupal-to-the-pantheon-drupal-platform/"/>
	<rdf:li rdf:resource="http://groups.drupal.org/node/57208"/>
      </rdf:Seq>
    </items>
  </channel><item rdf:about="https://web.dev/">
    <title>Home  |  web.dev</title>
    <dc:date>2018-11-12T22:06:40+00:00</dc:date>
    <link>https://web.dev/</link>
    <dc:creator>Aetles</dc:creator><description><![CDATA[Let's build the future of the web.
With actionable guidance and analysis, web.dev helps developers like you learn and apply the web's modern capabilities to your own sites and apps.]]></description>
<dc:subject>google performance webdevelopment testing</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Aetles/b:12e0b647c92c/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:webdevelopment"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:testing"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://premium.wpmudev.org/wp-checkup/">
    <title>WP Checkup - Get a WordPress Checkup Quick, Free &amp; Easy | WPMU DEV - The WordPress Experts</title>
    <dc:date>2016-11-10T16:00:32+00:00</dc:date>
    <link>https://premium.wpmudev.org/wp-checkup/</link>
    <dc:creator>Aetles</dc:creator><description><![CDATA[Get a professional performance, security and SEO scan]]></description>
<dc:subject>wordpress security webdevelopment performance SEO</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Aetles/b:0182825dbb84/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:wordpress"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:security"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:webdevelopment"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:SEO"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://css-tricks.com/building-website-performance-monitor/">
    <title>Building a Website Performance Monitor | CSS-Tricks</title>
    <dc:date>2016-10-20T14:04:40+00:00</dc:date>
    <link>https://css-tricks.com/building-website-performance-monitor/</link>
    <dc:creator>Aetles</dc:creator><description><![CDATA[The system I had in mind had to have three key components:

An application that listens for test requests and communicates with the WebPageTest API
A data store to persist the test results
A visualisation layer to display them, with a series of graphs to show the progress of the various metrics over time
I really wanted to build something that people of all levels of expertise could set up and use for free, and that heavily influenced the decisions I made about the architecture and infrastructure of the platform.

]]></description>
<dc:subject>github performance webdevelopment</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Aetles/b:c28fba89a33a/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:github"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:webdevelopment"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://rmurphey.com/blog/2015/11/25/building-for-http2">
    <title>Building for HTTP/2</title>
    <dc:date>2015-11-30T12:48:09+00:00</dc:date>
    <link>http://rmurphey.com/blog/2015/11/25/building-for-http2</link>
    <dc:creator>Aetles</dc:creator><description><![CDATA[Earlier this year, I got the chance to speak with Google's Ilya Grigorik about HTTP/2 for the 1.10 episode of the TTL Podcast. It was a great primer for me on how HTTP/2 works and what it means for how we build the web, but it wasn't until more recently that I started to think about what it means for how we build the web — that is, how we generate and deploy the HTML, CSS, and JS that power web applications.

If you're not familiar with HTTP/2, the basics are simultaneously simple and mind-boggling. Whereas its predecessors allowed each connection to a server to serve only one request at a time, HTTP/2 allows a connection to serve multiple requests simultaneously. A connection can also be used for a server to push a resource to a client — a protocol-level replacement for the technique we currently call “inlining.”

This is everything-you-thought-you-knew-is-wrong kind of stuff. In an HTTP/2 world, there are few benefits to concatenating a bunch of JS files together, and in many cases the practice will be actively harmful. Domain sharding becomes an anti-pattern. Throwing a bunch of <script> tags in your HTML is suddenly not a laughably terrible idea. Inlining of resources is a thing of the past. Browser caching — and cache busting — can occur on a per-module basis.

What does this mean for how we build and deploy applications? Let's start by looking at the state of the art in client-side application deployment prior to HTTP/2.]]></description>
<dc:subject>development http javascript performance webdevelopment</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Aetles/b:7122eb4bfcb3/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:development"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:http"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:javascript"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:webdevelopment"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://daverupert.com/2015/11/framework-cost/">
    <title>The Cost of Frameworks - daverupert.com</title>
    <dc:date>2015-11-17T21:57:18+00:00</dc:date>
    <link>http://daverupert.com/2015/11/framework-cost/</link>
    <dc:creator>Aetles</dc:creator><description><![CDATA[I think the interesting discussion to be had from Tom’s post is: Are we trying to make lightweight sites that WORK FAST or maintainable sites WORK FOR YEARS?

Your answer is probably different and depends on your past experiences.

Users don’t want to wait, so the Quest for Speed is very important. It’s also very alluring! If I do things just right and score 100 on Page Speed Insights, I’m promised that unforetold riches will be deposited into my bank account. It will rain rupees. Google is all-in on this effort: Fast is best because it makes money.

As a community, we talk a lot about performance because it’s easy to measure and we can quickly see who is doing a good job and who is doing a bad job.

However, by measuring what can only be measured in terms of page speed means we have no insight to the reasons a framework was employed or how much money it saved the organization. How big is team that built the site? One? Ten? What were past organizational failures that led to adopting a large framework? Did using a framework win out in a lengthy internal Cost-Benefit analysis? Is CSAT up due to swanky animations and autocomplete features that took minutes to build? Was code shipped faster? Was it built by one person over a weekend? Did the abstraction allow the developers to actually have fun building, therefore increasing job satisfaction, therefore reducing organizational churn, therefore reducing cost of the end product for the user?

We don’t know.

There’s so much we don’t know, it’s hard for me to believe any metric describes the quality of a site. I can build a very fast website that is harder to maintain due to critical path hoops, supporting AMP-HTML, and providing a near perfect offline experience. Just add more code and grunt tasks and you will be rewarded in ValhallaGoogle search results! Longtail, however, the user experience also suffers because updates are slower to roll out due to feature burden.]]></description>
<dc:subject>framework performance webdevelopment development</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Aetles/b:c4613b35c093/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:framework"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:webdevelopment"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:development"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://fsdata.se/blogg/optimera-hela-din-wordpress-hemsida/">
    <title>Optimera HELA din WordPress-hemsida - FS Data</title>
    <dc:date>2015-09-25T17:48:51+00:00</dc:date>
    <link>https://fsdata.se/blogg/optimera-hela-din-wordpress-hemsida/</link>
    <dc:creator>Aetles</dc:creator><description><![CDATA[När man använder en webbtjänst för att optimera sin hemsida så kontrollerar man en sida åt gången. Om man vill så kan man kontrollera alla sina undersidor manuellt på detta sätt. Vi har dock ett tips om hur man kan kontrollera och optimera hela sin hemsida – med WordPress – mycket enklare.

– Kontrollera & optimera alla sidor/inlägg i WordPress

För detta kommer vi använda ett WordPress-tillägg som heter Google Pagespeed Insights. Det är ett tillägg som använder Googles API för Pagespeed för att kontrollera alla sidor och inlägg per automatik. Detta kräver att man har ett Google-konto (för API:et).]]></description>
<dc:subject>performance wordpress speed webdevelopment</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Aetles/b:ae611a3ef5d9/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:wordpress"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:speed"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:webdevelopment"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://sixrevisions.com/web-performance/improve-website-speed/">
    <title>A Modern Approach to Improving Website Speed</title>
    <dc:date>2015-04-08T12:39:54+00:00</dc:date>
    <link>http://sixrevisions.com/web-performance/improve-website-speed/</link>
    <dc:creator>Aetles</dc:creator><description><![CDATA[Have you ever had the experience of going to a site and patiently waiting forever for it to load?

Probably not, because no one waits forever for a site to load. We just close the browser tab and move on.

Time matters.

When it comes to getting the user’s attention, we only have a very brief window of opportunity. According to Ilya Grigorik, on his “Speed, Performance, and Human Perception” keynote, you only have one second.

One second!

After that first second, a mental context switch occurs. In the user’s mind, it has been so long that they start to think about other things.

And after about 10 seconds, the user is already bored and will probably close their browser tab and get on with their day.

What I will cover in this guide is a process for optimizing your website’s performance. I’m going to use my own site as an example.

If you haven’t done the things discussed in this guide, you will get guaranteed website speed improvements after performing the steps that I will be discussing.]]></description>
<dc:subject>performance speed webdevelopment</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Aetles/b:4089ca5a3030/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:speed"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:webdevelopment"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.smashingmagazine.com/2014/09/08/improving-smashing-magazine-performance-case-study/">
    <title>Improving Smashing Magazine's Performance: A Case Study | Smashing Magazine</title>
    <dc:date>2014-09-08T20:50:25+00:00</dc:date>
    <link>http://www.smashingmagazine.com/2014/09/08/improving-smashing-magazine-performance-case-study/</link>
    <dc:creator>Aetles</dc:creator><description><![CDATA[Today Smashing Magazine turns eight years old. Eight years is a long time on the web, yet for us it really doesn’t feel like a long journey at all. Things have changed, evolved and moved on, and we gratefully take on new challenges one at a time. To mark this special little day, we’d love to share a few things that we’ve learned over the last year about the performance challenges of this very website and about the work we’ve done recently. If you want to craft a fast responsive website, you might find a few interesting nuggets worth considering. – Ed.
Improvement is a matter of steady, ongoing iteration. When we redesigned Smashing Magazine back in 2012, our main goal was to establish trustworthy branding that would reflect the ambitious editorial direction of the magazine. We did that primarily by focusing on crafting a delightful reading experience. Over the years, our focus hasn’t changed a bit; however, that very asset that helped to establish our branding turned into a major performance bottleneck.]]></description>
<dc:subject>performance css js javascript webfonts optimization webdevelopment</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Aetles/b:0d69d53a2675/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:css"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:js"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:javascript"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:webfonts"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:webdevelopment"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://daverupert.com/2014/07/rwd-bloat-part-ii/">
    <title>RWD Bloat Part II - daverupert.com</title>
    <dc:date>2014-08-04T21:16:34+00:00</dc:date>
    <link>http://daverupert.com/2014/07/rwd-bloat-part-ii/</link>
    <dc:creator>Aetles</dc:creator><description><![CDATA[Building off of my previous post on RWD Bloat, the following is step-by-step how I made my site faster over the course of a few days. For the purposes of this test, I’m hyper-focused on my Speed Index numbers for my Home and Article templates (the 2 most visited templates of my site). ]]></description>
<dc:subject>css performance speed webdevelopment</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Aetles/b:782debc1d7ed/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:css"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:speed"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:webdevelopment"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://filamentgroup.com/lab/performance-rwd.html">
    <title>How we make RWD sites load fast as heck | Filament Group, Inc., Boston, MA</title>
    <dc:date>2014-08-02T21:11:07+00:00</dc:date>
    <link>http://filamentgroup.com/lab/performance-rwd.html</link>
    <dc:creator>Aetles</dc:creator><description><![CDATA[There has been a lot of discussion about optimizing responsive layouts for performance lately, and I think that’s great. Speed broadens access and makes users happy, much like responsive design.
In the past year I’ve spent a lot of time researching page loading performance, both for our ongoing client work here at FG and for my soon-to-be-released book for A Book Apart. In the process, I’ve reaffirmed my belief that we don’t need to compromise the well-known benefits of a responsive layout in order to make our sites load as fast as heck.
In this post, I’ll outline some recent observations and approaches to delivering sites for speed and broader access, and link out to various tools we are using to facilitate our approach. All of the tips mentioned in this post are implemented on this very site, and we’ve tested them heavily to ensure that they’re working as well as they can.
I’ll start with some high-level observations, then later I’ll dive into the more technical how-to. First, some general notes about page loading performance and what we aim to accomplish.
]]></description>
<dc:subject>css performance rwd webdevelopment optimization</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Aetles/b:7782eea5a695/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:css"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:rwd"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:webdevelopment"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:optimization"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://csstriggers.com/">
    <title>CSS Triggers...</title>
    <dc:date>2014-07-29T19:53:41+00:00</dc:date>
    <link>http://csstriggers.com/</link>
    <dc:creator>Aetles</dc:creator><dc:subject>css css3 performance</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Aetles/b:7b6b52c17d8a/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:css"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:css3"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:performance"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.portent.com/blog/internet-marketing/research-site-speed-hurting-everyones-revenue.htm">
    <title>Research: Site Speed Is Hurting Everyone's Revenue</title>
    <dc:date>2014-05-21T09:23:59+00:00</dc:date>
    <link>http://www.portent.com/blog/internet-marketing/research-site-speed-hurting-everyones-revenue.htm</link>
    <dc:creator>Aetles</dc:creator><description><![CDATA[What We Found
Here’s the breakdown of our results, plus how you can capitalize:

Still slow after all these years.
In spite of a small riot of experts who agree that faster is better, most sites are still slow. In our study, 50% of sites average load times of 5+ seconds. That’s with a standard deviation of 8 seconds (yikes) so we trimmed outliers and still got 5 seconds with a deviation of .5s.

At least get from 8 seconds to 5
The biggest and easiest value/page view jump is from 8 second to a 5 second load time. While the biggest revenue jump is between 2 seconds and 1, going from 8 to 5 seconds is easier and generates an 18% value/page view increase.]]></description>
<dc:subject>webdevelopment performance</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Aetles/b:6c53f7667354/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:webdevelopment"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:performance"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.igvita.com/2014/05/20/script-injected-async-scripts-considered-harmful/">
    <title>Script-injected &quot;async scripts&quot; considered harmful - igvita.com</title>
    <dc:date>2014-05-20T21:02:07+00:00</dc:date>
    <link>https://www.igvita.com/2014/05/20/script-injected-async-scripts-considered-harmful/</link>
    <dc:creator>Aetles</dc:creator><description><![CDATA[The async attribute on the script tag provides two critical properties: it tells the browser to not block DOM construction, and it does not block script execution on CSSOM. As a result, the scripts are executed as soon as they are downloaded (at ~1.6 seconds) and without having to wait for the CSSOM. ]]></description>
<dc:subject>css javascript performance js webdevelopment</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Aetles/b:67b7c60cff41/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:css"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:javascript"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:js"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:webdevelopment"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://addyosmani.com/blog/removing-unused-css/">
    <title>Spring-cleaning Unused CSS With Grunt, Gulp, Broccoli or Brunch</title>
    <dc:date>2014-04-03T19:40:20+00:00</dc:date>
    <link>http://addyosmani.com/blog/removing-unused-css/</link>
    <dc:creator>Aetles</dc:creator><description><![CDATA[Delivering a fast experience on the web usually involves reducing server response time, minification of CSS/JS/HTML and an optimisation of images and above-the-fold content. We can further minimize the latency caused by stylesheet loading by removing unused CSS rules delivered to the client.

In this write-up, we’ll take a look at build tasks you can use to remove unused CSS in your pages. Before we begin, I thought it would be useful to share some success stories just to demonstrate that the tools here can be used to make a difference.]]></description>
<dc:subject>css performance webdevelopment</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Aetles/b:b5f5f97f4c8e/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:css"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:webdevelopment"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.millwoodonline.co.uk/blog/drupal-7-performance-gains-with-views-cache">
    <title>Drupal 7 performance gains with Views cache</title>
    <dc:date>2013-04-22T07:55:19+00:00</dc:date>
    <link>http://www.millwoodonline.co.uk/blog/drupal-7-performance-gains-with-views-cache</link>
    <dc:creator>Aetles</dc:creator><description><![CDATA[The Views module is the most powerful tool for a Drupal developer, and so much loved that from Drupal 8 the Views module has made it's way into Drupal core. As for Drupal 7, Views is still a contributed module and not all that famous for it's performance. This blog post will look at a few ways to improve the performance of your Views in Drupal 7 by using caching.]]></description>
<dc:subject>drupal drupal7 views performance</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Aetles/b:9a54ec554741/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:drupal"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:drupal7"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:views"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:performance"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://24ways.org/2012/responsive-responsive-design/">
    <title>24 ways: Responsive Responsive Design</title>
    <dc:date>2012-12-18T21:46:41+00:00</dc:date>
    <link>http://24ways.org/2012/responsive-responsive-design/</link>
    <dc:creator>Aetles</dc:creator><description><![CDATA[The reality is that high performance should be a requirement on any web project, not an afterthought. Poor performance has been tied to a decrease in revenue, traffic, conversions, and overall user satisfaction. Case study after case study shows that improving performance, even marginally, will impact the bottom line. The situation is no different on mobile where 71% of people say they expect sites to load as quickly or faster on their phone when compared to the desktop.

The bottom line: performance is a fundamental component of the user experience.

So, given it’s extreme importance in the success of any web project, why is it that we’re seeing so many bloated responsive sites?

First, I adamantly disagree with the belief that poor performance is inherent to responsive design. That’s not a rule – it’s a cop-out. It’s an example of blaming the technique when we should be blaming the implementation. This argument also falls flat because it ignores the fact that the trend of fat sites is increasing on the web in general. While some responsive sites are the worst offenders, it’s hardly an issue resigned to one technique.

To fix the issue, we need to stop making excuses and start making improvements instead. Here, then, are some things we can do to start improving the state of responsive performance, and performance in general, right now.]]></description>
<dc:subject>design performance webdesign rwd responsivedesign</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Aetles/b:9a2e08b9f2d8/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:webdesign"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:rwd"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:responsivedesign"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://drupal.org/sandbox/drewish/1820184">
    <title>drewish's sandbox: Panels, Why so slow? | drupal.org</title>
    <dc:date>2012-10-22T22:21:55+00:00</dc:date>
    <link>http://drupal.org/sandbox/drewish/1820184</link>
    <dc:creator>Aetles</dc:creator><description><![CDATA[Sick of wondering why panels is taking so God forsaken long to render a page? Now you'll know exactly which panes are to blame.

It'll show you and everyone else how many milliseconds each pane takes to render. So, you probably don't want to enable this on a *real* site unless you want to brag about how much you've optimized things.]]></description>
<dc:subject>drupal panels performance</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Aetles/b:2c423990d2cd/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:drupal"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:panels"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:performance"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://jtaby.com/2012/04/23/modern-web-development-part-1.html">
    <title>Modern Web Development</title>
    <dc:date>2012-04-24T14:53:06+00:00</dc:date>
    <link>http://jtaby.com/2012/04/23/modern-web-development-part-1.html</link>
    <dc:creator>Aetles</dc:creator><description><![CDATA[The mobile landscape today is all but monopolized by WebKit, as a result, most of the tooling and infrastructure to support mobile web development on the frontend is taking place in the WebKit Inspector, so I’ll focus on it, and take a deep dive into its entire feature-set and how and when to use it.

Google and the Chrome team have been pumping a ton of resources into the WebKit Inspector. The changes have enabled a whole new class of complex and ambitious applications that would have otherwise collapsed on their own weight. This is great news, of course, but as I talk to more and more web developers about their process and tooling, it became clear to me that many of them haven’t caught up with the changes or aren’t making effective use of the tooling available. This blog post attempts to remedy that, not only by walking you through the inspector’s feature set, but also highlighting certain techniques for bug hunting and feature development that I’ve found to be indispensable.]]></description>
<dc:subject>javascript performance programming web tools debugging webkit inspector</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Aetles/b:395923ff9d5b/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:javascript"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:web"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:tools"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:debugging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:webkit"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:inspector"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://blog.engineering.kiip.me/post/20988881092/a-year-with-mongodb">
    <title>A Year with MongoDB - Engineering at Kiip</title>
    <dc:date>2012-04-16T07:00:51+00:00</dc:date>
    <link>http://blog.engineering.kiip.me/post/20988881092/a-year-with-mongodb</link>
    <dc:creator>Aetles</dc:creator><description><![CDATA[Initially, we felt MongoDB gave us the flexibility and power we needed in a database. Unfortunately, underlying architectural issues forced us to investigate other solutions rather quickly. We never attempted to horizontally scale MongoDB since our confidence in the product was hurt by the time that was offered as a solution, and because we believe horizontally scaling shouldn’t be necessary for the relatively small amount of ops per second we were sending to MongoDB.

Over the past 6 months, we’ve “scaled” MongoDB by moving data off of it. ]]></description>
<dc:subject>database nosql performance mongodb</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Aetles/b:bd848476d3c8/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:database"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:nosql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:mongodb"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://2bits.com/caching/overcoming-long-views-rendering-time-drupal-sites.html">
    <title>Overcoming long Views rendering time on Drupal sites | 2bits.com, Inc. - Drupal Performance Optimization, Development, Managed Hosting, Customization and Consulting</title>
    <dc:date>2012-03-01T10:53:59+00:00</dc:date>
    <link>http://2bits.com/caching/overcoming-long-views-rendering-time-drupal-sites.html</link>
    <dc:creator>Aetles</dc:creator><description><![CDATA[Upon investigation, we found that one view was responsible for most of that time.

However, the query execution itself was fast, around 11 ms.

But, the views rendering time was obscenely high: 2,603.48 ms!

So, when editing the view, you would see this at the bottom:

Query build time        2.07 ms
Query execute time     11.32 ms
View render time    2,603.48 ms
Since this view was on each page, in a block on the side bar, it was causing all the pages of the site to be slow.

The underlying reason was really bad coding in the views-view--viewname.tpl.php, which is too long to explain. But the gist of it is that the view returned several thousands rows of taxonomy terms, and was was supposed to render them in a tree. However, the actual view template just looped through the dataset and did not do much and displayed static HTML in the end!

The solution for this was quite simple: enable Views caching.

To do this, go to the view's Defaults, then Basic settings, then Caching. Change to Time Based, then select at least 1 hour for each of Query results and Rendered output.

Save the view, and you will see a positive impact on performance of your pages.]]></description>
<dc:subject>drupal views performance caching</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Aetles/b:9668692d0b81/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:drupal"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:views"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:caching"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://online.wsj.com/article/SB122426318874844933.html">
    <title>Get Rid of the Performance Review! - WSJ.com</title>
    <dc:date>2012-02-23T21:35:43+00:00</dc:date>
    <link>http://online.wsj.com/article/SB122426318874844933.html</link>
    <dc:creator>Aetles</dc:creator><description><![CDATA[You can call me "dense," you can call me "iconoclastic," but I see nothing constructive about an annual pay and performance review. It's a mainstream practice that has baffled me for years.

To my way of thinking, a one-side-accountable, boss-administered review is little more than a dysfunctional pretense. It's a negative to corporate performance, an obstacle to straight-talk relationships, and a prime cause of low morale at work. Even the mere knowledge that such an event will take place damages daily communications and teamwork.]]></description>
<dc:subject>management performance productivity work</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Aetles/b:5ae5dc406219/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:management"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:productivity"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:work"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://davidbcalhoun.com/2011/mobile-performance-manifesto">
    <title>Mobile Performance Manifesto | David Calhoun's Developer Blog</title>
    <dc:date>2011-12-06T10:31:46+00:00</dc:date>
    <link>http://davidbcalhoun.com/2011/mobile-performance-manifesto</link>
    <dc:creator>Aetles</dc:creator><description><![CDATA[Earlier this year I gave a talk (slides) outlining the latest and greatest in mobile performance, including a bit of my own unscientific research into carrier latency and bandwidth thanks to boomerang.js.
I realized that interest in mobile performance has exploded recently, especially with Steve Souders announcing his focus on mobile, and I thought it was time for an update, this time in blog form. Also, my old slides have been somewhat embarrassing. For some strange reason, at the time I wanted to give S5 a try – that outdated, ancient, not-performant slideshow framework. The result is a slideshow on performance that loads slowly… doh! (incidentally, I recommend deck.js as an alternative).
In any case, it was time for a roundup of mobile performance best practices, in blog form. I’m not sure if it’s properly called a manifesto, but it is what it is! Onward!]]></description>
<dc:subject>css javascript mobile performance webdesign</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Aetles/b:eb45df43e589/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:css"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:javascript"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:mobile"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:webdesign"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://support.cloudflare.com/cgi/discussions/suggestions/78-optimal-settings-for-drupal-based-web-sites">
    <title>Performance &amp; Security for Any Website | CloudFlare | Knowledge Base</title>
    <dc:date>2011-05-26T14:36:55+00:00</dc:date>
    <link>http://support.cloudflare.com/cgi/discussions/suggestions/78-optimal-settings-for-drupal-based-web-sites</link>
    <dc:creator>Aetles</dc:creator><description><![CDATA[first of all: CloudFlare really excels with Drupal based web sites! After a bit of trial and error, we've by now figure out some optimal performance gainers fiddling around with both Drupal and CloudFlare settings and we would like to share these insights with you guys!]]></description>
<dc:subject>drupal cloudflare performance</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Aetles/b:7c4c2d8952fb/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:drupal"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:cloudflare"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:performance"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.lullabot.com/articles/varnish-multiple-web-servers-drupal">
    <title>Configuring Varnish for High-Availability with Multiple Web Servers | Lullabot</title>
    <dc:date>2011-04-06T18:34:30+00:00</dc:date>
    <link>http://www.lullabot.com/articles/varnish-multiple-web-servers-drupal</link>
    <dc:creator>Aetles</dc:creator><description><![CDATA[Varnish is an amazing and incredibly efficient tool for serving up common resources from your site to end-users. Besides simply making your site faster, it also can add additional redundancy to your setup by acting as a full backup if the web servers fail. In order to make Varnish both serve as an effective backup and efficient caching layer, it needs to clean up incoming headers from the browser, strip down cookies, and consolidate the "Accept-Encoding" header.
After such extensive explanations it's easy to get overwhelmed, but the good news is that the VCL file provided here can quickly be deployed to almost any Drupal site and start working immediately. For most sites no further customization is needed, and sites that need to tweak it will have a good head start towards huge reductions in server load. On our sites, Varnish is usually able to handle about 85% of the traffic without ever touching the web servers. Even during peak times with hundreds of thousands of requests coming in per hour, Varnish can hum along at less than 5% CPU usage of an average 4-core server. Instead of scaling out your web servers horizontally, adding a few Varnish machines in front of them can save a huge amount of processing and speed up your site at the same time.
If you haven't already, grab the actual default.vcl file that we use on our sites and read it through start to finish. Now with all of the individual pieces explained in-depth above, we hope you can use it as a starting point for your own VCL configuration. Happy caching!]]></description>
<dc:subject>apache drupal performance server varnish</dc:subject>
<dc:source>https://instapaper.com/</dc:source>
<dc:identifier>https://pinboard.in/u:Aetles/b:de4b769673e9/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:apache"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:drupal"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:server"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:varnish"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://blitz.io/">
    <title>Blitz | Making load and performance testing a fun sport</title>
    <dc:date>2011-03-14T14:20:58+00:00</dc:date>
    <link>http://blitz.io/</link>
    <dc:creator>Aetles</dc:creator><dc:subject>performance testing</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Aetles/b:027ff4be2601/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:testing"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://pinboard.in/blog/173/">
    <title>Anatomy of a Crushing (Pinboard Blog)</title>
    <dc:date>2011-03-08T21:05:29+00:00</dc:date>
    <link>http://pinboard.in/blog/173/</link>
    <dc:creator>Aetles</dc:creator><description><![CDATA[A number of people asked about the technical aspects of the great Delicious exodus of 2010, and I've finally had some time to write it up. Note that times on all the graphs are UTC.

On December 16th Yahoo held an all-hands meeting to rally the troops after a big round of layoffs. Around 11 AM someone at this meeting showed a slide with a couple of Yahoo properties grouped into three categories, one of which was ominously called "sunset". The most prominent logo in the group belonged to Delicious, our main competitor. Milliseconds later, the slide was on the web, and there was an ominous thundering sound as every Delicious user in North America raced for the exit.]]></description>
<dc:subject>pinboard performance</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Aetles/b:39deb30c61c9/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:pinboard"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:performance"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.midwesternmac.com/blogs/jeff-geerling/drupal-7-front-end-performance">
    <title>Drupal 7 Front-End Performance - Shared Hosting Recommendations | Midwestern Mac, LLC</title>
    <dc:date>2011-02-23T08:29:09+00:00</dc:date>
    <link>http://www.midwesternmac.com/blogs/jeff-geerling/drupal-7-front-end-performance</link>
    <dc:creator>Aetles</dc:creator><description><![CDATA[I've spent a lot of time working on making sure my smaller Drupal sites (mostly run on shared hosts or very small VPSes) run lean and mean. This helps the pages load faster, users are happier, and my hosting providers don't have to shut down any of my sites, even when they're under pretty heavy load.

Here are my three recommendations for making your Drupal 7 website run great on a shared (or low-end VPS) host:]]></description>
<dc:subject>drupal drupal7 sharedhosting performance</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Aetles/b:4e814a7b89ca/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:drupal"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:drupal7"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:sharedhosting"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:performance"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.mysqlperformanceblog.com/2011/02/21/death-match-ebs-versus-ssd-price-performance-and-qos/">
    <title>Death match! EBS versus SSD price, performance, and QoS - MySQL Performance Blog</title>
    <dc:date>2011-02-22T08:15:00+00:00</dc:date>
    <link>http://www.mysqlperformanceblog.com/2011/02/21/death-match-ebs-versus-ssd-price-performance-and-qos/</link>
    <dc:creator>Aetles</dc:creator><description><![CDATA[Is it a good idea to deploy your database into the cloud? It depends. I have seen it work well many times, and cause trouble at other times. In this blog post I want to examine cloud-based I/O. I/O matters a lot when a) the database’s working set is bigger than the server’s memory, or b) the workload is write-heavy. If this is the case, how expensive is it to get good performance, relative to what you get with physical hardware? Specifically, how does it compare to commodity solid-state drives? Let’s put them in the ring and let them duke it out.
I could do benchmarks, but that would not be interesting — we already know that benchmarks are unrealistic, and we know that SSDs would win. I’d rather look at real systems and see how they behave. Are the theoretical advantages of SSDs really a big advantage in practice? I will show the performance of two real customer systems running web applications.]]></description>
<dc:subject>ec2 performance ssd aws database hosting</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Aetles/b:eaa6648a91b8/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:ssd"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:database"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:hosting"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://highervisibilitywebsites.com/convert-your-mysql-database-myisam-innodb-and-get-ready-drupal-7-same-time">
    <title>Convert your MySQL database from MyISAM to InnoDB, and get ready for Drupal 7 at the same time | Drupal Services and Consulting</title>
    <dc:date>2011-01-23T17:56:35+00:00</dc:date>
    <link>http://highervisibilitywebsites.com/convert-your-mysql-database-myisam-innodb-and-get-ready-drupal-7-same-time</link>
    <dc:creator>Aetles</dc:creator><description><![CDATA[If you haven't already heard, Drupal 7 will default to using the InnoDB storage engine instead of MyISAM for MySQL (though a MyISAM database will continue to work just fine in Drupal 7). This is fairly substantial change within Drupal core, and as the thread in the issue queue I linked to shows, there were a lot of questions and apprehension about it. However...

...we are going to just skip over a lot of that apprehension and get down to point of this article - there's no good reason not to hop right into using InnoDB today on your Drupal 5 or Drupal 6 site. The rewards are; a possibly significant improvement in performance, a definite improvement in scalability (most highly trafficked Drupal sites have been using InnoDB for some time now because of this), and you'll start getting used to working with what will be more and more common in your Drupal-life, InnoDB.]]></description>
<dc:subject>drupal performance mysql</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Aetles/b:fd57bcfb9bbc/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:drupal"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:mysql"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://tag1consulting.com/blog/drupal-performance-next-step">
    <title>Drupal performance - the next step | Tag1 Consulting, Inc.</title>
    <dc:date>2010-12-13T13:58:39+00:00</dc:date>
    <link>http://tag1consulting.com/blog/drupal-performance-next-step</link>
    <dc:creator>Aetles</dc:creator><description><![CDATA[The result is obviously, that Hiphop has by far the most advantage over a "normal", e.g. PHP+APC Drupal, install, a whopping 30%. Also, the gains from the PHP extension in any case are rather minor (2-3%).

An additional result is that sadly Drupal 7 is much slower (60%), at least for this page.]]></description>
<dc:subject>drupal performance</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Aetles/b:767d55e5e257/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:drupal"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:performance"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://blog.benstrong.com/2010/11/google-and-microsoft-cheat-on-slow.html">
    <title>Ben Strong's Blog: Google and Microsoft Cheat on Slow-Start. Should You?</title>
    <dc:date>2010-12-09T18:25:58+00:00</dc:date>
    <link>http://blog.benstrong.com/2010/11/google-and-microsoft-cheat-on-slow.html</link>
    <dc:creator>Aetles</dc:creator><description><![CDATA[I decided a couple of weeks ago that I wanted to build an app, most likely a web app. Being a premature optimizer by nature, my first order of business (after deciding I need to learn to draw) was to find the absolute fastest way to serve up a web page. The Google home page is the fastest-loading page I know of, so I thought a good place to start would be to figure out how they do it and then replicate their strategy. 

The full story of my search is below, but the short version is that to match Google's page load times you have to cheat on the tcp slow-start algorithm. It appears that stretching the parameters a little bit is fairly common, but Google and Microsoft push it a lot further than most. This may well be common knowledge in web development circles, but it was news to me.]]></description>
<dc:subject>google http performance speed tcpip</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Aetles/b:48c4de1a6013/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:http"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:speed"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:tcpip"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.webperformanceinc.com/load_testing/blog/2010/09/optimizing-drupal-from-baseline-drupal-to-the-pantheon-drupal-platform/">
    <title>Optimizing Drupal: From Baseline Drupal to the Pantheon Drupal Platform | Load Testing Blog</title>
    <dc:date>2010-09-22T20:19:58+00:00</dc:date>
    <link>http://www.webperformanceinc.com/load_testing/blog/2010/09/optimizing-drupal-from-baseline-drupal-to-the-pantheon-drupal-platform/</link>
    <dc:creator>Aetles</dc:creator><description><![CDATA[We were pleased to demonstrate the ease with which we were able to use Web Performance Load Tester to collect performance metrics on various Drupal configurations.

Some of the gains we demonstrated represented fairly low-hanging fruit.  Installing a PHP accelerator like APC is a no-brainer on almost any production platform and can nearly triple the capacity of a heavily-trafficked web site.  Caching is also very easy to enable.

On the other hand, the Pantheon Drupal Platform outperformed our expectations with better than an order of magnitude improvement in user capacity.  Pantheon represents many long hours of tweaking and optimization by Drupal experts, but  in the end Pantheon was extremely easy to use and compatible with the vanilla Drupal database schema.

]]></description>
<dc:subject>drupal performance</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Aetles/b:560e352d248d/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:drupal"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:performance"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://groups.drupal.org/node/57208">
    <title>First step at scaling mid level site? | groups.drupal.org</title>
    <dc:date>2010-03-22T11:15:12+00:00</dc:date>
    <link>http://groups.drupal.org/node/57208</link>
    <dc:creator>Aetles</dc:creator><description><![CDATA[This question is probably a bit on the beginner end for this group but you've all probably been in my shoes previously so hopefully you'll be able to help me out.

I have a site with 6,000 nodes and 15,000 users. I make liberal use of Views, CCK and Taxonomy on all my pages and I use normal drupal caching and views caching. I run this site on a single VPS however my CPU usage lately has been a bit high (10% on a regular basis) and I need to figure out what my next step is to scale so as not to get on the bad side of my host.

Given modest financial investment (this is a niche site and thus doesn't generate much revenue at all) - what do you think the best way to reduce my CPU load / scale my site will be?]]></description>
<dc:subject>drupal performance</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Aetles/b:ab2eee2d4b13/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:drupal"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Aetles/t:performance"/>
</rdf:Bag></taxo:topics>
</item>
</rdf:RDF>