• We may be forced to disable your plugin due to the bad deployments of HTML and CSS. The usage of non-unique IDS is the first issue.

    BUT, the one that is mission critical, The webfont is also very frustrating. Your plugin loads a webfont. Not sure WHY you would even load ANY font in your plugin. But its causing massive issues. First, it loads the webfont in a non-standard WordPress manor. So it does not work with lazy load plugins.

    Thus, it presents as a rendering blocker. One that takes 1.49s!

    ALSO, its the SECOND webfont we are loading. The plugin does not dedupe the webfont and the version on the webfront query string ensures it loads twice.

    Please allow a way to disable the CSS and/or please fix the page blocking. This is not acceptable and we will have to find a new plugin. 🙁 Also, because of the way your loading it, the CDN wont pick up the responsibility. Please advice!

    P.S. to reproduce, goto and run the audit tool. You will find one page blocking resource and its yours.

    A) because we load another webfront with another plugin and the two versions compete. B) the Webfont does not lazy load.

    This means your plugin is now slowing our main page down by 1.49s! Thats INSANE!

    Please setup the webfont to load with lazy load or use4 a method of loading the font with the wordpress functions so that lazy load plugins can use your code.

    The page I need help with: [log in to see the link]

Viewing 5 replies - 1 through 5 (of 5 total)
  • This CSS is unacceptable. Removing it has removed the issue. This is NOT the way you load fonts. It’s not even on the top of the page.

    src:url(‘../fonts/fontawesome-webfont.eot?#iefix&v=4.6.1′) format(’embedded-opentype’),
    url(‘../fonts/fontawesome-webfont.woff?v=4.6.1’) format(‘woff’),
    url(‘../fonts/fontawesome-webfont.ttf?v=4.6.1’) format(‘truetype’),
    url(‘../fonts/fontawesome-webfont.svg?v=4.6.1#fontawesomeregular’) format(‘svg’);

    We have removed it. We will be removing the plugin as well. These quality issues hint at more pressing problems with the plugin. Using multiples of this plugin causes the page to not validate.

    Plugin Author smashballoon


    Hi @mgparisi,

    Sorry to hear you experienced some issues with the plugin. We’re continually trying to make the plugin better and appreciate any input from our users to help us achieve that.

    I’ll address each point below:

    1) If you add multiple feeds to a page then this will result in duplicate IDs in the HTML, however, this will not negatively affect SEO in any way. Google have confirmed that while severely broken HTML which is unreadble by their crawlers will affect their ability to rank pages, simple HTML validity issues (like a duplicate ID) is not going to negatively affect your ranking and has no bearing on SEO.

    We do have this on our list of things to address in the plugin, however, due to it’s low impact it is further down our development priority list. We appreciate you pointing the issue out though, and have taken your feedback on board.

    2) Regarding web fonts, I ran an audit on a page with our plugin on it and it scored a perfect 100 for performance (screenshot). The reason we include the fonts in the CSS file is a) we only use 4 font icons in the plugin and so felt it uneccessary to include CSS for hundreds of them, and b) it avoids an external HTTP request to get a font CSS file which then loads the fonts in the same way at the top of the file.

    It seems like you have some experience with performance audits and so am interested to know why loading the font files in our CSS file is poorer for performance than loading them within an external CSS file. I’m by no means an expert on performance and so am genuinely interested in learning more about this. Wouldn’t loading the font files in our plugin CSS file avoid that additional HTTP request to get the external Font Awesome CSS file?

    I also assumed that it would be adventageous to do it this way as we are only using 4 icons, and so only include the CSS for 4 icons vs the hundreds in the Font Awesome library. Wouldn’t this be better for performance? In our other plugins we just include the Font Awesome file in the way you suggested, as we use more icons in those plugins, but in this plugin we decided to do it this way as we only use a few of the icons.

    Would a better approach be for us to check first whether Font Awesome is included and if it’s not then to just add the font CSS to the head element in style tags? That would then allow the fonts to be loaded immediately and the text to be rendered more quickly than either of the other methods. I’d be interested to hear your thoughts on this though.

    Again, we really appreciate the feedback as it helps us to further improve the plugin.

    Hope you’re having a good day!



    I also have major performance / page load time issues due to your Plugin.

    Everything mentioned by the first comment is true.

    A pagespeedtest for shows only 28 points due to the issues.

    An option to remove all the css and especially the external fonts is required.

    Until then we will also remove the Plugin due to the huge impact on page rendering due to poor coding from this Plugin.

    The Plugin in general is providing great benefits but the price on user experience is currently too high.

    Plugin Author smashballoon


    Hi @svensonsan,

    We don’t use this plugin on our website. We have the Pro version installed on there which doesn’t load fonts in this way. As I mentioned previously, the reason the fonts are loaded this way in the free versions is that we only use a few icons from the font file and so didn’t want to load the entire library of icons. We did a performance audit on the free version and it was rated 100, nonetheless, we will be addressing the font loading in an upcoming update.

    Thanks for the feedback!


Viewing 5 replies - 1 through 5 (of 5 total)
  • The topic ‘CRITICAL: POOR PAGE PERFORMANCE ON ALL PAGES USING PLUGIN!’ is closed to new replies.