Closed jpdevries closed 8 years ago
jpdevries
commented
8 years ago I may be able to make even dirty art–boards stay under 10kB initially if I removed the .no-js support for the various at scale previews.
Waiting on hearing back from the competition because I'd like to think that it is lazy weight which aides accessibility. I've been assuming just the initial "blank" art–board counts as the initial weight for my 10kB but the way the legalese is worded has me nervous
jpdevries
commented
8 years ago Some last thoughts on this are that it kind of seems to boil down to if that part of the legalese means any page in the site map (of which there are two) or possible to be served via the API (of which there are countless) and with a certain amount of cells filled can pass 10kB.
More on the API here https://github.com/jpdevries/makeanico/#api
jpdevries
commented
8 years ago Added endpoints for /icos/random and /icos/randomalpha to easily create dirty art board full of random pixels. At solid transparency page sizes can get up to about 24kB
with alpha pixels 30kB
jpdevries
commented
8 years ago Pages with every cell filled have a lot of header weight. I'm counting as much as 2.5kB over GZIP.
I did a test where I stripped out the no-js support of the additional components, took out the static preview, and stripped out the markup for the favicon, and I measured initial weight of very dirty art-boards around 14kB without headers.
So with this HTML architecture and the way HTML weight scales when combining it with the accessibility consideration of initially serving semantic HTML, there is no way to keep it under 10kB. I even tried rounding the rgba decimals to only two places. If I remove the data-a attributes from the initial HTML markup I can get it down to 13.4kB with headers so around 11kB without.
So I think I just have to 🙏 that the initial load is just the two pages of the site map and not any URL that the API supports.
jpdevries
commented
8 years ago All of the code needed for folks to use your project should be contained in that 10kB. You can use techniques like lazy-loading to enhance the experience by pulling in additional functionality, higher-resolution imagery, etc. as it makes sense to do so. https://a-k-apart.com/faq#size
I feel all of the code needed for use is in the first 5.7kB. The initial HTML consisting of the tabular art–board and the fill component. Now as the application is used
This means that if no-js users make edits they will taken to new pages whose initial DOM can exceed 10kB because it contains the inlined artwork.
If a user visits the app, fills every cell, and shares that icons URL should that URL be considered a "public page" of the app under 4. What Constitutes An Eligible Entry?
If not, the app has two pages. If every possible icon the API can generate is considered a "public page" then there are a lot of pages:
jpdevries
commented
8 years ago In https://github.com/jpdevries/makeanico/commit/dd16f8a8b03edddb79c01b43e80ef92203ef5a70 Got a dirty art–boad under 10kB with no-js https://github.com/jpdevries/makeanico/issues/11#issuecomment-251234639
jpdevries
commented
8 years ago In https://github.com/jpdevries/makeanico/commit/f372077fd27987ea0c1d8a6dd8efa201e6843598 got almost any dirty art–board under 10kB. http://makeanico.azurewebsites.net/icos/randomalpha can still go over. Every cell is an alpha pixel.
jpdevries
commented
8 years ago I got non–transparent dirty art–boards smaller by adding an option to not initially print the <input type="hidden"> of each cell. They are below 10kB so if I misinterpreted the rules and dirty art boards do also need to be under 10kB I could remove alpha transparency support and lazy–load the stylesheet and see if I could get away with that.
jpdevries
commented
8 years ago In https://github.com/jpdevries/makeanico/commit/ac7c499bf94591b4fa91ad43a49f954dc69d49e1 all non–transparent art–boards are < 10kB initial load and in https://github.com/jpdevries/makeanico/commit/7457ca289bf3b4d56fcf8a7d80cd71eb053de665 transparency support is removed if force10kB is on. the stylesheet gets dropped from the initial HTML load and is lazy loaded if art boards are over half full.
still not sure if this is necessary but basically a back up plan that some nice optimizations came out of.
jpdevries
commented
8 years ago Great news: we received your entry and have spun up your server on Azure! Check it out: https://make-an-ico-10kapart2016.azurewebsites.net/
Also see weigh In section of the README https://github.com/jpdevries/makeanico#weigh-in
I've assumed that it ok initial page weights of "dirty" art–boards can creep above 10kB because they are themselves part of lazy loading. as the user draws, their art-board along with the URL itself grows. If they return to that URL it will have the art-board initially served inline for no-js support. One question I have reading the legal docs though:
I would hope that under that rule the only two pages of my application are the home screen and the accessibility page.
Dirty art-boards are publicly accessibly pages though (they can be shared) and their initial weight (if you don't factor in cacheing and service workers) can be ~15kB with GZIP. This is because the initial 5.7kB of weight grows to include populating the art–board and previews of the app. The markup weight grows because the data URI is repeated in a few places of the HTML.
Was my assumption Correct? Are "dirty" art–board OK?