Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 17 reacties
Bron: Crisp's blog

Crisp heeft op zijn weblog in de vorm van 1.1 een nieuwe versie van JSMin+ vrijgegeven. JSMin+ is een 'JavaScript minifier' die via PHP een JavaScript-bestand als het ware kan verkleinen. Dit verkleinen heet ook wel minification en haalt alle onnodige tekens zoals spaties en commentaar uit een JS-file zonder dat de werking van het bestand wordt veranderd. In het geval van JSMin+ wordt deze lap JavaScript-code omgezet naar deze minified code. Meer informatie over JSMin+ is hier te lezen. De nieuwe 1.1-release van het programma wordt met de volgende release notes geleverd:

Version 1.1 of JSMin+ is available for download. This version has improved performance and fixes some issues. If you use labels in your javascripts you are strongly adviced to use this version to re-minify your scripts.

Changelog:

  • Improved tokenizer performance by reading smaller chunks for matching
  • Bugfix: jumplabels for break/continue statements were not written to output
  • Improved stringmatching: cases like '\' and '<newline>' now throw unterminated string literal error
  • Fixed linenumber offset bug caused by JScript conditional compilation blocks
  • nest() always calls Statement() so no need to use call_user_func() with a parm
Versienummer:1.1
Releasestatus:Final
Besturingssystemen:Scripttaal
Website:Crisp's blog
Download:http://files.tweakers.net/jsminplus/jsminplus.zip
Bestandsgrootte:12,00KB
Licentietype:GPL
Moderatie-faq Wijzig weergave

Reacties (17)

33% kleiner bestand klinkt leuk, maar wat doet het nou met de tijd?
de files zijn sneller binnen bij je clients, en in theorie duurt het parsen vande files aan de clientkant ook minder lang, omdat er minder witruimte is om weg te gooien. Maar dat is volgens ons nogal nihil, maar alle beetjes helpen natuurlijk ;)
Ik denk niet zo veel, aangezien het na een g-zip weer ongeveer even groot is...
lijkt me dat de winst die je hiermee boekt marginaal is. Maar misschien als je echt heel veel bezoekers hebt dat je wat bandbreedte bespaart.
Gzipped is de besparing nog ongeveer de helft, dus als je minified versie 20% kleiner is dan bespaart je dat nog ongeveer 10% na gzip compressie.

De winst is inderdaad marginaal, maar niet geheel verwaarloosbaar. Op een bestand zoals onze general.js die uncompressed ongeveer 50KB is en waarop ik ongeveer 23% winst boek met minificatie zie ik een winst in laadtijd (gzipped geserveert, +/-12KB) van ongeveer 0.01 tot 0.02 seconde bij een lege cache op een 12Mbit verbinding voor dat ene bestand (ten opzicht van de niet-minified versie - gezipped +/-14KB). Aangezien dit bestand gelinkt wordt in onze <head>-sectie is dat ook een blocking download voor het parsen van de content. Bij meerdere gelinkte scripts neemt de winst nog verder toe, en bij tragere verbindingen is de winst relatief groter en dus ook merkbaarder.

Bandbreedte is in deze voor ons niet echt een argument geweest, wel het feit dat de content clientside eerder beschikbaar is*. Dit is ook echt een optimalisatie die je eigenlijk pas moet doen als je het ook eenvoudig kan implementeren. Bij ons zit dit nu geautomatiseerd in het deployment proces dus het kost ons verder geen extra tijd bij wijzigingen aan een JS bestand :)

* nog beter is om je scripts aan het einde van je <body> te linken, maar dat is niet altijd mogelijk...

[Reactie gewijzigd door crisp op 12 april 2009 14:47]

Hulde. Of het nu veel scheelt of niet, ik kan vooral de manier van denken erg waarderen. Als alle softwareboeren zo dachten zou ik nou geen dual core processor nodig hebben om windows te draaien, en zouden programma's als bijvoorbeeld acrobat reader geen 150 MB of meer vreten.
Naar mijn ervaring helpt het alleen als je het geminifiede bestand kunt cachen, anders ben je de clientside bespaarde 1ms weer kwijt aan het minifien serverside.

Maar ach, alle kleine beetjes helpen, en het staat opzich wel netjes vind ik.
Het minimizen gebeurt niet on the fly hč. Aan het eind van het ontwikkelproces worden de files door de minimizer gehaald en deze bestanden worden als een statische file op de server gezet. (op tweakimg.net om precies te zijn).

Minifien gebeurt dus maar 1x en dat is wanneer de bestanden in productie uitgerold worden...
Hier de uitleg van crisp zelf wat deze tool doet: http://crisp.tweakblogs.n...ript-minifier-jsmin+.html

En even de uitleg waarom de tool geschreven is:
quote: crisp
For some time we have been looking for ways to minify the javascript and CSS files for Tweakers.net but were unable to find the right tool for this. If finding the right tool takes too much time there is only one other option: create your own tool, which is exactly what we did. Even better: we are releasing this tool to the public so you can use it too!
Misschien is renaming ook wel handig, aangezien je dan functies en variabelen met lange namen korter maakt, en dat parst ook weer sneller :)
Nee, het hernoemen van variabelen en functienamen neemt risico's met zich mee en stelt zware eisen aan hoe je javascript ontwikkelt; je moet dan altijd expliciete referenties gebruiken en al je referenties moeten besloten zijn in hetzelfde bestand (tenzij je je beperkt tot variabelen binnen functiescope).

Dergelijke rigide eisen zijn counter-productive (net als de syntax-eisen die bijvoorbeeld de originele JSMin stelt) en wegen imo niet op tegen de extra winst.
Welnee, de packer van Dean Edwards kan het toch ook (als je base62 encoding uitzet)... alleen private variabelen wordt verkort. Dus globals en object properties niet.

[Reactie gewijzigd door _Thanatos_ op 13 april 2009 12:52]

Dat zeg ik ook:
tenzij je je beperkt tot variabelen binnen functiescope
hoewel je dan alsnog geen truuken met eval'ed code moet doen en je dan ook nog risico loopt bij gegoochel met scope (with/call/apply) ;)

Zie onder andere dit voorbeeld

Ik zie wel mogelijkheden though, dus wellicht dat ik het ooit nog inbouw ;)

[Reactie gewijzigd door crisp op 13 april 2009 23:23]

with hoef je alvast niet te ondersteunen, want dat is een onofficiele uitbereiding die sommige parsers "toevallig" ondersteunen. Het is een statement dat - áls het werkt - sowieso voor ambiguďteit kan zorgen en dat is op z'n minst bad practise te noemen. Net zoiets als het const-statement, dat werkt ook niet overal.

Wat de problemen met call/apply zouden zijn, begrijp ik niet helemaal. een variabele is local of global. Er bestaat geen scope die "meer local" is dan local. Je kunt wel een functie in een functie maken, maar de variabelen daarin zijn niet meer of minder local dan andere, zegmaar :)

[Reactie gewijzigd door _Thanatos_ op 14 april 2009 02:03]

with hoef je alvast niet te ondersteunen, want dat is een onofficiele uitbereiding die sommige parsers "toevallig" ondersteunen.
Onzin, with is gedefinieerd in Ecma 262 (hd 12, p 10). Bad practice of niet, we moeten er mee leven. Daarbij zijn er meer 'extensies' die je toch niet zomaar kan negeren, JScript's conditional compilation is daar een voorbeeld van (hoewel die implementatie in JSMin+ nog niet volledig is).
Wat de problemen met call/apply zouden zijn, begrijp ik niet helemaal.
Met call/apply zijn inderdaad geen problemen, die heb ik te snel op de hoop met with en eval gegooid. Dat scheelt dus weer :P
Ecmascript != Javascript.
javascript implementeert meer dingen niet, die ecmascript wel definieert...
Je weet dat ECMAScript de gestandaardiseerde versie is van JavaScript, gesubmit door Netscape indertijd? JavaScript is op dit moment meer een superset van ECMAScript, ik heb echter geen idee of en waar JavaScript verder afwijkt van ECMAScript; als je voorbeelden hebt dan zie ik die graag :)

Maar with is zeker geen onofficiele uitbreiding en afaik ondersteunen alle browser-implementaties van ECMAScript dialecten het. Dit in tegenstelling tot bijvoorbeeld const wat inderdaad een JavaScript extensie is die niet gedefinieerd is in ECMAScript en ook niet ondersteund wordt door bijvoorbeeld JScript.
Afhankelijk van de grote van het bestand kan het voornamelijk op trage verbindingen meerdere seconden schelen per pagina die geladen wordt.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True