Een moderne lay-out zonder tabellen, de weigering om inline-stijlen te gebruiken en compressie van HTML-pagina's kunnen het serververkeer aanzienlijk verminderen en de laadsnelheid van de site verhogen voor gebruikers die op "smalle" kanalen werken. De winst in verkeer kan 60-80% bedragen (voor HTML)!
Desondanks zijn er nog een aantal voldoende grote bestanden, die de browser van de bezoeker zal moeten downloaden: de belangrijkste css met lay-out (van 10 tot 30 KB), javascript-framework (mootools - 70-80 KB, prototype.js - 120 KB, enz.) Uiteraard worden deze bestanden door de browser in de cache opgeslagen en worden alleen geladen bij het eerste bezoek, maar het is niet aan mij om u uit te leggen hoe belangrijk het is dat de gebruiker, nadat hij de resultaten van de zoekmachine heeft verlaten, de geladen site zo snel mogelijk ziet...
Je kunt deze bestanden elke keer dat je ze opent comprimeren, door ze via mod_gzip (mod_deflate) uit te voeren. Maar dit zal onvermijdelijk leiden tot extra belasting van de server, wat van cruciaal belang kan zijn voor een bezochte site tegen een lage prijs virtuele hosting.
Een andere manier, die in dit artikel zal worden besproken, is om gecomprimeerde (.gz) bestanden op de server op te slaan, samen met de originele, en, met behulp van de mod_rewrite-richtlijnen, .js.gz en .css.gz uit te voeren in plaats van .js en .css, respectievelijk. Dus laten we aan de slag gaan.
Eerst moet u beslissen welke bestanden compressie vereisen. Voor een typisch Joomla-sjabloon! Dit is bijvoorbeeld doorgaans /media/system/js/mootools.js en template_css.css van de actieve sjabloon.
Nu moet u gecomprimeerde versies van de bestanden voorbereiden. Dit kan op Windows worden gedaan met behulp van gratis archiver 7-ZIP, waarbij GZip als formaat wordt gekozen bij het maken van het archief. Let op: elk bestand bevindt zich in een apart archief. In de UNIX-serverconsole kan dit worden gedaan met behulp van de gzip-opdracht:
gzip mootools.js -c > mootools.js.gzHierna moet u .js.gz en .css.gz in dezelfde mappen op de server plaatsen waar hun niet-gecomprimeerde versies zich bevinden (als de compressie in Windows is uitgevoerd met behulp van 7-Zip).
Als .htaccess niet bestaat in de hoofdmap van de site, maak het dan aan en voeg de volgende regels toe:
Optie 1
### Koppel de .gz-extensie aan gzip AddEncoding gzip .gz ### Laten we mod_rewrite gebruiken RewriteEngine Aan ### Geef foo.bar.gz op in plaats van het foo.bar-bestand als foo.bar.gz aanwezig is in dezelfde map, ### hetzelfde als foo.bar. Als de browser Safari is, geef dan foo.bar op RewriteCond %( HTTP:Accepteer-codering) gzip RewriteCond %( HTTP_USER_AGENT) !Safari RewriteCond %( REQUEST_FILENAME) .gz -f RewriteRule ^(.*) $ $1 .gz [ QSA,L]Optie 2
Deze methode werkt echter soms niet. De server stelt de Content-Type HTTP-header in op application/x-gzip en browsers die het gegevenstype hierdoor bepalen (bijvoorbeeld Firefox) en niet op basis van inhoud (IE) “zien niet”-scripts en css. Om dit probleem op te lossen, moet je het Content-Type forceren naar text/javascript of text/css. In dit geval moet je de volgende code toevoegen aan .htaccess (“optie 1” moet worden verwijderd of becommentarieerd!):
AddEncoding gzip .gz ### 1. Js-bestanden verwerkenAlle, geen veranderingen meer nodig!
U kunt controleren of de methode correct werkt in Firefox met geïnstalleerde plug-in Live HTTP-headers:
- Cache wissen
- Open het plug-invenster, wis het logboek en zorg ervoor dat het vakje ernaast is aangevinkt Vastlegging
- Laad de site opnieuw zonder het Live HTTP Headers-venster te sluiten
- Serverreacties op GET-verzoeken voor gecomprimeerde bestanden zouden er ongeveer zo uit moeten zien:
Browserverzoek
http://site/templates/vectora/css/template.css KRIJG /templates/vectora/css/template.css HTTP/1..0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14 Accepteren: text/css,*/*;q=0.1 Accepteren-taal: en-us,en;q=0.5 Accept-codering: gzip,deflate Accept-charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Verbinding: keep-aliveReactie van de server
HTTP/1.x 200 OK Server: nginx/0.5.35 Datum: zaterdag, 19 april 2008 18:01:45 GMT Inhoudstype: tekst/css Verbinding: keep-alive Keep-Alive: time-out=20 Laatst gewijzigd: dinsdag 01 januari 2008 22:56:51 GMT Etag: "40bc5ff-131d-477ac533" Acceptatiebereik: bytes Inhoudslengte: 4893 Inhoudscodering: gzip
Geschiedenis van veranderingen:
- 19.04.2008 — primaire publicatie;
- 14.11.2008 - toevoeging alternatieve optie(BestandenMatch);
- 21.03.2009 — een typefout in het voorbeeld van een alternatieve optie (FilesMatch) is gecorrigeerd.
Hallo allemaal!
We blijven optimaliseren en vandaag hebben we optimalisatie van JS (JavaScript) en CSS-code. Laat me je eraan herinneren dat we gisteren met afbeeldingen hebben gewerkt. Als je ze nog steeds niet hebt geoptimaliseerd, dan is dit alleen voor jou (zorg ervoor dat je toepast wat daar staat).
De les zal kort zijn, dus laten we snel aan de slag gaan. Laten we gaan!
Wat is JS- en CSS-code?
Momenteel loopt een website die uitsluitend in HTML en CSS is gemaakt al achter, omdat het in deze talen onmogelijk is om handige, nuttige dingen te schrijven die de interactie ermee gemakkelijker zouden maken. Gebruikers moeten op hun beurt het handigste product (webbron) aangeboden krijgen. Implementeren deze vereiste Verschillende programmeertalen, waaronder JavaScript, zullen helpen.
JavaScript- een programmeertaal waarmee u kunt creëren verschillende scripts(applicaties) die zijn ingebed in HTML-pagina's. Scripts worden uitgevoerd in de browser van de gebruiker.
Om zelfs die beruchte tijdteller weer te geven, heb je JS nodig. Ik denk dus dat deze programmeertaal ook op uw website aanwezig is.
CSS- beschrijvingstaal verschijning elk element van de site. Dat wil zeggen: hoe uw site, mijn site en elke andere site eruit zien, is in deze taal geschreven.
Waarom moet u JS- en CSS-code optimaliseren?
Het doel van dit evenement is één: het verkorten van de laadtijd van websitepagina's. Helaas bevatten JS-scripts en CSS-code vaak veel tekens en spaties, waardoor het laden van een webbron wordt vertraagd. De optimalisatie van dergelijke bestanden is gericht op het afsnijden van onnodige tekens, extra ruimtes, waardoor ze kleiner worden en het daardoor gemakkelijker wordt om webpagina's te laden. In wezen vindt normale bestandscompressie plaats. Je kunt meer doen diepgaande optimalisatie, als je natuurlijk verstand hebt van programmeren en het bouwen van websites.
Optimalisatie van JS- en CSS-code
Op internet zijn er, net als bij beeldoptimalisatie, verschillende online services die doen wat hierboven is geschreven:
Uw taak: kopieer de bestandscode en plak deze in een van de vermelde diensten, haal de geoptimaliseerde code op en plak deze in bronbestand. Dat is het.
Ik waarschuw je: na optimalisatie wordt de code onleesbaar, dus verder werk het zal een beetje moeilijk met hem zijn.
Tijdens het optimaliseren van mijn , heb ik beide services geprobeerd: ik uploadde het problematische JS-bestand naar de eerste, en CSS () naar de tweede, en letterlijk na 5 seconden was de code geoptimaliseerd en was het al mogelijk om deze te uploaden, en dat is wat Dat deed ik.
Het is nog steeds de moeite waard om de meest karakteristieke problemen van deze compressie en unificatie te benadrukken.
Laten we beginnen met iets simpels: hoe JS-compressie ons humeur kan verpesten. En hoe je het terugkrijgt :)
UPD Er is een websiteversnellingswedstrijd gestart. Prijzen zijn onder meer: monitor, webcam, muis. Alles gaat supersnel.
JavaScript-compressie
Over het algemeen is het de moeite waard om meteen te vermelden dat het comprimeren van JavaScript-bestanden ons slechts een verkleining van 5-7% oplevert in vergelijking met reguliere gzip, die kan worden gebruikt overal(nee, echt, overal - van Apache-configuratie via .htaccess tot statische compressie via mod_rewrite + mod_mime en nginx (of LightSpeed) configuratie). Maar terug naar het onderwerp: we willen JavaScript-bestanden minimaliseren, wat is de beste manier om dit te doen ?Twee jaar geleden werd een evaluatie van de huidige tools uitgevoerd, gedurende welke tijd de situatie niet veel is veranderd (behalve dat Google Compiler verscheen). Maar alles is in orde.
- Laten we beginnen met iets eenvoudigs. JSMin (of zijn kloon, JSMin+). Het werkt zeer universeel (volgens het principe van eindige toestandsmachines). Bijna altijd wordt het geminimaliseerde bestand zelfs uitgevoerd. Extra winsten (hierna gerelateerd aan eenvoudige gzip) - tot 7% in het geval van de geavanceerde versie, d.w.z. heel weinig. De processor eet matig (de geavanceerde versie, JSMin+ is sterker en het geheugen is aanzienlijk), maar analyseert de reikwijdte van variabelen niet en weet daarom niet hoe hij de lengte ervan moet verkleinen. In principe kan het voor vrijwel alle scripts worden gebruikt, maar soms zijn nuances mogelijk. Ze worden bijvoorbeeld verwijderd voorwaardelijke opmerkingen(dit kan worden verholpen) of verschillende constructies worden verkeerd herkend (++ wordt bijvoorbeeld omgezet in ++, dit doorbreekt de logica), dit kan ook worden verholpen, maar het is ingewikkelder.
- YUI-compressor. De bekendste (tot voor kort ook de krachtigste) tool voor het comprimeren van scripts. Het is gebaseerd op de Rhino-engine (voor zover we weten liggen de wortels van de engine ergens in de buurt van het Dojo-framework, dat wil zeggen heel, heel lang geleden). Comprimeert scripts perfect, werkt op de reikwijdte (kan de lengte van variabelen verminderen). De compressiesnelheid ligt tot 8% boven gzip, maar de processor eet gezond (vanwege het gebruik virtuele machine Java), dus wees voorzichtig als u het online gebruikt. Ook door de afname van variabele lengtes is het mogelijk verschillende problemen(en er zijn er potentieel zelfs meer dan voor JSMin).
- Google Closure Compiler is onlangs verschenen, maar heeft al het vertrouwen van het publiek gewonnen. Gebaseerd op dezelfde Rhino-engine (ja, niets nieuws onder de zon), maar gebruikt geavanceerdere algoritmen voor het verkleinen van de grootte broncode(uitstekend overzicht in alle details), tot 12% ten opzichte van gzip. Maar hier moet je dubbel voorzichtig zijn: een zeer aanzienlijk deel van de logica kan worden weggelaten, vooral bij agressieve transformaties. jQuery gebruikt deze tool echter al. Qua processorkosten is het blijkbaar zelfs zwaarder dan YUI ( dit feit niet getest).
- en Packer. Dit hulpmiddel is al verleden tijd door de ontwikkeling van communicatiekanalen en de vertraging van de processorkracht: omdat compressie daarin (een algoritme vergelijkbaar met gzip) wordt uitgevoerd met behulp van een JavaScript-engine. Dit levert een zeer aanzienlijke (tot 55% zonder gzip) reductie van de codegrootte op, maar extra kosten tot 500-1000 ms voor het uitpakken van het archief. Uiteraard wordt dit irrelevant als de processorkracht beperkt is (hallo, IE) en de verbindingssnelheid erg hoog is (+ gzip wordt al bijna overal gebruikt en ondersteund). Bovendien is deze optimalisatiemethode na minimalisatie het meest vatbaar voor verschillende bugs.
Problemen met het samenvoegen van JavaScript-bestanden
Nu we de compressie van JavaScript-bestanden hebben besproken, is het goed om even in te gaan op het onderwerp van het samenvoegen ervan. De gemiddelde website heeft 5-10 JavaScript-bestanden + verschillende ingebouwde (inline) stukjes code die op de een of andere manier plug-inbibliotheken kunnen aanroepen. Als gevolg hiervan kunnen 10-15 stukjes code worden gecombineerd (hier zitten veel voordelen aan - beginnend bij de laadsnelheid aan de gebruikerskant en eindigend met serverfouttolerantie voor DDoS - hier telt elke verbinding, zelfs statische degenen).Maar laten we teruggaan naar de schapen. Nu zullen we het hebben over enige automatisering van het combineren van scripts van derden. Als je iets met ze te maken hebt volledige toegang(en je begrijpt webontwikkeling), dan is het geen probleem om de problemen op te lossen (of een aantal problematische scripts uit te sluiten van de samenvoeging). Anders (als een set scripts niet zonder fouten wil samenkomen), is de volgende aanpak iets voor jou.
We hebben dus 10-15 stukjes code (sommige in de vorm van ingebouwde code, sommige in de vorm van externe bibliotheken, die we ook kunnen samenvoegen). We moeten hun onafhankelijke prestaties garanderen. Wat is het?
Als we een JavaScript-fout in een bestand hebben, stopt de browser met het uitvoeren van dit bestand vanwege de fout (enkele van de oudste versies stoppen in dit geval ook met het uitvoeren van alle JavaScript-bestanden op de pagina, maar daar hebben we het niet echt over) . Dienovereenkomstig, als de eerste bibliotheek waarin we willen combineren gedeeld bestand, een foutmelding geeft, zal in alle browsers onze clientlogica na het samenvoegen uit elkaar vallen. Triest.
Bovendien is het vermeldenswaard dat ingebouwde (inline) code vrij moeilijk te debuggen is. U kunt het uitsluiten van de samenvoeging (bijvoorbeeld door de aanroep van het samengevoegde bestand voor of na de code te plaatsen), of als u deze gebruikt, kunt u de samenvoeging van de bestanden helemaal annuleren.
Achterwaartse compatibiliteit
Wat kunnen we eraan doen? De eenvoudigste manier: uitsluiten problematische bestanden(in dit geval kunnen fouten alleen in de samenvoegfase optreden, maar individuele bestanden kunnen met een knal werken) vanuit de samenvoeglogica. Om dit te doen, moet u nagaan waar de fout optreedt en voor elk dergelijk geval een configuratie samenstellen voor het samenvoegen.Maar je kunt het iets eenvoudiger doen. Voor JavaScript kunnen we de try-catch-constructie gebruiken. Ja, snapte je het idee? Nog niet? We kunnen alle inhoud van de bestanden die we combineren insluiten in try () , en in catch(e) () kunnen we de verbinding van het externe bestand ongeveer zo noemen:
try ( ... inhoud van de JavaScript-bibliotheek... ) catch (e) ( document.write("eerste aanroep van het JavaScript-bestand"); // of console.log("moet het JavaScript-bestand uitsluiten van de samenvoeging "); )
In dit geval zal de gebruiker slechts één bestand downloaden als er geen problemen optreden. Als er fouten zijn, worden alle externe problematische bestanden in dezelfde volgorde verbonden. Dit zal ervoor zorgen achterwaarts compatibel.
Prestatieproblemen
Dat is duidelijk deze aanpak is niet “het meest correct”. Het meest logische zou zijn om JavaScript-fouten te identificeren, deze op te lossen en één bestand voor alle gebruikers te downloaden. Maar dit is niet altijd mogelijk. Het is ook de moeite waard om te overwegen dat de try-catch-constructie een beetje zwaar is om uit te voeren in browsers (voegt 10-25% toe aan de initialisatietijd), dus je moet er voorzichtig mee zijn.Maar de beschreven aanpak kan uitstekend worden gebruikt voor het debuggen van specifiek het samenvoegen van JavaScript-bestanden: je kunt er immers nauwkeurig mee bepalen welke bestanden "bezaaid" zijn (als er enkele tientallen bestanden zijn, is dit heel erg handig).
Een korte samenvatting
Controleer na verdere verkleining van JavaScript-bestanden hun functionaliteit. En het debuggen van de juistheid van het combineren van JavaScript-bestanden kan eenvoudig worden geautomatiseerd, of zelfs worden geconfigureerd voor achterwaartse compatibiliteit als het onmogelijk is om specifieke scripts te debuggen.Igor.
Update: 25 november 2017. Hallo, lieve lezers
blogsite. Als volgende stap die uw site aanzienlijk kan versnellen, analyseren we het proces van gzip-compressie van de meest gebruikte bronnen die nodig zijn voor de correcte weergave van sitepagina's, namelijk stijlbestanden (CSS), scripts (JS) en HTML . Over het algemeen het meest effectieve hulpmiddelen om de mate van optimalisatie van webprojecten vandaag de dag te controleren Pagina-technologie Snelheid, gebruikt door veel gespecialiseerde webbronnen. Google zelf biedt webmasters dezelfde tool aan in de vorm van een gespecialiseerde online dienst (lees over de nuances van het testen van websitepagina’s in Google Paginasnelheid
Inzichten).
Voordat u dit artikel verder leest, raad ik u aan om op zijn minst kort vertrouwd te raken met de materialen die over, vorming, over praten. Alleen een geïntegreerde aanpak geeft u immers de mogelijkheid om uw website maximaal te versnellen.
Het is zeker niet de moeite waard om activiteiten te verwaarlozen die uw site nog een beetje sneller zullen maken, aangezien zoekmachines steeds meer aandacht besteden aan het rekening houden met de snelheid van bronnen.
Dat is de reden waarom zelfs een winst van enkele honderden of zelfs tientallen milliseconden, waarin de elementen van een webpagina in de browser worden geladen, u aanzienlijke voordelen kan opleveren bij websitepromotie. En het volgen van alle aanbevelingen van dezelfde Paige Speed zal het effect aanzienlijk vergroten (ik raad u nogmaals aan de bovenstaande links te volgen). Ooit heb ik tijdens de optimalisatie van een van mijn projecten dezelfde PageSpeed-tool gebruikt om te testen, maar toen werd deze onder andere aangeboden als onderdeel van add-ons voor Google Chrome
en Mozilla, en om dat laatste te installeren moest je eerst de onvergetelijke Firebug-extensie () installeren.
Dus bij de volgende stap bij het optimaliseren van een van mijn bronnen, toen ik de paginasnelheid controleerde, liet ik weten dat het de uitvoering van gzip-compressie van scripts, stijlbestanden en HTML-documenten is die aanstaat op dit moment prioriteit (aanbeveling stond in de rode zone):
Daarom heb ik het instellen van de compressie destijds niet uitgesteld. lange doos, en begonnen onmiddellijk actie te ondernemen (hieronder leest u meer over de specifieke stappen), waardoor we uiteindelijk een aanzienlijke verhoging van de laadsnelheid van de pagina konden realiseren, en het probleem onmiddellijk naar de categorie opgelost (groene zone) verplaatste:
Implementatie van gzip-compressie werd mogelijk gemaakt dankzij de activering mod deflate-module, die kan worden ingeschakeld via richtlijnen in het .htaccess-configuratiebestand, dat alle processen met betrekking tot sites regelt Apache-servers. Lees meer over dit alles verderop in de tekst, maar nu wil ik wel opmerken dat deze methode alleen goed zal werken als Apache in pure vorm geïnstalleerd is op de hosting waar uw website “leeft”.
Feit is dat veel toonaangevende providers een combinatie van Apache + Nginx gebruiken, waarbij dit laatste een zeer belangrijke rol speelt belangrijke rol, waarbij onder meer de functies van een caching-server worden uitgevoerd en de hoofdbelasting op zich wordt genomen. Als jouw hoster deze specifieke optie gebruikt, dan worden alle instellingen (niet alleen compressie, maar bijvoorbeeld ook) op Nginx gedaan.
De meeste eigenaren van websites die zich op gedeelde virtuele hosting bevinden, kunnen dit om puur technische redenen eenvoudigweg niet zelf doen. Trouwens, mijn huidige provider Sprinthost () heeft gzip ingeschakeld via Nginx, dus de sitepagina heeft de compressietest in Paginasnelheid met succes doorstaan:
Voordat ik verder ga, wil ik advies geven aan beginnende webmasters. Als de compressie op uw server niet werkt (u kunt dit achterhalen via de testresultaten in Page Speed) en niet start na de juiste acties om deze te activeren, neem dan contact op met uw hostingondersteuningsdienst. Een adequate aanbieder zal uiteindelijk zeker helpen; het oplossen van klantproblemen is in zijn belang.
Hoe u websitecompressie online kunt controleren, inclusief de aanwezigheid van de Content-Encoding HTTP-header
Zoals ik al zei, zal Google PageSpeed u vertellen of compressie werkt op de pagina's van uw bron. Het zou echter niet verkeerd zijn om dit op een andere manier te controleren, bijvoorbeeld door gebruik te maken van online-dienst ov. Wekt vertrouwen deze, waar u binnenkomt Pagina-URL, klik op de knop “Test” en na een paar seconden krijg je het antwoord:
IN in dit geval Het is te zien dat de componenten van de geteste pagina zijn gecomprimeerd, wat betekent dat compressie op de server is ingeschakeld voor HTML-documenten.
U kunt op dezelfde manier ook de compressie voor CSS-bronnen controleren. De analysator liet bijvoorbeeld hetzelfde beeld zien met betrekking tot het hoofdstijlbestand van deze blog:
Nou, mijn gecombineerde script (JS) bleek ook gecomprimeerd:
Er is er nog één goede bron GTmetrix(voer de URL van de onderzochte pagina in en klik op de knop “Analyseren”), die analytische informatie biedt over alle aspecten van de webpagina van de site. Ga na de test naar Tabblad "Waterval".:
Hier kunt u alle objecten die zijn geladen met een webpagina voor compressie gedetailleerder bestuderen. Weet je nog, ons doel is om gzip aan te bieden HTML-compressie, scripts en stijlbestanden. In het resulterende GTmetrix-rapport vindt u dus al deze gegevens.
Allereerst moet u de cursor verplaatsen naar het getal dat de bestandsgrootte in bytes weergeeft. Wanneer compressie is ingeschakeld, verschijnt er een tooltip, die ook de grootte van het niet-gecomprimeerde object weergeeft. Voor het voorbeeld in de volgende schermafbeelding is het bijvoorbeeld duidelijk dat het bestand HTML-pagina's bijna vier keer tijdens de vlucht gecomprimeerd:
Maar dat is niet alles. Door op het plusteken te klikken naast de regel die overeenkomt met een bepaald object, onthult u informatie over de serverreactie, waarvan de aanwezigheid Inhoudscodering met de waarde gzip betekent dat compressie is ingeschakeld.
De parameters van de Accept-Encoding-header informeren over welke compressiemethoden deze browser ondersteunt (tegenwoordig is het onwaarschijnlijk dat gebruikers oudere versies van webbrowsers zullen gebruiken die een of andere vorm van compressie niet ondersteunen, maar toch...). We controleren de CSS- en JS-bestanden (scripts) op dezelfde manier:
Hoe gzip-compressie van JS, CSS en HTML in htaccess in te schakelen
Eigenlijk zijn het idee van compressie in het gzip-formaat en het mechanisme voor de implementatie ervan uiterst eenvoudig gemeenschappelijk begrip. De bestanden die nodig zijn voor de correcte weergave van een webpagina (CSS-stijlen, verschillende soorten scripts, HTML-documenten) worden gearchiveerd en in gecomprimeerde vorm naar de browser van de gebruiker verzonden. Dit verkort de laadtijd van de pagina aanzienlijk. Over het algemeen zijn die er verschillende soorten compressie, maar in dit geval is gzip het meest effectief.
De meeste moderne webbrowsers ondersteunen (zeker) gzip-compressie, dus er zijn aan deze kant geen problemen, zoals ik hierboven al zei. Vervolgens zullen we er twee bekijken verschillende methoden implementatie van compressie: dynamisch en statisch.
De eerste wordt zeer snel uitgevoerd met behulp van richtlijnen die zijn geschreven in het beroemde .htaccess-bestand, maar gaat gepaard met extra belasting van de server (), en de tweede dwingt je om meer inspanning, maar vereist geen extra hostingbronnen. Elk heeft zijn eigen voor- en nadelen, dus u moet de methode overwegen en kiezen die bij uw prioriteiten past.
Dynamische gzip-compressie voor maximale snelheid van de website
Deze methode om compressie mogelijk te maken bestaat uit het direct archiveren van bestanden, dat wil zeggen onmiddellijk vóór verzending, en het vervolgens uitpakken ervan in de browsers van gebruikers. Bovendien is het in dit geval mogelijk om zelfs het HTML-paginadocument zelf effectief te comprimeren, hoewel het, in tegenstelling tot CSS-bestanden en scripts, bij gebruik van een CMS (bijvoorbeeld) dynamisch wordt gegenereerd op basis van basissjablonen.
On-the-fly compressie is zeer productief, maar omdat er gebruik wordt gemaakt van servertools, wordt de compressie extra belast. Denk er dus goed over na of dit voor u geschikt is. In die zin dat je misschien moet upgraden naar een duurder exemplaar tariefplan om binnen de grenzen van het gebruik van hostingbronnen te blijven.
We zullen dynamische compressie inschakelen met behulp van hetzelfde magische .htaccess-bestand, dat verantwoordelijk is voor de configuratie van de server waarop Apache draait (zoals ik hierboven opmerkte, als je de combinatie Apache + Nginx hebt, zal het nummer niet werken en moet je neem contact op met de host voor hulp).
Maak eerst verbinding met de webserver via FTP, met behulp van een betrouwbare manager zoals FileZilla(). Het .htaccess-bestand moet zich in de hoofdmap (public_html of htdocs) van uw site bevinden:
Als het er niet is, probeer dan vanaf te gaan bovenste menu Filezilla naar het gedeelte "Server" en selecteer uit contextmenu"Weergave verborgen bestanden" In de meeste gevallen zou dit moeten helpen. Maar als .htaccess daarna plotseling niet verschijnt, kunt u het zelf maken.
Omdat het configuratiebestand nodig zal zijn om daarin speciale richtlijnen aan te geven, is het handiger om een ander bestand te gebruiken voor bewerking nuttige software Kladblok++(). Maak daarin een nieuw bestand rechtstreeks op de server en noem het “.htaccess” (dat klopt, met een punt ervoor):
Nadat je op een of andere manier de aanwezigheid van het Apache-serverconfiguratiebestand in de root van de site hebt bereikt, is het tijd om het te vullen (of aan te vullen) met de juiste code.
In naam van het behoud correcte werking site bij het bewerken van bestanden is het belangrijk om te doen back-ups hun originele versies.
Dus compressie in relatie tot benodigde bestanden geactiveerd op Apache-servers met behulp van de module mod leeglopen, waarvan de richtlijnen, zoals we al hebben ontdekt, in .htaccess moeten worden ingevoerd:
De aanwezigheid van "IfModule" in de richtlijn (vergelijkbaar met het gebruik van mod voids en mod headers met ) maakt het mogelijk om de aanwezigheid van een module te controleren en deze in te schakelen als deze niet is geactiveerd. Dit zal voorkomen onnodige problemen geassocieerd met verstoring van hulpbronnen. Als de module niet geïnstalleerd is, volgen er immers niet zomaar wijzigingen, maar functioneert de website als voorheen.
Let er ook op dat de richtlijnen een module bevatten mod setenvif, dat oudere versies van sommige browsers die gzip niet ondersteunen opdracht geeft om niet-gecomprimeerde versies van bestanden weer te geven. Hoewel dergelijke webbrowsers door een klein aantal gebruikers worden gebruikt, denk ik dat het verlaten van “mod setenvif” redelijk is, het zal de zaken zeker niet erger maken.
Als de bovenstaande code niet werkt, is het heel goed mogelijk dat mod deflate in eerste instantie niet op de server is geïnstalleerd. Probeer in dit geval in te schakelen mod gzip(de praktijk leert dat de ene of de andere module noodzakelijkerwijs aanwezig is op de meeste hosters op Apache-servers) met behulp van de volgende richtlijn:
Als dit niet werkt, probeer dan de universele optie:
Ondanks het feit dat de IfModule-container de verschijning van eventuele fouten na het invoegen van de code uitsluit, moet u er toch een regel van maken dat elke keer dat u bestanden (niet alleen .htaccess) op de server bewerkt, u er back-ups van maakt en een geavanceerde editor gebruikt zoals Notepad ++ als u niet wilt dat uw site ontoegankelijk wordt.
Als u het vakje naast dit item aanvinkt, kunt u het probleem van het inschakelen van gzip-compressie onmiddellijk oplossen. Dan zullen maatregelen die de noodzakelijke richtlijnen in .htaccess aangeven niet alleen onnodig, maar ook onwenselijk zijn. Dit staat duidelijk vermeld in de beschrijving van deze optie (zie screenshot hierboven).
Hoe u statische gzip-compressie inschakelt om de belasting te verminderen
Laten we nu verder gaan met de tweede compressieoptie, die wat meer inspanning zal vergen, maar met zijn hulp kunt u de belasting van de server vermijden. Dit geldt vooral voor degenen die niet graag willen overstappen naar een duurder tarief.
Idee deze methode bestaat uit het maken van gecomprimeerde kopieën van scriptbestanden en CSS-documenten, en deze vervolgens samen met de niet-gecomprimeerde versies in de hoofdmap te plaatsen. Nu worden, indien nodig, in reactie op een verzoek reeds gecomprimeerde stijl- en JS-bestanden naar de browser overgebracht en hoeft de server niet langer zijn bronnen op te geven voor compressie.
Toegegeven, als je het gemerkt hebt, heb ik niets over de hoofdzaak gezegd HTML-document. De meeste eigenaren gebruiken immers een of ander CMS, bijvoorbeeld WordPress (), om hun websites te beheren.
Het thema binnen de engine bestaat uit PHP-bestanden, als gevolg van interactie waarmee een pagina in de browser wordt gegenereerd. Daarom kunnen we een gecomprimeerd bestand niet vooraf samenstellen HTML-versie in de hoofdmap, zodat alleen statische scripts overblijven en CSS-bestanden.
Implementeren dus statische gzip-compressie van JS- en CSS-bestanden, moet u ze eerst naar uw computer downloaden (opnieuw zal Filezilla u helpen). Om ze te archiveren, kunt u een gratis archiveringsprogramma gebruiken 7-ritssluiting. Download het en installeer het zoals gewoonlijk, er zouden geen installatieproblemen moeten zijn. Trouwens, misschien zal iemand in de reacties alternatieve archiveringshulpmiddelen voorstellen? Ik zal alleen maar blij zijn, het zal ook nuttig zijn voor andere lezers.
Na de installatie opent u het programma en klik met de rechtermuisknop klik op het vooraf geladen bestand dat bedoeld is voor compressie en selecteer vervolgens in het contextmenu “7-zip” - “Toevoegen aan archief”:
Hierna verschijnt een dialoogvenster waarin u het archiefformaat (gzip) en de bewerkingsmodus (toevoegen en vervangen) moet selecteren, de overige instellingen worden standaard ingesteld, zoals in de afbeelding, dat hoeft niet iets veranderen:
Nadat u op de knop "OK" hebt geklikt, zal er een verpakking plaatsvinden (in dit geval CSS) en zullen we 2 bestanden ontvangen: één origineel, ongecomprimeerd, de andere in gzip-archiefformaat met de gz-extensie.
Pas nu op dat je niets verprutst. Sommige browsers accepteren geen bestanden met de gz-extensie, dus verwijderen we de .gz-extensie met behulp van de optie voor het wijzigen van de bestandsnaam. We krijgen alleen style.css, maar in feite zal het een gzip-archief zijn.
Volgende. Oudere versies van browsers ondersteunen geen gzip-compressie, maar sommige gebruikers gebruiken deze nog steeds. Daarom voegen we nogzip toe aan het originele, niet-gecomprimeerde bestand en krijgen: style.nogzip.css, we geven het aan browsers die geen compressie ondersteunen. In de som van alle acties krijgen we twee bestanden CSS-stijlen in de hoofdmap:
Het bestand style.css (gecomprimeerd) wordt dus gegeven aan browsers die gzip-compressie ondersteunen, en style.nogzip.css (niet-gecomprimeerd origineel) wordt gegeven aan oudere versies van browsers die archivering niet ondersteunen. Nu moet een soortgelijke bewerking worden uitgevoerd voor alle JS- of CSS-bestanden die samen met de webpagina's van de site worden geladen. Om statische gzip-compressie te laten werken, moet je de volgende code meerdere keren in het .htaccess-bestand invoegen:
Bovendien, als u eerder dynamische gzip-compressiecode had, moet u deze vervangen door de bovenstaande code, anders werkt niets. Dat is waarschijnlijk alles, maar het onderwerp websiteversnelling zal zeker worden voortgezet, dus vergeet u niet te abonneren op blogupdates.
Concluderend stel ik voor om een reeks video-tutorials van zes afleveringen te bekijken (inclusief gzip-compressie) gewijd aan de meest belangrijke aspecten het versnellen van een WordPress-site en praktische implementatie van PageSpeed-aanbevelingen:
");">
Wilt u tijdig nieuwe, relevante en nuttige artikelen ontvangen? Dan kunt u zich abonneren:
Meer artikelen over dit onderwerp:
37 beoordelingen
- Andrej
Igor, het artikel is cool en erg nuttig. Ik ben dit probleem zelf tegengekomen. Hosting ondersteunt geen compressie. Ik besloot de tweede optie te proberen, maar kwam een vraag tegen. Comprimeer de CSS van alleen de thema's of alle CSS-bestanden die ik heb gevonden. Ik heb bijna geen scripts gevonden. Geef indien mogelijk aan met welke specifieke bestanden u wilt werken.
- Igor
Andrey, zoals ik het begrijp, bedoel je statische compressie? Comprimeer de CSS-bestanden die zich in de hoofdmap bevinden (bijvoorbeeld style.css van het huidige WordPress-thema). Nou ja, het heeft natuurlijk geen zin om hele kleine bestanden te comprimeren; het spel is de kaars niet waard.
- Nikolaj
Cool, geweldig, het werkte!
Hartelijk dank voor het artikel, het heeft enorm geholpen!
Het laatste deel kwam goed van pas!
Ik ga verder met het volgende artikel! - Arkadi
bedankt voor de informatie.
- Vladimir
Hoe bewerk ik het .htaccess-bestand?
Ik open het met kladblok, bijna alle regels beginnen met c#
Is het zo makkelijk in te brengen? Ik voeg in, er gebeurt niets, of de hosting crasht.. - Igor
Vladimir, heb je nog een laatste regel: #END WordPress? Als deze bestaat, plaats dan de code tussen deze regel en de regel erboven (die hoogstwaarschijnlijk de afsluitende tag /IfModule bevat). Als compressie niet werkt, moeten alle vragen worden gericht aan de hostingprovider. Voor mij werkt bijvoorbeeld alles.
- Vladimir
Een zeer uitgebreid en nuttig artikel. Ik probeer het op deze manier en dat en niets werkt. Blijkbaar ligt het probleem bij de host. Maar toch bedankt.
- Vladimir
Hosting ingeschakeld rucentrum Dat gebeurt niet zomaar)
Ik heb een oplossing gevonden, wie heeft hetzelfde probleem http://forum.nic.ru/showthread.php?t=2389 - Igor
Ja, Vladimir, helaas ondersteunen niet alle hostingproviders gzip-compressie in dit formaat, dit is het nadeel van deze methode.
- salade
Je kunt alle CSS in één comprimeren en in base62 pushen.
Dit zal echt een verschil maken. - Irina
OK! Bedankt!
De code hielp:AddOutputFilterByType DEFLATE tekst/html AddOutputFilterByType DEFLATE applicatie/javascript AddOutputFilterByType DEFLATE tekst/javascript AddOutputFilterByType DEFLATE tekst/css BrowserMatch ^Mozilla/4 gzip-only-text/html BrowserMatch ^Mozilla/4\.0 no-gzip BrowserMatch \bMSIE !no -gzip !gzip-only-text/html
- Ilja
Klas! Klas! Klas!!!
Bedankt. De eerste optie werkte meteen.
Ik ben gewoon verbaasd: hoe kun je zulke diepgaande artikelen schrijven? Ik zou niet genoeg zijn =))) - Joeri
BEDANKT!
Op beide sites werkte het.
Apache dressoir, instantcms-motor
Laadsnelheid tot 0,07 werd 0,04.PageSpeed Insights: was 43\100, nu 69\100
Ik heb de eerste code ingevoerd. De rest werkt ook.
In de hostingvoorwaarden staat niet dat deze functie bestaat.
Nogmaals bedankt - Igor
Yuri dacht eerlijk gezegd niet dat zoiets een positief effect zou hebben. een groot percentage gebruikers. Geweldig!
- Stijit
Bedankt voor de informatie. Is het mogelijk om hetzelfde te doen, maar dan met een plug-in?
- Igor
Ik denk dat het mogelijk is, maar ik heb er geen getest. Ik probeer zulke dingen te doen met behulp van codes.
- Vladimir
Ik heb je opties geprobeerd, maar helaas resulteren alle richtlijnen die in htacces worden ingevoerd in fout 500. Kijk naar webprofit.kz, het werkt op nginx. Wat kunt u mij bieden?
- Igor Gornov
Vladimir krijgt helaas niet iedereen een 100% resultaat. Veel hangt af van de serverconfiguratie-instellingen op uw hosting. Als al het andere niet lukt, neem dan contact op met het ondersteuningsteam van uw hostingprovider.
- Nikita
Vertel me, wat moet ik doen als de JS- en CSS-bestanden niet in de hoofdmap staan?
Ik heb compressie geconfigureerd en alle online services zeggen dat gzip is ingeschakeld, maar bij het inchecken in PageSpeed Insights staat dat sommige bestanden (die zich in mappen bevinden) niet zijn gecomprimeerd.
Ja, Yuri, de interface is inderdaad enigszins veranderd, het is goed dat je het hebt opgemerkt. Ik zal de link naar de verificatiepagina verduidelijken:
http://www.port80software.com/support/p80tools
Voer daar de URL van uw bron in het bovenste veld “Compressiecontrole” in en klik op de knop aan de rechterkant “Controleren”.
- Joeri
Ik ben erg dankbaar voor de hint, en ik heb ook een vraag: de bovenstaande compressiemethoden zijn van toepassing op gewone HTML sites???, - of alleen die gebaseerd op WordPress (ik heb alle inhoud voor .htaccess geprobeerd - het werkt niet - ik vraag me af of het de moeite waard is om archieven te maken)
- Igor Gornov
Ja, al vind ik dat een eenvoudige HTML-site sowieso snel moet laden. Of het de moeite waard is om statische compressie te gebruiken, het hangt allemaal af van de staat van uw bron en de mate van “druk” op de hostingserver.
Hoewel ik meteen zal zeggen dat je alleen als gevolg van compressie geen krachtige en merkbare toename van de laadsnelheid van de site zult bereiken. Een ernstig effect treedt pas op nadat alle versnellingsoperaties volledig zijn uitgevoerd.
Toch is de statische compressiebewerking behoorlijk vervelend, dus laat het voor later als je een reserve hebt. Mogelijk kunt u het zonder doen, probeer andere manieren om uw site te versnellen.
- Alexander
Goedemiddag
Ik heb besloten om statische gzip-compressie van JS- en CSS-bestanden uit te voeren volgens uw instructies. Maar ik kwam een probleem tegen. Als ik niet verwijder gecomprimeerd bestand extension.gz, dan worden de stijlen normaal geladen, maar zodra ik de extensie verwijder, worden de stijlen niet geladen. Vertel me, wat doe ik verkeerd? - Igor Gornov
Alexander, controleer nogmaals of je alles volgens de instructies hebt gedaan.
- Alexander
Hallo Igor! Ik kwam uit de situatie met behulp van de volgende code:
### 1. Js-bestanden verwerken
ForceType tekst/javascript Headerset Inhoudscodering: gzip RewriteEngine aan RewriteCond %(HTTP_USER_AGENT) !".*Safari.*" RewriteCond %(HTTP:Accept-Encoding) gzip RewriteCond %(REQUEST_FILENAME).gz -f RewriteRule (.*)\.js$ $1\.js.gz [ L] ForceType-tekst/javascript ### 2. CSS-bestanden verwerkenForceType tekst/css Headerset Inhoudscodering: gzip RewriteEngine aan RewriteCond %(HTTP_USER_AGENT) !".*Safari.*" RewriteCond %(HTTP:Accept-Encoding) gzip RewriteCond %(REQUEST_FILENAME).gz -f RewriteRule (.*)\.css$ $1\.css.gz [ L] ForceType-tekst/css Met deze code kunt u de naam van het archief niet wijzigen. Als gevolg hiervan zijn er twee bestanden met stijlen in de map: style.css en style.css.gz
Bedankt! de eerste code hielp!
- YaBlogo.su
Winkelscript geeft fout 500
In dit artikel zullen we kijken naar online manieren om js te comprimeren ( javascript) bestanden om hun grootte te verkleinen. Tegenwoordig worden veel webbronnen gebruikt als derde partij Java scripts (bijvoorbeeld hetzelfde jQuery-bibliotheek en talloze plug-ins ervoor), en eigen ontwikkeling. Compressie verkleint de grootte van de laadpagina van de site en daarmee ook de laadtijd. Dit is een van de optimalisatiefasen die iedereen zou moeten doen.
Zelfs als de server gebruikt gzip compressie, die ongetwijfeld de omvang zal verkleinen, mag de bestandsoptimalisatie niet verwaarlozen, aangezien het uitpakken van bestanden uit het archief ook tijd kost.
Laten we eens kijken naar de twee meest voorkomende en effectieve manieren compressie: YUI Compressor en Google Closure Compiler.
YUI-compressor
Maakt gebruik van een parser javascript geschreven in taal Java die wordt genoemd Neushoorn.
Gepatcht Neushoorn comprimeert via twee hoofdbewerkingen:
- verwijdert onnodig witruimte tekens en opmerkingen
- vervangt lokale variabelenamen door kortere
Officiële website Yahoo biedt geen kansen online compressie scripts, maar er is een service op het netwerk
het bieden van deze mogelijkheid.
We zullen bijvoorbeeld het knipperende tekstscript comprimeren:
Var blink_text="Knipperende tekst?" var speed=700 var n=navigator.appName var ns=(n=="Netscape") var ie=(n=="Microsoft Internet Explorer") if (ns)( document.write(" ")) else if (ie)( var verificatie = 1; document.write("
") blink()) function blink())( if (verify == 1)( document.all.blink.innerText=blink_text; verifieer=0;) else ( document.all.blink.innerText=""; verifieer= 1 ;) setTimeout("blink()",speed); Plak de code in het tekstveld, selecteer het bestandstype JS(je kunt ook comprimeren CSS bestanden) en klik Comprimeren.
Als resultaat krijgen we:
- Grootte tot 489 bytes
- Na compressie 417 bytes
- Compressiepercentage 15%
- Na compressie en gzip-verpakking 270 bytes
- Het percentage compressie en verpakking in gzip is 45%
Google Sluitingscompiler
Dit hulpmiddel is afkomstig van Googlen en net als YUI effectief omgaat met zijn taak. In tegenstelling tot YUI-compressor het heeft een officiële online compressieservice
Voor compressie gebruiken we dezelfde code. Plak het in het tekstveld en klik Compileren.
Aan de rechterkant van het venster krijgen we een gecomprimeerde versie
- Grootte tot 439 bytes
- Na compressie 390 bytes
- Compressiepercentage 11,16%
- Na compressie en gzip-verpakking 255 bytes
- Compressie- en pakkingspercentage in gzip 6,25%
Google Sluitingscompiler, te oordelen naar de bestandsgrootte na compressie, 390 bytes tegen 417 bytes bij YUI-compressor vermindert effectiever. Efficiënter (bijv in dit voorbeeld) op 6,5 %
Het is echter vreemd dat de initiële grootte van het script door beide services anders wordt bepaald.
U kunt van elke dienst gebruik maken.
Het script terugbrengen naar de oorspronkelijke staat
En om uw gecomprimeerde javascript-bestand weer in een leesbare vorm terug te brengen, maken we gebruik van een online service
