For a near-instantaneous page load you will need to get the initial request size down to a few hundred kilobytes or fewer - that budget will already be exceeded by one huge hero image. If you are including desktop-resolution images on mobile devices, you can optimize loading times all you want, your performance will still be abysmal. Responsive images and lazy loading #įor every website that contains images, using responsive images is the most important performance aspect, period. It will let you know which are the most important issues to fix, so you know where to get started. If your site is still in development and is not publicly available, you can use the Lighthouse tool included in the Chrome browser. This tutorial focuses mainly on ‘low-hanging fruit’ - techniques that are easy to use and can be applied to most normal ProcessWire sites while having a huge impact on performance.īefore you get started, make sure to test the performance of your site with some tools such as PageSpeed Insights to get a feeling for where you’re standing. Also, some of the most important techniques are not specific to ProcessWire, but apply to all CMS-based web projects. Of course, performance optimization has many layers and there are many techniques to cover - too many for one tutorial. This tutorial documents a number of opportunities for page speed gains which you can apply to your own sites to achieve noticeably faster loading times. However, with a growing expectation for sites to load pretty much instantaneously, there’s always something to optimize. ProcessWire is already pretty fast by default because of its small overhead. Optimize the performance of ProcessWire sites Serving compressed assets to reduce bandwidth usage.Server-side caching: Template cache and ProCache.ℹ️About GitHub Wiki SEE, a search engine enabler for GitHub WikisĪs GitHub blocks most GitHub Wikis from search engines.Toggle site navigation Skip to main content Overview If your page is a MagicPage it will load YourPage.css and YourPage.js files automatically in the PW backend when editing any page of type YourPage. If you have many templates you can disable the feature by setting $config->useMagicClasses = false. Note that this feature loads one page of each available template at every boot so it has a little performance penalty. onSaveReady() instead of hooking Pages::saveReadyįor all available methods see MagicPages::addMagicMethods()!.editForm($form) instead of hooking ProcessPageEdit::buildForm.$page = $this->wire->page // currently viewed pageĪ MagicPage does also have other magic methods that make the most common hooks a lot easier to use: But hooks that belong to the page class should in my opinion be written in the pageclass file and not in /site/ready.php! When using RockMigrations you can make your pageclass even smarter and attach hooks directly from within it's own pageclass file: // example pageclass That means you can't attach hooks in custom page classes by default. The problem with custom page classes is, that they do not trigger init() and ready() automatically. You avoid hook-hell and your IDE can assist you because it suddenly understands your code!
#Ide for processwire code#
If you are not using custom page classes yet I highly recommend to start using them now! Without them every page is a "stupid" page object, but when using custom page classes you add so much more logic to your code and suddenly every event is an EventPage and every newsitem is a NewsPage.
0 kommentar(er)
